on 05-31-2016 4:23 AM
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?
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
- 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.
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.
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).
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
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
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
User | Count |
---|---|
97 | |
9 | |
8 | |
6 | |
3 | |
3 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.