Best Practices for Mapping: Naming and Usage

Successful EDI implementations must begin with the development and employment of proper naming conventions and best practices. Too often a company will make hasty decisions in an effort to implement an EDI customer quickly only to find that good practices were not put to use and the bad habits are then continued for all remaining EDI implementations.

When mapping, it is important to develop and standardize in-house naming conventions that can be used for all maps. This will help to identify maps and keep them organized.  One recommendation is to use some variation or reference to the trading partner the map will be used for. Other suggestions may include using the document type, version, or division references in conjunction with the trading partner name. By using some of these methods in your map naming you will make it easier to identify the purpose of the map.

For example, consider if doing business with Acme Corporation they require the 850 Purchase Order (sent) and 810 Invoice (received) using version 4010. Map names might consist of “810_ACME4010S” and “850_ACME4010R.” Maintaining such consistency will be crucial for any EDI implementation, particularly if consisting of dozens of trading partners and document types.

There are many ways to use maps in conjunction with your trading partner setups. The most typical setup is one map, per document type, for each trading partner. This makes it possible to configure trading partner specific modifications to each map without the concern of how it might affect other trading partners who are sending or receiving the same data with you.

Should the organization or trading partner(s) have multiple divisions, another consideration is to use multiple maps. This involves creating multiple maps for one document type, for one trading partner. This application is excellent if each division requires strategically different mapping setups or if they have varying requirements (such as different EDI versions of the same document type). Despite this not being a common scenario, it can be accomplished but might require a unique setup for the trading partner.

It is also a viable option to use one map, for one document, but shared by multiple trading partners. This is ideal if you are “calling the shots” or telling your trading partners how you would like them to setup their maps for doing business with you. This is one of the luxuries a buyer might have by using a common format for all vendors.

These are just a few examples that illustrate how you can increase the efficiency and organization of any EDI system. Efficiency and organization are key factors to the optimization of any system.

7 thoughts on “Best Practices for Mapping: Naming and Usage

  1. Roy Hayward

    Wow. “The most typical setup is one map, per document type, for each trading partner.” Are you serious? This would seriously bog you down in endless updates, lack of a uniform and predictable process, slow response time to changes and end with getting you sacked.

    I have been about this for a few years. This might work if you goal was to integrate with 5 trading partners, but having an integrations that accommodate thousands of trading partners, there is no way we could ever maintain anything close to a 1:1 map and TP.

    There is a place for special features to accommodate a highly desirable TP, but there is no place to have a whole map dedicated to a single TP unless they really are the only game in town.

    Mapping is a job for a pro that can setup a framework that allows you to be nimble and comprehensive with new trading partners. There is logic that can be implemented that allows for some custom behaviour and leverages your mapping technology to make dis-similar things become the same thing.

  2. Babelabout

    The most interesting thing for me in this discussion is the fact that it would not happen if standard EDI formats – X12 or EDIFACT or … – were actually “standard”!
    I am sure that we – EDI specialists – would love to only have to maintain 1 mapping per document type (of a specific version). However, this is simply not possible, as standard formats are NOT “standard” :-(

    The X12 (or EDIFACT) “standard” is like being given a standard set of (thousands of) building blocks, but without being given a standard set of instructions to use when building things, and this results in a lot of non-standardised constructions.
    Both Supplier 1 and Supplier 2 could claim that they have used the same building blocks to construct their 850 Purchase Order, but at the end of the day their respective 850 Purchase Orders could be (and often are) completely different :-/
    Although you try to maintain 1 unique mapping for the 850 Purchase Order, you might end up having to code “If Supplier 1 do this, If Supplier 2 do that, …, If Supplier 1000 do…”, so instead prefer to maintain 1,000 different mappings, and try to keep them “consistent” with each other 😉

  3. Pingback: Tweets that mention Best Practices for Mapping: Naming and Usage | EXTOL Technology Blog -- Topsy.com

  4. Pingback: uberVU - social comments

  5. Roy Hayward

    @Babelabout

    I have heard this complaint many times. “X12 EDI is not really a standard.” And each time I go deeper, I find that I am talking with people that really don’t understand and use EDI. I am not saying that is the case, but it seems to be a recurring theme when I encounter there complaints.

    As someone who has implemented integrations with thousands of trading partners, I have seen some variances in the implementation and utilization of the varying document types, but nowhere near what you are describing. It just isn’t that hard.

    My experience is that retailers and vendors in a given industry all use pretty much the same set of data in pretty much the same set of segments. Yes, if you are crossing between say, the Automotive industry, and Healtcare, you will see a wide shift in what segments and what data they use in their 850. But between Ford and GM, there will be a very small difference.

    Maintaining a nimble map that handle part numbers in two or three places is not nearly as hard as maintaining 50+ 850 maps for 50 TP all doing versions of the same work.

    I understand that we all have our own experiences, but it does not sound like yours has been anything like mine. And EDI is what I do.

  6. John

    In my past I’ve used a hybrid approach where some of my demanding (substantial amount of business) trading partners who DON’T follow the standard get their own map. The trading partners that follow the standard for the most part, share a map even if I need to add logic as Roy mentions. If I had that same demanding trading partner in the shared map, it would increase the complexity of the map to where it is no longer maintainable.

  7. Babelabout

    @Roy Hayward
    Not very happy that you might think I am not understanding EDI, but at the end you made my point 😉 You said: ” Yes, if you are crossing between say, the Automotive industry, and Healtcare, you will see a wide shift”. That’s what I meant. If, as a supplier, you are managing EDI connections with both Automotive and Healtcare industries, you would prefer to maintain different mappings for the same document type, wouldn’t you?

Leave a Reply

Your email address will not be published. Required fields are marked *


*