cancel
Showing results for 
Search instead for 
Did you mean: 

FI document generated from GR even though GR - no valuated indicator is set

Former Member
0 Kudos

Hello,

When I create a PO order and I select the GR no valuated indicator, I am expecting that no FI documents are created once I recieve the material (only the inventory quantity should increase). Basically, I want it to act like a UB STO at the time of GR....

However, even though no price is showing on the PO, when I complete a GR a FI document is created and  is a posting to the inventory account based on the receiving plant MBEW price....

PO showing U and no price

GR no valuated is selected

FI document which was created after GR shows a .12 cent amount

This amount is coming from accounting view of receiving plant ( 122/1000)

This same thing happens also when I check the "free item" indicator on the PO.

Is there a reason why this would be acting like this or how I can prevent this FI document generation? Is there a way to prevent the creation of FI document from GR via a BADI/Exit? The closest I could find was include  MM07MFF9_F_BELEG_ERGAENZEN but I dont think thats really the right place.

Note - I did find a similar issue through the below thread : http://scn.sap.com/thread/3326681


Accepted Solutions (0)

Answers (1)

Answers (1)

JL23
Active Contributor
0 Kudos

if you have a standard price valuated material, then the receipt is valuated at standard price, and the variance between the standard price and the PO price goes to a difference account. That was always so, no matter if the PO has a free of charge indicator active.

for me it is even questionable how you could get an active GR non-valuated indicator for an inventoried item. I have never seen this before.

Non-valuated GR was from my experience always only possible for account assigned purchases.

But this indicator if probably automatically coming if you have a zero price in the PO.

As said it has no impact on GR valuation because of standard price evaluation.

Former Member
0 Kudos

Hi Jurgen,

To answer your question first... I was able to do this based through debugging the PO Create BAPI used in a custom process we have for STOs (see below)...

Here is high level explaination of the process ( which I inherited... I do not recommend or design this etc).

For some of our plants, we have a custom STO process which when demand is generated on the receiving plant, the shipping plant creates a delivery document, and once its PGIed, we have a must BADI which will call the PO create BAPI and generate a PO (ZNB for inter and ZUB for intra) on the receiving plant side. So its more of a push process rather then the standard STO process which creates the delivery after the PO etc....

This process works nice for intercompany scenerios, but for intra company it causes issues (manual workaround on accounting side)  because both the document types are acting like a intercompany process, therefore a GR and MIRO posting accords for plants in the same company code.

I'm trying to figure out the best way to resolve this, and my 1st step was to pass the U in the item category and "check" the GR non value indicator.  This process works in that I am able to stop the MIRO document generation this way, but the GR is still creating a FI document.

Is there a BADI which could be used during GR save which would stop the generation of the FI document from the GR? Or anything else I might be able to do? My 2nd thought was o create a new document type which is a complete copy of a UB and have it act exac/tly the same way, BUT then the system is expecting a PGI after the PO has been created.

If  you see the thread I attached, it seems like this similar request but I wasnt 100% sure and was hoping to get some direction.

Thanks!

JL23
Active Contributor
0 Kudos

Do you want to say that you do not get the accounting documents if you use the standard UB process? I cannot imagine it.

in a 2-step standard process, you get the accounting document in the receiving plant in the moment of goods issue, because the goods issue is posted into the in-transit stock of the receiving plant. the receipt itself does not create any accounting doc because it is only a transfer posting from in-transit to the storage location within the same plant.

From what I read and see I would say that either the ZUB is not identical customized like a UB, or the PO creation from the BAPI is done like NB instead of UB. A UB order does usually not have a condition tab, your screen shot has one. And if the GR creates accounting documents like in a NB process, then the delivery did not recognize that it was actually against a UB kind of order.

I personally would try to isolate the error. which means I would start creating UB documents with the BAPI instead of ZUB, followed by a standard VL10B and a standard MIGO_GR. So I can finally know if the error is in  the document created by the BAPI, or in the customizing of ZUB.

Former Member
0 Kudos

Hi Jurgen,

Yes you're correct.. I'm trying to stop the FI document generation when completing the GR... The current process already stops the creation of a FI document during PGI of the delivery.

And yes - the ZUB is not excatly like a UB, because it does not ask for a supplying plant, and also doesnt require the U in the item category. I changed the BAPI to act more like a UB by inputting the data ( U in item category, no value GR etc) but you can see it still generated FI document after FR.

If  I were to have the process create a UB ( or another ZUB lets say) wouldnt it treat it as a standard UB STO, therefore requiring a VL10B to create a delivery etc (which would be wrong because the process has already issued out hte material from the intial delivery created)?

JL23
Active Contributor
0 Kudos

Oh I missed this part that you had already a delivery, I thought you create a STO just seconds ahead of the delivery. Of course would a new UB order create an entry in the delivery due list index

How do you create this delivery?

Why do you need this process like it is designed?

Can't you create a delivery without reference, for an item that does not  require a goods issue, just to have paperwork  like for normal deliveries.

And you do the material movements with a BAPI, just with movements 351/101

Former Member
0 Kudos

No problem I probably didnt explain it as clear as I should of...

High level process is:

1) MRP generates a PR on receiving plant, and transfer request on supplying plant

2) Supplying plant creates a delivery without reference (VL01NO)

3) Upon PGI of that delivery, the Z_MB_DOCUMENT_BADI is called which takes information from the delivery, along with a custom table which links the custom and vendor #s together ( similar to the standard STO configuration) , calls the PO_BAPI_CREATE1, and creates a PO in the receiving plant. It creates a ZNB or ZUB based on the delivery type from the delivery. Material is also issued out of the supply plant at this point

4) From there standard GR processing happens to receiving in material to receiving plant

This works great if its a inter company scenerio, but intra company it causes a lot of manual accounting fixes becasue of the GR and IR postings which generate.

My solution was to change it to act more like a UB (but without a need for delivery) but as you can see a GR posting still creates a FI document on the price of the material (not the PO - which is zero)

This is why I was starting to think of looking at a BADI or exit at time of GR which would stop the GR posting from according but still receiving in material ( Like a standard UB).

Hopefully that answers your question and gives more clarity... Its a tough one since its a custom process (in which I did not design but inherited) which hopefully we can change at some point, but for now that is not an option so I am looking else where.

Former Member
0 Kudos

Would it be possible or make more sense  to attempt to stop the FI document creation during the GR posting process instead... possible during the GR it calls the same function as which is called during the MIGO of a UB STO ?   Or if thats not possible then override the costs with zero values?