Logistics Invoice Verification[rev]

• Invoice management
• Account Determination
• Revaluation
• GR/IR Clearing Account Maintenance
• Material revaluation
• Material revaluation in consignment settlement
• ERS 
• ERS process - MRRL - Currency determination
• How to set up the Evaluated Receipt Settlement - ERS
• Invoice reduction
• Credit Memos and Reversals
• Credit Memo
• Reversal
• Returns
• Posting Credit Memos and Invoices for Returns
• Settling Delivery and Returns Items
• Posting Returns
• Additional information
• 628468 - MIRO: Incomplete MM documents
• 963185 - MM-IV: Tolerance check when you enter or release invoices
• 10757 - FAQ: MR11, clear GR/IR clearing account
• 790426 - MR11: Functionality
• 184632 - MR11: Account maintenance in GR-based IV
• 3061836 - MR11 GR/IR Clearing Account determination / Account Movements
• 2839847 - MIRO: Payment method not derived from the vendor master data
• 2036775 - Duplicate Invoice Check in Logistics Invoice Verification
• 2572664 - MIRO: Invoice blocked due to date variance
• 2948075 - MIRO/MIR7: Invoice Verification with manual exchange rate does not have any influence upon LC2 and LC3 calculation.
• 1674290 - Determining Invoice Posting Values
• 2684845 - LIV: Posting logic for Service items
• 2535485 - MR8M: Error M8283 occurs while cancelling an invoice via MR8M
• 3059707 - How not to maintain CO objects in GR/IR Account
• 2519546 - Different Number Range required for Credit Memo in case of Purchase Return
• 2612071 - MIRO: Proposal logic for exchange rates
• 539793 - MIRO: User-specific document type
• 2071682 - FAQ: Distributing unplanned delivery costs in the case of follow-on invoices/multiple account assignment
• 844861 - EDI: Transfer prices

Purchase Account Management - SAP Help Portal

Invoice management

• Master Data: Material Data, Vendor Data, Accounting Data.
• Transaction Data: Purchasing Document, Material Document, Accounting Document

Transactions 

• Enter Invoice (MIRO)
• Park Invoice (MIR7)
• Cancel Invoice (MR8M)
• Invoice Overview (MIR6)
• Evaluated Receipt Settlement (MRRL)
• Revaluation (MRNB)
• Invoicing Plan (MRIS)
• Invoice Verification in the Background (RMBABG00)

Choosing the Transaction

• You have received a vendor invoice. The vendor invoices you for the goods that you have ordered from that company.
• Credit memo: The vendor has invoiced you too much for the last delivery, for example, less than the agreed quantity was delivered and that at the agreed total price, or you have returned part of a delivery to the vendor due to quality problems.
• Subsequent debit: You have already received an invoice from your vendor for all the goods received. Subsequently, freight costs are to be taken into account, however, the invoice quantity remains the same.
• You have already received a credit memo from your vendor for all the goods received. Subsequently, freight costs are to be credited to your company, however, the credit memo quantity remains the same.

Allocating Invoices

• Purchase order / Scheduling agreement
• Delivery note
• Bill of lading (GR)
• Service entry sheet
• Vendor
• Transportation service agent

Prepayment

You make settings to control prepayment in Customizing for logistics invoice verification by choosing Incoming Invoice  Prepayment  Configure Control of Prepayment at Company Code Level.

Prepayment has the following characteristics:

• A vendor item is created and an invoice is paid, independently of the corresponding goods receipt and the invoice check.
• Payment of an expense invoice is triggered when the invoice is entered.
• The posting date of the invoice document is used as the posting date for the prepayment document.
• You can use the SET_POSTING_DATE method in BAdI WRF_PREPAY_INVOICE to change the posting date, for example, to the current system date, or the posting date of the invoice document.
• Relevant invoice amounts for prepayment of the invoice are transferred to Financial Accounting (SAP FI).
• The prepaid invoice is checked at a later date.
• The inclusion of a clearing account for prepayment. The system clears this after invoice verification and the corresponding FI posting have been carried out.

