# Purchase Orders
Purchase orders are sent from Sherwin Williams as an EDI 850 document.
# Schedule
A cron job is set up to run every 15 minutes from 4am to 5pm Pacific. This can be found in a VOC entry for SW.EDI. To disable, just comment out the [PL SW.EDI]
C [PL SW.EDI]
This runs as a phantom and saves any output into the PHL file.
SW.EDI first runs SW.EDI.ORDERS to check for and save any new orders. Then it runs REMOTE.ORDERS to convert any saved orders into pending orders.
# Checking for Orders
SW.EDI.ORDERS hits the Infocon Outbound With Date endpoint to see if there are any orders that have not yet been received. It is always only checking the current day as the date range. The way it can tell if it has already received a PO is that it stores the PO's in a file called SW.EDI.STATUS.
# Determining the Customer
Sherwin Williams has a lot of stores that it can order from. Each of these stores is setup as an account in the CR file. All Sherwin Williams accounts have the same bill to account number of 91000982.
The SNID field is the store number that is used to determine the correct account. The SNID is 6 digits but Momentum only uses the last 4. A search is made on all Sherwin Williams accounts that matches the store number at the end of the Ship-to Name field (CR<17>). The ship city and ship state must also match the SNCity and SNState fields.
If there is no CR record that matches these criteria, then an error email is sent to the SW.SVC.ADMIN email group. The process is then halted.
An EDI.CR record is also required for each Sherwin Williams account. If none exist for the found account, then an error email will be sent and the process halted.
# Determining the product
For each line item, it tries to figure out the momentum product. First it checks the customer part number cross reference (CUST.VP) based on the Sherwin Williams part number. If it can't find it in there, it uses TRANSLATE.CUST.PART.DESC to try to figure out what momentum part number it is based on Sherwin Williams' description.
DICT.BP TRANSLATE.CUST.PART.DESC is really just a formatting wrapper for DICT.BP FIND.PRODUCT.
If that is successful in finding a match, then it creates records in both the customer part number cross reference and the customer product cross reference (CUST.PM) if they don't already exist.
If it still can't find the correct Momentum product, it will still carry on. It will later handle this when it is ran in the remote orders processing.
# Saving to FTP_IN
The header and detail lines are read from the JSON and put into a delimited text file inside FTP_IN. This file will be picked up by the REMOTE.ORDERS processing later to be turned into a pending order.
For each line item, Sherwin Williams will reference an assigned ID (found in the AssignedID field in the JSON). This number is used to match line items later on in the acknowledgment and invoices and will be stored in the line item messages.
# Logging
A log record is created for each line of the PO. This is saved in SW.LOG with the key of the PO number and the detail line's assigned ID. The assigned ID is a special number that is given to each line by Sherwin Williams.
A log of the actual JSON will be stored in the SW.EDI.IN file with a key of the po.json as well as a multi-valued version using LOG.JSON with a key of po.mv. These are stored with the headings and values in fields 1 and 2.
Because we need to store a lot more fields for sending back the acknowledgments and invoices, we use the same SW.EDI.IN po.mv record. For some reason, Sherwin Williams needs to receive all of these fields back (according to Infocon). So we store these "default values" here starting with field 3.
# Errors
Along with sending an email to the SW.SVC.ADMIN group, errors are logged in SW.ERR with the time, date and PO.
# Remote Orders
This process is ran right after SW.EDI.ORDERS saves the data to FTP_IN. This process was already in place to handle other EDI customers. It was modified for Sherwin Williams in order to handle orders that needed to be split by warehouse.
It starts with PGMWB0019 but uses other processes along the way.
It was also modified to handle EDI.CR instead of using the Web Profiles. If an EDI.CR exists for the customer it uses that data. Otherwise it will use the web profiles data.
It will also halt processing if it can't find the correct Momentum part number. It then sends an email to the the email group listed in the EDI.CR record. This is typically SW.CUST.SERV.
Once it has completed making the pended orders (depending on if it needed to split it by warehouse), it will send a notification email. This is to the email group listed in the EDI.CR record. This is typically SW.CUST.SERV.