Automatic Recording into NAV with barcoding, Part 1

In my previous post I wrote about creating labels, sticker, tag, or whatever it’s called, by making use of barcode. (see: https://joemarselo.wordpress.com/2010/10/02/barcode-picture-and-2-columns-list-with-nav).

Now, what we can do after we can print a barcode label within NAV. Many! I can say that almost all recording tasks. When a task requires user to type in the form to input / record transaction, that’s your chance.

In an operation that I manage, I have implemented automation in many processes. With this, we can save hours of resource for doing data input, we can eliminate human / typing errors, we can shorten tremendously the (field) operation procedure, and so on. There are really a lot of advantageous and benefit to the operation, for businesses, for industries, and of course, for consultant.

Part 1 – On Production Floor, on material consumption . In this post I will cover some time-saving works that we can implement in the production floor. What I have now are examples.

This is only an idea, a model, a scenario that I made. It needs more than this example to run in real business operation.  It needs adjustments, and modifications to fit the business / operation model.

The main point is, NAV can produce barcode print-out. We can make use of that barcode print-out to replace our manual things. My focus is to use Dataport to read the output of scanned barcode data and automate the Consumption Journal line creation.

On material consumption – the assumed condition or the scenario is,
every request / issue of material completed by designated Production Order No. and Item No. to what the material is used for. In a work station, the slip is stacked. Every end of shift, there is a user will scan everything, and post it into NAV as a consumption journal.
When scanning the ticket, there is an intermediate program just to store the data. In the program interface there is data log, a button to save the stored data into a plain text file – which is consequently a CVS. Then that text file is imported into NAV as a consumption journal, then Post the journal.

In material label, or material issue ticket, or other type of slip to server this purpose; draw your barcode to contain:
Item (material) No., Item (finished good) No., Prod. Order No.

Don’t mind about the order, what important is, when the barcode is scanned, it give you the result as you want, example:

M8901,BICYCLE01,PROD-4021002

About barcode set Code39 – see here for more detail
(http://en.wikipedia.org/wiki/Code_39).
There are Code39 (only) and Code38 Full ASCII.   I’m using Code38 Full ASCII.
If you use Code39 only, you can not use comma sign (",") as separator.

The material issue ticket looks like this:

Finish with the ticket, now we work on NAV part.

From this point, we have some options on how to collect the scanned data. We can use Notepad, Word processing, Spreadsheet, personal database like MS Access, we can use a new table / form in NAV. The point is, we need an interface, where it holds the data, and store it just as is.

After all data recorded, we need to pull out everything stored in it, to a simple text file. Just plain text file, and at the NAV end, we use dataport. Let’s make a dataport, name is as "Auto Consumption".

Dataport: Auto Consumption

Data Item : Item Journal Line

Code:
Item Journal Line – OnAfterImportRecord() ========================================
"Journal Template Name" := ‘CONSUMPTIO’                  //or work your own here.
"Journal Batch Name" := ‘AUTO.C’                         //or work your own here.
"Posting Date" := WORKDATE;                    // you may have different opinion.
"Entry Type" := "Entry Type"::Consumption;
"Document No." := "Prod. Order No.";
"Source Type" := "Source Type"::Item;
"Source Code" := FORMAT(‘CONSUMPJNL’);
"Document Date" := "Posting Date";            // you may have different opinion.
Quantity := 1                                      //in this case, 1 slip, 1 pc.
"Invoiced Quantity" := Quantity;
"Value Entry Type" := "Value Entry Type"::"Direct Cost";

There is a call to another routine to get Line No., but you can replace with your own routine. The easiest way is, define a var, e.g. ln – integer. Assign in OnPreDataItem() as ln := 0.  Use ln += 10000; "Line No." += ln;

prodline.SETRANGE(Status, prodline.Status::Released);
prodline.SETRANGE("Prod. Order No.", "Prod. Order No.");
prodline.SETFILTER("Item No.", "Source No.");
IF prodline.FIND(‘-‘) THEN BEGIN
     Description := prodline.Description;
     "Shortcut Dimension 1 Code" := prodline."Shortcut Dimension 1 Code";
     "Shortcut Dimension 2 Code" := prodline."Shortcut Dimension 2 Code";
     "Prod. Order Line No." := prodline."Line No.";
     "Location Code" := prodline."Location Code";
END ELSE MESSAGE
(‘There is no record with :’+"Prod. Order No."+’ , Item: ‘+"Source No.");
                                            // you may have different opinion.

itm.GET("Item No.");
IF itm.FIND(‘=’) THEN BEGIN
     "Inventory Posting Group" := itm."Inventory Posting Group";
     "Unit Cost" := itm."Unit Cost";
     "Unit Amount" := "Unit Cost";
     Amount := "Unit Amount" * Quantity;
     "Gen. Prod. Posting Group" := itm."Gen. Prod. Posting Group";
     "Item Category Code" := itm."Item Category Code";
END ELSE MESSAGE(‘Can not find Item: ‘+"Item No.");    //or work your own here.

There is a call to another routine to get (material) Item Unit of Measure, but you can replace with your own routine. We need to consider our field procedure, whether to use material’s base u.o.m, prod. bom u.o.m, or other u.o.m (where of course need to be exist in Item Unit of Measure table).

itmuom.GET("Item No.","Unit of Measure Code");
"Qty. per Unit of Measure" := itmuom."Qty. per Unit of Measure";
"Quantity (Base)" := Quantity * "Qty. per Unit of Measure";
"Invoiced Qty. (Base)" := "Invoiced Quantity" * "Qty. per Unit of Measure";

prodcomp.SETRANGE(Status, prodcomp.Status::Released);
prodcomp.SETRANGE("Prod. Order No.", "Prod. Order No.");
prodcomp.SETRANGE("Prod. Order Line No.", "Prod. Order Line No.");
prodcomp.SETFILTER("Item No.","Item No.");
IF prodcomp.FIND(‘-‘) THEN BEGIN
     "Prod. Order Comp. Line No." := prodcomp."Line No.";
END ELSE "Prod. Order Comp. Line No." := 10000;
===========================================================

Finish it, compile it, put it in the Navigation Pane. Then you have done your work!

Well, in my case, I name it ‘Im/Ex-port Consumption Jnl.’, because I make it also able to export certain lines from Item Journal Line.

This is the Part 1, about work around in Production Floor, in consumption journal.

Next, I cover 2 topics in one post;
(1) capacity journal or it’s know as production progress, and
(2) production output.

I understand that this is not a good whole business case;
Why in this earth I need to record Manual consumption when I can use Forward or Backward Flushing?
Why do I use different tool to store the barcode scanned data, then pull it again to be imported by dataport into NAV?
Why don’t I just revise the form to read the barcode scanned data?
I even can just read material issue history if it’s loaded with Prod. Order No. and f.g. Item No., and select a line to process it as consumption journal.
and so on …

The answer is … as I wrote somewhere early above …

This is only an idea, a model, a scenario that I made. It needs more than this example to run in real business operation.  It needs adjustments, and modifications to fit the business / operation model.

The main point is, NAV can produce barcode print-out. We can make use of that barcode print-out to replace our manual things. My focus is to use Dataport to read the output of scanned barcode data and automate the Consumption Journal line creation.