Have you ever wondered why planners tend to rather use a safety stock with MRP Type 'PD' to buffer variability, as opposed to a reorder procedure? Oftentimes PD is used across the board and no one wants to bother with another MRP type. However, with SAPs standard configuration the safety stock doesn't serve as a planning buffer and the additional inventory ends up being dead stock.

 

Consider the following scenario: a safety stock of 30 pieces is set and a production order asks for 10 pieces on April 15. A deterministic planned material (PD) would replenish the inventory up to 40 pieces just before April 15. If, for some reason, the production order would increase the required quantity to 15 pieces two or three weeks before its start date, the MRP run (which excludes safety stock in the net requirements calculation) would generate an additional order proposal for 5 pieces. In that case, the inventory on April 14 would be 45 pieces... even though 40 would be plenty (25 more than needed). Simply speaking: safety stock is taken out of the planning efforts and the entire safety stock remains unused (...becomes dead stock).

 

 

 

A far better solution, in my opinion, is the use of a reorder point method. If we're taking the same example, we'd set the reorder point to 30 pieces and thge MRP run would only replenish if the inventory level is lower than 30. During the replenishment lead time these 30 pieces serve as a true buffer and are consumed by regular consumption. Any safety stock that is set, is only used as a signal (exceptional message) when inventory gets really low. As you can see in below graphic, this method is a true buffering strategy.

 

 

Switching your policy from a PD with safety stock to a reorder point procedure will instantly reduce your dead stock and bring average inventory holdings down. If you're concerned about stock-outs, increase the reorder point. That is much better than never dipping into safety stock.

 