Prepayment requires invoices that you enter using logistics invoice entry.

• In a background process
• Using BAPI BAPI_INCOMINGVOICE_SAVE or BAPI_INCOMINGINVOICE_PARK
• Using EDI
• By parking (preliminary entry of) incoming invoices

Before the system is able to begin prepayment, you must have entered the logistics invoices in the system. There are three ways of entering invoices:

• You can enter them manually for the background check.
• You can park them, in which case they are known as parked invoices .
• They can be entered automatically (using Electronic Data Exchange (EDI) or BAPIs).

To enable the system to take account of invoices from a vendor when performing prepayment, you must have made settings in company-code-specific Customizing and for the Prepayment Relevance field in the vendor master.

When a logistics invoice entry is made, the system transfers payment-relevant data to Financial Accounting. The system creates the relevant prepayment document in SAP FI as an FI invoice. In Financial Accounting, the system posts the payment-relevant data to a clearing account for the prepayment and creates an open vendor item.

1. Specify taxes
2. Set Change Prepayment Status indicator
• It is possible to override the prepayment status using the PREPAYMENT_RELEVANCE_CHANGE method in the WRF_PREPAY_INVOICE BAdI.
4. Calculate cash discount
5. Perform FI assignment

Account Determination

Your entries provide the following information:

• Which vendor account must be posted to?
• Which amounts must be posted?

The material master record provides the following information:

• Which valuation class does the material belong to?
• Which type of price control is required for the material?
• Which account must be posted to for the material?
• Is the stock available smaller than the quantity invoiced?

Posted documents provide the following information:

• What is the purchase order price?
• Has a goods receipt been posted for the purchase order?

The system setting sprovide the following information:

• Is the invoice posted as a net or a gross amount?
• Which G/L accounts must be posted to?

----------------------------------------------------------

• Vendor Account: There is a separate account in the sub-ledger for each vendor that all amounts concerning this vendor are posted to. Making a posting to the vendor account is not the same as making a payment; payment is only made when the Financial Accounting department posts the vendor's payment to a bank account.
• Stock Account: The system only posts to the stock account when a price difference occurs for an invoice.
• GR/IR clearing account is an “intermediate” account between the stock account and the vendor account. At goods receipt, the net invoice amount expected is posted to the stock account. The offsetting entry is posted to the GR/IR clearing account. This posting is then cleared by an offsetting entry on the vendor account at invoice receipt.
• Tax Accounts
• Cash Discount Clearing Account
• Freight Clearing Account: The stock account is debited with the planned delivery costs at goods receipt and the system makes the offsetting posting to a freight clearing account. This posting is then cleared by an offsetting entry to the vendor account at invoice receipt.

Revaluation

For purchase order items for which a goods receipt is planned, the system creates an accounting document that debits the stock account. The offsetting entry for this is posted to a goods receipt/invoice receipt clearing account (GR/IR clearing account), which is cleared by posting the invoice.

GR/IR Clearing Account Maintenance

Transaction MR11 should always be the last action performed on a PO. It is meant to clear the GR / IR account in case there are no invoices or goods receipt to be expected from the vendor anymore.

Quantity differences between goods receipt and invoice receipt for a purchase order result in a balance on the GR/IR clearing account.

• If the quantity invoiced is larger than the quantity received, the system then expects further goods receipts for this purchase order to clear the balance.
• If the quantity received is larger than the quantity invoiced, the system then expects further invoices for this purchase order to clear the balance.
• You can also clear differences for delivery costs.

If no more goods or invoices are to be received, you must clear the balance manually.

This can be done in different ways:

• You can return the extra goods to the vendor.
• You can cancel the invoice and post a corrected invoice or a credit memo for the surplus posted quantity.
• You can clear the GR/IR clearing account manually.

The GR/IR clearing account is usually cleared at the end of a period or fiscal year for those order items that no further goods receipts or invoices are expected for.

If you clear quantity differences between the goods receipt and invoice receipt for a purchase order using account maintenance, the system produces an account maintenance document.

GR/IR Account Maintenance: Account Movements

