on 07-27-2016 9:09 PM
When the TO is created it does not remove material from the first storage type in the sequnce
example
three storage types
001
002
003
storage type search sequence
002 001 003
if there is sufficient stock in all storage types the TO should select from 002 before selecting stock from 001 and lastly storage type 003
in practice it is removing from 001, then 002 , and lastly 003
I have confirmed that when creating the TO in the foreground the stock figures screen presents the available quants based on an alpha sort of the storage types and not based on the sort sequence from Storage type search sequence.
Has anyone else identified this?
is there a fix available?
thx
t
I have never seen an instance of SAP simply ignoring the sort sequence defined in the storage type search sequence for movement type, in every instance of unexpected storage type selection there has been a definitive reason for it. Whether it was related to the stock removal strategy maintained in for the storage type or some details of the inventory itself there has been some other underlying cause that influenced the systems behavior.
Perhaps you could post images of your relevant configuration, then perhaps we could point out the issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You are creating the TO in the foreground by going to the stock list and entering quantities in the stock list which is sorted numerically?
Personally I would not expect the system to consider the storage type search sequence while manually assigning pick quantities from the stock list...
Based on the screen shot of the storage type search the system will consider your search sequence during background processing.
Have you analyzed the search log or clicked foreground processing to confirm the system will follow the sequence you have maintained?
It seems you are expecting the search sequence entries to apply to the stock list but I do not believe that is the case by design. stock list is a different thing entirely
The "stock that can be removed ..." tab shows only storage types that are included in your storage type search.
The storage types are listed in ascending order here.
Whats missing for a full analysis is the stock situation.
Is there any stock in ATB storage type?
Is there any stock left in 111 after the proposed quantity of 200 is picked?
is there any stock left in 101 M99E if all 132 are picked?
is there any stock left in 101 M106E if all 132 are picked?
is there any other bin in 101 with stock of this material (which bin number?)
What is listed on the tab "Stock that cannot be picked"?
if the answer is "no" to the first 3 questions then I would say everything is in order.
About which business case are you talking when saying "stock removal" , picking for deliveries, goods issue for production orders, staging for production?
are your materials batch managed? if yes, is batch determination carried out in the referenced documents already?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If it is an attribute it is an unpleasant one.
As to your suggestion of this being due to stringent FIFO I say nay.
the quants all have the same GR dtae and the quant numbers as displayed in the stock figures display ( which complies with the alpha sort sequence I alluded to earlier ) does not indicate that the first quant having been the first created.
therefore I again state that this seems to be a violation of the ST Sort sequence ...
no this is not a violation of the sort sequence, it is nothing else than the docu explains: Strategy: Stringent FIFO Across All Storage Types - Warehouse Management System (WMS) - SAP Library
I will not engage in a further discussion of whether it is due to FIFO.
As I stated earlier
1. Stringent FIFO is not activated.
2 The sequence of removal is not FIFO either based on GR date nor Quant number.
Thank you for your input but perhaps someone has better insight into this functionality.
t
So, you say the process is for fixed bin replen (might of helped if you'd mentioned that in your original question).
Cheers
Custom Mvt 921 ... a clone of Std replen
Yes Ref = 921
in this case the removal strategy is as stated above 002 001 003
based on my observations I think that the eligible(based on all Storage types listed in the removal strategy) available stock quants are selected and then an alpha sort based on Storage type and storage bin is done in the program.
then the TOs are created from this sorted list.
thus violating the storage type search sequence
The list should be prepared one storage type at a time and the next eligible storage type quants appended to the bottom of the resulting list
thus preserving the integrity of the storage type search sequence
your thoughts?
t
Only that there is something wrong somewhere in your configuration, as I have used this many times and not experienced the results you are getting.
Unfortunately, my current client doesn't use this process so cannot even look at the set up.
The only other explanation is, as Juergen stated, something in your settings is driving stringent FIFO.
When you say that you use "Mvt 921 ..... a clone of Std replen" do you mean standard mvt 319 ?
If so, have you tried changing the requirement type from P-Production Supply to N-Replenishment for Fixed Bins ??
Cheers
User | Count |
---|---|
85 | |
7 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.