Duplicate invoice configuration

[Shawn_Webster]

I am redesigning my duplicate invoice logic and running into a few road blocks. My first try, I created a unity LC using portfolio relationships for each keyword value like PO #, Invoice #, Vendor Name and Invoice Date. I did Invoice to invoice. I also did rules for each and on true would ask about the next value. During testing I found that it wasnt looking at the same document for these values but if these values existed on any document in onbase. I decided to try mapping all my values on 1 relationship but this doesnt work either. It keeps going false even though there is a doc with PO # and Invoice #. I need to be guided the right direction as I dont know what the common way to perform this. Our old setup uses folder types using invoice or PO# and this doesnt work hardly at all. Any advice would be appreciated. 

[Craig_Statt]

So, I am not sure why it would not work.

If the "exclude primary" and "keyword mappings" are all correct then I would then look at the timer service to see if I had reset that to pick up the changes.

Another note, when I set up invoice duplication, I general don't match on invoice date.  I found that invoice dates (being automatically generated) could change (e.g., a vendor re-issued an invoice).

[Shawn_Webster]

I discovered why it didnt work. I imported it as a different doc type and never flipped it to invoice. So I am on the right course? I should also check exclude primary in the portfolio? I think PO#, Invoice#, Invoice amount and vendor name might be best. My original setup, which didnt work anyway, had issues with invoice amount and went with vendor name and invoice date. I'll adjust my logic using this recommendation 🙂

[Craig_Statt · Accepted solution]

You want to exclude primary, because you don't want it to ever match itself. 

Invoice is tough:  it would be interesting to see others opinion.

PO, Invoice and Vendor # is probably the safest way to go.  Vendors may change names, and they may re-issue invoices with a credit or different invoice amount (net terms, etc).   I have seen scenarios in which vendors may tag an 'a' or another value at the end of the invoice for the re-created invoice.

We had scenarios in which the invoice would come through the dropbox and the buyer spoke directly to the vendor and they emailed them the revised invoice.

I had always erred on the side of more human scrutiny just because of how unpredictable the vendors have been.

[Shawn_Webster]

yea I thought this was a snap but the vendors unreliability is the biggest pain. JLG reuses invoice #s all the time from what I was told. Good information thank you