This content has been marked as final. Show 2 replies
Sarah, you bring up a good issue and thanks for moving your discussion to the community forum.
Here's a few recommendations:
1. Do not use browsing tree: Shopping page only shows the first level BROWSING
(aka navigation) categories. To avoid using the browsing tree, create item
categories (aka genus) only and do not link them to any parent (browsing)
category. In this case, no browsing tree will show on the shopping page.
2. Use multiple first level parent categories based on simple rules: I know that
some exchanges categorize item categories by the item category names' starting
alphabet. Limitation to this solution is it only work in one language (not
working in Chinese).
Development is actively looking into the enhancement of support previous/next page in the browsing category page. However, we don't know if it will be built. Also, OEX.com
has acquired a hierarchy from Requisite.
From an oex.com perspective, Requisite created a browsing structure for us. It's
really the UNSPSC hierarchy. It sounds better than what Belgacom is currently
dealing with but does have problems that we have yet to resolve. The biggest one
in outlined below.
1) Browsing and genus level category names cannot be the same and they are in
some cases. To get around this we attached the unspsc number to each browsing
category, but this number displays, without any indication to what it represents,
to customers browsing our catalogs.
Perhaps Worldcrest group can add their Requisite experience here. Are there others out there that can share their solutions?
Oracle Exchange Developmen
Our solution to this problem may not be necessary once the Requisite eMerge 3.0 is released. That will allow the transfer of the Table of Contents.
We now create a separate XML hierarchy file that provides browsing level categories. This allows us to create three levels.