Ancora (IDC) can't split and index off of a barcode fixed to the document you wish to file away?

Anyone using IDC to split and index off one barcode on the document you wish to file away?

We are trying to file away our receipt packing slips based on a barcode that our team will apply to it after they receive it. At the end of the day/shift they can set the stack of packing slips on the scanner and then IDC would separate individual packing slips, and index them, off the barcode mentioned above. For some reason ancora requires us to add a manual separator page in-between each packing slip. Is it just me or is this odd?

Here is what we heard from someone speaking to ancora:

ā€œFrom what Iā€™ve been able to find, it doesnā€™t look like weā€™d be able to utilize two barcodes on the same page. This would likely have to be two pages where the first page is the separator sheet only and the second has the barcode to capture/index. From there, you would need to set the barcode separation settings to ā€œdelete separator sheetā€ in Batch Type settings so that by the time it reaches Data Verify, the only page left for the document is the barcode for the receipt number.ā€

Not a direct answer but food for thoughtā€¦

We donā€™t use Ancora for this, we straight up use ECMā€™s client and barcode scanning to bring in all of our Job Travelers and associated docs. Each is placed on the Ricoh MFC and sent to ECM using a button on the screen for PDF scanning to a folder. It works flawlessly when married to a workflow with a few datalinks to gather the info and attach it back to ERP.

1 Like

Okay Mike, so did you buy the barcode module for IDC/ECM to do this?

Mike, can you set the whole stack of travelers on it and will it split them and attach them without having to add a separator page in-between?

ECM - we bought the barcode module/license for ECM, but only sort of use it like intended. Easier to show than explain, but here goes:

The ECM Client brings in the document from the folder being monitored - that is the drop point form the Ricoh MFC. This creates the new document in ECM of the JobTraveler content type. The Workflow then has the ā€˜read barcodeā€™ step, and goes through a datalink to get info from ERP, and lastly attached it to the Job in ERP. Our processing on the floor allows for a traveler to be scanned as the job makes it to shipping, so we donā€™t do any bulk scanning. However I think it would work.

The following screen is where you can specify a combination of blank page/barcode detection rules which may be exactly what you need.

1 Like

Mike thanks for showing me the screens :pray:. I need Epicor or someone to give me the yes or no answer to the question: can you set the whole stack of travelers on it and will it split them and attach them without having to add a separator page in-between?

Based on what you show I donā€™t know if itā€™s possible to avoid the blank page or separate page, is that what you would guess too?

What they did at the previous place, was put a ā€œBREAKā€ barcode on the sales order, and it was always the first document related to the following documents.

Not a huge fan of batch processing myself. Sometimes it couldnā€™t read the barcode and the whole stack went to one order. :person_shrugging: Iā€™d prefer whatever key be on each document and load them as they were made or scanned when complete. But thatā€™s just cranky ole meā€¦

1 Like

It looks like you could use one of the Document Split Method. Unless I am missing somethingā€¦

@utaylor I also do this in ECM but without the barcode module using @MikeGrossā€™s workflow as the starting point I tweaked it for us. We do use the HP separator page and scan them in one stack and they are split into PDFs that we drop into a folder for ECM. Even without the barcode which would likely get me to 100% I can get 90%+ with just OCR on the PO number and packslip. I do in in ECM since I am very protective of my IDC counts. Takes one person 10 minutes to fix the indexing in the ECM workflow for the day.

My fear of barcodes as a separator for documents I donā€™t control is much like @Mark_Wonsilā€™s one errant vendor barcode placement and I have a mess.

1 Like

The other thing I didnā€™t like about batch processing is that we treated the old vanilla folder as the thing to store and not individual documents. Inevitably, when someone wants to see the traveler, they also have access to the invoice, which we prevented them from seeing in ERP. :person_shrugging:

One big :peach: pdf, one document type, one security group. :person_facepalming:

Couldnā€™t use document packages to see if a document was missing either.

Also, we had to manually file all the documents until they could be scanned, so they werenā€™t available in DocStar until after invoicing. Invoice was the worst because we printed it out - so we could scan it in the back in. :thinking:

But thatā€™s the way weā€™ve always done itā€¦ Yeah, not a fan of batch processing when I can avoid it.

Thatā€™s a good point mark, what happens if it misses the break codeā€¦ The whole thing goes to one documentā€¦

Greg, not sure I am following what you are saying here, might need to wake up a little and read this again.

So you are saying ECM has built in OCR capabilities without the IDC module?

Thatā€™s what these ā€œpre-processing optionsā€ are? It can see barcodes and read them without IDC and without the barcode module?

Yes. ECM has a built-in barcode reader. YMMV.

@utaylor yes it does. To @Mark_Wonsilā€™s point it is not perfect. I changed the font and location of the PO on the inventory movement report to get the PO number to 100% and the packing slip from the receipt to 90%. If I had the barcode module I would have printed those barcodes on the report to OCR.

I changed @MikeGrossā€™s workflow step Get PONum and Packslip to do OCR on these two fields.

image

Here is our process.
Stack receipts in this order. Movement report, customer documents, separate page.
Scan with HP scanner and use their utility to make individual PDFs
Copy those to an ECM monitored folder that sends them to the Packslip Import workflow. No preprocessing is done.
OCR for PONum and packslip number.
Check if that is a valid receipt.
If it matches then rename the pdf file with PO number and packslip and attach to receipt in Epicor.
If not it goes to a manual indexing to fix the packslip number, then attaches in Epicor.

95% of this is from @MikeGrossā€™s workflow. I just made a few tweaks.

2 Likes

Thank you both @MikeGross and @gpayne for taking the time to take screenshots.

I am going to try and test the efficiency and accuracy of these three methods (they all are around a bulk import process):

  1. IDC to split on a barcode and then use itā€™s OCR to read PO and packslip from a text field below the barcode
  2. use ECM to do the same as approach #1 with the workflow you guys have (IDC not required).
  3. ECM split and index off barcodes with barcode module.

Each approach has downsides with the IDC side costing more per page processed like you mentioned Greg. I donā€™t know how good ECM is at OCR and what caveats there are, like does the barcode need to be in the same place every time?

Anyways, I would love to stick with the bulk processing and splitting so that the person doesnā€™t have to get up and scan in every separate pack slip. Maybe I could just buy a scanner for every deskā€¦

Thanks everyone.

1 Like

Greg, so you guys print/use separator pages?

Who is doing this in your organization?

@utaylor It used to be the receptionist until they did away with that position, now it is someone in documentation.

I just went and talked to him. He uses the official hp separator page after each grouping and will fill the input tray fullish for each run.

Thanks Greg, this whole automation thing is great, I just canā€™t believe the solution to automating splitting was adding in another manual step of inserting separator pagesā€¦

Iā€™ve already seen 3 repos on github of how to split a file into many separate files on a barcodeā€¦ you would think Ancora or ECM would have automated this step a little bit more, not added another manual process.