• Material with Moving Average Price (MAP): The GR/IR account is cleared against the stock account, unless no stock coverage exists. If the material stock is smaller than the quantity to be cleared, only the actual stock quantity is debited or credited proportionally. The remaining amount is posted to a price difference account.
• Material with Standard Price: The offsetting entry is posted to a price difference account.
• Purchase Orders Assigned to an Account: The offsetting entry is made to the cost or fixed asset account shown in the account assignments in the purchase order.

Material revaluation

Material revaluation in consignment settlement

In the consignment settlement, the transaction MRKO uses the table RKWA and posts the FI document according the value RKWA-WRBTR (amount). In a case where you change the info record condition after the FI of Consignment, table RKWA will not be updated and the change cannot be detected from transaction MRKO. Therefore the change of the price information in table RKWA would lead to an inconsistency on the G/L account, that would not be balanced after MRKO posting. 

The required functionality to post subsequent debit/credit is not available for consignment scenario as it is used in MRNB. This is the way how the consignment is designed in SAP standard.

The only method to do "revaluation" is cancel the MRKO settlement and make it once again with the required price.

ERS 

Tax code derivation

When using Evaluated Receipt Settlement (ERS) transactions (MRRL/MRDC), it is the requirement to be able to change the tax code for specific delivery costs as you do in MIRO/MIR7.

If the requirement is to change the tax code for selected delivery cost lines, consider using badi MRM_ERS_IDAT_MODIFY and change field MWSKZ from importing parameter I_SEGTAB into exporting parameter E_SEGTAB_DC_CHANGE.

The planned delivery costs line can be identified by flag XEKBZ filled ("X") from I_SEGTAB.

Fields STUNR, ZAEHK and KSCHL can be used as well for identification.

Bear in mind to set the exporting parameter E_CHANGE as "X".

How to set up the Evaluated Receipt Settlement - ERS

• Goods receipts are settled without receiving an invoice from the vendor.
• The payment sent to the vendor is based on what has been ordered and received.
• The system can then inform the vendor about the settlement by creating a record of settlement, which allows a letter to be sent to the vendor. This is very useful function that saves time and effort when used appropriately.

When: Inter- or intra-company purchases between different elements of Customers’ own business.

If a goods receipt has already been invoiced, but, the goods have been returned to the vendor, the system automatically generates a credit memo for the returned quantity during the next run of ERS.

Can be settle via MRRL transaction when flag “Settle Goods Items + Planned Delivery Costs” is set or Can be settle using MRDC transaction.

MRRL and MRDC transactions are connected to MR90 transaction, so, it is possible to define a form in customizing.

A message record is created during settlement (in the table NAST). This message completes the form.

• ERS - ERS Procedure
• ERS6 - ERS Procedure EDI

When trying to cancel an ERS-Invoice via MR8M transaction, system shows customizable message M8414 – “The invoice to be cancelled was created during ERS”.

Depending how M8414 is set up in OMRM transaction (error or warning), an invoice created during ERS can be cancelled.

To ensure that the invoice creation/deletion is only done by ERS, correct process is:

1. Create an invoice only via MRRL transaction based on a goods receipt.
2. Cancel the corresponding goods receipt and not the invoice. ERS will cancel the relevant invoice document for the cancelled goods receipt. 

Ensure that the flag “Reversal of GR allowed for GR-based IV despite invoice” is set for movement type 102 in the OMBZ transaction.

Vendor master must be flagged as being subject to ERS. Set this via XK02 > Purchasing data > Control data tab:

• AutoEvalGRSetmt Del.: Specifies that ERS or the automatic generation of invoices according to an invoicing plan, is to be possible in relation to materials supplied or services performed (respectively) with regard to this vendor or this document item.
• AutoEvalGRSetmt Ret.: Indicates that ERS of return items is possible for this vendor or this document item.

In the PO item:

• ERS must be set.
• GR-Based IV must be set.
• Tax code has to be defined

Configure OLMR > Evaluated Receipt Settlement (ERS) > Specify Automatic Settlement of Planned Delivery Costs:

