Problem solve Get help with specific problems with your technologies, process and projects.

Web-based invoicing systems

We are getting hit with numerous customer requests to begin using their Web-based invoicing systems which for the most part appears to be Web interfaces that create EDI 810 files. If we want to eliminate the duplicate effort and create these from SAP R/3, where do we start? A year or two ago I was told the business connector was the solution. I recently read SAP has determined to end-of-life it. Is XI the answer or is it SAP's infant solution to third party EDI subsystems? Are most companies using a third party EDI subsystem? I have read horror stories with Gentran and some good things about Mercator & Atos Origin.

Where should I start researching what such an EDI/XML project entails?
Well, I heard horror stories about ATOS Origin, Mercator, Frontec and good things about Gentran or Seeburger. This depends on the personal experience, I am not meant to give real recommendations or damn any one of these tools. They are all pretty much the same and the result depends on the people of the respective bureau that services you.

No, the problem is not the tool, they are all more or less the same. All the mentioned companies have a policy: they do not generate revenue by selling adapters, but by selling services. So they want you to subscribe to their service to set up the converter for your needs.

The horror stories stem mainly from three sources:

The converters are sparsely documented because the companies want to send their own people to do the set up for you. The usually offer what they call a Value Added Network (VAN), meaning that you send your raw data to them and they do the conversion and delivery. If you are not willing to subscribe for this effort their support is reluctant.

EDI is a vague standard. EDIFACT/UN and ANSI/X.2 describe formats, but most companies make minor modifications with terrific consequences. This goes so far that some misinterpret the delivery note number: the sender thinks this is the delivery note number of his document, the receiver thinks it is the delivery note number of the transporter. If you deal with large companies like automotive, they force you to prepare EDI message according to their standards. This leads often that you create slightly different message for the same type of content for GM, VW, BMW etc.

Interface is about communication. Communication lives from speed and interaction. If you sit in Wyoming and your EDI partner in Rhode Island, then all the communication may become very tough. Especially if the partner has a tendency to point you to their Web site where allegedly all definitions are properly published. A good and efficient EDI setup requires some physically sitting together and doing testing. If you do not know your peer, it won't work. That is why those VANs are useful, because they know the requirements of most major firms and can act bas their representative in dealing with it.

I already explained my take on SAP BC and SAP XI in previous posts, basically concluding that they are not EDI tools. It is first of all true that SAP XI completely replaces SAP BC, which was a licensed third-party Windows product. They can be transformed into EDIFACT converters by accessing respective templates, which exist for free for the SAP BC.XI might be able to use them as well, but I have not tried it.

There is a company in Germany that also delivers a converter for EDI written in ABAP and is hence a simple ABAP plug-in. Check with Axantis AG in Schriessheim/Heidelberg http://www.axantis.com. I have not seen it life yet, but it looks promising.

But again, to make it clear: The secret of successful EDI is not the converter tool. Rather, it lies in the conversion templates and translation tables that must exist for every EDI message type and often as a dialect for individual major companies that use EDI. This is especially true for automotive and retail, while other industries are typically much more flexible.

If you are not within automotive or retail I strongly suggest to make any effort to convince your EDI partners to use simple EDI/XML, which is straight-forward, error redundant and the definitions are freely accessible via the WWW. On the other hand, you would have to pay real money for just reading the EDIFACT standard. However, none of these approaches frees you from building the know-how to understand what our EDI partner need. That is the cost driver and the asset of the VAN providers.

Dig Deeper on SAP Web applications

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.