| Oracle® Retail Invoice Matching Operations Guide Release 19.2.000 F36992-03 |
|
 Previous |
 Next |
This chapter contains information related to the technical design of Invoice Matching.
Invoice Matching user interface is based on the optimistic locking strategy. It means that no entities will be preemptively locked before modification. Only at the point when modification needs to be performed the locking mechanism will be used. If two users are trying to modify the same entity, for example the same invoice, both users can do this on the screen. At the same time only the first user to attempt to save the changes will actually successfully save them and the second user will get an error message and would need to refresh the entity and try again.
Example
User1 is trying to update document D0. Document D0 has terms T0. User1 is trying to update T0 to T1. User2 is also trying to update document D0. User2 is trying to update T0 to T2. If User1 will be the first to attempt to save the change to D0 then D0 will have terms T1. User2 would need to refresh D0 to see the ne value of the terms and only after that would be able to change T1 to T2.
All user interface workflows can be sub-divided into 2 categories - simple entity workflows and complex process workflows. For simple entity workflows the locking is handled by the ADF framework. For complex workflows the workflow entities are copied into session (workspace) tables. For such workflows the locking is done by custom logic to allow data to be modified both by ADF framework code and by backend PL/SQL.
To facilitate locking, all tables that hold modifiable data have a standard - OBJECT_VERSION_ID - that is updated every time the entity is modified. New entity is created with OBJECT_VERSION_ID of 1. Modification verification is performed by comparing the copy's being modified version id with the original copy version id. If it different then the user's copy of the entity is out of sync.
In a batch mode no locking is performed. It is assumed that the batches will be run during the batch windows. It means the assumption is that he batch user will be the sole user of the entities. Because of this the batches should not be run ad-hoc during the normal business hours.
Invoice Matching has been designed to handle a multiple number of currencies. This section addresses the system's assumptions, conversion process, and validations that are related to this capability.
Consider the following assumptions.
Merchandising defines one currency as the primary currency of the system (held on the Merchandising SYSTEM_OPTIONS table in the CURRENCY_CODE field).
Merchandising specifies that each purchase order can have one currency. This purchase order currency does not have to be the same as the Merchandising primary system currency or the Merchandising supplier currency.
Invoice Matching requires that each document have its currency stated (IM_DOC_HEAD.CURRENCY_CODE). This invoice currency does not have to be the same as the system primary currency.
Invoice Matching assumes that a purchase order and any invoices associated with that purchase order are in the same currency. This assumption is based on the business reality that these currencies are almost always the same and on the development consideration that currency conversion processes have an adverse impact on system performance.
The following is information about the currency conversion process for amount tolerances.
Amount tolerances are established in the currency of the tolerance entity (each tolerance entity has a currency setting). However, because the invoices and POs to be matched could reflect a different currency, amount tolerances must be converted before they can be applied. In other words, the currency established for amount tolerances is converted when the invoice/PO combination is not in the tolerance currency. For example, a tolerance defined as 10 US dollars (USD) has a much different meaning than a purchase order/invoice defined in Thai Baht (10 Thai Baht is about 0.23 USD). If the system merely utilized the number 10 and failed to perform a currency conversion, the amount tolerances would not apply correctly.
Currency conversion rates are stored on the Merchandising CURRENCY_RATES table. The conversion factors on this table are in terms of the primary currency of the system. For example, suppose a retailer wishes to convert from Thai Baht to Uruguayan Pesos and the system's primary currency is USD. First, the system performs a conversion from Thai Baht to USD. Secondly, the system converts the USD value to Uruguayan Pesos. In other words, to perform its conversions, the system always must 'go through' the primary currency of the system.
Currency conversion is always done based on he consolidated exchange rate.
One of the validations performed by the EDI Injector process is that it determines whether the currency on the invoice is the same as the currency on the purchase order. If the invoice currency is not the same as the purchase order currency, the invoice is rejected.
The graphical user interface (GUI) invoice entry process also validates that the currency on the invoice is the same as the currency on the PO associated with the invoice. If the currencies are not the same, the user receives a warning message.
Monetary values must be properly formatted according to the associated currency for matting rule. The precision for the currency formatting is defined in Merchandising CURRENCIES table.
