This topic has been superseded.

The workbench can recognise variation order numbers in an eInvoice XML message. The workbench will look for a / character in the <BuyersOrderNumber> tag and take the trailing number after it to be a variation order number. The EC parameter SWWBMEMO must be set to N and the PL parameter NONPOWBS set to Y,

The workbench can recognise small works order numbers (which end with a WBS code) in an eInvoice XML message. If the EC parameter SWWBMEMO is set to Y then the workbench will first break down the order number found in the <BuyersOrderNumber> tag in the XML according to the order number format and prefix set in the PO/PONUM1, PO/POORDPFX and PO/POPFXFST parameters.

Having decided what the order number should look like the workbench then looks for another / character. If one is found then the workbench assumes that any characters after this are a WBS code. For example, M-v7w/0001/001 will be parsed as order number M-v7w/0001 and WBS code 001. If the order number is found in the Coins ERP+ company, the "WBS code" value is stripped from the order number and placed at the front of the description field in the Details screen. The variation order processing explained above doesn't happen.

In the example below, the PO number format is set to Contract/Prefix/OrderNumber. The invoice comes in with an order number v7w/HM/0003/001. V7w/HM/0003 is a valid committed order so the workbench has removed the ending /001 and put it into the description.

You can set rules that will endeavour to auto-correct any typing errors the supplier may have made in the PO number. Set the parameter PL/FIXPONUM to Y and set the rules using Order Number Heuristics. Typical rules are shown below. The rules are processed in numerical sequence.

Here we replace any letter O (upper or lower case) in the first six characters or eleventh to fourteenth characters of the order number with the number 0 (zero). Use the wildcard character * to represent "any character"; the eighth character will always be replaced by the letter H. Use \ to "escape" special characters \ and *. The \ on line 90 stops the * character from acting as a wildcard; only if the 9th character is a * will it be replaced by M. If we find a \ as the seventh character we replace it with the / character.

When 3-way matching Purchase Orders to GRNs to Invoices, or 2-way matching POs to Invoices there are eight criteria that are vital in the auto-matching process:

Apart from the order number, any of these checks can be disabled (either for all invoices or for individual suppliers).

The 2-way match process is invoked if the accrual method for the contract when the order is created, possibly modified by the supplier's office, is Order or Neither, and if 2-way matching for electronic invoices is switched on. A 2-way match is attempted for every invoice when the Create Batch action is run.

A 3-way match can be attempted using eCommerce Invoices Automatch Costing or by running E-Invoices for Matching Report.

Any of the invoice matching criteria (except the Purchase Order number) can be turned off using the parameter PO/AUTCHK. This parameter holds a multi-selection list of options. For example:

Here all criteria are checked except for the expected price. If the parameter is blank, all checks are made.

supplier by supplier these settings can be overridden in the Organisation Setup PLINV record.

Here the Delivery Date criterion has been relaxed for Acme Open Order Limited.

The matching process is determined by configuration. For material orders, the JC/ACCMETH states what accrual methods are valid; choose from any or all of these values:

O Order
G GRN
Z Neither

The contract will then have one of the valid accrual methods.

The accounts payablesupplier details record can override this accrual method using one of the valid values. The contract might normally use G for all suppliers, but a particular supplier record (in the Company Information Workbench) might have O to accrue PO values not GRNs.

Where O is used and the PL/AUTOINVM parameter is set to 2, it is possible for an eInvoice to go straight to approval if all the matching criteria described above are met.

2-way matching of eInvoices is enabled if the PL/AUTOINVM parameter is set to 2.

The 2-way match process can be restricted to specific contracts or overhead departments using the PL parameters AMJOBS and AMDEPTS.

For example, if PL/AUTOINVM is set to N (that is, by default, we do not want to 2-way match), setting PL/AMJOBS to A*|2,B*|2,C*|0 will attempt to 2-way match invoices for any contract whose number begins with A or B but will not attempt to 2-way match for contracts beginning C.

This could get more elaborate because the parameter is read from left to right. So setting PL/AMJOBS to AA*|0,A*|2,B*|2 will not try to two-way match anything beginning AA but will attempt anything else beginning A, and try to match anything beginning B. As a belt and braces measure you could add *|0 as another value at the end of the list but this is implied by the setting of PL/AUTOINVM. (For consistency with the PL/AUTOINVM parameter, you can use N in PL/AMJOBS if you wish instead of 0.)

When loading files, Coins ERP+ will validate all invoices, automatically rejecting documents where configured to do so. A previously loaded file will be re-validated when the

(Review) button is pressed, or the Create Batch action is used.

If invoices fail the validation, they can be automatically removed from the workbench, and a notification email can be sent to a designated recipient.

Use Validation Error Codes to configure the handling of invoices with validation errors, for a range of pre-defined error conditions. Validation Error Codes is a non-company-specific configuration program. You may specify the following for each error code:

The following recipient roles are permitted: Accounts, Buyer, Site or supplier. When deciding who should receive a given notification, if the validation table role is Accounts, Buyer or Site Coins ERP+ will cross-reference this with the User Roles, giving priority to any contract-specific entry that may exist for that role. In each case, the first entry with an email address will be used (i.e. the same contract and role could have several entries for different users).

In the case of notifications to suppliers, Coins ERP+ will look for an office or company-specific invoice rejection email address specified against the HUB document type in Organisation Setup.

In both cases, if Coins ERP+ is unable to find a role-specific email address, the EC/MAILFROM parameter will be used. In all cases, the sender's address is taken from the EC/MAILFROM parameter.

In the unlikely event that all of the above attempts to derive an address fail, as a last resort Coins ERP+ will send an internal mail message to the current Coins ERP+ user to indicate that an error notification failure occurred during validation.

Sample messages designed to test the validity of a message from a new supplier are marked by a tick in the Sample column in the workbench. (The Sample column and sample messages are only visible if the user is an administrator for the workbench, and the filter is set to All Messages or Sample Messages.)

Sample messages are validated and behave exactly the same as regular 'live' messages but can never be passed through to the ledger, the Create action is not available for these messages.

This functionality is only available for XML messages coming from the ETC Hub.

Every XML message can be seen on the workbench in a readable format by clicking thebutton in the Render column. The XML is made readable by use of an XSLT Stylesheet. A standard Coins ERP+ stylesheet is used to render this image in a web browser. This stylesheet can be changed (by you, or as a chargeable service from Coins ERP+) to suit your needs.

It is possible to have a customised stylesheet for each supplier. An example invoice using a Wolseley-specific stylesheet is shown here.

Some suppliers may send with the XML eInvoice one or more attached documents. This functionality is only available with XML messages coming from the ETC Hub. If these are available they are shown in the web browser when the Scanned Image button is pressed. Attached documents can be of any file type that can be rendered by the web browser, typically TIF or JPG files are used.