• Define a freight vendor to be applicable for automatic settlement for planned delivery costs.
• This same vendor must be assigned to the delivery costs in the PO.

If a vendor has been set as subject to ERS, the system sets the ERS indicator as a default in each item when a PO is created for the vendor.

This can be prevented by flagging the info record for the material and the vendor as not being subject to ERS.

ERS process - MRRL - Currency determination

When posting an invoice via the transaction MRRL, the currency is not determined taking into account the vendor currency.

1. Create a PO for a determined currency in the delivery/invoice tab, i.e. USD
2. Add the desired partners from the same country, i.e. Germany, their order currency is EUR
3. Post a goods receipt using MIGO transaction.
4. Run the MRRL for this PO.
5. See the invoice is posted for the PO-currency. Here, it is USD.

The invoice currency will be determined based on the currency key in the purchase order and goods receipt despite vendor settings. This determination can be found in the below code:

FORM LESEN_BESTELLPOS_DATEN RMMR1MRS
MOVE xek08rn-waers TO px_segtab-waers. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

During the ERS-posting, if you need to use the vendor/partner currency instead of the PO-currency, please, use one of the following workarounds to achieve this requirement:

Post the invoice through MIRO where you first enter the currency in the header (Basic Data tab), and only then, enter the PO number.

Or, create the PO using the same currency as the vendor/partner. 

Or, develop your own code* using one of the below options:

    a) User exits EXIT_SAPLMRMH_001 and EXIT_SAPLMRMH_002.  

    b) the BADI MRM_ERS_HDAT_MODIFY.

Invoice reduction

Transaction OLMR. Select the option Tax Treatment in Invoice Reduction:

In this example the new Tax value will be in the complaint document. If it is required that the new tax value is calculated in the Invoice, the option must be "1 Tax reduction in original document".

According to the documentation that is available in this option:

The system creates two accounting documents for invoice reduction. The first document (original document) contains the invoice data sent by the vendor. The second document (complaint document) contains information about the invoice reduction.

• If the tax reduction is carried out in the complaint document, the taxes in the original document correspond to those in the vendor invoice. The tax amount for the invoice reduction is credited in the complaint document.
• If the tax reduction is carried out in the original document, the taxes in the original document are reduced by the tax amount for the invoice reduction. In this case, the complaint document does not contain any tax postings. This procedure is particularly recommended if you have the system calculate the taxes automatically.

Notice: It is not possible to calculate the taxes for the reduced amount only when using retention. This is because the taxes will not be calculated for the retention separately and thus you would not have paid any taxes on the retention amount once it is released.

Credit Memos and Reversals

Credit memos are used to adjust the amounts owed to a vendor. Credit memos differ from subsequent debits/credits, which don’t change the invoiced quantity but only post the amounts.

With a credit memo, the invoiced quantity is updated. In an SAP system, canceling an invoice isn’t possible, but invoices can be reversed by posting a credit memo. Credit memos will update the same G/L accounts (with opposite debit/ credit entries) that the invoice originally posted to.

Reversal

Choose Logistics Invoice Verification Further Processing Cancel Invoice Document. MR8M

The system automatically posts a credit memo or invoice. You receive a message.

1. The system checks an invoice created as a result of cancelling a credit memo for variances. If variances occur, the invoice may be blocked for payment. If it is, a message appears.
2. When you cancel an invoice or a credit memo, the system creates an invoice or a credit memo from information contained in the document to be cancelled. In the simplest form, the postings in the invoice or credit memo are simply reversed.
3. However, this is not always possible. If, for example, an invoice is cancelled in which material was debited, the postings can only be reversed if there is enough stock when the invoice reversal is posted. If there is not enough stock, the reversal posting is made proportionally: the part for which there is sufficient stock coverage is posted to the stock account, the remainder to a price difference account.
4. When you cancel an invoice or credit memo referencing a purchase order, you cannot reverse the account movements originally made if a further invoice with a different price was posted after the invoice that is to be cancelled.

Credit Memo

The term credit memo always refers to a credit memo from the vendor. Therefore, posting a credit memo always leads to a debit posting on the vendor account.

