After having supported many customers for the past several years, I look back at some of the more critical issues and quickly recognize that most of these could have been resolved (or certainly avoided downtime) had the customer employed reasonable and simple testing.
The one recurring theme is the amount of implementation work that is performed without equal efforts applied to testing that work. One would expect that any configuration with impact on company reputation and revenue would be tested to its’ fullest potential before it is ever promoted to a production status. Schedules and deadlines do not always allow for intense sessions of testing and debugging, however, there are many important yet unrecognized advantages to the testing process. Continue reading
When setting up a new trading partner or business integration process, thinking through the process beforehand can greatly decrease the implementation time and help minimize problems. Many integration projects can come to a grinding halt in the middle of implementation if it’s only later realized that required data is not configured in your backend application, or if your system doesn’t support the particular communication protocol your new trading partner intends to use. “Looking before leaping” will help alleviate potential problems later.
It is often a common practice of organizations to develop new EDI trading partners and transaction sets from within the same environment where production EDI trading partners and transaction sets already exist.
While this is possible, it can often be disruptive and dangerous as the results of test and modifications could inadvertently result in problems with production data.
Employing multiple EDI environments will make it possible for a single EDI translator to have access to (and use) two or more “EDI configuration areas”; for example, to separate all production configurations and data from development (or production division 1 from production division 2). Continue reading
Many considerations must be assessed when deciding on a standard format for exchanging information electronically with trading partners. Two of the more widely used document standards are Electronic Data Interchange (EDI) and Extensible Markup Language (XML). Of course, when doing business with buyers and larger partners it is generally necessary to comply with the requirements of those trading partners. However, it is good practice, and demonstrates good business sense, to be proactive and develop an in-house (internal) data specification (and format) that will provide an option for smaller partners to comply with.
Questions must be answered before best decisions can be made for your needs. Continue reading
It is not uncommon to encounter situations where you need additional data that is not generally available either from your EDI application/interface (outbound) or from your trading partner (inbound).
Consider the situation where your trading partner sends purchase orders but omits the item descriptions…this item description being a necessary piece of information for processing the received orders. One option is to require that your trading partner includes this description for each item on the order – good luck trying to persuade a buyer to accommodate your request. Another option is to modify your application to eliminate this requirement – this may require a considerable amount of redevelopment.
The solution: Create an external table to host descriptions for each partner item that can be accessed during the translation process. Continue reading