About Item Tracking

Belias

what do you think about standard item tracking functionality?
I am currently analyzing a project where we have to choose whether to use the standard functionality or create a new one.
here some guidelines (pretty raw, because the project just started):
- basically, the barcodes (serial nos. for item tracking) are passed in through a txt file or so
- these barcodes are static: i mean, as they're lending cylinders of gas, these cylinders go to the customers, then come back (i am not interested in chares on cylinders up to now), can be transferred between different locations in the company and then lended again. As these barcodes are statics, it would be a good idea to have a table where these barcodes are stored and eventually updated with some info about current location, item of reference etc.
- a new barcode have to be inserted in the just described table before being usable by the procedure
- barcodes will then be widely used through the application (ledger tables and sales/purch/transf/shpt/receipt documents)
- barcodes can be partially shipped/received (!)
...more info will probably come...

i would be grateful if you tell me how do you feel with this standard functionality and how easily/hardly can be enhanched.
Thanks in advance!

Belias

Sorry, I forgot some important info:
- nav 2009SP1 rtc will be used
- they currently have (in their "will be old" system) about 100/120K barcodes, and they does not increase too much: as i said, the same barcode is reused when comes back to the warehouse. Moreover, if the barcode label gets damaged, it will be replaced with one with the same number.
Thanks!

rsfairbanks

We currently barcode all our product made, including WIP and raw materials (with unique numbers) and use the standard Lot No Tracking, and it works well.

On booking In / Production the lot No is created and the Lot No Information Table populated using a designed form.
We then use basically 2 besoke forms , one to move stock (populating a reclassification journal) which requires the Lot No and destination. The other to allocate stock to a Sales/Transfer/return order, requiring the Lot no and order Number (populating and posting a reclassification Journal then allocating to the order using the item tracking functions). A further form is used to identify where stock is located by entering either the Lot No or Item Number (based on warehouse entries).

Most of this is done on Samsung Q1s on a forklift which continue to work well even in a dusty enviroment.

I think you should be able to use standard functionality easily

Belias

thanks for your inputs.
A pair of questions:
- do you use only lot nos?
- after usage, is a lot no. "burned" or can it come back through a return order, and then resold with the same code?
I'm waiting for other suggestions, too. one more time thanks, rsfairbanks!

rsfairbanks

We only use Lot Numbers
Yes, the same Lot can be sold, returned and then sold again. It is part of our traceability

bstoyano

One of our clients uses Serial numbers. But in NAV 5. The functionality works fine. You can use one serial number many times.
One feature (I think this is a disadvantage) is that you can have several items with the same serial number at the same time.

Belias

i have destroyed a cronus database to be able to understand how the code of item tracking runs...and i think it's really smart!i have to personalize it here and there, but it generally fits our needs (up to now)...thanks for the inputs, we're also going to implement a fast sales order creation, having the user inputting only customer(s) number and barcodes for them: nav will automatically create the document(s) and its reservation entries. We'll do this fast order creation for other documents maybe...and we'll also implement a file import from palm devices to move the serial nos.
Pretty much work for me
now, it's time to begin the weekend, thanks for the input, bye!

Sunset

First time I've heard anybody talk possitively about the way NAV creates serial/Lot! In my book (and MS/NAV self) it is a death-sin to code the creation of data dependent on a form. Especially as in this case; the closing of a form. Makes it very hard to call the standard code from other places, forcing you to have 2 sets of live code doing the same thing.

Belias

I've not found so hard to call standard functions...yes, i will probably use only standard documents, that means that i've only to populate reservation entries if necessary (for example, if i import a text file of serial nos.).
Here i'm not talking about the code design, but the logic behind it: i think it's solid and clear, but i've only done a first analysis.

Belias

ok, now it's getting tough, i need your kind help because i've been banging my head for 2 days on this (obviously, these 2 days mibuso was not working )
i am personalizing the item tracking collection codeunit, because i want to add my own checks on the serial no. being show in the "select entries..." function.
This means that if the user manually digits a serial no. which is not in the "select entries..." page, he'll get an availability warning.
here's what the standard code does:
1. retrievelookup function: sets some filters on reserventry and itemledgentry variables, and then pass them to TransferReservEntryToTempRec and TransferItemLedgToTempRec functions.
the function about itemledgentry fills a TempGlobalReservEntry table, too.
Both functions call the createentrysummary function.
2. Createentrysummary fills the TempGlobalEntrySummary which is the one shown in the "select entries.." function.
3. the availability warning is generated as an output from LotSNAvailable function, and in my specific case the exit of this function is always

EXIT(TempGlobalEntrySummary.ISEMPTY);

here's what i personalized:
in the TransferReservEntryToTempRec and TransferItemLedgToTempRec functions i added this

        //TransferItemLedgToTempRec
        IF NOT TFSerNoOk THEN BEGIN  //TFSerNoOk is the return value of a function
      //+@MHC1.MM 12.04.10
          TempGlobalReservEntry.INIT;
          TempGlobalReservEntry."Entry No." := -ItemLedgEntry."Entry No.";
          TempGlobalReservEntry."Reservation Status" := TempGlobalReservEntry."Reservation Status"::Surplus;
          //bla, bla, bla...
          IF TempGlobalReservEntry.INSERT THEN
            CreateEntrySummary(TrackingSpecification,TempGlobalReservEntry);
        END;

and this

      //TransferReservEntryToTempRec
      IF NOT TFSerNoOk THEN BEGIN
        TempGlobalReservEntry := ReservEntry;                     
        TempGlobalReservEntry."Transferred from Entry No." := 0; 
        IF TempGlobalReservEntry.INSERT THEN
          CreateEntrySummary(TrackingSpecification,TempGlobalReservEntry);
      END ELSE
        CLEAR(TempGlobalReservEntry);

what i want to do is analyze one by one the records extracted by the standard filters and occasionally skip them. In that case they won't show up in the "select entries..." form and an availability warning should be shown.
This works until i close and reopen the form, because at that time, the availability warning disappars.
I think i've probably misunderstood some piece of standard code, so, if someone have already personalized this function, can he be so kind to explain me why am i wrong?
If you need more info i will be pleased to add everything you need to my explanation.

P.S.: i think this will be a difficult post to answer, but i am going to launch my laptop from the window if i don't manage to solve it...
Thanks in advance to everyone

Belias

I realized that the warning are not the thing that blocks the posting, but the checks are done on other condition's basis...i think i'll write a blog post on what i have discovered when i have some time...