A number of factors need to be thought through when automating the ordering and invoicing processes, relating to the trading units used, and the prices charged.
Product Codes
Most of your customers should use your EAN code numbers, not your internal stock code, when ordering products. Some may use their own product codes. This is largely catered for within the XML system, by building a table of EAN and other codes that link these codes to your product codes.
Some customers, although using the supplier’s EAN code in the order, also include their own item codes, and require that this is included in XML invoice lines returned. In such cases you need to include a data item in the order detail file to hold this code and to set a suitable parameter to ensure it gets returned in the XML invoice file.
Trading Units
Trading partners will order products in trading units, which are rarely the same as the units sold to the final consumer. For example, a food retailer may purchase (say) a bottled soft drink product by the case from the supplier, the case containing (say) a dozen bottles. The retailer orders cases, and the EAN code used represents the case — the bottles will have a separate EAN code to be used by the retailer’s checkout bar-code scanners.
The supplier, selling only to wholesalers or retailers, may consider the case to be their stock-keeping unit. But the retailer’s system will want to know the number of consumer units per case, as this is often used within their invoice validation process.
Your stock system, therefore, must include a "pack size” data item, so that the correct unit of ordering quantity can be quoted in XML invoices. If you are not using the Datafile pack quantity data item for its normal purpose, then use that. If you add a new data item for this purpose, then the stock maintenance screen must include it as a data item, and the ProFiler application $XP amended to carry this item into the lookup files.
Packing Units
This is the number of trading units that may be packed in a carton or on a pallet, and is nothing to do with consumer units. There may be a need to check that the quantity ordered is a multiple of the packing unit and revised upward or downward as a result. This would require a pre-processing step to be written between deconstructing the XML order files and updating the data into the SOP system.
Product Pricing and Discount Matrix
Some customers include the price at which they are ordering your product in the orders; others do not. As part of a pre-processing step you may decide to check that the customer is not ordering at a price that is less than you have agreed. This price check would need to use the discount matrix as part of its process.
When orders are updated into the SOP system, however, it is the discount matrix price that is used, if present, not that quoted by the customer. Should you want to transfer the customer’s price as an item for display or other purposes within the SOP system, you must amend the SOP detail file to include a data item to hold it, and change the update procedure to transfer it.
Article ID: 1845 Created On: Tue, Jul 10, 2012 at 11:31 AM Last Updated On: Thu, Jun 22, 2023 at 4:47 PM