As in the case of invoices, credit memos refer to purchase orders or goods receipts. They are used to correct the purchase order history if the quantity invoiced was too high, for example, if an invoice was too high or if part of the quantity was returned.

In the SAP system, a credit memo is the reversal of an invoice. In the same way as the system assumes that a corresponding goods receipt was posted or is expected for an invoice, the system assumes that a credit memo is linked to the reversal of a goods receipt. The credit memo is therefore managed on the GR/IR clearing account.

Invoice reversal is a special form of credit memo. The system automatically determines the credit memo amount and the credit memo quantity from the invoice, so that there is no variance between the invoice and the credit memo. The postings made when you reverse an invoice follow the same rules as credit memo postings. This means that an invoice reversal does not necessarily reverse the postings made when the invoice was posted.

When you post a credit memo, the total quantity in the purchase order history is reduced by the credit memo quantity.

If you do not want the total quantity invoiced to be reduced, you must post the credit memo as a subsequent credit.

• The maximum quantity you can credit is the quantity that has already been invoiced.
• If you post a credit memo for the same quantity as was invoiced so far, the system expects that the total amount invoiced so far is also credited. 
• Otherwise, a situation might arise where you had no stock for a material but a stock value. If you do not enter the amount invoiced so far, the system automatically replaces your entry and proceeds to the item screen. A warning message informs you that your entry has been changed.
• If you post a credit memo for a smaller quantity than that invoiced to date, the amount of the credit memo cannot be larger than the amount invoiced so far. If you post a larger amount, the system displays an error message
• The system does not check if your entries in the columns Amount and Quantity correspond to the purchase order price or the invoice price.

Returns

In Purchasing, order items can be flagged as returns items. The system expects a credit memo for a returns item. Credit memos can be settled up against an invoice or issued separately.

Posting Credit Memos and Invoices for Returns

Settling Delivery and Returns Items

Posting Returns

• Account postings for returns are made according to the same program logic as those for delivery items:
• In the case of delivery for a returns item, the material returned is deducted from the stock account. The offsetting entry is posted to a GR/IR clearing account. When you post the credit memo, the GR/IR clearing account is cleared. The offsetting entry is posted to the vendor account.
• If price variances occur for a returns order, they are posted in the same way as quantity and price variances for delivery items.
• Taxes are also handled in the same way for returns and delivery items.

FMs IDOC_INPUT_INVOIC_FI and IDOC_INPUT_INVOIC_MRM.

• For the FI invoice: Qualifier 026 (billing date) has to be used.
• For the MM invoice: The document date (qualifier 012) is used as posting date.

Additional information

628468 - MIRO: Incomplete MM documents

In rare cases, due to update problems, during the posting of a logistics document in the invoice verification (transactions: MIRO, MIR4, MIR6, MIRA) for an FI document, the MM data may be updated only incompletely or not at all.

To find documents with incomplete updates, implement the report below Z_FIND_MISS_MM_EXT.1. The report analyzes the MM data for an existing FI document.

1. Specifically, the existence of header, item and purchase order history entries are checked.
2.  Other follow-on documents are also checked:
1. CO document (controlling).
1. The report checks the reference to purchase orders with account assignment or direct G/L account postings -> relevant table COBK.
2. ML document (material ledger): The check is carried out at company code level -> relevant table MLHD.c) FM document (Funds Management):

The check is carried out at company code level -> relevant table FMIFMHD.

963185 - MM-IV: Tolerance check when you enter or release invoices

You use one of the transactions or functions from the area of logistics invoice verification to park or post an invoice or to release an invoice blocked for payment.

Even though you have made the correct settings in Customizing for the following tolerance keys:

• “Amount for item without order reference” (AN)
• “Amount for item with order reference” (AP)
• “Form small differences automatically” (BD)
• “Percentage OPUn variance” (IR before GR)(BR)
• “Percentage OPUn variance” (GR before IR)” (BW)
• “Quantity variance when GR quantity = zero” (DW)
• “Amount of blanket purchase order” (LA)
• “Blanket purchase order time limit exceeded” (LD)
• “Date variance” (ST)
• “Price Variance "(PP)

