batch determination based on WM storage type stock positions

[Former Member]

Hello experts,

I am hoping the get some advise on the best method to achieve this:

We have batch determination turned on for select customers and the system is proposing stock that is mainly in our each or lose pick storage types (110), the issue with that is the fact that we do not pick in less then case qty for those customers so if the stock doesn't exist in our general storage the user must re-determinthe batch codes before delivery release.

This process is becoming very time consuming so I would like to improve it.

My first thought is to create a custom check in the batch search strategy that will only propose batch codes that exist in our general storage (search strategy based on WM stock positions)

Are there any other options to achieve a batch search strategy based in WM stock positions other then the one above and does that solution sound practical?

[Former Member]

"batch determination turned on for select customers" - is your BD setup at SD or WM? I'm assuming based on your subsequent notes that the BD is set up at WM.

Why cant you include general storage in addition to each or lose pick storage types so that the search is across various storage types. With the aid of a custom routine for quantity proposal (from BD condition record), you should be able to control the pick of full case (not sure how you are controlling this today).

[Former Member]

Hello, thank you for responding!!!

Our warehouses are WM managed and our system looks at all storage types for unrestricted stock that fits the batch search strategy durring batch determination. That is actualy what we would like to avoid, as you know the batch search takes place on the plant level but we need the batch search to happen on the storage type level to aviod the picks going to our lose pick.

It's the batch code selection that we need to change so that the actual batch codes populated in the delivery after batch determination are from the storage types we need to pick batch specifc from (due to the fact that we only send full cases or pallets to our batch specific customers).

Currenty we remove the batch codes proposed if the only stock of those batch codes exist in lose pick (110) only, this is what we would like to aviod, the manual removal of batch codes from 110 and reassignment of the qty to the batch codes in genaral storage is time consuming.

So it isn't as simple as sending the correct pick qty to the correct storage type, it's actualy before the delivery pick transfer order creation that we need to apply a fix. The fix must be in the actual batch code selection durring batch determination.

[Former Member]

Apparently, you are running BD at delivery level. Which means, any batch determined in delivery will be passed to the WM for the pick and therefore, you cannot have a subsequent BD at WM/Storage type level. There must already be a rational behind this question, but let me ask you any way. Why cant you include 'general storage' as well, in the picking storage type search. If the rational is that you need to pick full cases from these storage types then I'd reckon you may have to introduce a custom picking search strategy (MWMTO008 may suffice).

[Former Member]

Hello,

Yes, very sorry , we are running "BD" at delivery level as defined from our entries made with VCH1. This populates the batch codes in the deliveries before t.o. creation. Durring batch determination the system is looking at the plant level to find the correct batch codes, we over ride this manualy to aviod the 110 area. We have no issue at all sending the correct picks to the correct storage type (EG: case picks going to the 120, 310, 330 storage types durring t.o. creation / lose pick going to 110). So our picking search strategy is solid/working well. For the batch specific deliveries we would get "cannot find soucre storage bin" errors if we tried to release them with the proposed batch codes (the batch codes the system populates when the delivery is created) because they are often ONLY in the lose pick storage type.

So to answer "Why cant you include 'general storage' as well, in the picking storage type search"

We do include 310

[Former Member]

If I understand it correctly now, you want to drive the storage type search based on case/lose picks that are determined in the delivery. So, you may have to use the suggested enhancement to drive the logic to the appropriate storage type because I do not reckon any other standard way of accomplishing this.

[Former Member]

Thanks for your efforts but no you are not understanding (or I am not understanding you perhaps)

We need batch determination based on WM storage type stock positions, it's batch determination that needs to be defined based on stock positions not the type of picking after the BD is run.

[Former Member]

I'm not referring to the type of picking either (i'm not referring to picking strategies at all). I'm referring to storage type search criteria defined in OMLY.

"We need batch determination based on WM storage type stock positions" -> you are running BD at delivery level and therefore, there is nothing from a standard perspective that we can do to run BD based on WM storage type again. Since the BD has already occurred, we need to find other venues to direct the pick to the appropriate storage types.

This is what I'm understanding but I reckon there's something that I'm missing and so let's take the below example and then you can get back with corrections:

R001 plant

ZM01 storage location

Z01 WH

110, 120, 130, 140 storage types (110, 120, 130 are case/lose pick, and 140 is general)

Since you had mentioned earlier that the BD is running at plant level, I'd assume the storage location ZM01 is automatically determined (since the batch resides in ZM01). Since the batch is already determined, based on your 'storage search strategy' (110, 120, 130) the system tries to pick this batch in these storage types. Now, when there is no full case, you have to manually change the storage type to 140 to pick and this is where the problem is. So, I was recommending that since there is no standard way to automatically pick the full case from 140, use the enhancement.

[Former Member]

Thanks for not giving up on this. I think I see where we are confused, we do not change the storage type, we actualy remove the best batch codes that the system finds and populates in the delivery before we even attempt t.o. creation, when we remove them manualy we do a search manualy and enter batch codes that exist in the storage type we want to pick from. If I understand customer exit MWMTO008 it is for for defining the stock search strategy for t.o. creation and not batch determination. It's the batch codes that are found after availability check that's run on plant level that I need to modify. We currently use a custom batch determination by maintaining entries in VCH1, we currently run formula registation checks for select customers. I was thinking the only option for us would be to create a new custom check to trigger from VCH1 and use some basic material lookup program filtering on storage type so the custom check would only see the batch codes in the storage types we need to pick from. I hope that I am wrong and that MWMTO008 could be used for limiting the batch codes the system selects durring BD. Are we now understanding each other or am I possibly wrong about MWMTO008? (hoping I am wrong)

[Former Member]

Essentially, you want to run the delivery BD proposed batches into WM to identify the appropriate storage type before confirming the batch for actual pick, and you want to use the same BD logic. Well, it would have been easier if you had run BD at WM level but I guess you need to run BD at delivery since you have customer based logic. I do not think of any other way of accomplishing this besides the one you are suggesting.

[Former Member]

Close, I want to check WM for only the available batch codes that fit the requirement (age, formula registration,) AND only from select storage types so they system would not see or select the batch codes in storage types we do not pick from. The batch codes are populated in the delivery when it's created so the batch codes are already confirmed in the deliveries as batch split lines before we even go to create the t.o.

Honestly I think I may have dismissed the customer exit you mentioned because I did not consider turning off batch determination, now I am wondering if the user exit could be used to assign the correct batch codes durring t.o. creation.

Not sure how we could run the formula registration checks, Can you tell me the following:

Do you think we could turn off BD and use the cusomer exit to select batch codes

First by: only looking at select storage types

Second : formula registation check (batch code custom table check)

Third: FIFO or LIFO based on the customer requirements

Fourth: minimun remaining shelf life of the batch code

[Former Member]

Still unresolved...

[Former Member]

Thought one last bump might be appropriate before marking unanswered and closing

[Former Member]

No thoughts on the subject? (even a personal opinion would be welcome)

[Former Member]

Now the buisness is complaining as I expected they would...

THoughts?

[Former Member]

Are there any other options to achieve a batch search strategy based in WM stock positions other then the one above and does that solution sound practical?