Ahh...the old problem of having many SKUs for one item. Yes, this is tricky
one. First, I'll tell you how I dealt with it in a real project.
One project I worked on with FreeTrade sold shoes of different sizes. The
SKU for a pair of shoes was the same except for the last three digits for
the size. You you might have SHOE006, SHOE007, ... This retailer used a
big fulfillment house that provided a rigid, text-based interface. Twice a
day, a script gathered orders and sent them to the fulfillment house via
FTP. When a shoe (or anything else with a variation) was part of an order,
the upload script would assemble the correct SKU according to the
fulfillment house file specification. There was some logic to it: if an
item had both a color and size, the color code went first, for example. We
did it this way because communication with the fulfillment house was poor.
And it just kind of happened. :)
In an ideal situation, where you have perfect information and the time to
plan, you could build in functionality to handle all these variations. If
your SKUs do follow a pattern, you could put a column in the variation table
that holds the SKU suffix, and then use the DisplayPrecedence to add them in
order...but that's kind of messy. And it doesn't sound like it works for
you, Jeremy.
The database structure can deal with 2000 SKUs for an item. The UI cannot.
Somehow, the UI has to bundle up the SKUs into one line with pull-downs. It
is possible, but tricky. My first inclination is to put a flag on the item
for whether SKUs should be bundled this way. If this flag is set, the item
screen should get the set of variations and put pulldowns. When the
customer puts the SKU in the basket, the ADD_BASKET action would search
through the SKUs to find a matching record. What I don't like about this
solution, though, is that you might have gaps (red pants never come in
odd-numbered waist sizes), and the customer doesn't know this until after
trying to buy it. Microsoft SiteServer has this problem.
So, here are two other solutions. First, how about asking the customer for
their size before they start shopping? That narrows the number of SKUs you
need to show. Or, you could have JavaScript to implement all the checking
for valid color/size combinations.
Any of these solutions is heavy-duty, so I don't expect anyone to code it.
Let me think about it, and maybe I'll work something into FT2.
Leon
_______________________________________________
FreeTrade-dev mailing list
[EMAIL PROTECTED]
http://share.whichever.com/mailman/listinfo/freetrade-dev
