Information Systems:POS catalog

POS systems import and use catalog files generated by uniPHARM. ECU is the Unity extension that generates full and weekly/change catalog files every Thursday. This page is a placeholder to elaborate on the topic of POS catalogs, and the issues/observations that are idiosyncratic to each POS software's use of the uniPHARM catalog.

Kroll

• KrollRx uses both the full and weekly change files.
• The process for new installations is usually for the agent to request the full catalog via email for loading (even though it's available via FTP), and then set up Kroll to point to the weekly changes folder so that the catalog can be updated automatically upon the presence of new files.
• Because the weekly folder contains many change files, it is unknown how Kroll tracks them and processes only the most recent one. They are consistently named, with the date in the filename, so that may be what the software is reading.
• It is unknown whether Kroll acknowledges the A/C/D in the change files, but the fact that the software only auto-updates from the weekly change files (much smaller subset), means less issues are encountered.
• (April, 2018) With regards to the previous point, it is possible that the A/C/D is not being acknowledged, because an issue came up where a Kroll user (with an updated catalog) had a stale item record which was flagged with a "D" several years before. This seems to suggest that Kroll merely does a match-replace rather than use the A/C/D flag to act on the item.

ARI WinRx

• ARI uses only the full catalog file.
• They retrieve the full catalog via FTP, manually and on their own schedule. It used to be emailed to Ron Little (who would do the transformation as a courtesy for all WinRx users) until 2016, but this was stopped at their request since they were pulling it via FTP anyway.
• They transform the catalog to make it readable in WinRx. Some steps include - converting to CSV from fixed-format, removing leading character (e.g. "A").
• The full catalog is meant as a full replacement, or for initialization of new POS installations. Thus, all records are "A"/add only. The weekly change files have the A/C/D, which ARI does not currently process.
• Once the catalog is transformed, it is made available to WinRX installations via their own means (likely through FTP) so that users can update their catalog.
• Items are cross-referenced via DIN to another internal item database, so only items with a DIN match are updated.

Issues

• Because the software is not aware of the weekly changes and/or the A/C/D flag, item updates are done on an iterative and last-match basis:

• Iterate through the list, if DIN match is found, update fields for the item.
• If another match is found later, overwrite last update.

Obviously, this poses a problem if an item exists twice in the catalog (e.g. Buying decides there are enough changes to an item that they want to recreate it as a new item number), with the latter one (the one with the higher item number) being later cancelled/discontinued, and the former one being "re-activated". There are actually increasing instances of this that have been observed.