| Oracle® Retail Invoice Matching Operations Guide Release 19.2.000 F36992-03 |
|
 Previous |
 Next |
This chapter of the operations guide is intended for administrators who provide support and monitor the running system.
The content in this chapter is not procedural, but is meant to provide descriptive overviews of the key system parameters that establish the Invoice Matching environment.
See the Oracle Retail Invoice Matching Installation Guide for hardware and software requirements. Also see Oracle Retail application software compatibility information.
Unit of Measure
For invoices sent from Merchandising with quantities representing weight rather than number of eaches, Invoice Matching converts the unit of measure (UOM) on the receipt to the UOM on the invoice.
Invoice Matching uses non-merchandise codes defined on the Merchandising table NON_MERCH_CODE_HEAD. The form that allows users to enter non-merchandise codes in Merchandising is not available when the Merchandising invoice match indicator (SYSTEM_OPTIONS.REIM_IND) is set to no. Instead, non-merchandise codes should be added to the NON_MERCH_CODE_HEAD table using the database.
Supplier options
All suppliers must have options defined for their invoices to be processed by the system, and the terms defined for those suppliers must be completely updated in Merchandising. To support the use of suppliers in Invoice Matching, terms must have the following properties on the TERMS_DETAIL table:
ENABLED_FLAG is set to Y.
START_DATE_ACTIVE must be defined.
END_DATE_ACTIVE must be defined.
GL account maintenance
All reason codes, non-merchandise codes, and basic transactions must be mapped through GL account maintenance to support posting to the retailer's financial solution. Transactions are posted to a staging table in Invoice Matching, the extract to update the accounts payable/financial solution is the retailer's responsibility.
TAX
If TAX is turned on and set to use Single Tax, the retailer must have VAT regions, Tax items, and Tax codes set up in the merchandising system (such as Merchandising) to support validation of invoiced tax charges. If Tax is turned on and set to use Global Tax, tax foundation data and tax rules will need to be set up in Merchandising to support validation of invoiced tax charges. Note that setup will be different for single tax and global tax. Verify the following values on the IM_SYSTEM_OPTIONS table:
|
Note: The values below should not be changed after initial setup. Changing them can cause errors in the system. |
NUM_TAX_ALLOW is set to S (single) TAX, N (no) TAX, or G (global tax).
TAX_VALIDATION_TYPE is set to RECON (Reconcile TAX), VENDR (Always Use Vendor TAX), or RETLR (Always use Retail TAX).
The DEFAULT_TAX_HEADER is set to Y or N.
TAX_DOCUMENT_CREATION_LVL is set to ITEM or FULL_INVOICE.
The property file has only technical configurations that are specific to the particular deployment. All the business related configurations are located within the system option scope.
The following properties are configurable
#help settings
help.server.url - Help server URL
reim.help.library - path to the Invoice Matching specific help deck
reim.release.version - help version
reim.help.url.suffix -help URL suffix identifying specific document within the library
reim.help.default.url.suffix -default page within the document
#JMS settings
reim.jms.connection.factory.name -name of the JMS factory within JNDI tree on WL used for spreadsheet induction
reim.jms.queue.doc.induction.name - name of the JMS queue within JNDI tree on WL used for spreadsheet induction
reim.jms.application.code- Application code identifier used for JMS publishing
reim.jms.connection.factory.docseq.name - name of the JMS factory within JNDI tree on WL used for document sequence assignment
reim.jms.queue.doc.docseq1.name… reim.jms.queue.doc.docseq20.name - names of 20 JMS queues within JNDI tree on WL used for document sequence assignment
#Notification settings
reim.jdbc.raf.async.task- name of the data source within JNDI tree on WL used for async publishing
This file contains a key value pair for some of the labels visible through the GUI at run time. Text labels and error messages have been identified, separated from the core source code, and placed into the properties file. The contents of the file can be used for retailer-specific configuration purposes (such as for the creation of custom labels or error messages). Some other sources of translatable data is used within the system such as XLIF files and database tables.
