Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.6K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 272 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
This looks like a bug in NAV (it still exists in 2013)
Charleh
Member Posts: 44
Not entirely sure as my NAV knowledge is limited (I'm a relatively new NAV developer and currently learning the product)
We have an issue with a client when creating a pick for a warehouse shipment - in some instances there are blank bins for particular pick lines even though there is more than enough free stock to cover the pick across many bins. I narrowed the issue down to two things:
The GetBinType function in Create Pick CU (7312)
And the fact that they have some blank "Bin Type" codes in their "Bin Contents" table. Now I know that the blank bin type codes should not be there (it may have been imported data or a manual deletion of the bin type code) and upon rectifying this the pick happens correctly, but I couldn't help but wonder about the code above.
The sequence of events that causes the issue is:
1. The bin checking routine gets the bin type setup for a particular bin, say "PUTPICK"
2. The bin checking routine tries to get the bin type setup for a blank bin type code (which does a BinType.INIT)
3. The bin checking routine gets the bin type setup for the same bin code before the blank one "PUTPICK"
4. Because of the optimisation to skip getting the bin type setup again, the INITed record is used instead of the actual values, so you end up with "PUTPICK", "No", "No", "No", "No" (no for all bin operations)
5. Because we have a INITed record and all operations are "No" the system decides the bin is useless for a pick even though it should be pickable and contains loads of stock.
I can see this being an issue with other operations that use this routine too
This sounds like a bug to me - surely the INIT should be a RESET instead?
If this is a bug, where do I go to submit it to MS?
We have an issue with a client when creating a pick for a warehouse shipment - in some instances there are blank bins for particular pick lines even though there is more than enough free stock to cover the pick across many bins. I narrowed the issue down to two things:
The GetBinType function in Create Pick CU (7312)
GetBinType(BinTypeCode : Code[10])
IF BinTypeCode = '' THEN
BinType.INIT
ELSE
IF BinType.Code <> BinTypeCode THEN
BinType.GET(BinTypeCode);
And the fact that they have some blank "Bin Type" codes in their "Bin Contents" table. Now I know that the blank bin type codes should not be there (it may have been imported data or a manual deletion of the bin type code) and upon rectifying this the pick happens correctly, but I couldn't help but wonder about the code above.
The sequence of events that causes the issue is:
1. The bin checking routine gets the bin type setup for a particular bin, say "PUTPICK"
2. The bin checking routine tries to get the bin type setup for a blank bin type code (which does a BinType.INIT)
3. The bin checking routine gets the bin type setup for the same bin code before the blank one "PUTPICK"
4. Because of the optimisation to skip getting the bin type setup again, the INITed record is used instead of the actual values, so you end up with "PUTPICK", "No", "No", "No", "No" (no for all bin operations)
5. Because we have a INITed record and all operations are "No" the system decides the bin is useless for a pick even though it should be pickable and contains loads of stock.
I can see this being an issue with other operations that use this routine too
This sounds like a bug to me - surely the INIT should be a RESET instead?
If this is a bug, where do I go to submit it to MS?
Charleh
0
Comments
I think that CLEAR(BinType) is better then BinType.INIT in your situation.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
You need to look at why you pass a blank BinTypeCode.
With all due respect Torben, when doing professional software development, methods and functions are expected to produce reasonable output even in the cases of incorrect input. This function results in incorrect behaviour and side-effects on other areas of the codeunit when certain values are passed to the function. I would classify this as a bug - as others have suggested, a better implementation with no side-effects would be a CLEAR() rather than an INIT.
I do realise the root cause is the incorrect Bin Content entries - but the function is side-effecting and therefore incorrect.
I will submit this to Microsoft.
well this may be sort of legacy, but it was never a good idea to have records with a blank code in tables where more than one record should exist. The NAV code expects "reasonable" input, blank codes (except for setup tables) are not expected. You often find code like "if <fieldname> <>'' then...". This will fail for records with a blank code.
with best regards
Jens