warehouse picks in Manufacturing

Fisherman

Is there a configuration in NAV5 that would allow the user, from a handheld device (barcode scanner), to drive from which lots/bins inventory were taken, rather than having the WMS (from the production order) driving it? Basically, to pick what I actually did, rather than what the system told me to do.

djswim

There shouldn't be.... I know this sounds crazy, but WMS in NAV, once turned out, forces you to do the right thing. If something got put in the wrong place (which shouldn't happen unless someone is actively trying to mess things up), you should have to make an adjustment prior to the pick working.

This is why turning on WMS in NAV should only be done when processes and training are top notch, otherwise it will make your life a living hell.

Maybe there is a way to do it, but there really shouldn't be... the power to do an inventory move/adjust shouldn't be in the hands of someone when they've only been sent out to do a pick... a pick/put-away should be used for that.

Fisherman

dj -

I disagree. specific lot and bin tracking is not important to all companies. We don't have specific requirements to FIFO - only to tie the component lots that were used to the Finished product. Therefore, we need lot tracking, but we don't need suggested picks.

This situation is compounded if you have have bulk storage locations for pallet storage, and each storage location may have multiple lots within it. It is important in that case to identify which items and quantities of lots are in a specific bin for inventory tracking. In this example, if you were to continually maintain a physical FIFO flow on the floor in order to meet the system's rigid demands, you would eat up all profitability in warehouse overhead to constantly move inventory around, assuming that you didn't spend tons of money installing flow-through racking. This is not an efficient way to manage business, and ERP is all about improving the economics (efficient use of resources...) of your business.

Designing a WMS so that it only works when you use single-space bins and single-bin lots is limiting to the point of insanity - it forces you to conform to only one style of production/warehousing.

Does anyone know how to late bind inventory to a production component line in NAV?

djswim

It's possible I misunderstood your question...

You're talking about getting a pick list with bin tracking turned on (Tells you #,Item No., and Bin), and picking from somewhere other than where it says on the pick list, right?

