General Assortments and specific assortments

[Former Member]

Would there be an issue if I created a general assortment containing all the items the business sells and another assortment of just the items that will be distributed to a specific site or site group? The business needs to be able to process returns, transfers, selling, etc of all items in the business regardless of where or how a customer bought the item. Each site does not carry all items at all times, the 2nd assortment would be what is actually displayed at a site.

This question is also related to a question I previously posted about assortment defining allocations.

If there is a better way to go about this, please let me know. Im stumbling in an area outside of my expertise.

Thanks

Edited by: nkokinos on Jul 28, 2011 12:37 AM

[paul_gendreau]

You may be confusing the issue by trying to think of one piece that solves all cases, when there are multiple pieces to consider

I'm not clear on the requirement that's driving your desire for two assortment (one seems to be a global list and the other the "real" assortment for the store).

Is this for inbound (i.e. the return of an article, POS inbound) will require the article to be listed to the site. Or is this for outbound (POS system requires information of all articles), in which case you have more problems to consider (pricing, among them).

For the case of enabling returns, please review the concept of Subsequent Listing for Articles. This is a setting on the site master and will enable on-demand listing of an article to enable the returns process.

The assortment execution approach has a great deal to do with the level of granularity that the business will require for managing assortment differences across stores. In the case that the assortment varies greatly, and for greatest flexability, consider the use of layout modules with general assortments rather than using general assortments and assortment grades.

[Former Member]

Thanks for the response! Its given me plenty to think about and discuss with my team.

What we need is a way to list every single SKU at every store without actually generating a listing condition for every SKU/Store combination. Having listing conditions at every SKU/Store level is a massive amount of data for our 50000+ SKUs and 100+ stores. It was my understanding that an assortment creates listing conditions related to it so by linking stores to the assortment that they can use those listing conditions without having to have a listing condition at the store level.

We need to be able to accept returns and also sell it if need be. Stores can decide to keep an item that they arent assorted for and sell it, instead of shipping it back to a DC. And with the Subsequent Listings, we would be running into data volume issues again because of our return/exchange policy.

As for the assortment approach, I was planning on developing assortment modules to use. Defining them along various criteria, and user specifications.

[paul_gendreau]

You wrote: "What we need is a way to list every single SKU at every store without actually generating a listing condition for every SKU/Store combination."

Yes, but why do you think that you need this? What will this be used for? In particular, what is the output that will be driven by this? This sounds more like a requirement for a report or outbound interface based on all articles rather than a requirement for listing conditions.

There are several ways to appoach execution of assortment management, but the result of all approaches is the same: listing conditions. A listing condition, as you know, answers the question: Is a given Article authorized for business processes at a given site on a given day (usually today).

So you need to consider ... why am I managng assortments? In other words, what business processes do you expect to control by answering the question as to whether an article is listed to a site? Typically listing conditions are used to restrict activity. For exmple ...

-- restrict the amount of data sent to POS Outbound (i.e. only send article/price records for listed articles)

-- restrict purchasing activities (e.g. only allow purchase of a listed article for a given site)

-- restrict goods movements (e.g. only allow moving a listed article from a DC to a Store)

Also consider ... How much will my assortment vary across sites? Choosing an assortment management approach requires an answer to this question. The effort required to manage can be very little (general assortments and assortment grades, for example), or can be great (general assortments and layout modules, for example), but in either case requires a great deal of thought and planning both for implementation and ongoing execution in production.