ERP Migrations and Vendor Cleanup

When an organization migrates from one ERP to another, if they are using PaymentWorks, there will be work that needs to be done. The PaymentWorks account will have supplier profiles uploaded and connected that reflect the vendor number and site code from the original ERP. So part of the migration planning is to map the old vendor numbers and site codes to the updated values as defined in the new ERP. Once mapped, as part of the migration process it's a simple task to modify supplier profiles in PaymentWorks to reflect the new data.

This post describes a case where the migration did not include this step, resulting in a significant vendor master cleanup effort.

Creating the Mess

Sometimes it's not always possible to do this transformation systematically as part of the system migration process. In one case where NVR Partners has recently been involved, a more involved vendor master cleanup was required because the customer had migrated to a new ERP system without pausing to update all the reference IDs.

In this case, more than half of their connected suppliers had registered prior to the migration. That meant that the profiles uploaded and displayed in PaymentWorks had the vendor number and site code from the original ERP. About 40% of the connected suppliers had registered after the migration, so they had vendor numbers and site codes that correlated to the new ERP.

Nonetheless, this still could've been a very straightforward transformation, in which the old reconnected suppliers are mapped and updated to the corresponding values in the new ERP, by changing the vendor numbers and site codes.

However, in this case, that simple transformation was only possible in 25% of the records. The rest had complications that required additional work.

First issue: Multiple connections made with a single NVR

One of the challenges in this case arose because the customer had several site codes (locations or DBA) for several suppliers. This is common and PaymentWorks naturally supports this more complex organization. However, for several of these complex suppliers, the customer had mistakenly connected multiple site codes to a single NVR.

So, for example, the customer had 38 locations, or payees, for their supplier Fisher Scientific, but they had mistakenly connected all of them to a single registration, which really correlated to only one of those payees. So the cleanup job involved identifying which of the 38 profiles matched the registration, and then deleting the connection for the other 37.

Second issue: Edit registrations connected to new ERP records

When a supplier modifies their remittance address, which is the primary key used by PaymentWorks to define a connection, that change will be delivered to the payer as an edit registration. (For more on edit registrations, see the post on Registration Routing).

In general, an edit registration should not result in a new connection. It's either a minor modification to an existing address, which would leave the site code and existing connection unchanged; or the modification could represent a whole new address - but instead of making a new connection, the site code of the existing connection can be updated to point to the new address in the ERP. (See Untangling Edit Registrations).

Unfortunately, in this case, the payer had used those edit registrations to create new connections on new site codes in the new ERP. This required that all those new connections be removed, and then the existing connection, with the old side code, needed to be updated to point to the new ERP and the new address.

Third issue: Missing vendor records from the new ERP

The next to final step in this vendor master cleanup involves making sure that all suppliers from the original ERP had migrated to the new, and that there was a clear correlation from records in the first to the second. This case had 150 missing records that needed to be located and added to the crosswalk.

Final step: manually finding remaining correlations between the two ERPs

When those three remediation steps were complete, there were still over 1,100 connections in PaymentWorks for which the new site code was not obvious. This was generally because the supplier had more than one address in the new ERP. This called for a manual effort to find which of the many site codes in the new ERP matched the record from the old ERP. Unfortunately, this was the most time-consuming and task on the project.

In short…

The moral of the story: when a PaymentWorks customer takes on an ERP migration, make sure the transformation mapping is done as part of the migration process. Don't leave it for later!

Next Steps

To learn more about PaymentWorks configuration and data options or to discuss your specific area of interest or concern, please reach out to set up a complimentary consultation. We’d be happy to connect!

You can fill out this form including an overview of your interest, or simply reach out directly at bestpractices@nvrpartners.com.