(note: if you're adamant about using PD. you can customize SAP so that at least a portion of the safety stock is considered as a buffer for planning)

When you create an STO, do you know it is one-step or two-steps transport? When you

create delivery for the STO, can you judge if the movement type system determined is correct or
not?

 

In this blog, let me introduce my way to check these points.

 

★Whether the STO is considered as 1-step?
    debugging screen.jpg

 

As you can see in the picture above, system check table T161W with supplying plant+ recieving plant +
document category.
The document type of the STO is not a key for determination at all. You can check

table T161W to see if this STO is considered as one-step or not.

 

★How system determines the movement type?

    Afterwards, system checked the delivery item category, in T-code VL03N you can see it,

    for example the delivery item category is NLRN. Then in the following customizing:

   
    IMG->

         Sales and Distribution ->
               Sales -> Sales documents ->
                      Schedule lines -> Assign schedule line categories

 

system founds the schedule line category, for example it is NR. At last, in T-code VOV6, for Sched.line cat NR,
you can see there is setting: 

      

    ******************

    Movement Type             671

    Movement Type 1-Step   677

    ******************

 

Therefore if the STO is one-step transport, then the movement type will be 677 in the delivery. Otherwise it will
be 671.

Hope this can be helpful. You may also want to read KBA 1774717 - Table T161W - document type not taken into account.

Working as a FICO consultant on a number of different projects, I noticed that nearly all of my clients had a common issue: The GR/IR (goods received/invoice received) account. In theory, you raise a purchase order, the goods arrive, and you post a goods receipt. This acts as an accrual posting between costs or stock and the GR/IR account. If the quantity on the invoice equals the quantity posted in the goods receipt, the GR/IR should clear down to zero. Regardless of whether the quantities match, if the price doesn’t match the invoice could be blocked for payment.

On occasion, users couldn’t understand why a balance remained on their GR/IR account or why an invoice continued to be blocked for payment when they thought that the process had completed correctly. Often at the year end their GR/IR account had accumulated a large balance, which the accountants struggled to analyse for the resolution of any errors.

Somehow I always ended up involved not only in helping tidy up the account, but also explaining quite a lot about the process. I thought it would be a good idea to put everything I knew about it down in one place; an SAP PRESS E-Bite.

My E-Bite (link below), explains how the whole invoice verification process works and gives tips on how to optimise the flow. It begins by outlining the key settings in the vendor, material, and GL account master data, and the effect that they have on the behaviour of the purchase order and goods receipt, and therefore the way the matching takes place with the invoice and credit notes.

I noticed many users were either unaware of the different document types or unclear on which to use when. For example, when to use a credit memo and when to use a subsequent credit. Using the wrong document type may inadvertently create a balance on the GR/IR, where one did not exist before, or not clear one that should be cleared.

One chapter of the E-Bite explains the financial postings of all the documents and another goes through various reports and gives tips on how best to analyse the GR/IR account.  Just because there is a balance on the GR/IR account doesn’t necessarily mean that the invoice is blocked for payment; nor does a payment block mean that there is a related balance on the GR/IR account.

I firmly believe that, where possible,  you should correct errors at the source, so, if for example, a purchase order price is incorrect, it’s usually best to proactively make the corrections to the purchase order and/or the material/purchase info record. If a goods receipt or invoice is incorrect, simply removing the payment block risks having the incorrect stock, leaving a balance on the GR/IR and affecting the moving average price etc.

There are a number of scenarios where it may not be possible to correct the error at the source, but the good news is there are various transactions in SAP that you can use instead. I explain in my E-Bite which ones to use when.

My (non-SAP) sister was very excited when she heard that I had a publication with my own ISBN number.  I don’t know if she was expecting the next JK Rowling, but when I explained what it was about, she looked blankly at me and said “err -that’s not exactly going to fly off the shelves!” However; I do hope it is useful to some people, (other than for bed-time reading), and that there may be helpful information inside that not everyone is aware of.

https://www.sap-press.com/invoice-verification-with-sap-payment-blocks-in-grir-accounts_4052/

Storage Location Determination Rule by Qty & then Storage Location Priority.


This concept is used in most of the Industry where stock of a material is available in multiple storage loaction & there is a requirement that during Receipt or Issue system should consider the Qty as well as Storage location based on the business requirement.

 

In the below Screen Shot we can see the stock of a raw material available at 4 different Storage Location.

Stock.jpg

As in this case we are determining the stock based on Qty first & then Storage Location

Step01:-Firstly we create a Stock Determination Group with T code OSPX,

Stock Determination Group.jpg

 

 

Step02:-Assign the Stock determination group to material master

Material master.jpg

Step03:-Create a Stock Determination Rule & do the assignment of Plant, Stock Determination group & stock determination rule T-code OSPX


OSPX.jpg

 

We define the Priority of Storage Location as shown below.

 

Based on this priority of storage location will be determined.

 

Step04:-Now we assign the Stock determination rule to the respective Movement type

  1. Path:-SPROàMaterials ManagementàInventory management & Physical InventoryàStock DeterminationàAssign Stock Determination Rule in the ApplicationsàInventory Management

Movement Type.jpg

This completes the configuration Part.

 

 

 

Now for example we issue this Raw material to check how system determines the storage location priority.

Issue.jpg

As we press Enter system determines the stock based on Qty & then storage location as below

Storage Loc 201.jpg

 

This is how we can manage the stock of material based on Qty, Storage Location for all respective Movement types (i.e. receipt & issue).

Very often, when working in SAP support, we receive incidents of users asking us to find out the root-cause of an issue that happened in the past but that is not happening anymore. The answer for this kind of inquiry is usually "please provide a reproducible example of the issue on your system" and frequently the person who opened the incident cannot provide this example, but insists to know the root cause of the issue.

 

 

Let me explain what is our troubleshooting line on an application issue, in order to show how important is this reproducible example. When an incident is received by SAP Support, the following steps are carried out by the person assigned to solve the incident:

 

1 - General research on the documentation: In order to understand if the issue described is according to the system standard design or if there is a customizing to change the system behavior, the first step is to research on the documentation for a better understanding of the scenario. This research may include SAP Help, wikis, SCN or internal documentation and this step may be skipped if the scenario is already known.

 

2 - Notes search: If the research on the documentation points that the behavior described by the user is not planned, the second steps is to search for notes that may fix the issue or explain the scenario from a technical point of view. This notes search includes notes with code correction, modification notes, consulting notes, FAQ notes and KBAs.

3 - Search for similar problems: If there are no reference on the documentation or on notes, the next steps is to make a research in an internal database for similar issues described in the past. This is a very useful source of information, and we can find details about the analysis already made on a similar issue by another support engineers or developers.

 

If none of the above mentioned alternatives bring a solution, then the next steps is to analyze the issue directly on the system where it is happening. In this case, the best way to do it is to reproduce the scenario in the SAP internal test systems and then compare with the scenario on the system where the issue is happening.

 

When there is no master data or customizing setting difference that could explain the cause of the issue, there is only one option

we must run a detailed investigation using the debugger, to analyze the program execution and to understand why there is a difference between the SAP internal test systems and the system where the issue happens. In most cases, it is necessary to debug both systems in parallel, in order to understand where is such difference.

 

Below there are some very common issues, that it is generally only possible to find out the cause of the issue analyzing a reproducible example in debug:

 

1 - Database inconsistencies: Generally, a database inconsistency is only identified after it already happened. In this case, SAP can generally provide a correction report to fix the inconsistency. Analyzing the inconsistent data on the database tables is not enough to find the root cause of the issue, because the same table can be update by many different programs or transactions. Running the transaction without being able to recreate the inconsistency it is also not enough, since it will be only possible to observe the standard program flow.

 

2 - Issues caused by user-exits, BAdIs, modifications or customer enhancements: Very frequently, the issue is caused by a custom code implemented on an exit, BAdI, modification or enhancement. In this case, it is also necessary to analyze a reproducible example in debug, since the custom code implemented is not known to SAP. By running a reproducible example on the customer system, it is possible to jump the custom code in debug, in order to identify if the issue lies on the standard SAP code or on the custom code.

 

3 - A short dump or any issue that happens randomly: It is very common that an issue, such as a short dump, happens randomly on the system and the user cannot track exactly the steps to recreate this short dump. In some cases, the short dump provides useful information that helps to identify what is causing it, but this is not always true. Sometimes, the short dump does not provide enough information and it is necessary to reproduce the issue, so that it is possible to see the values of the internal variables and how they are calculated.

 

4 - A problem that happened in the past and it does not happen anymore: It is usual that an issue is observed on a system once and then it never happens again. Considering my area of expertise, I usually hear that the MRP results are incorrect, but when I try to run MRP again for the same material, everything is perfect. Unfortunately, it is not feasible to keep logs of everything on the system, as it would increase the database size and lead to performance issues. Therefore, sometimes it is not possible to interpret the results of an MRP run that happened in the past. The same is valid for all the areas.

 

If you take a look on the SAP 9, it explains that the when the issue is not reproducible, it may not be always possible to find out the root cause of the issue.

 

Therefore, before opening an OSS incident to SAP, please try by all the means to track the steps to reproduce the issue on your system. If this is not possible, please be comprehensive if you are asked for a reproducible example and try to understand if it is not possible to find out the root cause of the issue without this example.

Finally here is the part 2 of Invoice Tolerance keys which is the continuation of part 1  .

 

KW: Variance from condition value

Definition:

The system calculates the amount by which each delivery costs item varies from the product of quantity invoiced * planned delivery costs/ planned quantity. It compares the variance with the upper and lower limits defined (absolute limits and percentage limits).

1.png

 

 

System Behavior:

PO Qty = 100 EA

FRB1 = 100 SGD

 

GRN Qty = 100 EA

 

IR Qty = 100 EA

Planned delivery cost = 110 SGD

 

Variance (KW) = 100 * (110/100) = 110 which is 10 SGD more than PO but within the tolerance hence No warning message.

 

If planned delivery cost is 111 SGD

Variance (KW) = 100 * (111/100) = 111 which is 11 SGD more than PO value above the tolerance hence below warning message will be issued and invoice will be blocked for payment.

2.png

 

 

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

KW

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRP = X

(Price block for Delivery cost line)

NO


LA: Amount of blanket purchase order

Definition:

The system calculates the sum of the value invoiced so far for the order item and the value of the current invoice and compares it with the value limit of the purchase order. It then compares the difference with the upper percentage and absolute tolerances defined.

3.png

System Behavior:

PO Limit = 1000 SGD

GR not applicable

IR1 Value = 500 SGD

IR2 Value = 510 SGD system allows without any warning message as the variance = (500 +510)=1010 is compared with PO limit 1000 SGD which is within the tolerance.

If we try to post the invoice for 511 then system would throw below pop-up message. Still we can post the invoice which will be blocked for payment.

4.png

 

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

LA

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRP = X

  1. Yes. If we adjust the PO overall limit


LD: Blanket purchase order time limit exceeded

Definition:

The system determines the number of days by which the invoice is outside the planned time interval. If the posting date of the invoice is before the validity period, the system calculates the number of days between the posting date and the start of the validity period. If the posting date of the invoice is after the validity period, the system calculates the number of days between the posting date and the end of the validity period. The system compares the number of days with the absolute upper limit defined.

5.png

System behavior:

Scenario 1:

PO Validity end date: 03/12/2015

Posting date : 13/12/2015

No warning message because (13-03)= 10 days is within tolerance

 

Scenario 2:

PO Validity end date: 03/12/2015

Posting date : 14/12/2015

Warning message as below since variance is above tolerance (14-3) = 11 days. It will be blocked for payment .

6.png

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

LD

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRT = X

  1. Yes. If we adjust the PO Validity end date

 

PP: Price Variance

Definition:

 

The system determines by how much each invoice item varies from the product of quantity invoiced * order price. It then compares the variance with the upper and lower limits defined (absolute limits and percentage limits).

When posting a subsequent debit/credit, the system first checks if a price check has been defined for subsequent debits/credits. If so, the system calculates the difference between (value of subsequent debit/credit + value invoiced so far) / quantity invoiced so far * quantity to be debited/credited and the product of the quantity to be debited/credited * order price and compares this with the upper and lower tolerance limits (absolute limits and percentage limits).

1.png

System behavior:

Scenario 1:

PO Price :100 SGD / Item

PO Qty  -:100 EA

PO Total value : 10000 SGD

 

IR Total amount: 10010 SGD

IR Qty  - 100 EA

System would allow without any message. Since the variance is (10010 – 10000) = 10 SGD which is within the tolerance.

 

Scenario 2:

PO Price :100 SGD / Item

PO Qty  -:100 EA

PO Total value : 10000 SGD

 

IR Total amount: 10011 SGD

IR Qty  - 100 EA

System would pop-up below message. Since the variance is (10010 – 10000) = 11 SGD which is above the tolerance and it will be blocked for payment.

2.png

Scenario 3:

Invoice & Subsequent debit:

For the same PO Qty & amount if we do invoice as

IR Qty = 100 EA

IR Value = 10000 SGD

Then

Subsequent debit as

Qty = 100 EA

Value = 10 SGD

No warning message since the variance (already invoiced value+ current subquent debit value – PO amount ) = ( 10000+ 10 – 10000) = 10 is within tolerance.

 

If the value is 11 SGD then system would pop-up below message

  3.png

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

PP

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRP = X

  1. Yes. If we adjust the PO Price

 



PS: Price variance: estimated price

Definition:

If the price in an order item is marked as an estimated price, for this item, the system calculates the difference between the invoice value and the product of quantity invoiced * order price and compares the variance with the upper and lower tolerance limits defined (absolute limits and percentage limits).

When posting a subsequent debit/credit, the system first checks whether a price check has been defined for subsequent debits/credits, If so, the system calculates the difference between (value of subsequent debit/credit + value invoiced so far) / quantity invoiced so far * quantity to be debited/credited and the product quantity to be debited/credited * order price. It then compares the variance with the upper and lower tolerance limits defined (absolute limits and percentage limits).

4.png

                           This works same as ‘PP’ tolerance key when the PO price is flagged as Estimate price.

 

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

PS

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRP = X

  1. Yes. If we adjust the PO Price

 



ST: Date variance (value x days)

Definition:

The system calculates for each item the product of amount * (scheduled delivery date - date invoice entered) and compares this product with the absolute upper limit defined. This allows relatively high schedule variances for invoice items for small amounts, but only small schedule variances for invoice items for large amounts

   5.pngjavascript:;

System behavior:

Scenario 1:

PO item value: 100 SGD Per item

PO Qty = 10 EA

PO Value = 1000 SGD

PO Delivery date: 03/12/2015

 

IR Value = 1000 SGD

IR Qty = 10 EA

Invoice entering date = 02/12/2015

 

Variance = PO item amount * ( PO delivery date –Invoice entry date)

               = 100 (3- 2) = 100 *1 = 100 SGD

This is within tolerance hence no warning message.

If we post the invoice on 01/12/2015 then variance would be

            = 100(3-1) = 100(2) = 200 SGD

This is above the tolerance limit hence invoice would get blocked for payment.


                          There won’t be any warning message for date discrepancies before posting the invoice

 

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

ST

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRT = X

  1. Yes.

 



VP: Moving average price variance

Definition:

When a stock posting line is created as a result of an invoice item, the system calculates the new moving average price that results from the posting. It compares the percentage variance of the new moving average price to the old price using the percentage tolerance limits defined.

6.png

System behavior:

 

Material master MAP price: 100 SGD

PO Price = 100 SGD , Quantity = 10 EA and Value = 1000 SGD

Invoice value = 1060 SGD

New MAP after invoice posting = 1060/10= 106 SGD

Variance = (106 – 100 )/100 = 6%

Within PP tolerance limit but above the VP tolerance limit.

Below information message will pop-up and Invoice will not be blocked for payment. Based on this tolerance key we can make the below info message as Warning or error before posting.

   7.png

With this I have completed all the tolerance keys relevant for Invoice Posting.


P.S: There is one more tolerance key PC which is used for invoice with reference to Contract which is not covered in this article due to technical reasons.



More than a few times the analysis of issues regarding conditions in documents like POs, SOs, etc have me checking their Condition Record as the first step. Be it Message Output Type or Pricing Conditions or Tax Conditions. Also, for request like View Condition records through Table from my Master Data team or colleague  so that they can take dumps of the same or check if the request for maintaining a certain value in the Condition Record, recently I have the best possible answer for them. I owe this discovery to a senior Technical Consultant who showed me what i consider a trick !

 

First we go to the display transaction of the corresponding condition record MN06, VK13, FV13, MN03, MN09, MN15, MRM3, etc

Since I am an MM consultant will go with MN06 here for illustration purpose;

 

On the first screen we can select any Key combination for the desired output message, here we have 0003

1.PNG

 

Then we are prompted to choose the key combination, we will choose any as our objective is a complete list of values maintained irrespective of a particular Key combination chosen now;

2.PNG

The trick now is to fill the mandatory field (with anything, giberrish will do as shown below ) and hit the Condition Info button.

3.PNG

We are again prompted to select the desired condition,

4.PNG

now we see a screen with no mandatory fields

5.PNG

and on execution of the same.. TaDa !

6.PNG

We have the list of all the values maintained in the condition record. For further beautification click the ALV button on top and we have options to search and extract this data.

7.PNG


Hope you find this as useful as I do. Would love to hear back from you on this and all else

Wishing you a good life !

Archit

Hi


Reversal of Invoice (Credit Memo) hit Price difference account in case of multiple Invoice booked against a Purchase order and logic, how system is calculating GR/IR clearing account at the time of Credit Memo.



When the account movements are determined, the following items are taken into account:

-Credit Memo Quantity

-Credit Memo Amount


Invoice Quantity Greater than Goods Receipt Quantity


Invoice Surplus and Remaining Credit Memo Quantity


Calculation for posting in FI document for

Excess Invoice Quantity = IR reversal Qty  * (Total GR Amount  - Total LIV Amount ) / (total GR Qty - total IR Qty )


Remaining Credit Memo Quantity = IR reversal Qty  * (Total GR Amount) / (Total GR Qty)



The sum of these values is posted to the GR/IR clearing account. The credit memo amount is posted to the vendor account.


Tables to be refered for calculation

Total GR Qty = EKBE-MENGE with VGABE = 1

Total GR Amount  = EKBE-DMBTR with VGABE = 1

Total LIV Amount = EKBE-AREWR with VGABE =2

Total LIV Qty = EKBE-MENGE with VGABE = 2

In case of Delivery cost refer EKBZ table.


Note: The system will not necessarily reverse the exact amounts, It depends on several factors: goods-receipt-based invoice verification, service based, any changes to the fields, etc.When you cancel an invoice, the system posts a credit memo for the data in the invoice. The postings are made in accordance with the creditmemo posting logic. This means that the postings in the invoice are not necessarily reversed. This is especially the case when an invoice is to be cancelled for a purchase order for which several invoices have already been posted. GR-Based IV does not play a role in case of delivery cost.


Invoice Quantity Smaller than Goods Receipt Quantity

If the invoice quantity is smaller than the goods receipt quantity, the following values are calculated for the credit memo quantity.

This value is posted to the GR/IR clearing account.

The credit memo amount is posted to the vendor account.


Note: If the credit memo amount is different to the posting to the GR/IR clearing account, the difference is posted to the stock account or a price difference account, depending on the price control defined for the material.



Example: Material with MAP

 

Purchase Order with 100 Pc @ $11.00/Pc. (PO Based Invoice Verification)

 

Goods Receipt 80 Pc.

Accounting Entries

Stock Dr. - $800

GR/IR Cr. - $800

 

(Off setting entry posted to GR/IR Clearing Account)

GR/IR to be cleared can be viewed in MB5S.

 

First Invoice

Invoice amount $720 for 60 Pc & New Price Per Pc. $12.

 

Vendor Cr.  -  $720

GR/IR Dr.  -  $600

Stock Dr.  -  $120 (If enough stock coverage) OR

Price Difference Dr. - $120

Here GR/IR Account is cleared for 60 Pc and amount $600. Remaining GR/IR to be cleared is $200.

Note: The invoice is different to the purchase order price. The difference between the purchase order value and the invoice value is posted to the stock account if there is sufficient stock coverage.

 

Second Invoice

Invoice Amount $548 for remaining 40 Pc. & New Price Per Pc. $13.70

 

Vendor Cr.  - $ 548

GR/IR Dr.  - $ 494

Stock Dr.  - $ 54 (If enough stock coverage) OR

Price Difference Dr.  - $54

 

Another Goods Receipt

 

Goods receipt Qty * Invoice Price

10 Pc. X $13.70 pc = $137.00


Off setting posted to GR/IR Clearing Account


Credit Memo


Calculation for GR/IR Clearing Account

Note: The total of the excess invoice quantity and the remaining credit memo quantity is posted to the GR/IR clearing account. The credit memo amount is posted to the vendor account. The credit memo amount is different to the posting to the GR/IR clearing account. The system posts the difference to the stock account if there is sufficient stock coverage.


Second example (GR Based Invoice Verification)


PO Qty = 100 Pc & $10/Pc


GRN = 50 Pc

Accounting Entries

Stock Dr. - $500

GR/IR Cr. - $500


First Invoice = 50 Pc

Accounting Entries

Vendor Cr.  - $500

GR/IR Dr. - $500


Second Invoice = 10 Pc with $11/Pc

Accounting Entries

Vendor Cr.  - $110

GR/IR Dr. - $110

 


Third Invoice = 10 Pc with $12/Pc

Accounting Entries

Vendor Cr.  - $120

GR/IR Dr. - $120

 

Credit Memo for Third Invoice Qty = 10 Pc

Accounting Entries

Vendor Cr.  - $120

GR/IR Dr. - $115

Price Difference Account Dr. - $5.0 (System will hit PRD account even if there is sufficient stock coverage)




Service PO


Service PO for 10 Qty with $100 Net Price per Qty


Service Entry Sheet for 8 Qty = $800

Accounting entries in GRN

Service Account Dr. - $800

GR/IR Clearing account Cr. - $800

 

Invoice for amount $500

Accounting entries

Vendor Cr. - $500

GR/IR Clearing account Dr. - $800

Service Account Cr. - $300

 

Credit Memo

Accounting entries

Vendor Dr. - $500

GR/IR Clearing account Cr. - $500

 

Service Entry sheet reversed with Qty 8 = $800

Accounting entries in GRN

Service Account Cr. - $500

GR/IR Clearing account Dr. - $500

 

Note: When you see Purchase order history, it will show you wrong amount for Goods receipt.

 

 

SAP KBAs

 

1609927 - MR8M / Credit Memo postings

 

46564 - Cancelling/reversing an invoice/credit memo: Posting logic

 

127832 - Invoice verifcation: Price differnces w/ credt memo

 

323607 - Invoice reversal for services

 

 

SAP HELP LIBRARY


Postings for Credit Memos - Logistics Invoice Verification (MM-IV-LIV) - SAP Library


 

Thankx to all

 

Kaushal Sharma

Hi,

 

Objective:

    Recently I have implemented BAdI(ME_PROCESS_REQ_CUST) for ‘Direct purchase Requisition   creation Restriction against the Work Order(WO) with order category ‘30’ (Maintenance order )’.

   If user tries to create PR (Me51n) with Accountassignment Category ‘F’ with WO which has order category ‘30’ (Maintenance Order = ‘30’) then system will throw error message.

 

The Error message is  Sorry you cannot create direct PR with order category 30(mainta.Order).


How to do this?

You can use transaction SE18 to implement it.

 

  1. Go to transaction SE18.

1.jpg

 

2. Press 'Display'.

 

3. From the menu Implementation->Create

1.jpg

 

4. Give your implementation name as below (starts with
Z...). Here I have given as zme_process_Req_cust
.

 

1.jpg

  

5. Then give implementation short text as you like.

 

6. Then click 'Interface'  tab and select method 'PROCESS_ ITEM' (BY DOUBLE CLICKING).

1.jpg

  

7. In this method,please add the following coding.

 

 

method if_ex_me_process_req_cust~process_item.

  

include mm_messages_mac . "useful macros for message handling

  

data:   it_items_ref             type  mmpur_requisition_items,

 

        wa_items_ref             type  mmpur_requisition_item,

 

        ls_item_ref              type  ref to if_purchase_requisition_item,

 

        ls_item                  type  mereq_item,

 

        ls_acc_ref               type  ref to if_accounting_model_mm,

 

        wa                       type  mmpur_accounting_type,

 

        ls_accounting            type  exkn,

 

        ls_mmpur_accounting_list type  mmpur_accounting_list,

 

        ls_mereq_header          type  ref to if_purchase_requisition.

 

  
  data: lv_aufnr type aufk-aufnr.

 

  
ls_mereq_header   =   im_item->get_requisition( ).

it_items_ref      =   ls_mereq_header->get_items( ).

 

 

loop at it_items_ref into wa_items_ref.

         ls_item_ref   = wa_items_ref-item.

         ls_item       = ls_item_ref->get_data( ).

 

   if ls_item-knttp = 'F' and ls_item-estkz = 'R'.

 

   ls_mmpur_accounting_list = ls_item_ref->if_acct_container_mm~get_items( ).

 

 

loop at ls_mmpur_accounting_list into wa .

           ls_acc_ref    = wa-model.

                  ls_accounting = ls_acc_ref->get_exkn( ).

 

       select single aufnr  from aufk into lv_aufnr  where aufnr = ls_accounting-aufnr and autyp = '30'.

 

           if sy-subrc eq 0.

 

          message e026(zq) with ls_item-bnfpo.

 

        endif.

  

  endloop.

      
  endif.

endloop.

 

endmethod.

 

8. Finally 'SAVE' and 'ACTIVATE'.

=====================================================================================================

 

How to create error message?

 

Here in the above coding, my error message is E026 with message class ZQ.You can use transction code SE91, you can createyour own message.

1.jpg

=========================================================================================================

 

 

Testing:

 

9. Now try to create PR(me51n) with Account assignment category ‘F’ with WO (WO has order
category =’30’(Maintenance order),then you will get error message
Sorry   you cannot create direct PR with order category 30(mainta.Order). So , you cannot complete your PR..

 

1.jpg

 

 

I welcome your  suggestion, please. Thank you.

As we all know if we post material document which is relevant to valuation, an FI document will be created subsequently.
A typical MM/FI inconsistency would be the material document is generally while the FI document is however missing.
If ML(material ledger) is activated system will issue error C+048 and no more goods movement is possible for the material.
In the worst situation, period closing activity will be affected and even causing auditing issue.
(This is the same content moved from Chinese forum as per quest from peers)

 

Here will give a detailed explanation, possible reason and the way to prevent it:

  •   The important user-exit and BAdI

    • material document missing FI document
    • FI document missing material document
    • check mechanism to prevent it
  •    Relevant SAP notes

 

The important user-exit and BAdI

During goods movement, there're many requirements to implement customer specific checking logic, so BAdI

 

MB_DOCUMENT_BADI and User-exit  EXIT_SAPLMBMB_001(include ZXMBCU01 / enhancement component MB_CF001)

are the ones to be often used. If there're inappropriate command(from note 92550) below implemented in the BAdI or user exit,

MM missing FI could happen:

  • COMMIT WORK
  • FROM MEMORY
  • Remote Function Call (CALL FUNCTION .. DESTINATION)
  • Own updates on the document or stock tables (for example, an update on the table MBEW, MARD, MSEG)
  • Unlocking data (for example, by DEQUEUE_ALL)
  • ROLLBACK WORK
  • MESSAGE TYPE 'A'
  • Calling a dialog box (POPUP_TO_CONFIRM, for example)

 

  • material document missing FI document

        Here I'd like to introduce the concept of SAP LUW. LUW is "Unit Logical Unit of Work" and usually there're
        Database LUWs and SAP LUWs. SAP LUW is used to keep consistency of application programs that are executed

        across different work processes, and the updates are first registered and then executed by a single work process.

        One of the techniques is known as update task(via update function modules: CALL FUNCTION...IN UPDATE TASK).

 

        BAdI MB_DOCUMENT_BADI is called after the update function module MB_UPDATE_TASK, so if there is COMMIT WORK

        in MB_DOCUMENT_BADI method MB_DOCUMENT_BEFORE_UPDATE, SAP LUW will be destroyed.

8-18-2015 1-17-30 PM.png

 

   Considering sequence below:

  • Material document:

          Call function 'A' in update task.

          Call function 'B' in update task.

      
          BAdI  MB_DOCUMENT_BADI (method MB_DOCUMENT_BEFORE_UPDATE)
          COMMIT WORK -> update of material document is triggered and database MKPF/MSEG will be updated.

      

  • FI document:

          Call function 'C' in update task.

          Call function 'D' in update task.
         ->If there's any error happens at this stage, system can only rollback C and D while material document
            cannot be rolled back any more as it has been already written into database.

 

You may still have concern, why the issue does not always happen. Sometimes twice or three times in a month?
As shown in above flow, you could understand it only happens when LUW is destroyed i.e. there's error afterwards however
system can no longer roll back the whole transaction completely. If there's no error then with 2 times of COMMT WORK,
you can still see both material document and FI document are created.

 

  • FI document missing material document

        Similarly, if there's inappropriate ROLLBACK in user-exit, FI document missing MM could happen as well

  • Material document

         Call function 'A' in update task.

         Call function 'B' in update task.

      
        BAdI  MB_DOCUMENT_BADI (method MB_DOCUMENT_BEFORE_UPDATE) ROLLBACK is triggered
        -> material document update is cancelled

      

  • FI document

        Call function 'C' in update task.

        Call function 'D' in update task.

 

        Standard COMMIT WORK is executed, and only FI document is updated into database

 

  • check mechanism to prevent it

       
        We've got lots of customer incidents reported with this kind of inconsistency. The correction can only be carried out
        by SAP authorized engineer with debugging so we implement the checking mechanism in note 1776835

        to prevent such inconsistency. This note implement the coding to catch and track the inappropriate COMMIT

        or ROLLBACK in customer coding, and once it's detected system throws short dump to terminate the process.
        In transaction ST22 call stack, you can see in which user-exit or BAdI COMMIT/ROLLBACK is triggered, and then

        you have to review the coding with your ABAPers and correct it accordingly. So we highly recommend you to
        implement the note to prevent MM missing FI inconsistency. It's always necessary that customer development obey
        the rules and keep the completeness of SAP LUW.

 

SAP notes      
Regarding the MM/FI inconsistency topic, you can also refer to SAP note below for details:

  • Note 968812 MM-FI Differences caused by ROLLBACK or COMMIT
  • Note 92550  Stock inconsistency due to customer enhancement (exit, BAdI)
  • Note 1284654  Caution with implementations of the BAdI: MB_DOCUMENT_BADI

Hi Friends,

 

    I would like to share a situation which I faced recently in a trading company and how the issue was resolved.


Issue Description:

 

  •     In Material master, the negative stock is not allowed for the material.
  •     In customizing in OMJ1, the negative stock is not allowed for the plant and storage location.

 

    With the above condition, there should not be any negative stock for the material in the plant. But business came up with  a situation as there is negative stock for the material!!!

111.png

 

    We started analyzing the details and the reason for the inconsistency. While checking the material document table, we identified that two material documents (delivery for sales order) has been posted within a time difference of 88 seconds with "Total Valuated Stock Before Posting" as same quantity.

1112.png

     We checked the material document and found its a PGI document for sales order. The document flow for the sales order showed as below:

1113.png

         Now, we have one sales order, one delivery, 2 PGI documents against the same delivery and one invoice document!!!!

 

    Since the material document was posted wrongly, we suggested to cancel the PGI in VL09. But there starts the next issue - system was not allowing!!!

1114.png

 

    In fact, system was issuing the same message for any goods movement for the material! This was very critical since the material was a fast moving material and business can not stop due to inconsistency in SAP!  Since PGI was done, initially we defended by another question: We need to understand from the business, how the stock got issued physically to the customer if there was not enough stock!!!!

 

     But the the situation was strange and difficult to convince the business. Customer even started doubting the credibility of SAP!!  On further analysis, its found that the issue has been explained in the SAP Note: 935755 - Negative stock even though this is not permitted in Customizing !!. The note was a turning point!

 

      The note clearly explained the reason for the situation - It could be due to late update or due to custom procedure for goods movement. But in our case, the goods movements are posted through standard only. So the reason was assumed as "late update", which was easy to convince the users since the time difference for the posting was 88 seconds.

 

       Now users started asking for the solution. Customer was not ready to move any configuration change to PRD, since it may create another inconsistency for any other material.

 

       We again depended on the note. As per the note, the situation can be resolved only by passing another goods movement for the material. So we tried the following:

 

1. Goods receipt with 202 movement in MB1A  - System didnt allow - error message (M7 314)!

2. Physical Inventory to correct the stock in MI09 - System didnt allow - error message (M7 310)!

 

       Now there was no option other than moving a configuration change to PRD. The were 2 options:

 

1. Allow negative stock for the plant, storage location and material  and cancel the PGI. - The option can be done only after business hours and after locking all users for the plant, since the system will generally allow negative stock for the material and if any users post goods movement, it may create another inconsistency!

2. Suppress the message M7 314 and M7 310 temperorly: This was the most suitable solution, since the message can be suppressed only for a specific user through message version and then post a goods movement.

 

      We proposed option 2 and convinced the customer. Now, question came - which goods movement has to be posted - cancel the PGI or 202 with cost center or physical inventory with MI09.


      But since there was two material documents against the same delivery, we were not sure which material document will be posted if the PGI is canceled. If only one is cancelled, again it will be an inconsistency!  At last, we proposed to process 202 against cost center in MB1A and the issue resolved.

 

       In short, the issue was resolved with following steps:

 

1. Suppress the message M7 310, M7 314 in the path: OLMB - Define Attributes of System Messages, with a different version:

1115.png

2. Maintain the parameter ID: MSV with value as the message version number in SU3 for the user who is supposed to do the goods movement.

 

3. Goods receipt against cost center with 202 movement in MB1A for the quantity issued wrongly.

 

4. Once the 202 movement was posted, material stock shown correct quantity and value in stock reports.

 

5. Remove the parameter ID : MSV from the user master.

 

     This resolved the critical issue! Hope it will be useful for others who faces similar issues.

 

     Thanks for going through the blog and thanks for your time.

 

Regards,

Prasoon

Hello Everyone,

 

In this blog I would like to point out a system behaviour which was noticed while Plant creation/copy. As this is a forum of experts, would love to hear your thoughts on the observation explained below;

 

CASE 1:

For the first case we create a new plant afresh.

T-code  OX10/SPRO is used for defining the plant and then all the required assignments and configurations are made in the system with respect to this plant. When we define the Plant, Plant master table T001W is updated with the corresponding entries. When configurations like Company code and Purchasing Organisation assignment,Storage locations creation for this Plant, Valuation grouping code assignment to Plant; Tables T001W, T001K, T001L, etc are updated.

 

Here if we check the table T001W before assigning Valuation grouping code to the New Plant, the Valuation area column value will be missing. The same will appear after this assignment. Similarly, table T001K will have no values for the New Plant code created until a Valuation grouping code is assigned to this Plant.

 

CASE 2:

Here we create Plant by the SAP recommended technique of Organisational object copy Plant.

T-code EC02 is used to copy a Plant from an existing Plant. Here multiple tables are copied all at once, 142 in all, in my case of copy (which takes awhile). And yes i checked ! .The FROM Plant is the reference plant in business terms and the TO Plant is the new Plant you want created in the system (new Plant code required obviously).

In this case too the table T001W is updated appropriately, the created Plant code also appears as the Valuation Area in Table T001W and T001K.

 

CASE 3:

Now, this is the case that has caught my interest.

Here the Plant is created in T-code OX10 (New entry or Copy available in OX10) or the respective SPRO path, wherein only the Plant code, Names and respective address details are entered and saved in the transport.

Now, unlike CASE 1 instead of manual configurations, we go and copy this Plant object using t-code EC02.

Observations in this case;


Table T001W has all entries copied except for the columns Valuation Area, Purchasing Organisation and Sales Organisation, as observed below;

Plant copy.JPG

Whereas, in table T001K the created Plant is visible as a Valuation Area.

valuation area.JPG

Additional observations are a Plant created in such a way may or may-not appear as a Valuation Area in transaction OMWD (Group together Valuation Areas).

Also, other Org unit assignments like: Purchasing Organisation to Plant assignment, is also not conventional as the status column has text missing which existed in the reference Plant. Also, the Material Type Valuation and Quantity update settings are not copied in this scenario.


Well, the solution to all these inconsistencies is really simple, but not an easy one if the Plant is live in production and has transactions made against it.

 

When you have a requirement to create a Plant with reference to an existing Plant, copy the Plant object first using t-code EC02 and the edit the details for the same in OX10.


And cases where you have created Plant as in CASE 3, inconsistencies can be removed by deleting the Plant object in transaction EC02 and creating it again in the SAP recommended process as described in CASE 2.


Refer to SAP KBA 1754880 - Some configurations are missing when copying/creating plant master in T-code OX10 for SAP recommended standard process of Plant creation.


Would love to hear your thoughts on this topic and all else !!


Auf Wiedersehen


Overview

 

Aim of this document is to show how price variance is calculated in a context of standard cost.

 

Standard cost, is a agreement between Engineering and Finance areas, regarding the price of raw materials and operative supplies, this estimated price is a key input to calculate gross margins.

 

PPV impact on Gross Margin

 

The Purchasing Price Variance or PPV is a warning flag that says that the gross margin will have variance, taking care about the situation, on a nimble way, enable the organization to keep margins going forward.

 

 

Our scenario is built it to buy 1,000 LB of raw material, where:

 

  • Standard Cost is 10 USD per LB
  • Order Price is 11 USD per LB
  • Actual Price is 12 USD per LB

Standard Price

 

First of all, we have our raw material master data created:

 

ppv-001

Purchase Order Price

 

Then, we create an order; price is above our estimated standard price:

 

ppv-002

PPV at Goods Receipt

 

Now, lets assume that we had received the material before the invoice, so a difference is calculated:

PPV during GR = Standard Price – PO Price

 

ppv-003

 

The journal entry for this GR is:

 

Inventory Account DR 10,000 USD Standard Price
GR/IR Account CR 11,000 USD PO Price
PPV Account DR 1,000 USD Balance

PPV at Invoice Receipt

 

Now, when invoice is received, we realize that market change and now, the actual price is different than the PO price

PPV during IR = PO Price – IR Price

ppv-004

 

Journal entry is:

 

Vendor CR 12,000 USD Actual Price
GR/IR Account DR 11,000 USD PO Price
PPV Account DR 1,000 USD Balance

 

This means that the net PPV is:

Net PPV = Standard Price – IR Price = 10 – 12 = -2 USD per LB

 

This is an unfavorable Purchasing Price Variance.

Net PPV

 

Now, on SAP there is a report that can be customized (configured) to get this Net PPV, this is:

 

ppv-005

 

You can use transaction MC$G, to get the report with data related to PPV.  This is infostructucture S012 that can be enhanced to take advantage of Logistics Information System features, or a simple query using structure S012 can be created.

 

How to enhance LIS for MM.

http://scn.sap.com/docs/DOC-50821

http://scn.sap.com/docs/DOC-50822

 

Note: This note was originally posted on my personal blog at angelreyes [dot] wordpress [dot] com

Dear Community,

 

Do you have queries from your business users around inventory management valuations regarding the changes of the moving average price of certain materials? If so you may have already noticed that the moving average price of materials can be changed by several different documents in ERP systems, for example: material documents, price change documents, invoice documents, production settlements or even credit memos or material ledger documents. Due to the complex cross-application knowledge required to find all these documents it can be quite complicated to access and review all relevant documents.


The goods news is that SAP has just released a new supportability tool to help you with the analysis of such scenarios. The new report is available for all SAP ERP releases starting from ECC 600 and can be installed as an advance correction via note 2198317.

For more information please visit the following SAP Wiki Page:
Unexpected changes in the Moving Average Price - MBMAPCHANGES - ERP SCM - SCN Wiki

Kind Regards,
Peter

JAHEER HUSSAIN,CRISTAL.

______________________________________________________________________________________________________________________________
Hi,

 

Objective:

 

    Recently I have implemeted Badi(ME_PROCESS_PO_CUST)  for 'Not allowing create PO(with dcoument type NBPJ and CRPJ) without PR.

 

If user tries to create PO(PO document type PJCR or NBPJ) with out PR,then system will throw error message.The Error message is "There is NO Purchase Requisition for this PO !".

 

How to do this?

 

You can use transaction SE18 to Implement it.

1.Go to transaction SE18.

1.jpg

2.Press 'Display'.

 

3.From the menu Implementation->Create

1.jpg

 

4.Give your implemenation name as below(starts with Z..) Here I have given as  zme_process_po_cust.

1.jpg

5.Then give implementation  short text as you like.

 

6. Then click 'Interface ' tab and select   method 'PROCESS ITEM' (BY DOUBLE CLICKING)

1.jpg

 

 

7.In this method,please add the following coding.

 

 

method if_ex_me_process_po_cust~process_item.


  include mm_messages_mac . "useful macros for message handling

 


  CALL FUNCTION 'MEPO_DOC_HEADER_GET'


    IMPORTING


      EX_EKKO = LS_MEPOHEADER.



  IF ( LS_MEPOHEADER-BSART = 'NBPJ' OR LS_MEPOHEADER-BSART = 'PJCR' ) .  "here I am checking my document type



    CALL METHOD IM_ITEM->GET_DATA


      RECEIVING


        RE_DATA = LS_MEPOITEM.



    IF LS_MEPOITEM-BANFN IS INITIAL.


     MESSAGE E025(ZQ).

   

    ENDIF.



  ENDIF.

 

 

 

endmethod.

 

 

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

How to create error message?

Here my error message  is E025 with message class ZQ.You can use transction code SE91,you can create your own message.

1.jpg

 

8.Finally 'SAVE' and  'ACTIVATE'.

 

9.Now try to create PO with your own PO document type without PR,then you will get error message and without rcreating PR,you can not complete your PO..However you can 'HOLD' your PO.

 

 

I welcome your suggestion,please.Thank you.

Actions

Filter Blog

By author:
By date:
By tag: