I know partly this is a Master Data issue, having two vendor numbers with identical title, abn and fax. But After I Optimize the profile to say 'Use this specific vendor number' it should not question me in Verify as to which one to use.

Any ideas?

I have uploaded pics. It should go to vendor 800108 as it is optimised to that.

a) I don't have a profile for the second vendor 800103.b) the log tells me it did identify the correct vendor. "Identified as definition 22222 which is vendor 800103.c) Adjusted ini file so new supplier

Hi CiaranWe also had this issue with multiple vendors from the same vendor group. We have fixed it to some extent by a manual workaround in SAP. I am not sure this is the most efficient method and are open to suggestions.

In the vendor master data, we specified which were the ordering vendors and which were the Head Office vendors by changing the search term. For example, to Order or Head. We then ran a query in SE16 on table LFA1 to identify the Order vendors and dumped the data to Excel.

Then we copied and pasted the excluded vendor numbers into our VMD upload program (in the excluded values tab). That is, we don't send these vendors to Invoices therefore the system can't propose them.Obviously the master data is not constant and we will need to repeat this exercise every few months, but it has saved Verifiers are lot of immediate headache and the fix was quick to implement.

In the long run we should look to change the VMD upload program to exclude vendors on further parameters. Our ABAP resources are stretched so the above is a cheap and dirty workaround.Cheers

Hi CiaranGood to hear that the addition to the eiglobal file worked.I was thinking some more regarding the vendor master data upload. The parameters in the standard program to perform the upload are too basic.

For example, we have edited the program to flag which vendors are ERS so we can identify these when they come into Verify; and we need to identify which vendors are the Head Office or Ordering party so we can exclude the ordering party from the upload.Rather than all of us make changes to the standard program, as a group we should go back to Readsoft and request the program be changed. At least we all won't be investing in the same ABAP development work.So on that note, I would be interested to hear what changes users require to the VMD upload program from their ERP system?

I am un digging slightly this topic as we spent lots of effort here for that. We still dont get when/how this second validation is needed in Verify. We removed all suppliers in supplier list in order to keep only one supplier/buyer pair. However issue still occurs and we have to choose between several bank account data.

Hi PJAre you able to provide a snapshot of the Process log for one that has been matched incorrectly?In Verify: Invoice > Information from the Menu bar. Which version of Invoices are you on?Kind regards__________________CherylLinkedIn: https://au.linkedin.com/in/cherylc-651471a0

Hi again PJI just realised from your other post that you are probably on SP2.We had heaps of problems with supplier matching when we upgraded to Invoices 5-7 (with no patch level) and were advised to implement SP3. One of the issues was caused by the LearnIdentifiersUsingSingleItemFields setting in the eiglobal file. It is a new feature and comes with a setting of 1 with the upgrade. We turned it off however the damage had been done.

With this feature on, the system ignores the identifiers in your Invoices profile and dynamically learns identifiers. Before SP3, it could learn a blank space as an identifier. So the system learned a blank space and then when another invoice came with a blank space on it (ie. every invoice) the system went 'aha this must be for supplier X'. So if the system could not read the first two identifiers and went for the third dynamically learned identifier it matched on that. There was no rhyme or reason as to which invoices were matched to which suppliers.

We quickly implemented SP3. Turned off the LearnedIdentifiersUsingSingleItemFields and then checked every invoice definition that had been changed since the upgrade (see last change column in Optimize). Note, I pinpointed we had the problem within a few days of the upgrade so only had to check a few hundred invoice definitions.

I asked Readsoft support whether there was any report I could run which would tell me which Invoice Definitions had a dynamically learned identifier but they said there was none. So we had to manually open each invoice definition since the upgrade and check the identifier fields.

If this is the source of your problem, installing SP 11 alone is not going to fix it unless you weed out your offending IDs with incorrectly learned identifier fields.

It might be easier to ditch your Invoice Definitions and start again after installation of the patch. Just depends on when you upgraded, how long you have had the problem for, and the number of Invoice definitions you have.

For those reading this who have not yet upgraded or implemented Invoices 5-7, make sure you also implement at least Patch level 3 or go for Invoices 5-8 which includes all the fixes.

We have indeed SP2 and soon SP11 v5.7 for invoices.That is a great input you are bringing there. Are you sure vendor recognition comes from learnidentifiersUsingsingleitemfields setup rather than makesecondsupplieridentification setup ?Attached is our process log. It finds invoice definition and then somehow crosscheck with VMD and it says too many supplier with same MD --> supplier not identified. (screenshot attached).Invoice is so stopped in Verify all fields in green but validatio button in greey until we select one vendor on screen among a list (screenshot attached).

