How to do PGI from different sales order stock from the current sales order

[sanjay_ram]

Hi,

This is pertaining to sales order stock costing.

If i have 2 sales orders A and B, can i do PGI for sales order A using stocks from sales order B?

One way to do this is, transfer the sales order stock from B to A using MIGO and then do the PGI for A using the transferred stock. However this is a 2 step process which the users will not like. Is there a single step process to achieve the same?

If there isn't any, then i am thinking of creating an user exit so that during the VL01N saving, the system will transfer the stocks from B to A in the background via the user exit so that the stocks will be available in A, just before the actual PGI.

Does this make sense? My only worry is, will the system check for stock availability at the time of VL01N saving and won't allow the saving due to insufficient stocks in A?

If that is the case then i have to use the user exit before such stock availability check is carried out...Any user exits to suggest?

[Former Member · Accepted solution]

Hi,

Hope you got the same material in sales order A and B, in such case you can use back order transaction V_RA it will help you to transfer confirmed stock from one order to another.

please check and revert back if you need more details

Regards

[sanjay_ram · Accepted solution]

Hi Sarath,

Like i said, the customer does not want a 2 step process. How to make it a single step?

[sez41 · Accepted solution]

It is not good-practice, I might say. Technically you can make it a one-step process by creating an output after delivery creation (in your output program you can write the logic to transfer stock), but

- What if a user changes delivery quantity?

- What if delivery gets deleted?

[sanjay_ram · Accepted solution]

- What if a user changes delivery quantity? - The same user exit will also be there in VL02N to ensure sufficient qty is transferred as per the new delivery qty.

- What if delivery gets deleted? - It is okay to leave the stocks in the Sales order A as long as sales order A is not deleted yet. The user exit will be smart enough to transfer only the required qty from B after taking into account outstanding balance left out in Sales order A.

[sez41 · Accepted solution]

Another thing to consider: What about batches or serial numbers?

If you are sure enough that further possible complications will not bring more headaches than go for it. But I'm not sure about the user exit part. Badi IF_EX_LE_SHP_DELIVERY_PROC~CHANGE_DELIVERY_ITEM might work but would need strong regression testing. Activation of method IF_EX_LE_SHP_DELIVERY_PROC~FILL_DELIVERY_ITEM might be necessary as well.

[sanjay_ram · Accepted solution]

Hi Kivanc,

I thought batch numbers are not specific to sales order stocks?

Which means all batch numbers are available for both sales order stocks and normal stocks.

Am i wrong here?

[sez41 · Accepted solution]

If you material is batch relevant, your sales order item stock is kept in table MSKA. In that case, in order to initiate goods movement, you'd have to give the specific batch number you'd want to transfer.

Which means all batch numbers are NOT available for both sales order stocks and normal stock if your item has special stock indicator "E" (which relates to your case).

[jignesh_mehta3 · Accepted solution]

Hello Sanjay,

Hope you understand, User Exit will be "smart enough"till the extent of issues foreseen at the time of development and regression testing. We all often witness loopholes in the complex Z-developments which lead to further Z-developments in future to plug the holes.

Rather than a custom development at Development at Delivery level transferring the Sales order stock of Sales Order A to delivery of Sales Order B, I would suggest to develop a Z-Transaction that will call V_RA or MIGO in background & reassign the stock.

Still if the users insist and you have to go ahead with Z-development in Delivery, you should enhance it further to add some information in Sales order A regarding the Stock transferred to Delivery of Sales Order B. This will leave tractability incase someone needs to investigate in future or needs a report. 

Thanks,

Jignesh Mehta

[sanjay_ram · Accepted solution]

That will be a problem then, let me think how to handle this batch number issue then. I will post it here if i can find a solution.

[sanjay_ram · Accepted solution]

Fully understand it sir, but bringing a change in over 100 plants is a nightmare. Since sales order costing is introduced half way, we need to ensure it does not add more steps in the current operation. That is the objective.

[sanjay_ram · Accepted solution]

Hi Kivanc,

In SO A, if we select the material by batch number (regardless of the sales order stocks) in VL01N, then will the system allow me to select stocks from SO B?

[sez41 · Accepted solution]

I could not understand your question. Please refer that if your material is batch-relevant and your sales order item has special stock indicator "E", you have to post relevant batch to sales order item stock before posting goods issue.

[sanjay_ram · Accepted solution]

Yeah you are right, but i have not given up, give me a day or two, will find a work around for this and update it here.

[RAF]

HI,

first of all you will have Problem that A does not have sufficent confirmed quantity schedule line which is normally the Basis for the delivery quantity.

Then delivery is checking during creation the ATP - so again stock is missing.

If you bypass all these obstacles keep accounting in mind.

Normally for MTO with SO stock you do SO calculation. now the posting from B to A can cause some Revenue + or -

Please ceck if you are using with MTO/SO Stock the correct Scenario.

BR

[sanjay_ram]

Hi Robert,

I know what you mean but the advantage is the system will only check for stock availability during PGI and not during delivery creation. As such during delivery saving i can transfer the required stock from B to A just before the PGI.

But i don't understand your last point as to the revenue plus or minus. What do you really mean by that?

[RAF]

Hi,

please set a breakpoint in function module availability_check.

For me atp it is called within delivery creation.

"Revenue": You have SO B which is calculated with value/cost of 1000.

Now you repost to SO A which has mayba a different calculation based on and value is only 800.

So the PGI will create accounting with -200 ...

BR

[sanjay_ram]

Hi,

You may refer to the following 2 forums which confirms the availability check is done at the PGI step :-

http://scn.sap.com/thread/2071842

https://scn.sap.com/thread/2044746

With regards the price difference you are referring to, it will get actualized when we run Material ledger at month end.

[RAF]

Hi,

yes at PGI it is hopefully done as well.

See also note 36520 and customizing for your item category

[sanjay_ram]

Hi Robert,

Alright i will take note of that OSS note.

[Lakshmipathi]

If i have 2 sales orders A and B, can i do PGI for sales order A using stocks from sales order B?

Did you try doing manual availability check for order A before posting here?  With standard configuration, system will certainly allow you to do PGI irrespective of when the sale order was created and subject to stock availability

G. Lakshmipathi

[sanjay_ram]

Sir the stock to be PGIed for SO A is stored with SO B as a sales order stock. SO A do not have any sales order stock qty so have to transfer from SO B to A.

[Former Member]

Hi,

can u explain what determines the priority of sales order A than B,

if you want to release stock from a less impotent customer consider (B group) group those customers using customer master- sales tab- customer group.

--> tell your abaper to write an enhancement in Va06 transaction to filter sales orders according to customer group.

-->do required Z dev to release stock from less priority customers

-->then filter high priority customers and allot released stock in to the orders

use logic of V_V1 and V_V2 to reconfirm sales order.

All these process can be done from one screen if you can build a logic by considering  above points and its quite flexible

Regards