The warehouse task came out with the wrong Warehouse Process Type. You open the determination table, filter on your warehouse, and there is your entry — exactly as you configured it, pointing at exactly the right WPT.
So you look for the sequence number, to see what is sitting above it.
There isn’t one. This table has no sequence column, no priority field, nothing to drag up or down. And yet entries in it unmistakably outrank each other.
That is the part worth understanding, because it is not intuitive and it is not documented on the screen you are looking at. The rank of an entry is decided by its shape — by which fields you filled in, and more importantly by which ones you left blank.
A blank field here is not a wildcard meaning «any value». Leaving a field empty does not make an entry a broader fallback that applies when nothing better exists. It moves the entry to a completely different rung of a twelve-rung ladder — sometimes further down, and sometimes, unnervingly, further up.
This post is about reading that ladder, and using it backwards: from a task that came out wrong to the entry that actually produced it.
Two Things That Are Both True
Determination does not evaluate your table and pick the best match. It walks a fixed list of field combinations, from most specific to least specific, and asks the same question at each step: is there an entry where exactly these fields are filled?
The moment it finds one, the search is over. Nothing further down the list is read. Nothing is compared. There is no scoring, no best fit, no warning that a second entry also matched.
So «my entry is correct» and «the result is wrong» are not in conflict. They are the normal outcome when a more specific entry exists somewhere above yours — usually one that someone added for a different reason, months ago, for a case that happens to overlap with yours.
The one sentence to take away
A wrong Warehouse Process Type is very rarely a wrong entry. It is an entry of the wrong shape — yours is correct, and a differently shaped one further up the ladder answered the question before yours was ever asked.
If you have read the warehouse order post on which rule actually runs, this will feel familiar in outline, and it is worth being precise about how it differs. There, two separate sources competed: a rule named on the process type versus a search sequence on the activity area. Here there is only one table, and it competes with itself. Nothing else is involved. The entries you wrote are shadowing each other.
The Order Nobody Shows You
Four fields drive determination, on top of the warehouse number, which is always part of the key: document type, item type, priority, and the process type determination indicator (PTDI) that comes from the product master — the field Post 1 covered.
The system tries them in twelve combinations, in this order:
Read as a flat list of twelve, that is something to look up. Read structurally, it is something you can hold in your head — because it is not twelve rules. It is three blocks of four, and every block runs the same ladder: both extra fields, then priority alone, then PTDI alone, then neither.
Once you see that shape, you no longer need the list. You need two facts: item type outranks document type, and within any block, priority outranks PTDI.
The three rules that generate the whole thing
The item type is more specific than the document type. That is why every item-type-only access sits above every document-type-only access. An entry keyed on item type alone will beat your carefully built document type entry, every time.
Priority is more specific than the PTDI from the product master. Within a block, an entry carrying a priority wins over one carrying a PTDI.
The warehouse number is always part of the key. Process types are defined per warehouse, so nothing crosses warehouse boundaries — which is also why a configuration copied between warehouses can behave differently in each.
On what the priority field is called
You will meet this field under two names. Some screens and documentation call it delivery priority; the determination logic itself is described in terms of processing priority. It is the same input. This is worth knowing before you go looking for a field that seems not to exist, or conclude that two sources are describing different mechanisms.
First Question: Did Determination Even Run?
Before spending an afternoon in the determination table, rule out the case where the table was never consulted.
A Warehouse Process Type reaches a task by one of two routes. It is either determined when the warehouse request document is created — the path this series has been describing — or it comes from the individual step in process-oriented storage control. Work centre processing sets it too.
Whenever a warehouse task is created, a WPT has to be available from somewhere: either the warehouse request document brought one, or the process configuration supplies it.
This matters enormously for debugging, because in the second case your determination table is not wrong, it is irrelevant. A task created for the second leg of a two-step putaway takes its process type from the storage process step that generated it. You can edit the determination entry all afternoon and watch nothing change.
How to tell them apart quickly
Ask what created this task. If it came directly from a delivery — a putaway task off an inbound delivery, a pick task off an outbound delivery order — determination ran. If it is an intermediate leg of a multi-step movement, or something a work centre produced, look at the storage process first and leave the determination table alone.
Working Backwards, in Order
Once you know determination is genuinely the mechanism in play, the method is mechanical. Do it in this order and it resolves fast.
1. Read the WPT that was actually assigned. Not the one you expected — the one on the task. Open the task in the warehouse management monitor and read the process type off it. Everything else compares against this value.
2. Collect the four inputs for that specific item. Document type and item type from the warehouse request, the priority from the item, and the PTDI from the warehouse product master. All four, for the item that went wrong — not for the document as a whole.
3. Walk the twelve accesses top-down with those four values. At each step, ask whether an entry exists in your warehouse with exactly that combination filled in. The first one that exists is the answer the system got.
4. Compare where you stopped with where your entry sits. If you stopped higher up the list than your entry, you have found the shadowing entry and the investigation is over. If you stopped at your entry and the WPT is still not what you expected, the entry itself points somewhere you did not intend — a much simpler problem.
5. If nothing matched at all, you are looking at a different symptom entirely. No WPT could be determined, which is not the same failure as the wrong one being determined, and it surfaces at a different moment.
Step 2 is where this goes wrong most often, and it is worth being pedantic about. Determination happens at item level, because one of its inputs comes from the product. Two lines on the same delivery, with the same document type and the same item type, can legitimately resolve to two different Warehouse Process Types. If you collect the inputs at document level you will never reproduce the result.
The Four Inputs, and Where Each One Hides
Three of them are where you would look. The fourth is the reason this whole class of problem exists.
That last row deserves its own sentence. The PTDI is maintained per product, per warehouse, and per party entitled to dispose. It is not a property of the movement you are looking at. Nothing in the delivery, the task, or the determination table will tell you that a particular product carries one.
Which produces the single most confusing symptom in this whole area: two products travelling on the same document, through the same process, ending up with different process types — and no visible difference between them anywhere you were looking.
Where teams get burned
Someone needs a special process type for one urgent case. Rather than extend the existing entry, they add a narrow new one — keyed on item type alone, because that was the quickest thing that worked in the test. It solves the urgent case. It also sits above every document-type entry in the access order, permanently, for every document type in that warehouse. Nothing breaks that day. It breaks the next time somebody adds a document type and cannot work out why their brand-new entry is being ignored.
Symptom to Setting
The reverse lookup. Find the behaviour you are seeing on the left; the setting that produces it is on the right.
The Ninety-Second Version
When someone stops you in a corridor with this problem, this is the whole method:
What created the task? If it was a storage process step or a work centre, stop — wrong table.
What WPT did it actually get? Read it off the task, not off your expectations.
What are the four inputs for that item? Including the PTDI on the product, which means opening the product.
Is there an entry more specific than mine? Item type beats document type; priority beats PTDI.
Then read that entry. It is the one that answered.
This Week’s Practical Challenge
Open the determination table for one live warehouse and sort it by how many key fields each entry fills in. Then answer two questions.
How many entries are keyed on item type alone? Every one of them sits above every document-type entry in that warehouse. If there are more than a couple, and nobody can say why each exists, you have found where your next mysterious WPT is going to come from.
Is there an entry at access twelve — document type only — for every document type you actually use? That is your floor. Without it, a document type that matches nothing more specific gets no process type at all.
Both questions take about ten minutes and neither requires changing anything. The value is in discovering that the table has entries nobody in the room recognises, which is the normal state of a system that has been live for a few years and is exactly the condition this post exists for.
Closing the Series
Four posts, and really one idea: the Warehouse Process Type is the object every movement in EWM passes through, and almost nothing about it is visible from where the symptom appears.
Post 1 established what it is and where the PTDI lives. Post 2 split determination into its two mirror-image paths. Post 3 followed the movement through to the state the stock ends up in. This one turned the mechanism around and read it backwards.
If there is a single habit worth keeping from all four, it is the reflex this post opened with. When a task behaves in a way your configuration says it should not, the useful next thought is not what did I fill in wrong. It is what did I leave blank, and what did that blank promote.
Part of the Warehouse Process Type series
Start of the series
Deja un comentario