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.
Table 2-1 CreditNoteAutoMatchBatch Eligibility
| 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
Credit Note documents include the Credit Note Request ID and Invoice Number in the Credit Note Match Key fields on the header tab. Credit Note Request documents include the Invoice Number in the Credit Note Match Key fields on the header tab (The CNR # is not needed in the Credit Note Match Key field since it is already on the document). The Credit Note Match Key fields are optional, if they are populated then documents are pooled for the key and matching is attempted within the document-key set (match pool).
A document can exist 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 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 three configurable algorithms are finished processing within a document-key set, 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. 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
Table 2-2 Attempted Summary Match
| Document Type | Document ID | Unit Cost | Extended Cost | Quantity |
|---|---|---|---|---|
|
Invoice |
INV555 |
$11.00 |
$440 |
40 |
|
Receipt |
SHP444 |
$10.00 |
$300 |
30 |
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.
Table 2-3 Example 1: Matchable by credit note request ID
| Credit Note Request ID | Total Extended Cost | CNR ID | Invoice ID | Quantity |
|---|---|---|---|---|
|
CRDNRC-123 |
40 |
CRDNRC-123 |
INV555 |
40 |
|
CRDNRQ-456 |
100 |
CRDNRQ-456 |
INV555 |
10 |
Table 2-4 Example 1: Matchable by credit note request ID
| Credit Note ID | Total Extended Cost | CNR ID | Invoice ID | Quantity |
|---|---|---|---|---|
|
CRDNT-246 |
40 |
CRDNRC-123 |
INV555 |
40 |
|
CRDNT-369 |
100 |
CRDNRQ-456 |
INV555 |
10 |
The credit note request associated with a credit note is determined from the Credit Note Request ID 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.
Table 2-5 Example 2: Quantity matching required by supplier, outside tolerance
| Credit Note Request ID | Total Extended Cost | CNR ID | Invoice ID | Quantity |
|---|---|---|---|---|
|
CRDNRC-123 |
400 |
CRDNRC-123 |
INV555 |
20 |
|
CRDNRC-456 |
100 |
CRDNRQ-456 |
INV555 |
2 |
Table 2-6 Example 2: Quantity matching required by supplier, outside tolerance
| Credit Note ID | Total Extended Cost | CNR ID | Invoice ID | Quantity |
|---|---|---|---|---|
|
CRDNT-246 |
500 |
CRDNRC-123 |
INV555 |
25 |
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 (Credit Note Request ID), 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.
Table 2-7 Example 3 quantity matching required by supplier, within tolerance
| Credit Note Request ID | Total Extended Cost | CNR ID | Invoice ID | Quantity |
|---|---|---|---|---|
|
CRDNRC-123 |
400 |
CRDNRC-123 |
INV555 |
20 |
|
CRDNRC-456 |
100 |
CRDNRQ-456 |
INV555 |
4 |
Table 2-8 Example 3 quantity matching required by supplier, within tolerance
| Credit Note ID | Total Extended Cost | CNR ID | Invoice ID | Quantity |
|---|---|---|---|---|
|
CRDNT-246 |
500 |
CRDNRC-123 |
INV555 |
25 |
In the example, the match is not successful when using Credit Note Request ID 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 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 Invoice number 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.
Table 2-9 Example 4: Matchable by invoice ID
| Credit Note Request ID | Total Extended Cost | CNR ID | Invoice ID | Quantity |
|---|---|---|---|---|
|
CRDNRC-123 |
20 |
CRDNRC-123 |
INV555 |
2 |
|
CRDNRC-456 |
80 |
CRDNRQ-456 |
INV555 |
8 |
Table 2-10 Example 4: Matchable by invoice ID
| Credit Note ID | Total Extended Cost | CNR ID | Invoice ID | Quantity |
|---|---|---|---|---|
|
CRDNT-246 |
100 |
INV555 |
10 |
In the example, the Credit Note Request ID on the Credit Note 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
Table 2-11 Example 5: Matchable by PO Location
| Document Type | Document ID | Unit Cost | Extended Cost | Quantity |
|---|---|---|---|---|
|
Invoice |
INV555 |
$11.00 |
$440 |
40 |
|
Receipt |
SHP444 |
$10.00 |
$300 |
30 |
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.
Table 2-12 Example 5: Matchable by PO Location
| Credit Note Request ID | Total Extended Cost | CNR ID | Invoice ID | Quantity |
|---|---|---|---|---|
|
CRDNRC-123 |
40 |
CRDNRC-123 |
INV555 |
40 |
|
CRDNRC-456 |
100 |
CRDNRQ-456 |
INV666 |
10 |
Table 2-13 Example 5: Matchable by PO Location
| Credit Note ID | Total Extended Cost | CNR ID | Invoice ID | Quantity |
|---|---|---|---|---|
|
CRDNT-246 |
140 |
50 |
In the example, both the Credit Note Request ID and Invoice ID 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 status.
| 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 |
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.
Table 2-16 Match Unsuccessful; one Credit Note – two Credit Note Requests
| 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 |
Table 2-17 Match Unsuccessful; one Credit Note – two Credit Note Requests
| 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 |
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.
| 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 |
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.
Table 2-20 All Credit Notes Matched, Credit Note Requests Remain
| 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 |
Table 2-21 All Credit Notes Matched, Credit Note Requests Remain
| 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 |
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.
Table 2-22 Credit Note Match Within Tolerance
| 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 |
Table 2-23 Credit Note Request Match Within Tolerance
| 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 |
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.
Table 2-24 Credit Note Match Resolving Discrepancy
| 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) |
Table 2-25 Credit Note Request Match 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) |
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.
Table 2-26 Credit Note Cost 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) |
Table 2-27 Credit Note Request Cost Discrepancy
| Credit Note Request | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
|
CRDNTR 1 |
300 |
Matched |
||
|
Line |
1 |
$12.00 |
100 |
Matched |
|
Line |
2 |
$10.00 |
200 |
Matched (by resolving 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 (quantity 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 quantity discrepancy.
Table 2-28 Credit Note Quantity 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) |
Table 2-29 Credit Note Request Quantity Discrepancy
| Credit Note Request | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
|
CRDNTR 1 |
310 |
Matched |
||
|
Line |
1 |
$12.00 |
100 |
Matched |
|
Line |
2 |
$10.00 |
210 |
Matched (by resolving 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.
Table 2-30 Credit Note Orphan Items - credit memo
| 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) |
Table 2-31 Credit Note Request Orphan Items - credit memo
| Credit Note Request | Item | Unit Cost | Quantity | Status Post Matching |
|---|---|---|---|---|
|
CRDNTR 1 |
150 |
Matched |
||
|
Line |
1 |
$12.00 |
100 |
Matched |
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.
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.
Credit Note Matching will only be attempted if the Credit Note and the Credit Note Request are in the same currency. If that currency is not the same as the tolerance currency, the documents will be converted to the tolerance currency before variances are calculated.
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 user will have to resolve the Tax discrepancy manually through the user interface.
Invoice Match 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.