Hi, Everyone I have the following problem with WMS: I created a warehouse pick for 53 units of item A. The item is stored in boxes of 50. Instead of breaking bulk i.e take 2 boxes and place 100 units, then take 53 units Navision created lines which take 1.06 boxes and take 53 units. We have entered the bin quantities using the warehouse item journal and we suspect that may have something to do with the problem.
I had the same frustration with WMS in it’s “break bulk” functionality. This is indeed the way the system works. If breakbulk was not allowed then the system would only recommend a picking quantity of 1 box or 50 units depending on the unit of measure entered on the order. The only way to fix it is through a modification… This is an area of deep frustration as it can really limit the usability of the product straight out of the box. MBS screwed up here by not getting some “real distribution people” in-house to review the basics of the picking and shipping flow prior to releasing this product. Basically, what we’re stuck with is functionality from Navision Advanced Distribution version 2.5 that never really worked that well in the first place and needed to have some major attention placed to the real usability of the product. The whole picking scenario within the product is unfortunately rudamentary and necessitates NSCs to really go in and do some major modifications to it to offer the funcitonality that many distributors need. Sorry…a pet peave that has never been answered and I’ve been tooting the horn of this product for years!
Not very encouraging, but thanks for the clarification.
If this is true I think I’ll just run down to Home Depot, get some good strong rope, and hang myself. We are (or perhaps were) planning to upgrade to 3.7 (from 2.6) in order to fix our warehouse management problems. Now, if I’m reading this correctly, new problems will be created by doing so. Generally, we sell our items in three units of measure: a case, an inner pack and an each. In Atanas example, we may have a case of 50, an inner pack of 5 (10 smaller boxes inside the case) and, of course, an each of 1. Additionally, along with his example, we may take an order for 55 each’s. The pick document in 2.6 comes out as one case and one inner pack. USUALLY! Sometimes you end up with a mess and have to start over. This is just one of our 2.6 headaches, hopefully there is an easy fix to Atanas issue and there are no more surprises. Bill, has your firm has any experience with correcting this issue? If so, perhaps you could give me a call at 330-422-1840 x212 so we can discuss. Thanks.
Atanas and Scott… Let me clarify something here. My level of frustration was within the WMS system for version 3.6. We implemented 4 different medical distribution facilities and in each one the same frustrating pains occurred with the recommendations of break bulk. When I have gone in and tested the scenario that Atanas has outlined IN VERSION 3.70, I’ve found some definite improvements over the systems handling of these activities. Here are the assumptions I made… 2 different stocking units of measure with PCS and BOX. 1 Box = 50 PCS Receive in 2 Boxes of product into a bulk area. Create a sales order for 53 PCS. The system recommended that I do the following: Action Type Zone Code Bin Code Item No. Quantity Unit of Measure Code Qty. to Handle Take Bulk Bulk 1 70000 2 BOX 2 Place Bulk Bulk 1 70000 100 PCS 100 Take Bulk Bulk 1 70000 53 PCS 53 Place Ship Ship 70000 53 PCS 53 As you can see, the system found the bulk product and recommended the user to go get 2 Boxes and then “break bulk” them into 100 eaches back into the same bin. It next told the user to go gather the 53 units in the Bulk bin that were on the sales order and place them in the shipping area. Nothing looks out of place with this scenario. Just to give you a “heads up” here are the setups I used. I simply put a flag in the Allow Breakbulk field on the desired location / warehouse card. Scott, now I know I’ve worked hand in hand with Navision support regarding the improvement of the 3.60 functionality in this area, and it actually looks like some of this works in 3.70. I’ll be straight forward with you on this as well. I personally have not had the opportunity to delve as much into this area on 3.70 as I would have liked, but from a cursory overview, it looks like its working. And while I may not be as versed on the specifics of 3.70, I do have access to many more educated people on this subject. In addition, I don’t know the specific issues that you’ve got regarding your current 2.60 woes, but would definitely be interested in talking in much more detail regarding those. I think that we can definitely help point you in a good direction. I’ve been involved with enough of these implementations and actually have enough contacts that we should be able to get you a solution to your needs. Feel free to call me as well at 770-639-2990. Now back to my original statement about the Navision’s out of the box functionality being frustrating…it still is. I fell like the only thing that has improved with the distribution functionality is in regards to how it actually integrates with the manufacturing portion of the product in its allowing better shop floor control, traceability, and serial tracking. But after almost 3 years of dealing with the same basic set of picking and put away rules, you’d really think there would have been some advancement here. I’ve had to work with programmers too many times to try and replicate basic internal decisions that warehouse workers go through when deciding picking scenarios. It’d be nice to have some sort of template for picking like the put away process to let the user better tailor the process. Again…the rantings of a Navision disciple…
Thanks Bill… Lets look at the example again…if someone orders 53 of an item that comes in boxes of 50, should you be instructed to open 2 boxes??? Wouldn’t it be more efficient (since that is what we’re trying to be) to pick 1 box and 3 pieces? Perhaps there are some industry specific issues here, but I would think in general you would want to take a sales order in whatever unit of measure the customer gives you. The picking of that order should be a separate issue and the most efficient method. The method I am describing is how 2.6 works. We do have issues with 2.6, but the basic logic used fits our industry. Anyone have any idea how hard it would be to get 3.7 pick in this fashion?
You are correct in a practical matter, but from a systems matter, it’s not quite that easy. First off, the customer ordered 53 pieces…so the system tries to pick just that. If the customer had ordered 1 box and then 3 pieces, then sure it would pick it that way as well. But also, how are you going to get those 3 pieces without “opening” the 2nd box? The opening process is what the picking of 1 box and placing 50 eaches in the same bin is replicating. What the system is doing is trying to make the inventory equal out as an internal transfer of 50 eaches to 1 box. Now you could put a “picking” process in place where all put-aways are done on a base UOM of pcs. So if you had 5 boxes of product come in, you put them away in pcs meaning that the system would record 250 pcs on hand. The trick would be to NOT physically break the boxes down into pieces and keep them in the box format. When a customer’s order comes in, it will instruct the warehouse to go get the order in pcs…yet physically the product would still be in the box…and the user would need to know that they would have to open the 2nd box up to get the 3 units. The problem comes with this approach is when a physical inventory takes place. If you instruct the warehouse inventory takers to record exactly what they see with both boxes and pcs, then you’ll end up really causing difficulties here. You would need to make them always make a count in pcs to keep this clean and enter the inventory only in pieces. Be aware that on the put-away document on 3.70 there is a function that will automatically convert the Box to a lower UOM and also recalculate the qty to make sure everything matches up. The problem is that this is a manual process that must be done for each put-awy doc. If you simply made a modification here to take advantage of this process to be performed at the time of document creation for all items that have lower UOMs, then your issues might just be solved. On another note, I just verified that if you receive in bulk and then put away in pcs / lowest UOM and have the allow break bulk flag on, if you have an order for a box, but only pcs in inventory, the system will ask the user to go physically take 50 pcs out of the storage and then place 1 box in the shipping area. The bottom line is that if you enter a sales order in pcs, and the system has inventory in pcs or boxes, it will convert the recommended pick to the sales UOM. The problem lies in that what the customer orders, may not be the most efficient picking methodology for the warehouse. The problem is that there is no internal logic within Navision to try and “optimize” any picking process to find the most logical way of picking. All the breakbulk functionality within Navision does is allow you to break larger UOMs into smaller ones.
Yes…and I just bought my rope…[;)]
To add to the matter is the fact that Navision only supports 2 units of measure! We had originally set up our Attain DB with three units of measure (pallets, cases, each). We then had a mod written that would make the Pick Tickets to first pull pallets, then cases, and then each qtys for orders that are placed in qtys of each. This functionality worked great, but we began seeing many problems with Bin Replenishment when using 3 units of measure. We got Navision involved and their reply was that Attain does not support 3 units of measure. This, of course, translates into our warehouse not operating as efficiently as possible since we are now required to use only case and each quantities. I must agree with crazy. I think I’ll follow his example and head to the hardware store. 
As it stands we have not received a “fix” that will correct all the errors with the Req. Worksheet (I think we have received at least 4 fixes from Navision), and we had received at least 3 fixes in regards to Bin Replenishment. I’m still testing the “newest” fix for Bin Replenishment and so far it looks good. Then again, I had thought that exact same thing in the past just to find out that there is a bug somewhere else in the code. If you all have any other experiences let me know. Thanks.
D’Oh!!! I guess I don’t get it. Wouldn’t you think it would/could keep breaking down into sucessively smaller units? I mean, why have the ability to set up unlimited units of measure if they don’t work? Quern…what version are you on? I don’t think the concepts here are new or revolutionary. Anyone else know of any other surprises? I’m in the middle of documenting our system mods so I can get good quotes for the upgrade. But this scares me a little.
Crazy Bean Counter: We are on the latest version of 3.7 thru product improvement 44 feature pack 2. We also have a movement worksheet hotfix that hasn’t been released to the general public yet. This fixed issues we had when replenishing bins. The issue was as follows. We had two fixed “each” locations and both needed replenishment but we only had one overflow bin with inventory in “case” qtys. Navision would break down the cases for fixed location 1, then break down cases for fixed location 2… the issue was Navision was breaking down cases in the second break that had already been broken down in the first break, therefore Navision was adding parts to the location that physically weren’t there. The other main issue we have been having is using the req. worksheet. This hasn’t worked properly since version 3.1 and still doesn’t work properly today. Navision is aware of the issues and we are waiting with abated breath for a final solution. We have gone through at least 4 individual hotfixes for this issue and nothing has fixed the issues we have had to date. I agree with you that we should be able to break units down into successively smaller units. In my opinion, this is a bug on MSB Navision’s behalf. Unfortunately they view it as an enhancement… only 2 units of measure are supported. Let me know if you run into any surprises on your end. Thanks.
The multiple UOM replenishment issue is partially due to the fact that the system makes a recommendation to break a bulk UOM into a smaller UOM. When it goes to the next line to create another replenishment recommendation, it repeats the same logic of breaking that bulk. The problem comes in that technically in the system, the action of breaking the bulk has not yet been performed. No registering of the movement has occurred. Unfortunately, as we normal people / laymen read the report, it seems to appear that it is recommending breaking down multiple pieces that don’t exist. We’ve had to make some hard coding fixes to ignore previous lines for replenishment on some of our customers to make this work well or simply make it a process to do one item / bin at a time. This works in some customers eyes but is not a long term solution. It does concern me at the lack of basic testing here and with the requisition worksheet. Par for the course on much of the dist funcitonality though…good try, but the follow through just hasn’t been there lately.
mumbles bad words
So why doesn’t Navision or a reseller write a better ADCS that is more flexible? We were looking into the ADCS and Warehouse management until we found out that the system was going to tell us where to put product/components as opposed to allowing us to decide or override. The quote we received to allow this type of flexibility was 4x the cost of the module in the first place. I also hate the limited choice of hardware that works with this module. I want to use a client that can run 802.11a, such as a tablet pc, but there is no ADCS client for it. I’d also like to see an option to have the receive and putaway transactions done in one step.
Rich, Don’t get ADCS and Warehouse Management confused. ADCS is simply an enabler for WMS. WMS will make recommendations on the picking and putaway process based on the settings that you as a user setup. In addition, you can certainly override the recommendations on the pick document itself. That’s what the split line for example is used for. You can also simply just change the desired bin itself. I understand your frustration for the ADCS hardware. Be aware that Crazy Bean has identified a potential solution and Lanham and Associates has created one built with Intermec. As far as receiving and putaway in the same step, that’s a business specific need and as such should certainly be easily done with your NSC. It’s simply automating the putaway process to run after the receiving. The issue is that many organizations actually have different receivers and putaway people…again it really depends on the size and layout of your warehouse.
I agree will Bill. In this thread we discussed break-bulk and multiple units of measure. We have a solution in concept form, and looking at the code I don’t see any reason why it shouldn’t work. Again, my issue is that our customers tend to order in an “each” unit when acutally they want us to ship in case units. We intend to convert units of measure during the shipment creation process in warehouse management. A solution recommended by our NSC, and appears to be a good one with a low risk of side effects elsewhere in Navision. I’ll let you know if we have trouble. Keep in mind you hear various issues with ADCS and warehouse management. From what I have been able to sort out, the bulk of the problems have been resolved with the latest hotfix from Navision on version 3.7. Comments made prior to that version should be set aside or confirmed using the latest release.