cancel
Showing results for 
Search instead for 
Did you mean: 

Subsequent Cr/Dr in MIRO

Former Member
0 Kudos

One of our users used Subsequent Cr/Dr functionality to post invoices to lines that were already fully invoiced, Which resulted in overpaying the vendor.

Are there any configurations that could be used to restrict users( messages or verification ) from posting invoices using Subsequent Cr/Dr functionlaity to lines that are fully invoiced?

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Please see the explanaiton below and only way you can block is mentioned in block letters

A subsequent debit/credit exists when an additional invoice or credit memo is received for a transaction that has already been invoiced.

Use

When you post an invoice or a credit memo as a subsequent debit/credit, you should note the following:

The system records every subsequent debit/credit in the purchase order history.

By posting a subsequent debit/credit, the system updates the ordering transaction on a value basis but not on a quantity basis. The quantity invoiced therefore does not change, but the total value invoiced does.

The maximum quantity you can subsequently debit or credit is the quantity that has already been invoiced. It is not possible to post a subsequent debit before an invoice. The system does not check the quantity delivered. A subsequent debit/credit cannot be blocked due to quantity variance.

If you are entering invoices or credit memos containing both standard items and subsequent debits/credits, you have the following options:

If the invoice consists mainly of subsequent debit/credit items, you choose the transaction Subsequent debit and deselect the field Subsequent debit/credit for the items that are not subsequent debits.

If the invoice consists mainly of standard items, you choose the transaction Invoice and select the field Subsequent debit/credit for the items that are subsequently debited.

If you want the system to carry out a price check for a subsequent debit, it compares the value invoiced to date plus the value of the subsequent debit with the expected value based on the purchase order. The system takes tolerance limits into account when carrying out the price check. If a price variance exceeds one of the upper tolerance limits, the subsequent debit is blocked for payment.