Information Systems:POS catalog - Revision history

Norwinu at 00:44, 30 April 2021

2021-04-30T00:44:10Z

Norwinu at 21:03, 7 June 2018

2018-06-07T21:03:18Z

Norwinu: /* Issues */

2018-06-05T17:41:03Z

Issues

Norwinu: /* Issues */

2018-06-05T17:32:46Z

Issues

Norwinu at 17:28, 5 June 2018

2018-06-05T17:28:02Z

Norwinu at 17:27, 5 June 2018

2018-06-05T17:27:04Z

Norwinu: Created page with "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 p..."

2018-06-05T17:24:54Z

Created page with "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 p..."

New page

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 two items exist in the catalog, with the latter one (the one with the higher item number) being discontinued, and the former one being "re-activated". There are actually increasing instances of this that have been observed.

[[Category: ECU]]
[[Category: POS Ordering]]

@@ Line 1: / Line 1: @@
-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.
+POS systems import and use catalog files generated by uniPHARM. Catalogs are generated by ECU every Thursday and files are placed on the mail server. There used to be processes in place to email catalog files to various recipients (e.g. Ron Little) for further transformation and comptability with other systems, but now the catalogs are simply made available for retrieval via FTP. The exception is ARI WinRx, where there is a separate process to clean up the main catalog and transmit the cleaned up file directly to ARI's FTP server, where WinRx installations are configured to pull from.
 ==Kroll==
@@ Line 9: / Line 9: @@
 ==ARI WinRx==
 * 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").

@@ Line 15: / Line 15: @@
 * 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===

@@ Line 17: / Line 17: @@
 ===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:
+* 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 of the full catalog:
 :* Iterate through the list, if DIN match is found, update fields for the item.
-:* If another match is found later, overwrite last update.
+:* If another match is found later, overwrite last update. And so forth.
 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.

@@ Line 21: / Line 21: @@
 :* If another match is found later, overwrite last update.
-Obviously, this poses a problem if two items exist in the catalog, with the latter one (the one with the higher item number) being discontinued, and the former one being "re-activated". There are actually increasing instances of this that have been observed.
+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.
 [[Category: ECU]]

@@ Line 23: / Line 23: @@
 Obviously, this poses a problem if two items exist in the catalog, with the latter one (the one with the higher item number) being discontinued, and the former one being "re-activated". There are actually increasing instances of this that have been observed.
-[[Category: Unity Extensions - ECU]]
+[[Category: ECU]]
-[[Category: POS Ordering]]
+[[Category: Ordering]]