39 lines
1.8 KiB
Plaintext
39 lines
1.8 KiB
Plaintext
Goal:
|
|
Take shipping files from Source and turn them into X3 Sales Orders via ZSHPORD
|
|
Use same files and turn them into X3 Deliveries for the above orders via ZSHIP945S
|
|
|
|
Problems:
|
|
Source does not send accurate unit price, shipping charge, tax, and discounts. To
|
|
bring something accurate in we use the old Shopify integration. This brings up
|
|
another issue that the old integration brings in orders at creation, if these fields
|
|
get modifed (like from a refund) we are brining in the wrong amount.
|
|
|
|
Questions:
|
|
How does Source handle multiple lots on a line?
|
|
|
|
---------------------------------------------------------------------------------------
|
|
|
|
General process flow
|
|
-read in file(s) from Source ecomm FTP and archive file on FTP
|
|
-load shipment information into SQL table to report on, pass file to order creation process
|
|
-create ZSHPORD import from file, pass file to shipment process, ask X3 to process import
|
|
-create ZSHIP945S import from file, archive, ask X3 to process import
|
|
|
|
Recurring tasks in X3 have been set up named ZECMSL and ZECMSLSHIP.
|
|
|
|
--------------------------------------------------------------------------------------
|
|
Reporting on eCommerce:
|
|
To catch issues we need to look at:
|
|
-possible sales order duplicates that have the same Shopify PO number
|
|
-missing sales orders, that came into the shipping table, but failed to import in
|
|
-missing deliveries, that failed during import, e.g. not enough stock
|
|
|
|
To find these use the sql files in "daily sql reports"
|
|
|
|
----------------------------------------------------------------------------------------
|
|
Reimporting:
|
|
The open orders report finds eCommerce orders that should have shipped. This is typically
|
|
a problem because of stock shortages that we need to disassemble cases for. The
|
|
'source_ecommerce_reimport_from_archive.py' script can help mass reimport the
|
|
missing shipments
|