[TYPO3-mvc] Kicking off Hype Store on the Forge

[Thomas "Thasmo" Deinhamer]

Hi Franz, thanks for your feedback!

Product variants haven't been implemented as our agency needed a simple
form of maintaining products for our customer, so we decided to only
implement a simple system for the products. If someone has the need to
sell product variants, he's forced to create a new, seperate product.

At least that's what it is for now - the use of articles,
is imho, of course, a very nice and useful feature.

As for the pricing, I haven't thought of a real use, our project
has no need for special pricing cases, based on customer groups etc.,
even scaled prices were no real requirement, but I decided to implement
it in this basic way, as it's not that lot of work.

Additionally I thought of implementing a feature to define discounts,
based on specific customer groups or single customers, but as this is
my first shop, I haven't had a head yet, for planning all this stuff.

I think, if you have just basic products, with a simple price per unit,
and you decide to use a complex web-shop, like commerce etc., you're in
a real need of using a user-friendly backend module, which handles the
creation of default articles and all dependencies, if you don't want to
define 10 different things, just for a simple product with a price.

Your thoughts about product and pricing structures inspired me and I
think of maybe implementing a better pricing system. For articles
I'm not sure, but the topic itself, the implementation, could be quite
interesting, but also time-consuming.

So, thanks a lot for your time spent on having a look in the code,
and your ideas and thoughts about it, I really appreciate it!

Thank you,
Thomas


Am 06.02.2010 13:47, schrieb Franz Koch:
> Hi Thomas,
>
>> Thanks for your attention! It would be really great if some of you
>> are interested in testing this and giving some feedback. =o)
>
> Thanks for sharing. I only had a look at a few bits of code yet, but I
> noticed that you might run into trouble with your current pricing
> situation. I think you need to abstract the prices better in order to
> have the possibility to get custom prices based on fe_groups/fe_users etc.
>
> You might also think about product variants, where each variant has it's
> own article number/identifier but still has to be listed as one single
> product in the overview. In my ongoing project I did it like this:
>
> product
> -> articles
> -> prices
> -> priceValues
>
>
> Product:
> - a product can have multiple articles/variants
> - a product doesn't know about any stock, ean number, identifier or
> whatever - it's merely a container for articles providing common data
> shared by all articles
>
> Article:
> - a article is the unit that's getting sold
> - it knows about stock, ean, identifier, package units, attributes,...
> - a article can have multiple price objects assigned, but only one is
> displayed (depending on it's criteria)
>
> Price:
> - a price object is merely a container for price values
> - it knows about the criterias it applys for (usergroup, country,...)
> - it also has information about the price state (gross/net) etc.
> - it can have multiple priceValues also used for scaled pricing
>
> PriceValue:
> - it basically only stores the quantity it applies for and the
> price/value itself
>
>
>
> And to make it even more complex, products can themselfs also act as
> product groups/sets (different product types) where they don't relate to
> articles, but other products. Example:
>
> Audi A4 (Product Group)
> - Audi A4 Convertible (Product)
> - with diesel engine (Article)
> - with gasoline engine (Article)
> - Audi A4 Estate (Product)
> - with diesel engine (Article)
> - with gasoline engine (Article)
>
> Ok, car's might not be the best example as they are much more complex to
> configure then in the example, but you might get the idea.
>
> Hope that helps a bit.
>