VbzCart/docs/pieces/catalog/building/2017

Revision Notes

We now calculate stock availability in real-time, so we do not need to calculate that when building the catalog. What we do need is a per-Item (Template:L/vbzcart/table) flag to indicate whether the item is available from the Supplier or not, based on catalog status.

Apparently this change was done last year: we now have the isAvail flag.

Tables

Input:

• Template:L/vbzcart/table (SCSources) - a catalog listing items that are currently available from a SUpplier
• Template:L/vbzcart/table (SCGroups) - a sort of "availability pattern": a set of options (e.g. sizes) commonly available for a particular itemtype (e.g. longsleeve t-shirt)
• Template:L/vbzcart/table (SCTitles) - specifies that a particular SCSource says a particular LCTItle is available in a particular SCGroup
• Template:L/vbzcart/table (SCItems) - specifies which option-itemtype combinations are available in a particular SCGroup

Output:

• Template:L/vbzcart/table (LCItems)

Process

stage 0

Admins must manually create any new LC Titles.

stage 1

Action: Build a list (currently a recordset) of all supplier-items known to be available, based on combining active catalog(s). Match the list up against the Template:L/vbzcart/table table and build an action list containing each generated item: either new (to be added) or found (to be updated). Show links to matching items so user can verify the match, and allow the user to check off which actions to take.

Building the list itself is pretty straightforward, though admin review is necessary to make sure the matches are correct. It's basically LCSources x LCGroups x LCTitles

There isn't a rigorous way of matching this list up with our existing Items table because (of course) suppliers neither use our unique Item IDs nor do they supply their own. What they do have is catalog numbers, which tend to be persistently attached to a particular item -- but sometimes the item changes in ways that we want to keep track of (e.g. the shirt originally had lyrics over the basic design, but now it doesn't; or, the background color has changed) and sometimes a disused catalog number is reused for a new item.

So we use the catalog number as the basis for correlating the two lists, but it needs to be hand-checked. At present, we only check for title-string changes; ideally there should also be an image cross-check.

stage 2

Update Template:L/vc/table as follows.

For each approved change:

• isAvail: TRUE
• isInPrint: NOT LCSources.isCloseOut
• isCurrent: (needs rethink)
• Supp_LastUpdate: Template:L/vc/table.LastUpdate
• Supp_CatDate: Template:L/vc/table.DateAvail
• GrpCode, GrpSort, GrpDescr: Template:L/vc/table.*

For all remaining LCItems:

• isAvail: FALSE
• isCloseOut: unchanged
• isInPrint: FALSE
• isCurrent: (needs rethink)
• GrpCode, GrpSort, GrpDescr: unchanged

documentation still in progress

Future Notes

• LCItem.isCurrent needs to be re-examined.
• There should probably be a way to enter "orphan" catalog items that aren't really part of a repeated SCGroup.
• Should cat_items have a pointer to the catalog (source) which last updated it? Or, if that could be multiple catalogs, should there be a cross-reference table?
• Possibly there needs to be a "gone?" flag in SCSources, to make it possible to immediately discontinue a list of LCItems.
• We might want to have a LCItem.WhenExpires field later on, and that could receive the latest SCSource.DateExpires; for now, we just treat it as another flag to check based on the current date, i.e. if SCSource.DateExpires < NOW(), source should be considered inactive (same as SCSource.ID_Supercede = NOT NULL).