Set up edi in a stable way with Bots.

Setting up the technical part of edi involves:

• Import/export to/from your application.
• The translation to and from various edi standards (edifact, x12, tradacoms).

Setting up the import/export inhouse file for your application

• Use XML or JSON: these formats are more flexible; eg easier to add fields.
• Import: extablish your minimal requirements: what is minimal needed to import eg an order.
• ID's of eg partners and articles will often be different than your internal ID's. You either solve this in your internal application or in the edi software. This is were standards like EAN/UPC number are important.
• References in an edi message will be used in other edi messages; eg the order number of the buyers will be needed in the invoic.
• Export: export 'as much as you can'. Let the edi software decide what to send.
• Try to import/export each field in your ERP application to one inhouse field.

Connecting new trading partners to edi

Three possibilities:

• The edi messages they send/receive 'fit' into what you do. Great.
• The contents 'fits' with what you're already doing, but they use a different standard/format/version/records/fields etc. This has no impact upon the import/export format, the import/export module or your (ERP) application. You have to make changes, often small, to the translation in Bots.
• The contents does not 'fit' with what you're already doing. This impacts the import/export format, the import/export module and the translation in Bots. Hopefully you do not need to adapt your (ERP) application itself - but probably, the impact will be much more than just technical anyway.

With Bots, we ourselves often set up a first, working translation, which is broadly usable. Later, small changes are made by the users themselves - these smaller changes are relatively easy. This is a quick and inexpensive process.

Edi's golden rule

Be relaxed in accepting incoming edi data: just take out what is needed for your business - no endless checking for the sake of checking. You do not have to enforce edi standards, do you?
Be strict in sending edi messages - stick to the standards.

Grammars and subsets of edi standards

When you make a grammar, make it in such a way that it covers the complete edi standard for the message. Do not build grammars for subsets of edi standards, e.g. adapting the number of sequences, leaving out records etc. 'because we don't use it'. Reasons:

• A grammar for an edi standard message is stable - it does not change. There will be newer versions - but adapting a grammar to a new version is easier if the whole standard is used.
• You want to support an edi standard, not your local subset - or the subset of your trading partner. Check this - often it is not clear what is being implemented.
• When connecting your next trading partner to edi, you do not want to adapt the grammar.
• If the trading partner sends records/fields you don't use: so what, as long as it is in accordance with the standard? Edi processing is about picking out the data you need. You do not want to get edi errors because your trading partner sends data you do not use or did not expect - as long as it is standard compliant. What if they start sending e.g. their article description? It's not your problem. This is how edi standards work.

If you want to do specific checks for your system, do this in a mapping script and/or in the grammar of your inhouse file.

Do I have to send exactly what my trading partner edi specified?

Depends:

• Often, a trading partner insists upon your sending certain data exactly as they want them.
• But not everything that's documented applies to your business - for example, if you don't deliver perishable products, or don't do direct store deliveries.
• Some requirements will be new to your company. But the trading partner might insists upon this. You will have to check this out in order to understand how and why they want this - and whether it's necessary for your company to send this.
• You are allowed to send more data than specified - as long as this is in compliance with the standard. Compare this with paper invoices: you probably use one format for all your customers. Each customer uses the information they need from your invoices.
  Using the same philosophy in edi can lead to ONE edi implementation which you use for all your customers.
  But sometimes a trading partner 'forbids' you to send certain data...

Do I have to process all data my trading partner sends?

No, but:

• Is the data required for your business? Then process it. And do not forget that e.g. the logistical process might change - often this is the reason why the trading partner starts using edi.
• Is the data required for other edi transactions? E.g. you often need to send the customer's order number in a subsequent edi invoice.

On the other hand, if the trading partner sends e.g. both article number and article description: why process the description? (It's probably different from your own article description, anyway).