Information Systems:Electronic Sales Orders (POS Ordering)
Electronic Orders
Stores have POS (point of sales) computers that can generate orders, then either email or FTP them to us. It appears that these orders can be created as sales are made, or based on a predefined order point.
We don’t support these devices, but they have access to our FTP server.
For information on what the store has to do, see ‘POS file specs and examples / Order Invoice Interface Specs.pdf’. Also in this folder are sample files, and layouts.
History
Before the Unity project, uniPHARM supplied stores with a PC application called the EOB, or electronic order book. Each store had a three digit 'EOB number' to identify them, which was included in the order emailed to uniPHARM. When we converted the customer and supplier file into ASW, new customer numbers were assigned, and the EOB numbers were put into a cross reference file (IMPXRFP). Orders sent from stores' POS still use that same number.
We had problems every time we started receiving orders from a new POS - trying to explain why there had to be an account number that was different from the one used on invoices, statements, and Web Orders.
So the beginning of 2012, we changed the process to allow 5 digit EOB numbers, and put the ASW partner number into IMPXRF. Then at the beginning of 2016, we changed the process to look in SRONAM (ASW Partner File) if the number isn't in IMPXRF (EOB cross reference file).
They can be emailed to us, in X12, which will be processed by IMS, IMP, then IOP. The type of POS ('source') that sent the order is identified (in programs IMSNEP01 and IMPPAR01) by the subject. The 'source' is used to set the handler in ASW (in programs IOPASW01 and IOPRAW01), which is used to separate sales by the different POS types.
subject source handler X12 PO ARI EDI-ARI X12 PO ARI EDI-ARI INPHARM PO (POS#999999) TRI-POS EDI-TRIPOS INPHARM PO (RX#999999) TRI-RX EDI-TRIRX PT PO 999999 POSITEC EDI-POSITE
Where 999999 is the actual PO number.
For more on email orders, check this page.
FTP
KROLL EDI-KROLL
Note that this was originally used to receive orders from Prairie Supply Co-op, and was called ‘Alberta Integration’, so the name prefix is ‘AI’.
The user ID and passwords that stores have for our FTP server only allow them access to one folder - /FTPOrders/99999 (where 99999 is their partner number). Within that folder there can be two more; one for orders and one for invoices. If a store is sending orders from, or wants invoices sent to, more than one P.O.S. system, they can either have more sub folders under 99999, or they can have a new folder with an appended name; for example 99999K.
To see what has been setup, go to Unity / Start uniPharm Extensions / VA Company (PRODUCTION) / Work with UWD IT Tools / FTP Connections / Sales Orders FTP Configuration.
This calls DFU on file AIINTFP. This file is used to connect to the FTP server, search for order files, and upload them to the i. If a store is not setup in this file, we will not process their orders! The ‘FTP directory’ is what counts; the ‘Name’ and ‘Description’ are just to let us know which store it is. 'Customer # Type' is also a left over from Prairie Supply Co-op days; It indicates whether the customer number in the file is for PSC or UWD. 'Extensions' indicates the file layout, and tells program AIRUP020 which routine to use to translate them.
WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : AIINTFR File . . . . : AIINTFP
Name: Cust10702
Description: Tumbler Ridge Pharmacy
FTP Server: mail.unipharm.com
FTP User ID: ftporders
FTP Password: **********
FTP Directory: 10702/orders
FTP Archive Directory: archive
M=Move D=Delete N=None: M
Transmission Source: FTP
Customer # Type: UWD
Ext 1: KRO
Ext 2: ___
Ext 3: ___
After an order has been successfully moved from our FTP server to the i, it is moved to an ‘archive’ folder that has been setup within the ‘orders’ folder. Although it is optional, it is best to archive the file. If we delete it and there are problems, we won’t be able to figure out what happened. If we do nothing, we will pick up that order every time the interface is run.
Order files from different P.O.S. vendors can have different formats. We determine the format by the file extensions.
This is the job that does this. It is started by EOD, and runs all day, every day.
Work with Active Jobs BART
08/28/14 10:03:15
CPU %: 23.9 Elapsed time: 00:08:21 Active jobs: 573
Type options, press Enter.
2=Change 3=Hold 4=End 5=Work with 6=Release 7=Display message
8=Work with spooled files 13=Disconnect ...
Current
Opt Subsystem/Job User Type CPU % Function Status
MONITOR2 QSYS SBS .0 DEQW
FTP_ORDERS EODJOB BCH .6 PGM-AICUP010 SELW
Parameters or command
===>
The orders are formatted and added to the IOP files. To see what happens next, look at IOP - Inbound Order Processing.
Add New Source
Based on the source, set the handler (ie ‘EDI-TRIPOS’) in programs IOPASW01 (IOP -- Take an IOP order and create ASW EDi record), and IOPRAW01 (IOP -- Read an IMS order and create IOP records).
Add this handler to the Signature table in ASW. This should start with ‘EDI-‘ so that it will be recognized as an EDI order.