This looks like a bug in NAV (it still exists in 2013)

Charleh

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)

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?

lubost

Hi,

I think that CLEAR(BinType) is better then BinType.INIT in your situation.

ara3n

I suggest to report it to MS. It's the same code in 2013 R2. And yes clear(record) is better code

Torben_R.

It's not a bug. The code is to avoid errors if a blank BinTypeCode is passed.

You need to look at why you pass a blank BinTypeCode.

Charleh

Torben R. wrote:

It's not a bug. The code is to avoid errors if a blank BinTypeCode is passed.

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.

jglathe

Hi,

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