Docstar 3-Way Match

Just for new vendors, or when a vendor changes their layout - like I said, the system does a good job if the vendor has a decent layout. You don’t have to “teach” it as such, by you assisting it in recognising when certain fields are on a single invoice it should remember that are apply that learning to the next time it seems an invoice from the same vendor.

1 Like

Mike I don’t really - it’s a small team, they just picked it up and ran with it. Not aware of a training document as such.

1 Like

Hi Richard,

When comparing at the line item level we don’t compare description information because there can be times when descriptions are close to one another and only off by a digit or so and sometimes even cut off in the description field of the line item. For example, “Galvanized steel encasement screw coarse # 10” may come in on the invoice as “Galvanized steel encasement screw cou”. This could then match every size of that screw. The most effective way to perform line item matching is to match on the unique part number and if your vendor sends you invoices with their part number then we look to cross reference it in your system which requires you to maintain your item master with known aliases among vendors you purchase the item from. We could also perform receipt matching for sub totals and dates to narrow possible matches to just unique receipts and use the line data from the receipts. However, in any of these cases ambiguity may still exist requiring human intervention. The aim is to reduce the need for human intervention as much as possible. This may mean working with Vendors to have them send you invoices as PDF attachments to an email, reference your part numbers, or reference a shipment number if they don’t already. It may mean some initial loading of item number cross references into your item master, it may also mean changes to some of your internal processes, like using a packing slip number as a receipt number (or some prefix in front of it that can then be incorporated in the DocStar lookup as well) in your system so it’s more easily cross referenced.

As i mentioned an in an earlier post, there are several AP Automation options and solutions, depending on your circumstances one offering may be better than another. Mark and others provided some good feedback on this thread about what they are doing to address certain items. There are several ways to improve and increase levels of automation but it may take addressing several areas (including discussions with your Vendors) to improve the overall process and continuously adapt/improve the process to meet your goals. The key is to start seeing benefits as soon as possible and then build upon them vs. trying to make a perfect process right out of the gate. If you still have an open question on your process or what you’re trying to achieve, please let me know.

Thanks. :slight_smile:

1 Like

I picked up on a really key point there that @remirzian made - get it working ASAP. As soon as it is in and working, you’re saving time and it’s earning its keep. Then look to keep improving. I’ve seen many projects where the scope creeps and gets bigger and bigger, until it’s a solution that looks un-achievable.

We have saved hours per week of keying AP invoices into the system - pulling info from receipts and the document to 2 way match is a god send!

2 Likes

@remirzian - or anyone else…

Is there a workflow for processing receiving documents from the loading dock into docAlpha/DocStar? We’ve been considering the 2-way versus 3-way match and would like to create a workflow very similar to the AP Automation flow that we all have. As we envision it, we could really just take the two workflows (DA and DS), copy them and augment them slightly.

(Pseudo-flow)
For the Loading Dock employees:

  • Use a Copier/scanner/MFC device in the dock area to scan all the receiving docs for the day - into a DA hot-folder.
  • Workflow/process them through the DA “stations” and export them to a hot-folder (with the XML file) for DS.

In DocStar:

  • Use a DS workflow to bring them in and simply file them under the ‘RCV’ doc type using the vendor/PO combination like the AP workflow.
  • Change the AP workflow to find related RCV docs and add them as pages to the AP doc
  • Route to an approver and that person could do the 3-way match easily with the additional page(s) form receiving.

Anyone have something like this?

Oh and @markdamen - we noticed that our DA workflow wasn’t set to auto-find the vendor, nor did it have any data link to check Epicor, so zero documents could have been automatically processed without human intervention. I’m working on that this week, but any hint/tips you might have would be helpful given it will be the first foray into editing that workflow. :slight_smile:

Hi @MikeGross

In Administration station, this is what we’ve got in terms of DB lookups. The “blocks” tab shows the fields that it is picking up from scanning, and we have one called “Phone_AF” - do you have that?

Hi @MikeGross, We are looking to do something similar to this workflow you mention here. This is an old post, wondering if you made progress.

Well, that’s based on perspective really! :slight_smile: We’ve taken a few steps backwards and forwards and actually had our first training session with AP yesterday. I’m ashamed to say that it’s take a year to get here but there so many moving parts to this.

As for AP/RCV, we’ve figured that part out. The receivers are getting scanned in and indexed to the Vendor/PO#/Packslip and we configured the AP Invoice DocType to consider any other document for the same Vendor/PO as a related document. The moment we create an AP Invoice on the inbound side it assigns the document type, then any view of that invoice (even in the workflow) shows the Receiver as a related document. We found no need to make it an actual part of/page in the AP Invoice document if the related docs feature works. The processing rules then state that you cannot pass an invoice through the workflow without a related document. We’re about to try all that next week in production.