and also filled in the relevant data in the invoice items correctly or had them determined correctly by the system, the system incorrectly executes the tolerance check in relation to the aforementioned tolerance keys.

The attached repair report ZZ_CHECK_UPDATE_MM_T169G can be used for the analysis and correction in Customizing of tolerance settings with the symptoms mentioned above.

10757 - FAQ: MR11, clear GR/IR clearing account

The documentation states that the posting to the GR/IR clearing account made at the time of a goods receipt is "cleared" as a result of the posting of the invoice (and vice versa).

What is meant by this is that the postings made to the GR/IR clearing account then balance off to zero.

The formulation can lead to misunderstandings, as in financial accounting "clearing" can mean both this balancing off to zero and the process of marking items as cleared.

Maintenance of GR/IR clearing accounts is only relevant for purchase order items with valuated goods receipt and refers to quantity differences in a purchase order item.

A purchase order cannot be archived as long as there is a quantity difference.

Maintenance of GR/IR clearing accounts is required for clearing a quantity difference in a purchase order item which will probably not be corrected by other transactions (goods receipt, return delivery, invoice, credit memo...).

Why are freight/customs clearing accounts updated in stock transport orders?In stock transport orders, no invoice is expected, but additional freight costs are allowed in the purchase order item if they were set in customizing.

Why can maintenance of GR/IR clearing accounts in some cases not be carried out for a purchase order with account assignment type 'order'? The (maintenance) order was settled and closed in a technical and business-operational sense.

As of Release 4. 6C, Transaction 'MR11SHOW' can be used for canceling.

790426 - MR11: Functionality

1. MR11 online Execution Enter document header data and selection criteria for posting. Check the purchase order date to ensure that it includes the date on which the purchasing document was created. The field 'Qty var. less than/equal to' (screen field P_DPROZ), holds the default value of 10,0 percent. This value is hard coded in program SAPRCKM_MR11. Remove this quantity variance so that the selection of purchase order is not limited by the amount of the variance. Choose execute.

184632 - MR11: Account maintenance in GR-based IV

In the case of GR/IR account maintenance, the system searches for all purchase order items for which the delivered quantity is not equal to the calculated quantity ?.

In the case of GR-based invoice verification, it is possible for the GR/IR clearing account not to be cleared although the delivered quantity and the invoiced quantity are equal. In this case, the GR/IR clearing account must be performed manually by the posting of an invoice and a credit memo.

Example:

• Ordered: 100 pieces.a 10 EUR
• Goods receipt 1: 100 pieces
• Invoice: 100 pieces a 12 EUR
• Return delivery: - 30 pieces
• Goods receipt 2: 30 pieces

Account movements
                            GR 1     IR      RD       GR 2
Material stock account     1000 +   200 +   360 -    300 +
GR/IR clearing account     1000 -   1000 +  360 +    300 -
Vendor account                      1200 -

A balance of 60 EUR results on the GR/IR clearing account.

The problem only occurs if an invoice contains a price variance or the order price was changed between individual goods receipts and in the purchase order item the entire delivered quantity is equal to the entire calculated quantity.

The GR/IR clearing account must be cleared manually by posting a credit memo for the first goods receipt and an invoice for the second goods receipt.

Credit memo for goods receipt 1:     30 pieces         360 EUR
Invoice for goods receipt 2:         30 pieces         360 EUR

Account movements
                                    Credit memo       Invoice
Material stock account                                60 +
GR/IR clearing account              360 -             300 +
Vendor account                      360 +             360 -

You can prevent such a situation from happening if you in Customizing of inventory management for goods receipt-based invoice verification do not allow a return delivery after an invoice has been carried out (in this case, the invoice would have to be cancelled first before a return delivery can be carried out) in Customizing of invoice verification set the error message 'Quantity invoiced greater than goods receipt quantity' as an error message.

3061836 - MR11 GR/IR Clearing Account determination / Account Movements

