Datasheet

Release Notes - New Features included in Release 2.4.0
Page 28 of 89
• no lots are part-allocated.
SOFI creates a sundry invoice using the customer and currency of the entered sales order. The
invoice currency rate defaults according to the invoice date.
SOFI carries out the following processing for each qualifying sales order line. An FSAL (Manual
Alloc by Delivery) transaction is submitted, de-allocating the order line. A SICH (Amend Sales
Order Line) transaction is then used to reduce the order line quantity by the quantity that has been
deallocated. (SICL (Close Sales Order Line) is used if the order line quantity is reduced to zero.)
Any warehouse rents relating to the pallets that have been de-allocated are ended by WRCA
(Warehouse Rent Calculate) transactions. STTL (Stock Location Transfer) transactions are
submitted, moving the palleted stock to a location where the control reference identifies the
customer who now owns the stock (controlref1 = customer). LOCC (Lost Cost Change)
transactions are submitted reducing the value of the allocated lots to zero. WRST (Start Warehouse
Rents) transactions are submitted to start warehouse rents against stock which is now customer-
owned.
A sundry invoice line is generated for each qualifying line. The item number and price are obtained
from the sales order line and the quantity is that which has been de-allocated from the order line.
Filling Invoices use the VAT code identified on FSAM (Order Progress Management) for Outside
Scope (VATCODE-OUTSIDE). This should result in the VAT value of zero, consistent with the
VAT treatment required in this situation.
The SOFI transaction will not complete if any of the underlying transactions fail to complete. In this
situation, an exceptions message is written to BAMQ (Message File Enquiry), destination = 'SOFI'.
This would happen, for example, if any of the submitted LOCC transactions failed because the item
in question was standard-costed.
TROPOS Form provides a template for filling invoices. Sundry invoices with reason code = ‘FIL’
are assumed to be filling invoices and will be printed using the layout defined for filling invoices
(wppinpr.outfill) instead of the standard layout for sundry invoices. The filling invoices layout
includes details of the inventory making up this invoice.
4.2.3.19 AKPR Additional Order Checking and Error Messages (SR4440)
The AKPR (Acknowledgement Print) transaction has been enhanced so that additional optional
order checks may be performed. These are:
a) order completeness i.e. no missing lines
b) promise dates i.e. no line on the order has a promise date that is later than the customer's required
date and
c) credit status i.e. if the order is not already cleared for credit a customer credit check is performed.
Using a set of three flags each of the above tests can
a) be not performed, b) create a warning message or c) create an error message.
If an AKPR is done for a single sales order the checks are performed on line, when a Run Request
is entered the flags are set on each AKPR as it is put into the background queue. If errors are
detected the AKPR will fail in the background queue. The flags also work for TIGI and Batch Load
Wizard.