Pseudo categories

[tms]

In KonaKart the categories are based on a parent/child relationship.

We are looking to create a category structure where we have multiple ways to get to the same category
in order to avoid having to create and maintain identical categories.

Example 1:
Common computer accessories include bags, power supplies and headphones (that belongs to Sound category in this case).
One possibility would be to use one of the custom fields in the categories common data to express relationship between one or more categories.

Computers
|--------- Accessories (custom1: 100)
           |-Bags
           |-Power-supply
       
Sound     
|-----------Headphones (ID: 100)

Example 2:
Another way might be to create pseudo category that inherits tag-groups and products from the specified category, in this example headphones.

Computers
|--------- Accessories
           |-Bags
           |-Power-supply
           |-Headphones(custom1: 100)
                |
                |
Sound     |
|-----------Headphones (ID: 100)

Is this something that you know that has been implemented by your customers ?
If so, you might have given them pointers, could you point us in the direction on where would be the best way to implement this (CategoryMgr ?)
also what class(es) we would need to keep in mind on the store-front side.

Last but not least, isn't this something that could qualify as a core feature in KonaKart ? We are actually quite surprised
that this is not a core feature already since this is pretty common scenario in online stores.

Best regards.
Bjarni

[julie]

In KonaKart each category only has one parent. What we've found is that customers who have the "same" category under a different parent often want the possibility for it to contain a different subset of products although some may overlap.

Therefore if you have a headphpones category under Sound and another under Computer Accessories you need two categories and since products can belong to multiple categories you decide which products go into each where some products may be in both.

[tms]

Hi Julie, thanks for the quick reply.

What you explained is something we are well aware of, that is why we posted this question.
This might work for small stores, however when we are talking about a store with 10.000+ products this kind of manual work is not feasible.

Could you take a look at the questions I have, we will be happy to explain our needs if this seems unclear.

Is this something that you know that has been implemented by your customers ?
If so, you might have given them pointers, could you point us in the direction on where would be the best way to implement this (CategoryMgr ?)
also what class(es) we would need to keep in mind on the store-front side.

Last but not least, isn't this something that could qualify as a core feature in KonaKart ? We are actually quite surprised
that this is not a core feature already since this is pretty common scenario in online stores.

[julie]

We have stores with 10.000+ products . In these cases the products are always imported automatically mainly using the APIs. Nobody (as far as I'm aware) does it manually.

[tms]

We are also importing the products automatically using the APIs, that is not the issue here.
We do not have a problem with importing products, what we are addressing is the lack of functionality in the back-end, after the products have been imported and an actual human takes over.

[julie]

I suppose it all depends why the human has to take over? If you can import all of the data you require, that shouldn't be needed.

[tms]

We cannot guarantee that complex category relations will be available from every system we are planning on integrating with in the future, even though SAP supports it some other might not.
In some cases we might only get the top level category (and products), no other relations, and some manual work might have to be carried out.

Even though the goal is to automate importing, we cannot rule out human interaction in the back-end.

[julie]

From my experience if you have 10.000+ products to maintain, then completely automating that process is very important. If you have to go and manually edit products after importing them,  the process becomes very error prone as well as expensive to maintain. Even if you aren't using SAP, surely you should be able to encode somewhere in the ERP product, the information you need in order import it without manual intervention?

I've run across cases where images need to be fetched from outside of the ERP and maybe even the description and / or documents and videos are held elsewhere, but I think it should be possible to add the category information somewhere within the ERP.   

[tms]

we think you may be misunderstanding.  We are all in agreement on that we want the process to be automated as much as possible.  Our request is on that nature.  What we need is the option of sharing one category or more categories (where it applies) coming from the ERP system, with another, but we would need to do so in KK. This is therefore only one off action in KK. 

Our first post explains this.  We have headphones (id.100) that can be used as accessories with mobile phones, laptops, tablets, desktops, speakers, CD players and more.  Its very difficult and cumbersome and error prone if we would need to do this manually, categorizing each and every headset in this way.  What we need is a way to share one category with other product categories so that the headsets in this one category can be viewed as accessories in other categories.

We all know that ERP have limitations and can be very difficult to configure in ways that suits the customer. KK should help us make the ERP system better, by allowing us to expand and elaborate the functionality already in the ERP.  ERP should be considered a host of basic information whereas KK is the presentation layer (enabler of technology and new features) where extra features are avaiable and all the magic happens 

[greg]

Can't you solve that by setting up relationships between your products... eg... product A is an accessory for product B?

Not sure why you want to use categories for this kind of relationship.

[julie]

The way I would do it is to create the category tree structure in KK where you have a headphone category under mobile phones, laptops, tablets, desktops etc. if that's the way you want to structure it. In each of these headphone categories you add in a custom field the category name as you have it in the ERP. In this way the importer can automatically assign any headphone to all of the KK headphone categories.

However this category sharing does seem to be a strange way of doing it since it doesn't really allow for exceptions as far as I can tell. This means that you'll be grouping a $500 super HiFi set of headphones with a $5 earpiece all under mobile phones, laptops, tablets, desktops etc.