This has nothing to do with FIFO, or lot tracking (seperate issues), it has to do with knowing where things are... if you don't need to track by bin, then don't use bin tracking (I pray you're not already using it)... if you turn on bin tracking, you have to do what NAV tells you, because people shouldn't be telling NAV one thing and doing another when it comes to inventory movements.

Now, if you're talking about controlling where you want the item to be picked from prior to the pick list being printed, that's a completely different thing.

Fisherman

I'm saying that the users need to be able to select where the parts are on the floor, not where the system told them to go.

We don't (often) have the situation where the system said it was in bin A, and the user found it in bin G. It does happen OCCASIONALLY, but we try to control our inventory better than that

More often, you have the situation where Lots 1, 2, and 3 are in bin A, but Lot 1 is in the middle of a mass of pallets. Rather than picking lot 1, since we don't have a requirement to pick in lot order, we might pick lot 3.

This raises a good point, though. I would contend that NAV should allow for what other systems call a "late" or "empty" reservation. This is the idea that says "I need 400 pcs. Report back to me what you did". I'm not saying that it should enforce it, but it should allow it. This type of system would need for the Production Order Component, for example, to create a requirement in the system (through reservation entry, or whatever table is pertinent) for the Item, agnostic of Lot and Bin, and then have that that Reservation updated from the scanner/handheld device.

For example - If I start with a general requirement of 400 pcs of Item A on Production Order 1, then I write a "reservation entry", with no Lot or Bin information:

Item A, Production Order 1, 400 pcs

Now, my warehouse employee scans 100 pcs of Item A, lot 123 from bin 99, so why can it not be written to "split" the original reservation, leave the remaining quantity as a general reservation, and record what I just did. In other words, my original entry becomes:

Item A, Production Order 1, 400 pcs
Item A, Production Order 1, -400 pcs
Item A, Production Order 1, 100 pcs, Lot 123, bin 99
Item A, Production Order 1, 300 pcs

This would be consistent with the Ledger approach to inventory that NAV takes everywhere else... or, if you were using flow fields into Reservation Entry/Tracking, you could say

Item A, Production Order 1, 400 pcs
Item A, Production Order 1, -100 pcs
Item A, Production Order 1, 100 pcs, Lot 123, bin 99

My contribution aside, the primary issue is that I need for the warehouse employee doing the job to tell the system what he did, not for the system to tell my warehouse employee what he SHOULD do.

[edit] - Having worked for a large manufacturer before, I can tell you that this is where the concept of "Empty-bin Cycle Counts" is critical. The concept that having the system tell you where to go will uncover unexpected out-of-stock conditions and invalid product putaways is valid, because it makes those discrepancies between your ledger and your floor painfully obvious. However, we found that prompting the user to confirm that the bin is empty when the system thinks it is empty, or having them confirm that there is none of the specified item/lot is left in the bin when the system thinks that there should be, was just as useful. It's a simple prompt (Y/N) that was used when picking from a scanner after the pick was registered that could trigger a cycle counter to follow-up. This obviously was not NAV

djswim

I understand what it is you're trying to do, I'm not sure if NAV allows that or not... it's my understanding that if bin tracking is turned on, it's on all the time in the manner that I described.

Good luck though, I'd certainly like to know if the feature you're looking for exists.

kine

Fisherman wrote:

Is there a configuration in NAV5 that would allow the user, from a handheld device (barcode scanner), to drive from which lots/bins inventory were taken, rather than having the WMS (from the production order) driving it? Basically, to pick what I actually did, rather than what the system told me to do.

Of course, but it will need some customization. You do not need WMS at all if you just need to track serial/lot numbers. All what you need is to do interface for the mobile HW to be able to add tracking informations for selected documents (PO, TO, SO). WMS is really needed when you need to have system driven stock. But if I understand correctly, you want to have "man" driven stock. It means "just give the correct tool to the men, and he will tell to system what to do...".

Fisherman

That's precisely it - with one exception. They want the system to be able to tell them where the material is for inventory purposes. I thought about turning off WMS altogether at the onset, but they want to know which bin something is in.

I will keep working on it. I just didn't know if there was some configuration to do this.

djswim

If you allow pickers to override bin tracking and you have any sort of decent sized facility, NAV won't know where your inventory is for very long... not saying anything bad about your facility in general, it's like that everywhere I promise.

Fisherman

Not following you -

They shouldn't be allowed to take materials from a place where it didn't already exist in the system - that's just a bad idea. But, they should be able to override the suggestion, so that if the system wanted them to take the material from bin "a", but they have information that tells them that it's better to take it from bin "b", and the system actually records that they took the inventory from bin "b", then why does NAV care? Really, the only answer to that question is that it was architected to be this restrictive, but my question is... why? In most other respects, NAV is a framework that allows you to configure it to meet your processes, but WMS seems to be the "red headed stepchild" in that respect (no offense to red-headed step children )

I would not advocate allowing the user to record a pick from a bin where the system did not think that the material was to begin with. I'm saying that the system is not God (believe me - as a programmer, it pains me to say that ), and should therefore provide the flexibility to respond to conditions on the floor, and to respond to the processes in-place. In the particular instance in which I'm working - we know we need Item X, and the system sees that Item X is in bins 1, 2, and 3. If the system wants to suggest picking Item X from bin 1, then that's fine, but don't stop my user from saying that bin 1 is not accessible right now, and that he's going to pick from bin 2 instead.

This is, in fact, one of the principle tenants of ERP - that the system is not your process, but rather, that the system must reflect your process. It would appear that MS has made the NAV WMS run in such tight constraints that this can't be the case.

kine

All depends on tools used. E.g. our customers are using only the bin functionality from WHS, without need for picks. They have special forms for PDAs where they can see what to transfer (based on standard Transfer Order), they scan the serial no/lot no which they are transferring and that's all. System knows, what is on which bin, we added some info to the form to show users which lot is recommended by FIFO, on which bin it is, but they can freely scan another lot... Easy to develop, you just need some form and connect the information to some transfer order and create tracking for the lines through this...

Mig

Thank you for all your help.... =D>

David_Singleton

This is quite an interesting topic. My feeling is that Navision works on the principle (as Kamil indicates) that either the system tells the user what to do, or the user tells the system what to do. It doesn't have a mid solution, where the system "suggests" what to do, but allows for picking differently. Or at least it allows it, but its not easy.

As a specific case we had a client similar to the case above, where for expedience it was better to allow the pickers to pull the item closest at hand, instead of hunting for the item the system suggested. In fact the pickers were adamant that they would need many more staff if they had to follow the suggested picking proposal. After a while of analyzing the reality, I could see that we had a self fulfilling prophecy. What was happening was that the pickers were opening the nearest box to them to get the items they needed. Or they might need to pick 10 items, and the system was saying to pull 3 form one bin, 2 from another and 5 from another. When in fact there was a bin with 10 available. So being "efficient" and wanting to save the company money (not because they were lazy) they pulled the 10 and then went back and the di bin movements to fix the quantities. My involvement came when they wanted to automate this so that it would be easier to pull the 10.

But since I never believe customers, I went and did my own analysis, and it was very clear what was happening. The pickers were messing up the bins basically every item instead of have 50 in one bin, was spread over 4 or 5 bins. So every time they worked efficiently by pulling the easiest items, they made even more work for the next picker. What we did was simply disabled (through permissions) the ability for them to do the adjustments. After about 6 months the bins were sorted and the problem resolved.

So two lessons. One is try to train users to do their job properly before writing code, and second, sometimes in trying to fix a problem we can actually make it worse.