VbzCart/pieces/catalog/building/2016/rules

Matching

• If LCTitle has no Items, then we look across all Titles for matching CatNums. If any are found, this is a situation to resolve before proceeding.
• If LCTitle has Items, then for each proposed item we try to find matches in this order:

  a) Look for any items across all Titles whose CatNum matches the calculated CatNum of the proposed item

  b) Look for any items within this Title whose CatSfx matches the calculated CatSfx for the proposed item

Activations

• Each activated item from a regular catalog should be marked isForSale, inPrint, and isCurrent.
• Each activated item from a closeout catalog should be marked isForSale, out-of-print, isCurrent.

Deactivations

• Any Supplier for which no activations are generated should have all of its items marked not-current (isCurrent = FALSE) and isForSale should be TRUE only if there is stock.
  • The isInPrint flag should be disregarded when isCurrent is FALSE.
  • FUTURE: In order to ensure that gone items are considered not-for-sale as soon as stock runs out, perhaps isForSale should be eliminated, and IsForSale() should be ({item.qty_in_stk > 0} OR {Title.WhenDiscont > NOW or IS NULL}). (Title.WhenDiscont could be cached to minimize db lookups.)
• Any Supplier for which some activations are generated should have all *other* items marked isCurrent, not-in-print; isForSale as above.

Fields to Set

• (rules) → LCItem: isForSale, isInPrint, isCloseOut, isCurrent (as above)
• SCGroup → LCItem: GrpCode, GrpSort, GrpDescr
• SCTitle → LCTitle: WhenDiscont

Field Revision Thought Process

Originally, there was item.isActive, which was set by the build process to be TRUE if the item was either in a current catalog or in stock.

This meant that non-catalog items with stock could potentially be shown as available for some time after the stock ran out (i.e. until the next catalog build) -- so I considered ways to separate the "is available" from the "is in stock", so that each item's stock status would be checked dynamically while also allowing "available" items to be shown.

The first thing I came across was LCTitle.DateUnavail, which seemed like it was meant for this purpose. The problem with that (aside from complicating some calculations because now we have to look up the LCTitle record for each LCItem to find out which ones should be shown) is that an LCTitle may include multiple SCGroups (e.g. both shortsleeve and longsleeve shirts), with different availability (e.g. longsleeves might be discontinued while shortsleeves are still available). So really, title.DateUnavail is kind of useless, and should probably be eliminated or moved to LCItems.

My current thinking is that it doesn't really make sense to have this as a date. Any time-related record of an item's availability is probably best kept in terms of SCSources. If it turns out that there are reasons why we do want to maintain such information elsewhere, then that case can be documented when it occurs.

So we're down to this: a flag (not a timestamp), in LCItems (not LCTitles): we replace isForSale with isAvail, where the Item.IsForSale() function is (isAvail or (QtyInStock()>0)).

It also looks like time to replace the LCItem.QtyIn_Stk field with dynamic calculations from what's actually in stock, which we've already partly done.