SOX and EDI (post audit) 1314



  • Originally, we decided to route our EDI change management down a very similar path to our ERP change management. Namely, any changes to EDI maps must be made in the development/test environment, must go through a QA process, and must be tested and signed off by an end user prior to promoting the map to the production environment. With this structure, we passed our audit. However, we’ve had issues ever since with users frustrated and resentful over the amount of EDI testing we’ve had them do, especially for technical changes that don’t really affect them (ex: changing a field type in a map to a string and formulas that reference that field to accomodate the string type).
    I’m now considering trying to make a change to the process where we can identify some EDI map modifications as purely technical in nature based on certain criteria and will not require users to participate in testing those changes. I’m interested in how others are handling EDI change management and in particular how you’ve dealt with the end user testing component of it, especially when EDI mapping resides outside of your core system.
    A quick note on our structure: primary business and financial activity takes place in an ERP system that has a built-in (user driven) process for importing data from inbound EDI tables into production tables and exporting data from production tables to outbound EDI tables. We use a separate software suite to map data from inbound EDI documents to the inbound EDI tables and likewise map data from outbound EDI tables to outbound EDI documents. The end users review all data in the inbound EDI tables before running the import process and also generate the outbound data.


Log in to reply