The transaction code MR11 is used for clearing the GR/IR balances where GR/IR account can be reconciled during month-end or year-end process. It posts a journal entry of debiting the GR/IR account and credits the corresponding accounts which have the opposite entry. Basically MR11 reverses the accounting entries that created the GR/IR balances.

 

Posting Logic:

• Post: the account maintenance adjusts the invoiced quantity without changing the invoiced value. The account maintenance posts according to the same logic of an invoice or credit memo with a value of zero.
• Cancellation: the account maintenance cancellation posts like a credit memo with the value corresponding to the GR/IR value of the original account maintenance document. However the offsetting posting goes not to the creditor account, but to the material (BSX/KBS) and price difference (PRD) account.

Account Movements:

• Material with Moving Average Price (MAP): The GR/IR account is cleared against the stock account (BSX), unless no stock coverage exists. If the material stock is smaller than the quantity to be cleared, only the actual stock quantity is debited or credited proportionally. The remaining amount is posted to a price difference account (PRD).
• Material with Standard Price: The offsetting entry is posted to a price difference account (PRD).
• Purchase Orders Assigned to an Account: The offsetting entry is made to the cost or fixed asset account shown in the account assignments in the purchase order.

2839847 - MIRO: Payment method not derived from the vendor master data

During an invoice entry via MIRO transaction the Payment method (INVFO-ZLSCH) is not derived from the vendor master to the Payment tab

System copies the Payment term from the vendor master to the MM-invoice. In case the Payment term is defined with a Payment method as default, set via the transaction OBB8, the system transfers the Payment method from the Payment term to the invoice.
Therefore, to have the Payment method filled in the MIRO transaction proceed as follows:
For the Payment term used, access it via the transaction OBB8, maintain a Payment method and set it as default.

2036775 - Duplicate Invoice Check in Logistics Invoice Verification

In LIV transactions MIRO and MIR7, system considers the following fields when checking duplicates for both Accounting (FI) and Logistic Invoice (MM-IV) documents:

• Company code (BURKS)
• Document date (BLDAT)
• Reference (XBLNR)
• Currency (WAERS)
• Vendor (LIFNR)
• Amount (RMWWR/WRBTR)

Transaction XK02 (For ERP systems). Flag "Chk double inv" needs to be checked for the specific vendor under the "Payment Transactions" section (Company Code data).

Transaction OMRDC. Checkflags depending on the required fields need to be checked for the specific Company Code.

If all the customizing is correctly set and a duplicate invoice is created considered the points above, there are two messages which could be expected:

• M8 462 - Check if invoice already entered as logistics inv. doc. number & & (if duplicate logistics invoice documents are found)
• M8 108 - Check if invoice already entered under accounting doc. no. & & (if duplicate accounting documents are found)

Both of them are called in functions MRM_DUPLICATE_INVOICE_CHECK and MRM_FI_DOCUMENT_CHECK respectively and can be set as errors or information messages in transaction OMRM.

2572664 - MIRO: Invoice blocked due to date variance

You can use transaction code MRBR to delete the block reason and release the blocked invoice.

SPRO->Materials Management->Logistics Invoice Verification->Invoice Block->Set Tolerance Limits->Tolerance Key “ST”->Upper limit->Absolute, select “Check Limit” and set the absolute upper limit as, for example "51.37". This amount will be used to determine whether block for date variance should be set or not. (See Details in "Cause")

2948075 - MIRO/MIR7: Invoice Verification with manual exchange rate does not have any influence upon LC2 and LC3 calculation.

During transaction code MIRO processing, you have input manual exchange rate from the "Detail" tab and from your expectation, manual exchange rate will have influence upon amount in local currency 2 {LC2) and amount in local currency 3 (LC3). But if you check the Accounting document, you may find that the exchange rate between Foreign currency and LC2/LC3 are not the one you input in the "Detail" tab.

Same applies with other MM relevant transaction code. (MIR7, BAPI_INCOMINGINVOICE_CREATE/1, BAPI_INCOMINGINVOICE_PARK, MM-EDI, MRRL)

As in Material Management of Invoice Verification, we are only responsible and will only influence the exchange rate calculation up till amount in first local currency (LC1).

