Datafile Home \| KB Home \| Advanced Search

Template Configuration Notes

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

Datafile Software

Template Configuration Notes

Below are some notes to help guide configuration processes according to the XML application transactions that are to be used. Note that these guidelines have been followed in the example XML templates and processes shipped with the XML module.

Import XML Sales Orders (SOP)

The use of EAN codes to identify customers, delivery locations and products is becoming almost universal, though some customers still use their own location and product codes. The entry point for such codes, however, is best made in your sales and stock ledgers.

You’ll need to use lookup files† to translate from such codes to your own internal codes, and you will need, therefore, some additional ProFiler options to maintain these lookup files by extraction from the sales and stock ledgers, with the ability for manual entry too.

Using these lookup files, you can import XML sales orders direct into the SOP system. However, you should probably chain to some ProFiler validation processes to highlight any exceptional conditions, such as a different price compared to the agreed price (which may mean accessing the discount matrix). The XML audit report will notify you of customers, locations and products not recognised on lookup, and so not updated into SOP. You’ll need manual procedures to handle these.

Create XML Acknowledgements and Delivery Notes (SOP)

This should be a straightforward XML option, needing only the use of selection criteria to check for when a document is required, and that one has not already been created. The XML template should mark, therefore, the orders that have already been sent by XML, and also add a file generation number in case there is a need to query the file(s) created by a particular XML process.

Create XML Sales Invoices & Credit Notes (S/L)

Because sales invoices and credit notes are so important to an organisation, it is suggested that a pre-XML invoice validation process is run against the sales ledger to check that sales invoices are fully ready to send via XML. Such a ProFiler validation report is supplied, marking invoices and credit notes ready to send, reporting errors otherwise.

Things to check can typically include whether or not proof-of-delivery details are present (many customers will not accept invoices that lack such details), that the appropriate EAN codes are present in the system, and that a customer order reference code is present. Invoices are normally batched by customer, so that one XML file could contain the details of any number of invoices.

It is possible that only invoices and credit notes that have been created via SOP can be sent as XML files, as there may be insufficient information from invoices entered directly into the sales ledger for the receiving customer to process them electronically.

The XML transaction that creates the XML invoices is then a straightforward run. Note that HMRC may require a VAT control report to list the details of all invoices sent electronically, customer by customer.

The invoicing run should tag the batch number against all invoices sent. If the customer rejects a batch due to some invalid data, then you may have to recreate the batch once you’ve made the correction(s). This batch number, often referred to as the File Generation Number, enables you to pick out, using a separate XML transaction, the batch of invoices that was initially rejected.

Create XML Purchase Orders (POP)

This should be a straightforward XML process, picking out orders to those customers that accept XML, probably checking a flag within the order header that has been copied from the supplier account. Some users may like a report listing those orders sent by XML.

† A single lookup file can be used for multiple purposes, by using flags (Boolean data items) to indicate which type of lookup an entry belongs. Such an approach conserves database usage in ProFiler applications. It is possible that the same code may appear in two different lists, although in practice this is rare, except for 1- or 2-character codes. You may have to allow more than one flag to be set.

The major issue here is the product code to be used in the purchase order. Where a supplier uses a universal EAN code, there is no problem. But if the same product can be supplied by a number of suppliers, and each of them has their own set of product codes, then the design of the POP system must take this into account so that you can access theappropriate supplier product code.

Import XML Purchase Order Acknowledgement (POP)

Although the Datafile purchase order document is intended as an output notification to the supplier, we do not use this option to create XML orders.

Some suppliers, however, may send an XML acknowledgement, usually called an order response, to indicate whether or not they can supply the product, and whether in part or in total, and so on. Some will use the delivery notification for this (see below) and you should read that description too. There is little difference between this and a delivery notification, the latter usually indicating delivery dates.

Import XML Delivery Notifications or Order Responses (POP)

Many suppliers will use a delivery notification (often called an order response) to indicate whether or not they can supply the product, and whether in part or in total. In some cases, they may even return a substitute product code for one or more lines if they cannot supply the items requested. You’ll need extra data items in the POP detail file to hold the data from these XML files.

Where suppliers offer same or next day delivery, the order response, which uses a purchase order delivery document as part of the process, can update stock with the quantities expected to be delivered immediately. Usually such responses indicate the expected delivery dates for any back-orders that result.

Following import, you may want to chain to a report that list any differences against the order. For example: a product may have been substituted, and the delivery notification contains a different product code; the price quoted in the delivery notification may differ from that quoted in your original order; some or all the quantity may have been back ordered, and/or is to be sent from a different depot; a delivery date may be noted.

Some suppliers may not only acknowledge your order, with amendments as stated, but may also send you a separate advice when goods are shipped. You’ll have to work this into your business process, and will require a different XML process for each.

Import XML Invoices Received (POP)

The big choice here is whether or not to process the XML purchase invoice file direct into the purchase ledger, updating order processing and stock on the way. In general you will want to do so.

A major consideration is the extent to which you can batch the process of XML invoices, or whether you have to process each one in real time against the original order. If there is any chance that a batch of invoices could contain more than one invoice that references the same order, then you must use real-time processing for this.

At some point in the processing cycle you may want to report exceptions against your original order. To achieve this you will need to create extra data items in the POD file to hold the actual price charged, and perhaps the actual product code quoted back at you, to compare against those that were in the original order. Such exception reports can be achieved using ProFiler.

Import XML Credit Notes Received (P/L)

Where credit notes can be matched to orders (even credit orders) then they could be processed via the purchase orders system, as for invoices. However, it is more normal for credit notes to be raised by the supplier essentially independent of the original purchase orders. In such cases these will have to be processed direct to the purchase ledger using the appropriate XML transaction. This will require additional data items in the purchase ledger transactions file.

Custom Fields