Visual Integrator: records read not equal to records passed, but no records failed or were skipped

SOLVED

We are importing SO  invoice records using VI. There are 445 lines in the file.  The summary says that none of them failed or were skipped, yes the number "passed" is not equal to the number read.  

What causes this to happen?  

From looking at the summary, we can see that some lines were indeed silently skipped.

Parents
  • 0
    Along the lines of what Kevin M has been saying I think that without assigning a unique LineKey for each line that VI will look at the same item code/item type within an invoice as being one line in the sense that it will just keep overwriting itself and you will only end up with 1 line for that item. If you have control of how the import file is generated you could generate LineKeys within the import file. Sage's natural LineKeys look like this.

    Line 1, LineKey 1 = 000010
    Line 2, LineKey 2 = 000011
    Line 3, LineKey 3 = 000012

    So it starts it 000010 and increments by 1 from there. I haven't tested this but I would try to do a Incr Assign on LineKey within VI and set the default at 000010, hypothetically it should start at 000010 and increment by 1 from there.
  • 0 in reply to Jon_K

    Thanks for the tip! I've added the L.LineKey to the import job, set it to auto-increment starting at 10, but the job is still skipping records. What is really strange is that I don't see the L.LinkKey field at all in the "Record Detail" on the lines in the job summary. Is that normal? I made sure to save the job after adding the L.LineKey field and have tried it 3 times now.
    Regardless, it still skipped lines just as before. Is there something special that needs to be done to set the LineKey field? Also, I've only ran "Test" so far, not performed the actual import.

    Update: I've also tried editing the import file to manually add the line keys and doing a REPL on that column, but still the LineKey does not show up in the summary when I drill into the lines.  I noticed that the line key is red in the column select list for the import job maintenance, and assume that means it's a primary key. Does that means it can't be assigned manually?

  • 0 in reply to bradvido
    I've sometimes found that the linekey can only be set when updating data. When adding rows, it's ignored.
Reply Children
  • 0 in reply to Kevin M
    That makes sense then, because we are only inserting, not updating. We do have control over how the import file is generated, so I was thinking I could add "buffer" lines between any two lines that share the same ItemCode & ItemType. Any ideas on what would be best to add a $0 amt line? Is it possible to add a comment line or something like that?
  • 0 in reply to bradvido
    For us, Sage 100 2014 Advanced, /C is a miscellaneous comment line item. I suspect even with buffer lines you would still have this issue but it's worth a shot.
  • 0 in reply to Jon_K
    If you can add a simple counter value to your line data, instead of setting the L.LineKey, try a temp field set to that column in your data source, and have the temp field set to reset with the line (instead of header).

    Also, if your codes *TIME are a fixed list, you may want to set them up as Miscellaneous Items, like /TIME, instead. I think your problem may be an oddity with the on-the-fly item type.
  • 0 in reply to Kevin M
    verified answer
    Thanks for all the suggestions!
    The workaround of adding "buffer" comment lines between any two similar lines (line that have the same Item ID, Item Type, and Comment) fixed the problem for us. As long as the two similar lines have a comment line between them, the import did not treat them as a single entry and nothing was lost.