VbzCart/docs/pieces/catalog/building/2017: Difference between revisions

From Woozle Writes Code
< VbzCart‎ | docs‎ | pieces‎ | catalog‎ | building
Jump to navigation Jump to search
imported>Woozle
(battery low, saving edits)
m (Woozle moved page VbzCart/VbzCart/pieces/catalog/building/2017 to VbzCart/docs/pieces/catalog/building/2017 without leaving a redirect: correct naming (was no way to import directly to this name))
 
(4 intermediate revisions by one other user not shown)
Line 5: Line 5:
==Tables==
==Tables==
Input:
Input:
* {{l/vbzcart/table|ctg_items}} (LCItems)
* {{l/vbzcart/table|ctg_sources}} (SCSources) - a catalog listing items that are currently available from a SUpplier
* {{l/vbzcart/table|ctg_sources}} (SCSources)
* {{l/vbzcart/table|ctg_groups}} (SCGroups) - a sort of "availability pattern": a set of options (e.g. sizes) commonly available for a particular itemtype (e.g. longsleeve t-shirt)
* {{l/vbzcart/table|ctg_groups}} (SCGroups)
* {{l/vbzcart/table|ctg_titles}} (SCTitles) - specifies that a particular SCSource says a particular LCTItle is available in a particular SCGroup
* {{l/vbzcart/table|ctg_titles}} (SCTitles)
* {{l/vbzcart/table|ctg_items}} (SCItems) - specifies which option-itemtype combinations are available in a particular SCGroup


Output:
Output:
* {{l/vbzcart/table|cat_items}}
* {{l/vbzcart/table|cat_items}} (LCItems)
==Process==
==Process==
===stage 0===
Admins must manually create any new LC Titles.
===stage 1===
===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 {{l/vbzcart/table|cat_items}} 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.
'''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 {{l/vbzcart/table|cat_items}} 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.
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.
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.
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.
(documentation in progress)
===stage 2===
===stage 2===
Update {{l/vc/table|cat_items|LCItem}} as follows.
Update {{l/vc/table|cat_items|LCItem}} as follows.
Line 28: Line 28:
For each approved change:
For each approved change:
* '''isAvail''': TRUE
* '''isAvail''': TRUE
* '''isCloseOut''': LCSources.isCloseOut
* '''isInPrint''': NOT LCSources.isCloseOut
* '''isInPrint''': NOT
* '''isCurrent''': (needs rethink)
* '''isCurrent''':
* '''Supp_LastUpdate''': {{l/vc/table|ctg_sources|SCSource}}.LastUpdate
* '''Supp_CatDate''': {{l/vc/table|ctg_sources|SCSource}}.DateAvail
* '''GrpCode, GrpSort, GrpDescr''': {{l/vc/table|ctg_groups|SCGroup}}.*
* '''GrpCode, GrpSort, GrpDescr''': {{l/vc/table|ctg_groups|SCGroup}}.*


Line 37: Line 38:
* '''isCloseOut''': unchanged
* '''isCloseOut''': unchanged
* '''isInPrint''': FALSE
* '''isInPrint''': FALSE
* '''isCurrent''':
* '''isCurrent''': (needs rethink)
* '''GrpCode, GrpSort, GrpDescr''': unchanged
* '''GrpCode, GrpSort, GrpDescr''': unchanged
''documentation still in progress''
==Future Notes==
==Future Notes==
Possibly there needs to be a "gone?" flag in SCSources, to make it possible to immediately discontinue a list of LCItems.
* 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.
Still writing...
* 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).

Latest revision as of 01:53, 25 February 2024

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:

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:

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).