LC2 and LC3 determination and calculation logic are being derived either FI or CO area.
- If Material ledger (ML) is being active, then the corresponding exchange rate determination logic will taken from "Controlling (CO)" area
- If Material ledger (ML) is not being active, then the corresponding exchange rate determination logic will taken from "Financial (FI)" area.

1674290 - Determining Invoice Posting Values

Invoice posting values always have to take all previous postings into account, particularly if the indicator 'GR-BASED IV' is not used.

REMNG = total quantity of goods invoiced
WEMNG = total quantity of goods delivered
MENGE = total quantity of current invoice document
AREWR = Sum of posting values of all invoice receipts to GR/IR clearing account
WEWRT = Sum of posting values of all goods receipts to GR/IR clearing account
VWERE = The GR/IR clearing amount to be post
WERT = The current invoice item posting value

2684845 - LIV: Posting logic for Service items

The posting of a service item depends on a new "GR/IR Clearing" indicator which has been introduced in Release 4.70.With this indicator set, the GR/IR clearing account will be totally cleared regardless of the amount posted to the invoice.

When cancelling the service invoice from MR8M, the GR/IR account takes precedence, so the indicator will not matter in here (it is greyed out)

2535485 - MR8M: Error M8283 occurs while cancelling an invoice via MR8M

3059707 - How not to maintain CO objects in GR/IR Account

It is required to clear CO objects such as Cost Center, WBS, Functional Area from WRX in FI documents.

Invoice Verification Online (MIRO) transfers the CO objects from the PO (for the GR/IR line, despite the account is a balance sheet account) to the accounting modules

A substitution can be used that can fill or change any account assignments according to the substitution rules defined by the user in OKC9

2519546 - Different Number Range required for Credit Memo in case of Purchase Return

Within transaction OMR4 and the standard coding, the system does not derive an Invoice / Credit Memo Number Range based on whether the Purchase Order is setup as Standard / Return.

2612071 - MIRO: Proposal logic for exchange rates

An invoice is created in a document currency (which differs from the local currency entered in the transaction OBY6), and the exchange rate on the invoice items and taxes is different.

In the transaction MIRO there are two exchange rates, one for the invoice times (RBKP-KURSF) and one for the taxes (RBKP-TXKRS). Although they are both exchange rates, they have difference in its proposal logic, which sometimes is not clear.

Proposing logic for the exchange rate on the invoice items (RBKP-KURSF):

1. The system will check, whether there was a fixed exchange rate in the Purchase Order and will propose it.
2. If the exchange rate was entered manually in the MIRO transaction (header), the system will take it as the KURSF.
3. If an exchange rate was entered neither in the Purchase Order nor in the MIRO, the system will propose the translation date (WWERT), and calculate the exchange rate according to customizing set in transaction OB08.

Proposing logic for the exchange rate for the taxes (RBKP-TXKRS):

1. MIRO will propose the exchange rate on the taxes, based on the following setting (which can be also customized in the transaction OBY6): In case the transaction date for the taxes is the document date, the exchange rate on the tax and invoice items can differ, which can lead to differences and additional posting lines.

2071682 - FAQ: Distributing unplanned delivery costs in the case of follow-on invoices/multiple account assignment

844861 - EDI: Transfer prices

You enter an incoming invoice from IDocs with the IDoc type INVOIC and the function module IDOC_INPUT_INVOIC_MRM and the IDOC contains the segment E1EDP05.
If the segments contains valid transfer price data (CURTP, KOEIN, BETRG), the system copies the transfer price data and enters the invoice as "Transfer Price" (IVTYP = 7).
the system does not copy additional data of segment E1EDP05, for example, vendor conditions.

539793 - MIRO: User-specific document type

For MIRO the document type is determined from the Customizing settings (Transaction OMR4->Document types in invoice verification). Here a document type can only be assigned to a transaction and not to a specific user.

As of Release 4.7 you have the option of preassigning the document type via the BADI function module 'MRMBADI_HEADER_DEFAULT' (package MRM_BADI, function group MRM_BADI) user-specifically.