Datafile Home \| KB Home \| Advanced Search

Application Considerations - Other Considerations

Article Number: 1849 | Rating: Unrated | Last Updated: Thu, Jun 22, 2023 at 4:46 PM

Datafile Software

Application Considerations - Other Considerations

Product Codes

The stock codes used in your system will not normally be the product codes used by your suppliers. There are a number of alternative ways to determining the product code used:

If the product is specific to a supplier (there are no alternative suppliers) then the issue is relatively simple. The supplier’s product code can be stored in a suitable field in your stock system.

The only issue here is whether or not the supplier’s code is a 13-digit EAN code, or their own non-EAN product code. This only matters where the XML schema requires that the use of EAN codes is to be specifically tagged. A simple solution is to have two data items in the stock file for the supplier code in such circumstances: an EAN data item and a non-EAN data item.

The product can be purchased from several different suppliers. When ordering from distributors, it may be that there is a common EAN or product code used by all suppliers, in which case the solution is as above.

The product can be purchased from several suppliers, but they all have their own code for the product. In this case there are two further alternatives:

• Use the supplier price matrix "item 13” to hold the product code used by each individual supplier. This can be copied into the POD database (Database Profiles PO Detail Optional 4) to be used in the output XML files

• If only a few suppliers supply the product, then maybe the use of the Alternate/Cross Stock data items in the stock file can be utilised. This requires a more complex set of statements in the XML Datafile template in order to pick up the correct product code, and all the possible alternative stock codes to be copied into separate data items in the purchase order detail file.

It may well be necessary to set parameters for each supplier to indicate which product code strategy is to be used.

Order Types and Other Codes

It is not unusual for suppliers to require that certain codes are included in an order to indicate how to treat the order. How to supply these codes must be thought through. One way is to enter an order type in the POH file, using a lookup file to validate it. The lookup code might be an item that combines a supplier code with an order type, which makes for a unique code. It is then a relatively simple process to create the possible supplier/ordertype codes in the lookup file, giving the specific code required by the supplier.

For the BOSSFed system, a 4-digit code is combined with the order type as the lookup item, and the actual order type is held in a separate data item. Some of these order types require that a customer delivery address is supplied too, so a Y/N item in the lookup file is copied to the POH file to trigger a pop-up screen that forces this to occur.

Database Items

The database items given in the XML template must match the data items in your actual company data. Listed in the appendices are the additional data items added to the various application databases and used by the XML templates distributed. You should check the structure of your own databases against the base files that are distributed with the XML module and held in the XMLPROF folder.

Delivery and Other Charges.

For an XML invoice or credit note document, not infrequently a delivery or other charge will appear. This is in addition to the item lines in the original order and so cannot be predefined in, and therefore matched to, that order. The Datafile XML template allows you to accumulate a value from any input XML document that cannot be matched against any original order line, and to save that value in the order header. This item needs to be the Additional Charge item, of course, in the purchase order header.

Other Additional Data Items

Extra data items may be required for specific supplier applications. For example, the supplier may send an order response that highlights those lines that cannot be delivered as scheduled (if at all), those lines for which a substitute product will be supplied, or where the delivery will be made from a different location to the standard. Extra data items will be required to satisfy this, and appropriate reports designed.

In the case of invoices and credit notes, the actual product invoiced, its price and the tax considerations may need to be captured and compared to what was expected. Again, some reports may need to be created to report such discrepancies.

Responses: Delivered or Back-Ordered?

Where next-day delivery is common, the response can chain to a delivery document to update stock and the purchase order as though delivery had already been made. However, different suppliers have different ways to tell you what is happening. Some give the quantity of goods they are going to deliver. Others tell you what is on back-order, and you can assume the rest is to be delivered.

To allow the automatic document link to work, rather than record all deliveries manually, items have to be created in the POD file to calculate the (to be) delivered quantity. Two flags (?–type items) can be defined in the PLA file and copied via the POH to the POD, where they are used in calculations to determine the quantity being delivered. One states that the quantity delivered is given specifically; the other says that the quantity is derived.

Custom Fields