Hi PJI apologize for the late reply. I just reread your post and realize you are thinking to move to SP11. I loaded SP12 into our test environment and now the system will not identify most suppliers from our Vendor Master Data. I reported this into Readsoft mid Jan and third level support are looking into this me.

Identification is working great in our Production system on SP7. I loaded the same eiglobal file in TEST that I have in PRD and it still does not work in TEST. So I think there is an issue somewhere between SP8 and SP12, maybe Readsoft have changed the way a configuration settings works or have initiated new configuration options. The only other difference between our TEST and PRD systems is that I created a new invoice profile for XML invoices. So not sure if I have caused the problem or there is a problem with one of the SPs. I am currently waiting on Readsoft to get back to me. I guess because the issue is only impacting our Test environment our case has lower priority.

I am mentioning it however, because I think there might be a problem in one of the later SPs.

In the mean time, I have diverted off Readsoft to work on other issues in SAP. The joys of working in IT!

I have been busy finishing this project.So yes we implemented SP11 and issue is fixed with that "makesecondsupplier" option on ini file.Workload and impact for upgrading from SP2 to SP11 is low which is a good thing.

Hi PJThanks for letting me know. I am in the process of upgrading to Invoices 5-8 and its working nicely in our Test environment. The UI is even nicer than 5-7.We are just about to start user testing.

I did run some tests to try and work out how the system actually identifies the supplier.

I think it is doing this:

1. It looks at the overall invoice image and tries to find a match (if no match, then 2)2. It looks at the identification fields that have been learned on the invoice definition and tries to find a match (if no match, then 3)3. It looks for other values such as Name, VAT registration number, telephone number, etc until it finds a match.

Would be great to hear from an expert as to whether this understanding is correct???

I am just trying there to bring our experience as Readsoft does not explain at all how their solution work.

First action done by interpret is searching for the supplier on the image. For doing so, interpret checks all invoice definitions already stored and check if they are any match with what he sees on the image based on setup identifiers in priority and then all applicable data.

If he doesn’t find any match he reads the image and check data with vendor master data (address …. ) the more matches he finds the easier he can create a invoice definition. Note that PO box is not used at all in master data and recognition.

With version 5.7 (and we did not experienced that in 5.5) with parameter secondsupplieridentification in .ini file interpret makes a cross control between invoice profile (when it founds one) and masterdata. If you have same supplier linked to 2 different buyer he cannot make any difference and invoice stay with no match in Verify asking for a supplier confirmation.

Hope this helps.

I found also some more information from document found on that awesome forum (yes I mean it) on paragraph 1.2 interpret :

Firstly a full page OCR (Optical Character Recognition) is performed on the invoice image.

This is used to try to identify the supplier by reading for the Supplier name, ABN number, ID and checking for matches in the Invoice Definition database and the Master Data (Supplier) File.

If INVOICES Interpret module identifies an invoice as matching a known definition it will use that definition to extract the data and present it to the Verify operator.

A definition is automatically created at Interpret as a “learning definition”, using the Profile information and settings. It does this to identify the key fields required to identify if there is an existing definition. If an existing definition is found, that definition is used and the learning definition is discarded. The invoice definition contains all fields, all title, location and format specification and logo and image data for that supplier invoice.

If it does not find a definition in the definitions database, but DOES find the Supplier in the Master Data (Supplier) file, it will present the invoice as identified to the Verify operator, showing the Supplier Name in the Inbox column. The “learning definition” now becomes the basis of the new invoice definition. Once Approved in Verify (after the “first time” verification) the new Supplier definition is permanently saved.

If Interpret does not find either an existing Invoice Definition, or a matching entry in the Supplier File, the “learning invoice” (which is based on the Profile rules) is presented to the Verify operator as an unidentified invoice. This will undergo “first time” verification and eventually be approved and therefore saved as an invoice definition.

All definitions are saved as unique combinations of:

 Profile

 Source

 Buyer

 Supplier

Any differences in these four key criteria will result in a new definition being created.

Insert Photos

Web address (URL)

Image URL

If your URL is correct, you'll see an image preview here. Large images may take a few minutes to appear.
Remember: Using others' images on the web without their permission may be bad manners, or worse, copyright infringement.