669
Like
Share
Report
Introduction
Let’s see a piece of code in 7313 Codeunit “Create Put-away”
with PostedWhseRcptLine do begin
if not CrossDock then
exit;
CrossDockMgt.GetUseCrossDock(UseCrossDock, "Location Code", "Item No.");
if not UseCrossDock then
exit;
if "Qty. Cross-Docked" <> 0 then begin
if not Location."Bin Mandatory" then
PutAwayItemUOM.Get("Item No.", "Unit of Measure Code")
else
Bin.Get("Location Code", "Cross-Dock Bin Code");
Let´s focus in bin get statement, the last statement. I meet this statement in a very painful way. When a user try to create a put away from a posted reception get this error message “Bin does not exist……… Location Code=’MAIN’..Code=’’”. This message means nothing to him, and nothing to functional advisor. So they need somebody to debug this absolute meaningless message.
In the debugging we detect the line that raises this error:
Bin.Get("Location Code", "Cross-Dock Bin Code");
This way we can read the previous statements and conclude that the source of the error was a bad cross docking configuration in the location. Before that the only hint was we was searching and inexistent blank bin. In debugging we notice that the bin was searching comes from cross dock bin from posted receipt line.
Don´t break early. Break it earlier.
Yes that´s our fault, we made a bad setting and the system breaks before posting wrong data. So far, great. But no so great. If you need to debug an standard error to understand what is causing it, it is a bad signal, very bad signal.
It´s good to break execution early to avoid data incoherencies. But it better to break it before, not only to avoid the further incoherencies, you must break the code in a point that you can give explicit and significative information about the origins of the error.
Don´t worry if you find it hard to do, there is a simple rule that can standardize the error raising with get statement involved.
The Testfield + Get rule
Every time you do a “Get” statement, if blank value in primary key can not be expected, put a “testfield” before. This simple way the resultant error will be more explicit.
In the example above is so simple as write the code this way. Before:
else
Bin.Get("Location Code", "Cross-Dock Bin Code");
After:
Else begin
Testfield("Cross-Dock Bin Code");
Bin.Get("Location Code", "Cross-Dock Bin Code");
This way the testfield statement tell us that we have not a "Cross-Dock Bin Code" value in the posted receipt line. Neither is the final source of the error raising, but gives us a hint that the error is related with cross docking.
In other areas Base app do better its homework, In sales posting we can see this statement (poor information):
PaymentTerms.Get("Payment Terms Code");
But before does this check (good information):
TestField("Payment Terms Code");
Warehouse
In warehouse app we can find many messages with an alarming lack of information. I find myself sometimes debugging standard errors to get any information. I will try to ask to Microsoft to improve that in Git or "ideas site".
*This post is locked for comments