Difference between revisions of "VbzCart/pieces/catalog/building/2017"

from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
< VbzCart‎ | pieces‎ | catalog‎ | building
Jump to navigation Jump to search
(a bit of tidying; still working on this)
(→‎Process: stage 0)
 
(One intermediate revision by the same 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''':
+
* '''isCurrent''': (needs rethink)
* '''isCurrent''':
 
 
* '''Supp_LastUpdate''':  {{l/vc/table|ctg_sources|SCSource}}.LastUpdate
 
* '''Supp_LastUpdate''':  {{l/vc/table|ctg_sources|SCSource}}.LastUpdate
 
* '''Supp_CatDate''': {{l/vc/table|ctg_sources|SCSource}}.DateAvail
 
* '''Supp_CatDate''': {{l/vc/table|ctg_sources|SCSource}}.DateAvail
Line 39: Line 38:
 
* '''isCloseOut''': unchanged
 
* '''isCloseOut''': unchanged
 
* '''isInPrint''': FALSE
 
* '''isInPrint''': FALSE
* '''isCurrent''':
+
* '''isCurrent''': (needs rethink)
 
* '''GrpCode, GrpSort, GrpDescr''': unchanged
 
* '''GrpCode, GrpSort, GrpDescr''': unchanged
  
Line 45: Line 44:
  
 
==Future Notes==
 
==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.
 
* Possibly there needs to be a "gone?" flag in SCSources, to make it possible to immediately discontinue a list of LCItems.
* 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?
+
* 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 08:56, 2 July 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 (cat_items) 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:

  • ctg_sources (SCSources) - a catalog listing items that are currently available from a SUpplier
  • 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)
  • ctg_titles (SCTitles) - specifies that a particular SCSource says a particular LCTItle is available in a particular SCGroup
  • ctg_items (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 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. 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 LCItem as follows.

For each approved change:

  • isAvail: TRUE
  • isInPrint: NOT LCSources.isCloseOut
  • isCurrent: (needs rethink)
  • Supp_LastUpdate: SCSource.LastUpdate
  • Supp_CatDate: SCSource.DateAvail
  • GrpCode, GrpSort, GrpDescr: SCGroup.*

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