| Oracle® Invoice Matching Operations Guide Release 13.2.9 E73506-01 |
|
 Previous |
 Next |
This chapter contains information related to the technical design of ReIM.
ReIM locking is accomplished using database tables that hold record level locks. The locking of tables is performed for several reasons, including the following:
ReIM does not necessarily maintain a single connection throughout an entire screen/process. That is, the system opens a connection, fetches information, and then closes the connection. At a later moment in time, the system opens another connection to save changes and close the connection.
ReIM cannot maintain locks in some kinds of Java session structures because the system may be involved with more than one Java virtual machine (JVM).
Base tables that contain information to be locked (for example, IM_SUPPLIER_OPTIONS) have a corresponding …_LOCK table (for example, IM_SUPPLIER_OPTIONS_LOCK). The …_LOCK table contains the same columns as the primary key of the base table.
When the system creates a lock, it writes the primary key values for the base table records to be locked to the appropriate …_LOCK table. For example, if data in the IM_SUPPLIER_OPTIONS table is to be locked for supplier 12345, a record is written to the IM_SUPPLIER_OPTIONS_LOCK table for supplier with the primary key value, 12345.
When records in a base header table are locked, all detail records related to each locked header record are implicitly locked. Detail records are not explicitly locked because:
ReIM functionality must go through the header information to access detail information. In other words, the entry point to detail records is generally through the header.
On screens and within backend processes that include header information, some kind of summary of the details also exists.
The following two examples represent this type of header detail locking:
Example 1
If user A is looking at the header, and user B changes the details, user A does not have visibility to the changes and might perform an invalid action. Invoices are stored on IM_DOC_HEAD, and the non-merchandise costs on invoices are stored on IM_DOC_NON_MERCH. On the invoice header screen, user A can see a sum of all of the non-merch costs for invoice 99999. If user B could somehow at the same time add new non-merchandise costs for invoice 99999, the information that user A sees as the summary of non-merchandise costs would be invalid.
Example 2
If auto-match has selected all documents 'ready for match' and is processing and then additional data is entered for a document, the details with which the auto-match is working would no longer be valid.
For locking management, consider the following.
When a user that has an active lock exits a screen (that is, the user selects OK or Cancel buttons on the screen), data changes are committed (if necessary) and then any locks on data displayed on that screen are removed. If any expired locks on the screen data exist, they are also released upon screen exit.
When a user tries to commit information to the database, the locking service checks to ensure that the user has valid locks on any changed data being committed (for example, locks could have timed out as noted below). If the user does not have valid locks, the user receives a message noting that the user's changes cannot be saved. In this case, the user must exit the screen, enter the screen again, and re-enter the data changes that could not be committed due to invalid/expired locks.
In situations where accidental system exits occur (for example, the server shuts down unexpectedly from power loss), locks are not released immediately. After the system is restored from outage, the user will log into the system and access the main menu. At that point, any existing data locks are removed. Because this data is no longer locked, any user with adequate security permissions can acquire new locks on this data.
The lock timeout interval is defined in the reim.properties file. See Chapter 2, "Backend System Administration and Configuration," for information.
When locks are written to the …_LOCK table, they include an 'end time' value. When checking to see if a row of data is locked, the system inspects the related lock row 'end time' value. If the commit time is before the end time on the …_LOCK table record, the base table data changes may be committed. If the commit time is equal to or exceeds the end time, the data lock will be treated as 'expired' and the data changes will not be committed.
If a user needs immediate access to already locked data and cannot wait for data locks to expire or be released by the user holding the locks, a database administrator can manually delete existing lock records from the appropriate …_LOCK table to release the locks. However, this does not guarantee that the user that needs immediate access will be the next user to acquire locks on the just-released data. The manual release of locks should be a rare event due to the other lock release methods in the system.
ReIM 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.
RMS defines one currency as the primary currency of the system (held on the RMS SYSTEM_OPTIONS table in the CURRENCY_CODE field).
RMS specifies that each purchase order can have one currency. This purchase order currency does not have to be the same as the RMS primary system currency or the RMS supplier currency.
ReIM 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.
ReIM 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 primary currency of the system. 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 primary currency of the system. 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 RMS 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.
One of the validations performed by the EDI upload 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 (both single invoice entry and batch 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.
Currency must be properly formatted according to its applicable locale. For example, US currency uses a comma as a thousands separator whereas other currencies do not use a comma as a thousands separator. Java has built-in libraries for currency formatting that are based on locales.
ReIM uses built-in Java localization functionality mapped through the table IM_CURRENCY_LOCALE to RMS existing currency structure. ReIM provides an installation script that populates this table. The script creates records for every currency that RMS supports. Note that ReIM cannot guarantee the accuracy of RMS language data.
