| Oracle® Invoice Matching Operations Guide Release 16.0.2 F10135-02 |
|
 Previous |
 Next |
After installation, some of the mandatory steps need to be performed for the application to be functioning correctly. The objective of the checklist is to make sure that all the required data elements have been provided to eliminate failure in the document processing lifecycle.
Out of the box some of the system options have been set to default values. You need to verify that the values meet your business requirements. Some of the attributes that would need to reference identifiers for the existing entities could not be defaulted and would need to be set explicitly. Such attributes are:
Default Pay Now Terms (Deals)
Default Pay Now Terms (RTV)
Default Location
Default Department
Default Class
Default Set Of Books
URL for account validation web service
URL for drill forward web service
Please see the Oracle Retail Invoice Matching User Guide, System Options section for more information.
Each supplier in Retail Merchandising System would need to have Supplier Options defined before it can be "visible" within the Invoice Matching application. Supplier options can be defined at the Supplier level, Supplier Site level and Supplier Group level. Only Supplier level options are mandatory.
Please see the Oracle Retail Invoice Matching User Guide, Supplier Options section for more information.
If you expect to match documents within tolerance rather than matching exactly, you would need to define tolerance entities and map tolerances to appropriate tolerance nodes. Please see the User Guide, Tolerance Maintenance and Tolerance Mapping sections for more information.
If you expect to run Auto Match batch process, and you probably would, you would need to define some Matching Strategies. Please see the User Guide, Match Strategy Maintenance section for more information.
Reason codes would need to be defined to perform discrepancies resolutions. Reason codes are synonyms for the resolution actions that the application user can take to resolve matching discrepancies. This release of Invoice Matching application doesn't provide a dedicated screen for reason code maintenance. As such, the reason codes would need to be defined via back-end. The reason codes are defined in IM_REASON_CODES table.
An example reason code script to populate the table would look similar to the following:
You can also consult im_demo_data.sql script that is shipped with the product. Please note that the script would need to be modified to suite your needs.
There should be at least one entry for each action that would need to be performed. Actions are subdivided based on categories (REASON_CODE_TYPE).
Cost ('C')
Quantity ('Q')
Credit Note Matching related ('CNT')
Return to vendor ('RTV')
Tax ('T')
The same action can be mapped to more than one reason code. If you would need some comments to be provided when using the reason code, set the COMMENT_REQUIRED_IND to 'Y'. Hint comment can be optionally provided.
In addition to populating IM_REASON_CODES table with the reason codes, you would also need to populate IM_SEC_GRP_REASON_CODE table for each reason code. This table assigns reason codes to the security user groups defined in RMS. Only the reason codes that have been assigned to the user's security group will be available for processing. There should be a record for each user group/reason code that would require reason code access.
An example reason code security script to populate the table would look like:
The example is also available in the im_demo_data.sql script.
See the Oracle Retail Invoice Matching Data Model for more information on the tables structure.
To be able to successfully post transactions to Financial System, such as EBS you would need to define General Ledger account mappings. This release of Invoice Matching application doesn't provide a dedicated screen for General Ledger mappings. As such, the mappings would need to be defined via back-end. The mappings are defined in IM_GL_CROSS_REF table.
An example GL Cross Ref script to populate the table would look similar to the following:
The example also is available in im_demo_data.sql script.
The application supports up to 20 segments. Not all segments are required. Usually the number of segments doesn't exceed 10. There should be a separate set of mappings for each set of books defined in the system. Mappings would need to be defined for all basic transactions, as well as for all non-merchandising codes and for all reason codes defined in the previous step.
Optionally, the mappings can be differentiated per tax code.
In addition to populating IM_GL_CROSS_REF table with the GL mappings, you would also need to populate IM_GL_OPTIONS to indicate what segments, if any, would be dynamic. Dynamic segments don't need explicit mappings, but rather the mappings are dynamically determined based of the segment meaning.
An example GL Options script to populate the table will look similar to the following:
The example also is available in im_demo_data.sql script.
If Location segments are defined as dynamic then location segment mapping would need to be provided. It is done by populating IM_DYNAMIC_SEGMENT_LOC table. There should be an entry for each location that would need to be posted. There should be a separate set of mappings for each set of books defined in the system.
An example location mapping script to populate the table will look similar to the following:
If Department or Class segments are defined as dynamic then merchandising hierarchy segment mapping would need to be provided. It is done by populating IM_DYNAMIC_SEGMENT_DEPT_CLASS table. There should be an entry for every department/class combination that would need to be posted. There should be a separate set of mappings for each set of books defined in the system.
An example department/class mapping script to populate the table will look similar to the following:
See the Oracle Retail Invoice Matching Data Model for more information on the tables structure.
