| Oracle® Invoice Matching Operations Guide Release 13.2.9 E73506-01 |
|
 Previous |
 Next |
This chapter provides a diagram and description of the invoice matching process flow. It also describes the auto-match process through a series of detailed examples. The various levels of auto-matching are explained, including one-to-one invoice matching and line-level matching. The chapter concludes with a discussion of best terms calculations.
This section provides a high-level explanation of the process flow in ReIM for each of the following areas:
Data entry
Matching
Discrepancy resolution
|
Note: Documents drop out of the flow when they require no further processing. For example, if an invoice is matched in Step 2, Matching, the document would not continue to Step 3, Discrepancy Resolution. The document would be posted directly to the financial (AP/GL) staging table after Step 2. |
Data Entry
There are three ways in which invoices and other documents enter the ReIM system:
Electronic Data Interchange (EDI)
Invoices and credit notes uploaded as part of a batch are assigned a common control number, which is retained on the invoice table as a reference. The control number is assigned by the sender of the EDI file. It is displayed on the Invoice Maintenance screen and may be used for client reporting purposes.
As necessary, the EDI load process allows for the uploading of supplier's vendor product number (VPN) when neither the document number nor the UPC has been provided. The VPN and the supplier number, then, are used to look up the Oracle Retail item number. ReIM assumes the VPN is related to the supplier associated with the document. Note that the VPN number is not stored in ReIM; it is used to find the Oracle Retail item number which is then retained and used for processing within ReIM.
Allowing VPN to be used to find the Oracle Retail item number is optional.
EDI allows ReIM to upload the following documents:
Merchandise Invoices
The bills for goods or services received from a supplier or partner. Merchandise invoices may have both of the following:
Merchandise Costs: Costs that are associated with items on documents. Any other costs on an invoice are non-merchandise costs. The sum of the merchandise costs and non-merchandise costs is the total document cost.
Non-Merchandise Costs: Costs that are indirectly associated with invoice items, such as freight or handling charges.
Non Merchandise Invoices
Bills for non-merchandise costs only (a snow plowing service, for example). Non-merchandise invoices cannot contain items. Either suppliers or partners can create non-merchandise invoices.
Credit Notes
Documents received from the supplier, often issued in response to a credit note request from the retailer, which results in a reduction of the retailer's balance owing to a supplier. A credit note request may be raised in lieu of a deduction from invoice (that is, a debit memo) resulting from invoice over-charges, RTVs, rebate bill backs, and so on. Credit notes follow a functional process flow separate from the invoice flow, where credit notes are matched against credit note requests.
Group Entry
Group entry facilitates summarized, on-line entry of paper documents. The group entry process accommodates the same types of documents as supported through the EDI process.
Invoices are entered as part of a batch and assigned a group number, which is retained on the invoice table as a reference. This group number is displayed on the Invoice Maintenance screen and may be used for reporting purposes.
Because group entry is intended to quickly get invoices into ReIM, entry of item details is not required. Adding item details for an invoice can be done later through the Invoice Maintenance screen.
Single Entry
Single entry is designed as an exception-handling tool made for invoices and documents not entered (for whatever reason) within a group.
|
Note: Merchandise invoices entered by way of single entry also are assigned a group/transaction number. However, since each document will be assigned its own group number, some retailers may not want to generate so many additional group IDs. Retailers that require a group/transaction number for tracking purposes may want to restrict access to the single invoice entry screen. Single entry may be controlled for a user group by setting the Invoice Entry option on the User Group Details screen to Modify only. This allows users to change an existing invoice but prevents them from creating a single-entry invoice. In turn, this forces all manual entry to be done as group entry. |
Single entry accommodates the same types of documents supported in the EDI and group entry processes, as well as the following items (if not created automatically through other processes):
Debit Memo
A document created to support a deduction from the invoice being paid. Deductions may result from a price or quantity discrepancy. A debit memo also refers supplier billing for rebates, RTVs, and so on. Debit memos also can be created as 'stand-alone' documents (that is, created on-line, but not supported by any processes in ReIM or the merchandising system).
Credit Note Request (CNR)
A document sent from the retailer to the supplier, requesting a credit note for an over-invoiced amount (discrepancy) or in support of various billing activities (for example, rebates, RTVs). If a credit note request is not satisfied by the supplier in a timely manner, ReIM provides the ability to convert it into a debit memo (and include the number of the invoice to which it is assigned). Credit note requests also may be created as stand-alone documents.
Credit Memos
A document created to refund a supplier for an under-invoiced or over-billed amount (for example, for rebates not meeting threshold performance levels) amount. Credit memos also may be created as stand-alone documents.
|
Note: If the credit memo is the result of a reversed debit memo, the ID number of the invoice to which the debit memo is associated should be assigned to the credit memo, particularly if the invoice is being held for payment. Assigning the ID number in this manner ensures related documents are released to accounts payable at the same time. |
Matching
|
Note: Credit notes must be matched on-line against credit note requests. Credit note matching is not supported by the automatic matching process. |
Auto-Matching
Merchandise invoices are grouped by common PO/location; ReIM requires these attributes in all merchandise invoices. ReIM accesses the merchandising system to determine what shipments (receipts) were created for the PO/location. The auto-matching process attempts to support invoice cost and quantities against receipt quantities at PO cost within user defined tolerances.
If the auto-matching process identifies cost or quantity differences outside of the pre-established tolerance range, the system creates corresponding discrepancies (cost or quantity). Otherwise, matched invoices are posted to the financial staging table.
For header-level-only invoices, TAX validation is performed as a final validation step, after cost and quantity matching has been performed.
For more functional information about summary and detail-level auto-matching, see "The Auto-Match Process" in this chapter.
On-line Matching
Invoices
The on-line matching dialog provides users with the ability to match invoices with even greater flexibility than the auto-match process. Invoices are initially grouped by their PO/location, but the groups can be modified beyond the common PO/location relationship based on available (that is, 'unmatched') invoices and receipts, to support matches.
On-line matching either matches a document, which is posted to the financial staging table, or supports creation and resolution of a cost and/or quantity discrepancy.
Credit Notes and CNRs
Typically, invoices for which CNRs are generated are sent to accounts payable even if matching credit notes have not yet been received. The retailer, then, is issued an invoice that actually is higher than it should be and will have to wait until credit notes are processed before receiving credit for the overcharge. The supplier, in turn, may be overpaid. To avoid this inefficiency, ReIM allows invoices with unmatched CNRs to be held (not paid) until all corresponding credit notes are received-at which time the invoice automatically is sent to accounts payable. Depending on user group security, the user can manually control when the invoice is released to accounts payable-even before all credit notes are received.
When a credit note request is matched to a credit note through online matching, the ID number of the invoice to which they are associated is assigned to the credit note. In this way, the invoice and all related documents may be released to accounts payable at the same time.
When matching CNRs to credit notes on a held invoice, the original invoice should be checked for other open discrepancies. If none exist, the Hold Invoice indicator on the Supplier Options screen should be turned off so that the invoice and all related documents can be released to the financial system.
Discrepancy Resolution
Users assign pre-defined reason codes against cost and quantity discrepancies to support resolutions. The reason codes direct the system to take a specific action.
Cost and quantity discrepancies are routed to on-line lists by user group. (Pre-established user groups and routing rules determine which discrepancies populate which user group list.) For example, in many companies the merchant/buyer is responsible for verification of invoice cost against the PO. To support this functionality, a user group of buyers by department or class might be a logical association to assign to an on-line Cost Discrepancy Review List. (Each user group would see only discrepancies assigned to it). Each user group is empowered to resolve discrepancies according to their authorization. Similarly, it may be logical to assign users groups to Quantity Discrepancy Review Lists based on receiving location.
ReIM does not require the resolution of discrepancies through the routing process; the application will support a more centralized business process for resolving discrepancies using only the on-line matching dialog.
Once all discrepancies are resolved for the document, it is posted to the financial staging table along with any corresponding debit memos, and so on, for posting to the retailer's accounts payable solution.
Documents supporting discrepancy resolution (such as debit memos, credit note requests, and credit memos) are available for EDI download to the supplier. (Or the retailer may develop reporting from these values stored in the ReIM tables). These document records (except credit note requests) also are posted to the financial staging table.
If there is a discrepancy between a credit note and a credit note request, a new credit note should be created. Further, CNRs created inadvertently can be voided and fully reversed to expedite resolution. (It is assumed that if all CNRs related to a held invoice are voided, that invoice is released for payment.)
The Auto-Match process includes invoices and credit notes.
Invoices
Invoices in ready for match, unresolved, and multi-unresolved status are retrieved from the database to be processed through the auto-match algorithm. These invoices are grouped with receipts based upon PO/location.
If no receipts exist for the PO/location, invoices process through the cost pre-matching algorithm.
If receipts do exist, the system attempts to match all invoices and receipts for the common PO/location (referred to as'group matching), within summary-level tolerances.
If group matching fails, the system attempts to match each invoice to a single receipt in the one-to-one matching algorithm. If all invoices are matched in this fashion, then the next PO/location is processed.
If all of the invoices cannot be matched and a multi-unresolved scenario results, the matched invoices remain matched and the non-matched invoices are given a multi-unresolved status. No further processing occurs for this PO/location.
If an unmatched invoice is eligible for line level matching, an attempt is made to match each line on the invoice to an unmatched receipt line.
Credit Notes
Credit notes can be matched on-line against credit note requests or by using the credit note auto-matching process as described in the "Credit Note Auto-Matching" section below.
The auto-matching process determines whether the TAX values on header level-only invoices are correct. The system only processes invoices that do not have any unresolved TAX discrepancies.
The invoice status determines whether an invoice can be processed by the Auto-match batch process (AutoMatchService). Only invoices in ready-for-match status are processed. Those with a status of TAX discrepancy are not processed by the batch. See Chapter 9, "Batch Processes," for information.
Invoices created without details are not able to have their TAX information validated at invoice creation. All header level-only invoices are created with a status of ready-for-match. These invoices must have a TAX validation executed as part of the invoice matching process. This validation determines whether a header level-only invoice that was matched to a receipt should continue in the matching and posting process or whether it should be marked as having a TAX discrepancy and removed from the matching process.
Cost pre-matching occurs only for PO locations that meet the following conditions:
Invoices that have never been processed by auto-match exist.
No receipts exist.
Each invoice line unit cost is compared with the PO item location's unit cost. If the unit costs match within tolerance, the invoice and lines are processed again by auto-match once receipts come in for the PO location.
If there is a discrepancy, then the invoice is processed again once receipts arrive. However, the lines that contain a discrepancy are immediately routed for cost resolution. Once invoices are run through the cost pre-matching algorithm, they are not re-run when the next auto-match run occurs if there are still no receipts.
Scenarios can arise where no receipt lines exist, and no order line corresponds to an invoice line. The assumption is that validation occurs in the EDI upload process and in the manual invoice entry screens prevent these invoices from entering the system. Therefore, auto-match ignores this situation.
PO/location summary group matching processes the following:
Invoices that have never been processed before by auto-match.
Invoices that have been processed previously by auto-match but remain unresolved.
Invoices that have been processed previously by auto-match but that have been identified as multi-unresolved.
First, the system attempts to match the total extended cost of the invoices with the total extended cost of the receipts. Extended cost is defined as the unit cost for an item multiplied by the quantity received or the quantity invoiced. For this comparison, all extended costs are summed for the group of invoices and receipts and compared. The total extended cost for each invoice is taken from the invoice header. The process, however, calculates the receipts' total extended cost.
Quantity matching is also sometimes required. Whether quantity matching is performed is determined by a supplier option. Quantity matching compares the total quantity invoiced for the PO location with the total quantity received for the PO location. As in cost matching, the total quantity invoiced for each invoice is taken from the invoice header. For receipts, the process calculates this sum.
For invoices with quantities representing weight rather than number of eaches, total quantity displayed in the invoice header is represented as the sum of item quantities in abstract UOM.
Auto-match processing first attempts to match the total extended costs, and optionally the total quantities, exactly. If the costs and quantities do not match exactly, then the system attempts to match them within tolerance. If a match is achieved, all of the invoices, receipts, and their lines for the PO location are assumed to be matched. If a match is not achieved, all invoices and receipts for the PO location are unresolved. These invoices and receipts are processed further with one-to-one invoice matching.
Auto-match accounts for the actions taken by cost reviewers that fully resolve a cost discrepancy when attempting to match at the summary level. If a match is achieved at the summary level, auto-match deletes any outstanding unresolved cost discrepancies and any partially resolved cost discrepancies along with their partial resolutions for the PO location from the system.
Example 1
The following example illustrates a successful match:
| Invoices for a PO/Location | Total Extended Cost | Total Quantity |
|---|---|---|
| Invoice 1 | $50,000 | 1,000 |
| Invoice 2 | $150,000 | 5,000 |
| Totals: | $200,000 | 6,000 |
| Receipts for a PO/Location | Total Extended Cost | Total Quantity |
|---|---|---|
| Receipt 1 | $50,000 | 2,000 |
| Receipt 2 | $50,000 | 2,000 |
| Receipt 3 | $100,000 | 2,000 |
| Totals: | $200,000 | 6,000 |
In the example, the total extended costs and the total quantities match for the PO location. Therefore, all invoices and receipts will be set to matched status.
Example 2
The following example illustrates a successful match, but where quantity matching is not required by the supplier.
| Receipts for a PO/Location | Total Extended Cost | Total Quantity |
|---|---|---|
| Invoice 1 | $50,000 | 2,000 |
| Invoice 2 | $150,000 | 5,000 |
| Totals | $200,000 | 7,000 |
| Receipts for a PO/Location | Total Extended Cost | Total Quantity |
|---|---|---|
| Receipt 1 | $50,000 | 2,000 |
| Receipt 2 | $50,000 | 2,000 |
| Receipt 3 | $100,000 | 2,000 |
| Totals | $200,000 | 6,000 |
In the example, only the total extended costs match. However, quantity matching is not required for this supplier. Therefore, these invoices and receipts are considered matched by the auto-matching algorithm.
Example 3
The following example illustrates an unsuccessful match, where quantity matching is required by the supplier.
| Receipts for a PO/Location | Total Extended Cost | Total Quantity |
|---|---|---|
| Invoice 1 | $50,000 | 1,000 |
| Invoice 2 | $150,000 | 5,500 |
| Totals: | $200,000 | 6,500 |
| Receipts for a PO/Location | Total Extended Cost | Total Quantity |
|---|---|---|
| Receipt 1 | $50,000 | 2,000 |
| Receipt 2 | $50,000 | 2,000 |
| Receipt 3 | $100,000 | 2,000 |
| Totals: | $200,00 | 6,000 |
In the example, because quantity matching is required for the supplier, the match is unsuccessful despite the fact that the costs do match. The invoices and receipts will be set to unresolved status, and an attempt will be made to match them at a one-to-one level.
Example 4
The following example illustrates a successful match within tolerance.
| Receipts for a PO/Location | Total Extended Cost | Total Quantity |
|---|---|---|
| Invoice 1 | $50,035 | 1.000 |
| Invoice 2 | $150,100 | 5,000 |
| Totals: | $200,135 | 6,000 |
| Receipts for a PO/Location | Total Extended Cost | Total Quantity |
|---|---|---|
| Receipt 1 | $50,000 | 2,000 |
| Receipt 2 | $50,000 | 2,000 |
| Receipt 3 | $100,000 | 2,000 |
| Totals: | $200,000 | 6,000 |
One-to-one invoice matching attempts to match each invoice for the PO/location with a single receipt for the PO/location. First, the system attempts a match between the total extended costs. If the extended costs match, the system may, depending upon a supplier option, attempt a match between the total quantities. If there is either an exact match or a match within tolerance, the invoice and receipt along with their lines are considered to be matched. If no match can be found for the invoice, it is left unresolved.
One-to-one matching may result in a multi-unresolved scenario. If any invoices within the PO/location can be successfully matched with one and only one receipt and that receipt can be matched to only one invoice for the PO location, then those invoices and receipts are considered to be matched. If no unmatched invoices remain, then processing stops for the PO/location and all invoices are considered matched. Only when one unmatched invoice exists for the PO/location can line level matching occur. If more than one invoice remains after one-to-one matching, then all remaining unmatched invoices and receipts are considered to be multi-unresolved.
One-to-one matching is driven by invoices. Therefore, if there are unmatched receipts remaining but no unmatched invoices for the PO/location, no further processing occurs. The receipts remain unresolved but no discrepancies are generated.
Example 1
The following example illustrates how one invoice matches with one and only one receipt. One invoice and two receipts are unresolved.
| Invoices for a PO/Location | Total Extended Cost | Total Quantity | Status Post Matching |
|---|---|---|---|
| Invoice 1 | $50,000 | 5,000 | Matched |
| Invoice 2 | $100,000 | 10,000 | Unresolved |
| Invoices for a PO/Location | Total Extended Cost | Total Quantity | Status Post Matching |
|---|---|---|---|
| Receipt 1 | $50,000 | 5,000 | Matched |
| Receipt 2 | $25,000 | 2,500 | Unresolved |
| Receipt 3 | $35,000 | 2,500 | Unresolved |
In the example, Invoice 1 matches with Receipt 1. However, the remaining invoice and receipts do not match one-to-one. Because there are two unmatched receipts remaining and only one unmatched invoice, the remaining unmatched invoice and receipts are considered to be unresolved. If they are eligible for detail matching, they are sent to the detail-matching algorithm.
Example 2
The following example illustrates a multi-unresolved match, with no successful matches.
| Invoices for a PO/Location | Total Extended Cost | Total Quantity | Status Post Matching |
|---|---|---|---|
| Invoice 1 | $50,000 | 5,000 | Multi-unresolved |
| Invoice 2 | $25,000 | 2,500 | Multi-unresolved |
| Invoice 2 | $35,000 | 3,000 | Multi-unresolved |
| Invoices for a PO/Location | Total Extended Cost | Total Quantity | Status Post Matching |
|---|---|---|---|
| Receipt 1 | $40,00 | 4,000 | Multi-unresolved |
| Receipt 2 | $25,000 | 2,500 | Multi-unresolved |
| Receipt 3 | $25,000 | 2,500 | Multi-unresolved |
| Receipt 4 | $10,000 | 1,000 | Multi-unresolved |
In the example, Invoice 2 can be successfully matched to both Receipt 2 and Receipt 3. Therefore, no match can be obtained for Invoice 2. All invoices and receipts are set to multi-unresolved status.
Example 3
The following example illustrates another multi-unresolved match, with no successful matches.
| Invoices for a PO/Location | Total Extended Cost | Total Quantity | Status Post Matching |
|---|---|---|---|
| Invoice 1 | $40,000 | 4,000 | Multi-unresolved |
| Invoice 2 | $25,000 | 2,500 | Multi-unresolved |
| Invoice 3 | $25,000 | 2,500 | Multi-unresolved |
| Invoice 4 | $10,000 | 1,000 | Multi-unresolved |
| Invoices for a PO/Location | Total Extended Cost | Total Quantity | Status Post Matching |
|---|---|---|---|
| Receipt 1 | $50,000 | 5,000 | Multi-unresolved |
| Receipt 2 | $25,000 | 2,500 | Multi-unresolved |
| Receipt 3 | $35,000 | 3,500 | Multi-unresolved |
In the example, Receipt 2 can be successfully matched to both Invoice 2 and Invoice 3. All invoices and receipts are set to multi-unresolved status.
Example 4
The following example illustrates a multi-unresolved match, but one with successful matches.
| Invoices for a PO/Location | Total Extended Cost | Total Quantity | Status Post Matching |
|---|---|---|---|
| Invoice 1 | $50,000 | 5,000 | Multi-unresolved |
| Invoice 2 | $25,000 | 2,500 | Multi-unresolved |
| Invoice 3 | $35,000 | 3,500 | Matched |
| Invoices for a PO/Location | Total Extended Cost | Total Quantity | Status Post Matching |
|---|---|---|---|
| Receipt 1 | $40,000 | 4,000 | Multi-unresolved |
| Receipt 2 | $25,000 | 2,500 | Multi-unresolved |
| Receipt 3 | $25,000 | 2,500 | Multi-unresolved |
| Receipt 4 | $35,000 | 3,000 | Matched |
In the example, Invoice 2 can be successfully matched with both Receipt 2 and Receipt 3. Invoice 3, however, can be successfully matched only with Receipt 4. Therefore, Invoice 3 and Receipt 4 are set to matched status. All other invoices and receipts for the PO location are set to multi-unresolved status.
Example 5
The following example illustrates a scenario in which all invoices match, but there are remaining unresolved receipts.
| Invoices for a PO/Location | Total Extended Cost | Total Quantity | Status Post Matching |
|---|---|---|---|
| Invoice 1 | $50,000 | 5,000 | Matched |
| Invoice 2 | $25,000 | 2,500 | Matched |
| Invoice 3 | $35,000 | 3,000 | Matched |
| Invoices for a PO/Location | Total Extended Cost | Total Quantity | Status Post Matching |
|---|---|---|---|
| Receipt 1 | $50,000 | 5,000 | Matched |
| Receipt 2 | $25,000 | 2,500 | Matched |
| Receipt 3 | $15,000 | 2,500 | Unresolved |
| Receipt 4 | $35,000 | 3,000 | Matched |
| Receipt 5 | $75,000 | 10,000 | Unresolved |
In the example, all three invoices can be successfully matched to one and only one receipt. However, two unmatched receipts remain. The invoices are still considered matched, and the receipts remain unresolved.
In auto-matching, matching can be performed for entire invoices or broken down to the line level. PO location level matching and one-to-one invoice matching are performed for entire invoices and receipts. Line level matching is performed by item.
In order to be eligible for line-level matching, an invoice or receipt must meet the following conditions:
Neither the invoice nor receipt can be in multi-unresolved status: If the invoice or receipt is in multi-unresolved status, it is assumed that human intervention is required. No further attempts are made to match the applicable invoice at the line level.
Lines must be present on the invoice: Auto-matching assumes that invoices either have all lines in the system or no lines. The system neither validates nor processes partial invoices. If any lines are present, auto-matching assumes that all lines are present.
The number of days to routing must be exceeded: The system uses settings and a formula to arrive at its determination of routing days. A supplier option is used to define how long the system should wait before routing discrepancies for invoices for that supplier. However, if the invoice is due sooner than the routing date, then discrepancies may be routed earlier than the route date. A system option determines the maximum number of days before an invoice due date that discrepancies will be routed. The earliest date between the routing date defined by the supplier option and the routing date dictated by the system option is the date on which auto-match routes discrepancies for an invoice.
Supplier option: routing days = x days
System option: maximum days before due date = y days
Supplier driven routing date = invoice date + x days
System driven routing date = invoice due date - y days
The date of actual routing is the earlier of the supplier driven routing date and the system-driven routing date.
If only one invoice remains unmatched and zero-to-many receipts are unmatched for the PO location and the invoice is eligible, the system attempts to match each line item on the invoice to receipt line items on the receipts for the same item. If a match is not found, price and/or quantity discrepancies are created and routed. Once line level matching is complete for a PO location, if all lines have been matched, then the entire invoice and all of the receipts are considered matched. Otherwise, they remain unresolved.
When invoice lines are sent through line level matching, all existing unresolved or partially resolved cost discrepancies are deleted along with any partial resolutions. If line level matching produces new discrepancies, they are created and routed, thus ensuring that discrepancies are routed with the latest information available about the invoice and receipt lines.
If no receipt lines correspond to an invoice line, cost matching is attempted for the applicable invoice line using the unit cost from the PO. The system assumes the invoice line exists on the order. If there is a discrepancy, a cost discrepancy is created and routed. In this scenario, a quantity discrepancy is automatically created and routed where the entire invoiced quantity is the discrepant quantity.
For line-level matching, cost and quantity matching are always performed. If cost matching fails, quantity matching is still performed in order to route potential quantity discrepancies that may be discovered. When discrepancies are created, the PO supplier is associated with the discrepancy.
For quantity line level matching, the comparison is made between the quantity invoiced and the sum of the quantities received across the receipts for that item. If a quantity match cannot be obtained, then a quantity discrepancy is generated and routed for the invoice line and the receipt lines for that item.
Example 1
The following example illustrates a scenario in which all lines match, and the invoices and receipts are set to matched status.
| Invoice Lines for a PO/Location | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
| Invoice 1 | 550 | Matched | ||
| - Invoice line | Item 1 | $5.00 | 100 | Matched |
| - Invoice line | Item 2 | $10.00 | 200 | Matched |
| - Invoice line | Item 3 | $15.00 | 250 | Matched |
| Invoice Lines for a PO/Location | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
| Receipt 1 | 565 | Matched | ||
| - Receipt line | Item 1 | $5.02 | 105 | Matched |
| - Receipt line | Item 2 | $10.10 | 210 | Matched |
| - Receipt line | Item 3 | $15.03 | 250 | Matched |
In the example, assume line-level tolerances are set such that all lines match, and the line-level statuses are set to matched accordingly.
Example 2
The following example illustrates a scenario in which some lines match, and the invoices and receipts remain in unresolved status.
| Invoice Lines for a PO/Location | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
| Invoice 1 | 550 | Unresolved | ||
| - Invoice line | Item 1 | $12.00 | 100 | Unresolved |
| - Invoice line | Item 2 | $10.00 | 200 | Matched |
| - Invoice line | Item 3 | $12.00 | 250 | Unresolved |
| Invoice Lines for a PO/Location | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
| Receipt 1 | 550 | Unresolved | ||
| - Receipt line | Item 1 | $5 | 100 | Unresolved |
| - Receipt line | Item 2 | $10 | 200 | Matched |
| - Receipt line | Item 3 | $10 | 250 | Unresolved |
In the example, the lines value for Item 2 is matched. However, because Items 1 and 3 do not match within tolerance, the receipt and invoice are unmatched.
Example 3
The following example illustrates a scenario in which some lines match, and the invoices and receipts remain in unresolved status. Note that one invoice line has no corresponding receipt item.
| Invoice Lines for a PO/Location | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
| Invoice 1 | 550 | Unresolved | ||
| - Invoice line | Item 1 | $12.00 | 100 | Unresolved |
| - Invoice line | Item 2 | $10.00 | 200 | Matched |
| - Invoice line | Item 3 | $12.00 | 250 | Unresolved |
| Invoice Lines for a PO/Location | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
| Receipt 1 | 550 | Unresolved | ||
| - Receipt line | Item 1 | $5.00 | 100 | Unresolved |
| - Receipt line | Item 2 | $10.00 | 200 | Matched |
| Order Lines for a PO/Location | Item | Unit Cost |
|---|---|---|
| - Order line | Item 1 | $5.00 |
| - Order line | Item 2 | $10.00 |
| - Order line | Item 3 | $12.00 |
In the example, Item 2 matches. A cost discrepancy is created for Item 1. No cost discrepancy is created for Item 3 because its unit cost matches the PO unit cost. A quantity discrepancy is created for Item 3 where the received quantity is zero because the item is not on the receipt.
Example 4
The following example illustrates a scenario in which one invoice line is matched to many receipt lines.
| Invoice Lines for a PO/Location | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
| Invoice 1 | Matched | |||
| - Invoice line | Item 1 | $5.00 | 100 | Matched |
| Invoice Lines for a PO/Location | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
| Receipt 1 | Matched | |||
| - Receipt line | Item 1 | $5.00 | 70 | Matched |
| Receipt 2 | Matched | |||
| - Receipt line | Item 1 | $5.00 | 30 | Matched |
In the example, one invoice line can be matched with two receipt lines.
As soon as invoices arrive, the next auto-matching batch run processes them. If there are no receipts, invoices are sent to cost pre-matching immediately - allowing for early identification of cost discrepancies and correction of PO, if necessary, to improve match rates when receipts arrive.
Once receipts arrive, the invoices and receipts are matched at the PO/location level and at the one-to-one level. If no match exists, these invoices and receipts are recycled through summary level matching until the routing days parameter has passed. If there is a match, then any unresolved or partially resolved cost discrepancies are removed from the system.
For discrepancies that have been fully resolved, the actions taken are reflected in the adjusted total extended cost and adjusted total quantity of the invoices and the receipts. The adjusted cost and quantity values will be available to support summary matching on-line.
After the routing days parameter has passed, an invoice in unmatched status will undergo line-level matching. In this type of scenario, all existing unresolved or partially resolved cost discrepancies are deleted. New cost and quantity discrepancies are created if any exist.
After line level matching is performed for an invoice (through either the auto-match or the on-line matching process), that invoice is never processed by auto-match again.
Users may choose to split a receipt item. Splitting a receipt a portion of the receipt quantities to support a match or resolve a discrepancy online. The unmatched portion of the receipt is available to match against future invoices. Partially matched receipts (that is, the unmatched portion) are available to both on-line and auto-match processes to support matches.
Example 1
The following example illustrates summary level matching:
| Invoice Lines for a PO/Location | Item | Extended Cost | Quantity | Status Prior to Matching | Status After Matching |
|---|---|---|---|---|---|
| Invoice 1 | $30,000 | 500 | Unresolved | Matched |
| Invoice Lines for a PO/Location | Item | Extended Cost | Quantity | Status Prior to Matching | Status After Matching |
|---|---|---|---|---|---|
| $60,000 | 1,000 | Partially Matched | Matched | ||
| $30,000 | 500 | Previously matched | Matched | ||
| $15,000 | 250 | Unresolved | Matched | ||
| $15,000 | 250 | Unresolved | Matched |
In the example, a partially matched receipt is used to match an unprocessed invoice. Only the unmatched lines for the receipt are used to determine whether the invoice and receipt match at the summary level.
Example 2
The following example illustrates line level matching:
| Invoice Lines for a PO/Location | Item | Extended Cost | Quantity | Status Prior to Matching | Status After Matching |
|---|---|---|---|---|---|
| Invoice 1 | Unresolved | Unresolved | |||
| - Invoice line | 2 | $15.00 | 250 | Unresolved | Unresolved |
| - Invoice line | 3 | $15.00 | 250 | Unresolved | Matched |
| Invoice Lines for a PO/Location | Item | Extended Cost | Quantity | Status Prior to Matching | Status After Matching |
|---|---|---|---|---|---|
| Receipt 1 | Partially Matched | Matched | |||
| - Receipt line | Item 1 | $30.00 | 500 | Previously matched | Matched |
| - Receipt line | Item 2 | $15.00 | 250 | Previously matched | Matched |
| - Receipt line | Item 3 | $15.00 | 250 | Unresolved | Matched |
In the example, the invoice remains unresolved and the receipt becomes matched. Even though Item 2 of Invoice 1 matches with Item 2 of Receipt 1, Item 2 of Receipt 1 had already been matched to a different line on a different invoice. Therefore, it is not reused here to make a match. Item 3 of Receipt 1 is unresolved and is therefore available to be matched to Item 3 of Invoice 1.
Matching tolerances are defined for:
Costs and quantities, for both summary and detail (line-level) matching
Discrepancies in favor of the retailer and those in favor of the supplier
Tolerance ranges
Supplier, department, or system level (default)
Tolerances are set up for total invoice (merchandise) cost to support summary level matching during the auto-match and on-line processes. Summary level quantity matching is optional, per supplier parameter; the tolerance dialog. Detail (line-level) cost matching is performed based on the unit cost of the item. Quantity matching is always done at the line-level, requiring a tolerance provision. Tolerances may be set up as percentages or nominal amounts. A system option provides for definition of the maximum percentage tolerance that can be used.
Tolerances are defined separately for discrepancies in favor of the retailer and those in favor of the supplier. To illustrate, if the invoice cost is $20.00 and the purchase order (receipt) cost is $30.00, the discrepancy of 10 is in favor of the retailer because the invoice cost is less than expected.
Discrete tolerance amounts or percentages may be defined for value and quantity ranges to hone the matching process. Ranges are defined for summary and line-level matching.
In general, when attempting to match invoices with quantities representing weight, the percentage tolerance type at the system level should be used For these invoices, the system would apply the same logic regardless of whether the invoice shows number of pounds or number of packs. So using a percentage rather than an amount would be the more effective choice.
Tolerances may be defined at the supplier level, the department level, or the system-wide level. The matching processes first determine whether a supplier-level tolerance applies to the invoice being matched. If a supplier-level tolerance does not exist, a check will be made for department level. If line-level matching is being performed, then ReIM will use the department for that item to retrieve tolerances. In the summary matching case, an item is selected at random from the corresponding PO, and the department for that item is used to retrieve tolerances. Finally, if supplier- and department- level tolerances do not exist, the system-level tolerance will default.
ReIM records summary and detail history for matched invoices and receipts. In addition, the system records whether or not each match was exact or not. At the summary level, the group of receipts and invoice numbers is stored. At the detail level, receipt lines matching to a particular invoice line is also stored.
For each auto-match run, the following metrics about the run are stored:
The run date.
The number of invoices that matched exactly.
The number of invoices that matched within tolerance.
The total number of invoices processed.
The best terms calculation process compares the terms on the invoice and the terms on the PO, selects the most favorable term (according to each term's ranking), and determines a terms date. Best terms and terms date are subject to supplier-level option. The best terms calculation process is called after the auto-matching and on-line matching processes, and for pre-paid invoices.
After the best terms are calculated and the terms date is determined, the results are written to IM_DOC_HEAD for the invoice.
Terms are ranked numerically. Terms with a lower ranking are preferable to terms with a higher ranking. During the best terms calculation, the ranks of the invoice terms and the PO terms are compared, and the terms with the lowest rank are selected as the best terms.
The following supplier options (IM_SUPPLIER_OPTIONS) affect the best terms calculation:
Always Use Invoice Terms (USE_INVOICE_TERMS_IND): When this indicator is set to Y, only invoice terms will be used, and there the comparison against PO terms is not performed.
ROG Date Allowed (ROG_DATE_ALLOWED_IND): When this indicator is set to Y, the supplier allows the receipt of goods (ROG) date to be used to when determining the terms date. This indicator can only be set to Y if the Always Use Invoice Terms indicator is set to N.
The terms date is the later of the invoice date or the receipt of goods (ROG) date. The ROG date replaces invoice date as the terms date when all of the following are true:
Always Use Invoice Terms (USE_INVOICE_TERMS_IND) on the supplier options table is set to N.
ROG Date Allowed (ROG_DATE_ALLOWED_IND) on the supplier options table is set to Y.
The ROG date is later than the invoice date.
|
Note: If there are multiple receipts for an invoice, the ROG date is the date of the last receipt. |
Best terms calculation applies only to merchandise invoices.
Merchandise invoices must be in matched status before the best terms calculation is performed.
When the supplier option Always Use Invoice Terms is set to Y, the invoice terms are always used. The due date is calculated using the invoice date. The PO terms are never considered.
The payment of invoices prior to or during matching does not update the matching status of the invoice. In these situations, a pre-paid invoice indicator is tripped to ensure the invoice is not paid a second time after matching and to trigger the correct accounting distribution. The best terms process is not re-invoked if the pre-paid indicator is set to Y.
Credit Note Auto-Matching pairs credit note requests to corresponding credit notes sent by the supplier. The CreditNoteAutoMatchBatch attempts auto-matching of credit notes from suppliers, to credit note requests from the retailer without manual intervention. The batch also creates and resolves detail level discrepancies utilizing a predefined set of reason codes. These reason codes are defined within Invoice Matching through the System Options Maintenance screen. In addition, the batch utilizes a variety of configurable keys to allow for document groups to be matched in ways other than just distinct purchase order and location combinations.
The following table describes under which circumstances credit notes and credit note requests are eligible to be matched by the CreditNoteAutoMatchBatch process.
| Document Status | Document Hold Status | Holding Supplier | Credit Notes | Credit Note Requests |
|---|---|---|---|---|
|
Approved |
Never held |
Yes |
N/A |
Eligible |
|
Approved |
Held |
Yes |
Eligible |
N/A |
|
Approved |
Released |
Yes |
Eligible |
Eligible |
|
Approved |
Never held |
No |
Ineligible |
N/A |
|
Posted |
Never held |
No |
Eligible |
N/A |
In addition to the requirements listed above, the following criteria must apply for documents to be processed by the CreditNoteAutoMatchBatch:
Credit notes must never have had a discrepancy created against them.
Credit notes must never have been previously detail matched.
If the documents are eligible for matching, they are collected into a pool of matchable documents by the batch. The batch process is multi-threaded. It performs matching on eligible documents by first grouping the eligible documents with respect to the supplier. Once grouped with respect to the supplier, the documents are processed for each configurable key. Each document-key set is further processed using the following three matching algorithms.
Summary matching
One-to-one matching
Detail (line level) matching
In summary matching, documents are matched in groups at the summary level by comparing the total extended costs for all the documents in the group. Quantity matching is only attempted if the supplier options indicate it as required. If a match is achieved, the documents are marked with the matched status, and drop out of the matching pool.
If the summary match attempt fails for the group, the batch attempts matching at the one-to-one level. One-to-one matching attempts to match each distinct eligible credit note to a single credit note request. The match is again attempted by comparing the extended cost on the credit note to that of the credit note request, and quantity matching is only attempted depending on the supplier options. If one-to-one matches are found, they are flagged as such and will not be processed by subsequent match attempts.
Line level matching is the last attempted match algorithm. This algorithm attempts to match documents at the item line level. To avoid item matching between unrelated credit notes and credit note requests, this algorithm expects just one unmatched credit note to be remaining in the matchable pool. In case there is more than one credit note still in unmatched status, no match attempt will be made. Line level matching also automatically creates and resolves discrepancies, if the appropriate system options have been set. Once these discrepancies are created, the algorithm also attempts to resolve the discrepancies by creating resolution actions in the system in accordance with the nature of the discrepancies.
On the next run of the ReasonCodeActionRollupBatch, documents are generated for any resolution action generated by the CreditNoteAutoMatchBatch.
Grouping documents into sets using configurable (flexible) pool keys allows for matching in combinations beyond just the PO / Location combination. Note that when we refer to a document set, the set can only contain documents within the same supplier.
These document-key sets are categorized by common attributes which are defined on the document itself (credit notes and credit note requests). These attributes are referred to as Configurable or Flexible Pool Keys. By default, the credit note auto match process aggregates document sets based on the following keys:
Credit Note Request ID
Original Invoice ID
PO / Location combination
In case of Credit Note Request ID and Original Invoice ID, two of the four customizable reference fields of the documents are used as place holders for the key values. For instance, the Ref No.3 field is used to store the Credit Note Request ID, and the Ref No. 4 field is used to store the original Invoice ID.
A document can exists in only one document-key set at a time. Note that a document-key set will exist only if it contains both credit notes and credit note requests. Matching will be attempted only for sets not containing both credit notes and credit note requests. This makes it impossible to create, route and resolve discrepancies for credit notes that are yet to be received by the retailer.
Within each document-key set, matches are attempted using three different matching algorithms. If a match is obtained with an algorithm, the matched documents are flagged as such, and processing continues on to the next document-key set. When all configurable three algorithms are finished processing within a document-key sets, processing moves to the next configurable key-set and starts again from the first matching algorithm.
Below is the order for attempting a match in a document-key set when no match is found:
Credit Note Request ID (configurable key)
Summary Matching (matching algorithm)
One to One Matching (matching algorithm)
Line -level Matching (matching algorithm)
Original Invoice ID (configurable key)
Summary Matching (matching algorithm)
One to One Matching (matching algorithm)
Line -level Matching (matching algorithm)
PO / Location (configurable key)
Summary Matching (matching algorithm)
One to One Matching (matching algorithm)
Line -level Matching (matching algorithm)
Summary matching attempts to match the total extended cost of the credit notes with the total extended cost of the credit note requests. Extended cost is defined as the unit cost for an item multiplied by the quantity of the item on the document. The total extended cost for each credit note and credit note request is taken from the document header.
Quantity matching also is sometimes required. Whether quantity matching is performed is determined by supplier options. Quantity matching compares the total quantity on the credit note, with the total quantity on the credit note request. As in cost matching, the total quantity for each credit note and credit note request is taken from the header.
If the costs and quantities do not match exactly, then the system attempts to match them within tolerance. See "Matching Tolerances" for more details. If a match is achieved, all of the credit notes, credit note requests, and their lines for that document-key set are assumed to be matched. If a match is not achieved, all credit notes and credit note requests for that document-key set are left in their original approved status. After summary matching has been completed, the credit notes and requests become eligible to be processed with a different matching algorithm if no match was found at the summary level.
Consider an attempted summary match where two credit notes were received for two credit note requests. Assuming that the invoice and receipt data in the application is as follows:
Purchase Order=89890
Location=1000001
When matched, the invoice and receipt will create a cost discrepancy of $40, and a quantity discrepancy of $100--which will generate a credit note request cost for $40 and a credit note request quantity for $100.
The default Invoice Matching Pool Key configuration will have the following priority and values.
Credit Note Request ID
Invoice ID
Purchase Order/Location
Example 1: Matchable by credit note request ID; quantity matching not required by supplier.
The following example illustrates a successful match using the first Pool Key attribute, Credit Note Request ID.
The credit note request associated with a credit note is determined from the Ref No 3 field that should contain the credit note request Id. In the example, the total extended cost for a credit note matches exactly with the extended cost of its respective Credit Note Request. Therefore, all credit notes and credit note requests will be set to matched status.
Example 2: Quantity matching required by supplier, outside tolerance
The following example illustrates an unsuccessful match, where quantity matching is required by the supplier, and the tolerance level is set to 10%. It is assumed that the documents are matchable by credit note request ID.
In the example, the match is unsuccessful, despite the fact that the extended costs do match. The failed match is due to the requirement by the supplier to match quantities, and the difference in quantities on the credit note request--and the credit note is more than the allowed tolerance of 10 percent. The credit notes and credit note requests will remain in their original status.
Example 3 (quantity matching required by supplier, within tolerance)
The following example illustrates an unsuccessful match when the pool key is the credit_note_request_ID (Ref No 3), but a successful match when the pool key is Invoice_ID. In this scenario, quantity matching is required by the supplier, and tolerance level is set to 10.
In the example, the match is not successful when using Credit Note Request ID (reference field 3) as the pool key, because the extended cost difference (500 - 400) is outside of tolerance.
However, if the batch process was using the Invoice ID (reference field 4) as the pool key the match would be successful because the extended costs (400+100 = 500) match, and the quantities match within tolerance (20+4 = 24, where 24 is within 10% of 25). All the credit note requests and credit notes will be set to the status of matched. Example 4 illustrates a scenario in which Invoice ID is used as the pool key.
In case of cost discrepancies, the costs will match if the extended cost differences between the credit note request and the credit note are within tolerance.
Example 4: Matchable by invoice ID.
If the credit notes and credit requests are not matchable by the credit note request ID. The matching process will attempt a one-to-one, and then a line-level match before moving to the next document key-set which is the invoice ID. The invoice ID is populated in the Ref 4 field of the credit note. The following example illustrates an attempted summary match which failed when using credit note request ID, but is successful when the match is attempted using the second priority Pool Key attribute, Invoice ID.
In the example, the Ref 3 field is empty. Therefore, a match attempted with the Credit Note Request ID fails. Assuming that one-to-one and live-level matches also fail, a second attempt to summary match will be made in the next document-key set (using the invoice ID). In this case, because the credit note and credit note requests match by Invoice ID, all credit notes and credit note requests will be set to matched status.
Example 5: Matchable by PO Location
If a credit note and credit request is not matchable in the document-key sets utilizing credit note request ID, or invoice ID, then the match will be attempted using the PO and Location combination which is the third priority in the default Pool Key Attributes of the system.
Assuming that the invoice and receipt data in the in application is as follows:
Purchase Order=89890
Location=1000001
When matched, the invoice and receipt will create a cost discrepancy of $40 and a discrepancy of $100, which will generate a credit note request for $40 and a credit note request quantity for $100.
In the example, both the Ref No 3 and Ref No 4 fields on the credit note are empty. Therefore matching is not even attempted at the Credit Note Request ID or invoice ID pool keys. A third attempt to match will be made with the PO and Location combination. As calculated from the above data, the PO and location combination for all three documents is: 89890-1000001. Since this combination is the same for all three documents, and the extended cost of the credit note requests match with the credit note, all credit notes and credit note requests will be set to matched status.
One-to-one credit note matching is considered another form of summary matching. The only addition to the rule is that instead of attempting matches in groups, one-to-one matching attempts to match a single credit note with a single credit note request.
The batch first attempts a match between the total extended costs. If the total extended costs do not match exactly for the credit note and the credit note request pair, then tolerances are applied to check if the cost discrepancy is within tolerance. In case quantity matching is required by the supplier, header level quantity matching is also attempted for the document pair within tolerance. If no match can be found, the documents are left in their original status.
One-to-one algorithm will attempt a match only when at least one unmatched credit note exists in the document-key set. If no unmatched credit notes remain, then processing stops for the document-key set.
Some scenarios of one-to-one matching are listed below. Note that the examples are given to demonstrate an understanding of one-to-one matching algorithm. It is assumed that quantity matching is required in the supplier options, and documents are matchable only by credit Note Request ID.
Example 1: Exact Match
The following example illustrates how one credit note matches with one and only one credit note request. One credit note and two credit note requests are left in their original approved
In the example, CRDNT 1 matches with CRDNRC 1. However, the remaining credit (CRDNT 2) does not match with either of the two remaining credit note requests so it remains unmatched. The remaining credit note requests (CRDNRC 2 and CRDNRC 3) are also left in their original state. The matching algorithm will now move to the next matching algorithm within the document-key set to consider matching these documents.
Example 2: Match unsuccessful; one credit note but two credit note requests
The following example illustrates an unsuccessful match i.e. no successful matches.
In the example, CRDNT 2 can be successfully matched to both CRDNRC 2, and CRDNRC 3. Therefore, no match can be obtained for Invoice 2. All credit notes and credit note requests are left in their original status.
Example 3: Match unsuccessful; two credit notes for one credit note request
The following example illustrates another multi-unresolved match, with no successful matches.
In the example, CRDNRC 2 can be successfully matched to both CRDNT 2 and CRDNT 3. All credit notes and credit note requests are left in the original Approved status.
Example 4: All credit notes are matched, but credit note requests remain.
The following example illustrates a scenario in which all credit notes match, but there are remaining unresolved credit note requests.
In the example, all three credit notes are successfully matched to one and only one credit note request. However, two unmatched credit note requests remain. Since there are no credit notes left for matching, processing will stop for this document-key set.
Once summary matching and one-to-one matching pools have been exhausted, the CreditNoteAutoMatchBatch proceeds to attempts match at the line level.
In addition to the eligibility requirements for summary matching, lines must be present on the documents for Line-level matching to proceed. The batch assumes that all lines are present and valid for that credit note and credit note request. Moreover, the algorithm attempts matches only if there is just one credit note left unmatched in the document-key set.
Considering that only one eligible credit note and zero-to-many credit note requests are unmatched for a document key-set, the system attempts to match each line item on that credit note to a credit note request line item. When a detail level match is found, the detail on the credit note and credit note request documents are both flagged as matched. Once line level matching is complete for a document key-set, and all lines have been matched, then the entire credit note and all of its related credit note requests are considered matched. Otherwise, they remain in their original approved status.
For line-level matching, cost and quantity matching are always performed. If cost matching fails, quantity matching is still performed in order to route potential quantity discrepancies that may be discovered.
For quantity line level matching, the comparison is made between the sum of quantities from the credit notes and sum of the quantities on the credit note request for that item. If a quantity match cannot be obtained, then a quantity discrepancy is generated and routed for the credit note and the credit note request lines for that item.
Example 1 (match within tolerance)
The following example illustrates a scenario in which all lines match within tolerance, and the credit notes and credit note requests are set to matched status.
In the example, assume line-level tolerances are set such that all lines match, therefore the line-level statuses are set to matched accordingly.
Example 2 (match resolving discrepancy)
The following example illustrates a scenario in which tolerances allow only one line to matches, but the CreditNoteAutoMatchBatch is able to resolve the discrepancies in other items, and match the credit note and credit note request.
In the example, the lines value for Item 2 is matched. However, Items 1 and 3 do not match within tolerance. If however, reason codes are entered in the appropriate default columns for automatically handling Credit Note matching discrepancies in the system options table, then discrepancies are created automatically for Item1 and Item 3 and the two items are set to matched status on both documents.
When discrepancies are created as part of the line-level matching process, they are automatically resolved by the batch process. This resolution takes place by selecting the appropriate reason code from the system options and then resolving those discrepancy by creating resolution actions in the system. For instance, if a cost discrepancy is detected, then a resolution action in the form of a Credit Note Request for cost or a Credit Memo is generated. On the next run of the reason code action rollup process, these newly created resolution actions will be rolled up to create the appropriate resolution documents.
It is important to distinguish the differences between overages that are in favor of the retailer as opposed to the supplier. In credit note matching, when a credit note is greater than the credit note request issued for it, the overage is in the favor of the retailer and a credit memo is issued to reconcile the discrepancy. This is because the credit note already represents an asset to the retailer. The supplier has issued more credit to the retailer than was appropriate based on the credit note request. If the retailer does not wish to automatically issue credit memos when the credit note is larger than the credit note request, then the system options, Auto-resolution Reason Code for Credit Memo - Cost and Auto-resolution Reason Code for Credit Memo-Qty, should be left blank.
If the applicable system option for a resolution action code type does not have a reason code defined in the System Options Maintenance screen then discrepancies of that type are not generated. It is assumed that the retailer will handle these discrepancies manually. This means that the credit note will not be matched and processing will stop for the document set. This allows for the retailer to have the batch resolve only specific discrepancy types. For example, many retailers may not want to automatically generate Credit Memos in response to Credit Note overages.
Example 1 (cost discrepancy)
The following example illustrates a scenario in which the first line on the credit note matches with the first line on the credit note request. The second line has a cost discrepancy.
In the above scenario Item 2 in credit note and credit note request has a cost discrepancy of $5. The Line level match algorithm automatically generates a cost discrepancy for the item, and generates a Resolution Action in the system for a Credit Note Request - Cost, where the total extended cost on the credit note request is $1,000.00.
Example 2 (quantitydiscrepancy)
The following example illustrates a scenario in which the first line on the credit note matches with the first line on the credit note request. The second line has a quantity discrepancy.
In the above scenario, Item 2 in credit note and credit note request has a quantity discrepancy of 10 (assumed to be above tolerance values). The Line level match algorithm automatically generates a quantity discrepancy for the item, and generates a resolution action in the system for a Credit Note Request - Quantity. The above discrepancies are in the favor of the supplier. In case of the discrepancy being in the favor of the retailer, resolution actions would have been Credit Memos (cost or quantity).
Example 3 (orphan items - credit memo)
A case might exist when an item on the credit note does not exist on the credit note request. The CreditNoteAutoMatchBatch will resolve the discrepancy of the orphan items by utilizing the resolution actions for Credit Memos.
In this scenario Item 2 in credit note does not exist in the credit note request. This orphan item creates a cost discrepancy. Since the discrepancy is in the favor of the retailer, the Line level match algorithm will automatically generate a Resolution Actions in the system for a Credit Memo-Cost, where total cost on the memo is $2,000.00.
The ReasonCodeActionRollupBatch facilitates the CreditNoteAutoMatchBatch process in the following ways:
Document Creation
Resolution actions created as part of the discrepancy creation process of the CreditNoteAutoMatchBatch are converted to first class documents on the next run of the ReasonCodeActionRollupBatch. This is an existing feature of the ReasonCodeActionRollupBatch.
Transfer of Customizable Reference Fields
Currently, documents in the system have a set of four (4) customizable reference fields. These fields are completely optional and their population is left to the discretion of the retailer and their suppliers. If applicable, the CreditNoteAutoMatchBatch utilizes the third and fourth customizable reference fields to facilitate matching. In such cases the ReasonCodeActionRollupBatch makes sure that the values of those fields are transferred to the newly created documents.
Tolerances
Tolerances are handled in a manner similar to the invoice auto match batch process, and tolerance values used for credit note auto match are same as the tolerance values used for invoice matching.
Matching tolerances are defined at the following levels:
Summary or Line
Cost or Quantity
Favor of Retailer or Supplier
Amount or Percentage
Summary matching and one to one matching are both considered types of summary matching, therefore, one to one matches also uses summary level tolerances.
During the match process, tolerances are selected in the following order:
Supplier
Department
System
If no supplier level tolerances are defined, then departmental tolerances are used for a random item in the document set. If departmental tolerances are not defined for that item, then system level tolerances are used for the document set. Note that a document set must have items to use department level tolerances.
Tolerance values are stored using the primary system currency. If the credit note currency and the credit note request both have the same currency but that currency differs from the system currency, the CreditNoteAutoMatchBatch will convert them into the system currency utilizing the currency APIs to determine if the documents fall within appropriate tolerances. Note that the CreditNoteAutoMatchBatch process will not attempt to match a credit note with a credit note request if the currency between the two documents is not the same.
CreditNoteAutoMatchBatch only detects Tax discrepancies at the detail level. This means that when documents are being processed by the detail matching algorithm, a check is performed prior to matching, ensuring that for each item the Tax codes and rates on the credit note match those on the credit note request for the corresponding item. When a discrepancy is detected, processing for that document stops and detail matching is not performed for that document. In this circumstance, the Invoice Matching user will have to match and resolve the Tax discrepancy manually through the user interface.
ReIM records summary and detail history for matched credit notes and credit note requests. The existing credit note matching history data model will be leveraged to ensure than an accurate accounting of match data is stored in the system. In addition, a new history data model has been introduced which holds history data for a specific match. The new history tables are populated after the completion and success of a match.
When document data becomes dated, it is purged from the system through the TablesPurgeBatch. This is also true for the CreditNoteAutoMatchBatch related data. See "Batch Processes" in Chapter 9, "Batch Processes," for information.
| Document Type | Document ID | Unit Cost | Extended Cost | Quantity |
|---|---|---|---|---|
|
Invoice |
INV555 |
$11.00 |
$440 |
40 |
|
Receipt |
SHP444 |
$10.00 |
$200 |
30 |
| Credit Note Request ID | Total Extended Cost | Ref No 3 | Ref No 4 | Quantity |
|
CRDNRC-123 |
40 |
CRDNRC-123 |
INV555 |
40 |
|
CRDNRQ-456 |
100 |
CRDNRQ-456 |
INV555 |
10 |
| Credit Note ID | Total Extended Cost | Ref No 3 | Ref No 4 | Quantity |
|
CRDNT-246 |
40 |
CRDNRC-123 |
INV555 |
40 |
|
CRDNT-369 |
10 |
CRDNRQ-456 |
INV555 |
10 |
| Credit Note Request ID | Total Extended Cost | Ref No 3 | Ref No 4 | Quantity |
|
CRDNRC-123 |
40 |
CRDNRC-123 |
INV555 |
20 |
|
CRDNRC-456 |
100 |
CRDNRQ-456 |
INV555 |
2 |
| Credit Note ID | Total Extended Cost | Ref No 3 | Ref No 4 | Quantity |
|
CRDNT-246 |
500 |
CRDNRC-123 |
INV555 |
25 |
| Credit Note Request ID | Total Extended Cost | Ref No 3 | Ref No 4 | Quantity |
|
CRDNRC-123 |
40 |
CRDNRC-123 |
INV555 |
20 |
|
CRDNRC-456 |
100 |
CRDNRQ-456 |
INV555 |
4 |
| Credit Note ID | Total Extended Cost | Ref No 3 | Ref No 4 | Quantity |
|
CRDNT-246 |
500 |
CRDNRC-123 |
INV555 |
25 |
| Credit Note Request ID | Total Extended Cost | Ref No 3 | Ref No 4 | Quantity |
|
CRDNRC-123 |
20 |
CRDNRC-123 |
INV555 |
2 |
|
CRDNRC-456 |
80 |
CRDNRQ-456 |
INV555 |
8 |
| Credit Note ID | Total Extended Cost | Ref No 3 | Ref No 4 | Quantity |
|
CRDNT-246 |
100 |
INV555 |
10 |
|
| Document Type | Document ID | Unit Cost | Extended Cost | Quantity |
|
Invoice |
INV555 |
$11.00 |
$440 |
40 |
|
Receipt |
SHP444 |
$10.00 |
$200 |
30 |
| Credit Note Request ID | Total Extended Cost | Ref No 3 | Ref No 4 | Quantity |
|
CRDNRC-123 |
40 |
CRDNRC-123 |
INV555 |
40 |
|
CRDNRC-456 |
100 |
CRDNRQ-456 |
INV666 |
10 |
| Credit Note ID | Total Extended Cost | Ref No 3 | Ref No 4 | Quantity |
|
CRDNT-246 |
140 |
50 |
||
| Credit Note ID | Total Extended Cost | Total Quantity | Status Post Matching | |
|
CRDNT 1 |
$50,000 |
$5,000 |
Matched |
|
|
CRDNT 2 |
$100,000 |
$10,000 |
Approved |
|
| Credit Note Request ID | Total Extended Cost | Total Quantity | Status Post Matching | |
|
CRDNRC 1 |
$50,000 |
5.000 |
Matched |
|
|
CRDNRC 2 |
$25,000 |
2,500 |
Approved |
|
|
CRDNRC 3 |
$35,000 |
2,500 |
Approved |
|
| Credit Note ID | Total Extended Cost | Total Quantity | Status Post Matching | |
|
CRDNT 1 |
$50,000 |
5,000 |
Approved |
|
|
CRDNT 2 |
$25,000 |
2,500 |
Approved |
|
|
CRDNT 3 |
$35,000 |
3,000 |
Approved |
|
| Credit Note Request ID | Total Extended Cost | Total Quantity | Status Post Matching | |
|
CRDNRC 1 |
$40,000 |
5,000 |
Approved |
|
|
CRDNRC 2 |
$25,000 |
2,500 |
Approved |
|
|
CRDNRC 3 |
$25,000 |
2,500 |
Approved |
|
|
CRDNRC 4 |
$10,000 |
1,000 |
Approved |
|
| Credit Note ID | Total Extended Cost | Total Quantity | Status Post Matching | |
|
CRDNT 1 |
$40,000 |
4,000 |
Approved |
|
|
CRDNT 2 |
$25,000 |
2,500 |
Approved |
|
|
CRDNT 3 |
$25,000 |
2,500 |
Approved |
|
|
CRDNT 4 |
$10,000 |
1,000 |
Approved |
|
| Credit Note Request ID | Total Extended Cost | Total Quantity | Status Post Matching | |
|
CRDNRC 1 |
$50,000 |
5,000 |
Approved |
|
|
CRDNRC 2 |
$25,000 |
2,500 |
Approved |
|
|
CRDNRC 3 |
$35,000 |
3,000 |
Approved |
|
| Credit Note ID | Total Extended Cost | Total Quantity | Status Post Matching | |
|
CRDNT 1 |
$50,000 |
5,000 |
Matched |
|
|
CRDNT 2 |
$25,000 |
2,500 |
Matched |
|
|
CRDNT 3 |
$35,000 |
3,000 |
Matched |
|
| Credit Note Request ID | Total Extended Cost | Total Quantity | Status Post Matching | |
|
CRDNRC 1 |
$50,000 |
5,000 |
Matched |
|
|
CRDNRC 2 |
$25,000 |
2,500 |
Matched |
|
|
CRDNRC 3 |
$15,000 |
2,500 |
Approved |
|
|
CRDNRC 4 |
$35,000 |
3,000 |
Matched |
|
|
CRDNRC 5 |
$75,000 |
10,000 |
Approved |
|
| Credit Note | Item | Unit Cost | Quantity | Status Post Matching |
|
CRDNT 1 |
550 |
Matched |
||
|
Line |
1 |
$5.00 |
100 |
Matched |
|
Line |
2 |
$10.00 |
200 |
Matched |
|
Line |
3 |
$15.00 |
250 |
Matched |
| Credit Note Request | Item | Unit Cost | Quantity | Status Post Matching |
|
CRDNRC |
565 |
Matched |
||
|
Line |
1 |
$5.02 |
105 |
Matched |
|
Line |
2 |
$10.10 |
210 |
Matched |
|
Line |
3 |
$15.03 |
250 |
Matched |
| Credit Note | Item | Unit Cost | Quantity | Status Post Matching |
|
CRDNT 1 |
550 |
Matched |
||
|
Line |
1 |
$12.00 |
100 |
Matched (by resolving discrepancy) |
|
Line |
2 |
$10.00 |
200 |
Matched |
|
Line |
3 |
$12.00 |
250 |
Matched (by resolving discrepancy) |
| Credit Note Request | Item | Unit Cost | Quantity | Status Post Matching |
|
CRDNRC 1 |
600 |
Matched |
||
|
Line |
1 |
$12.00 |
110 |
Matched (by resolving discrepancy) |
|
Line |
2 |
$10.10 |
200 |
Matched |
|
Line |
3 |
$10.10 |
250 |
Matched (by resolving discrepancy) |
| Credit Note | Item | Unit Cost | Quantity | Status Post Matching |
|
CRDNT 1 |
300 |
Matched |
||
|
Line |
1 |
$12.00 |
100 |
Matched |
|
Line |
2 |
$5.00 |
200 |
Matched (by resolving discrepancy) |
| Credit Note Request | Item | Unit Cost | Quantity | Status Post Matching |
|
CRDNTR 1 |
600 |
Matched |
||
|
Line |
1 |
$12.00 |
110 |
Matched (by resolving discrepancy) |
|
Line |
2 |
$10.10 |
200 |
Matched |
|
Line |
3 |
$10.00 |
250 |
Matched (by resolving discrepancy) |
| Credit Note | Item | Unit Cost | Quantity | Status Post Matching |
|
CRDNT 1 |
300 |
Matched |
||
|
Line |
1 |
$12.00 |
100 |
Matched |
|
Line |
2 |
$10.00 |
200 |
Matched (by resolving discrepancy) |
| Credit Note Request | Item | Unit Cost | Quantity | Status Post Matching |
|
CRDNTR 1 |
310 |
Matched |
||
|
Line |
1 |
$12.00 |
110 |
Matched (by resolving discrepancy) |
|
Line |
2 |
$10.10 |
210 |
Matched |
| Credit Note | Item | Unit Cost | Quantity | Status Post Matching |
|
CRDNT 1 |
300 |
Matched |
||
|
Line |
1 |
$12.00 |
100 |
Matched |
|
Line |
2 |
$10.00 |
200 |
Matched (by resolving discrepancy) |
| Credit Note Request | Item | Unit Cost | Quantity | Status Post Matching |
|
CRDNTR 1 |
150 |
Matched |
||
|
Line |
1 |
$12.00 |
110 |
Matched |
