I do exactly that - to a point. Inbound docs such as orders use one map (one
850 and one 875, that is) with every segment active and a few from different
versions stuffed in there like MSG MTX and N9 in the same map. I have a
codelist that stores what qualifiers each customer prefers for parts and dates.
That map goes to a standard layout that I use to do validations and
integrations into the ERP. What the customer might send to indicate a ship
date and cancel date might be different but what I do with those dates once I
have them is always the same. Not everyone does this part of the work. Some
EDI systems do just the EDI translation but in my opinion SI is overpowered and
overpriced if you have it doing just EDI translation. Because that integration
work can take some time and throw errors for reasons that should not
inconvenience the external customer, I separate it from the EDI translation so
that they get their 997 based on the EDI translation and not internal
integrations.
For outbound invoices and ASN's I have found its not worth having one map.
They all use different segments and I have this personal rule that if I have to
use the function "empty" then I am doing something wrong upstream and working
too hard. If you need to manipulate the data you get from your internal
systems in the same way for every customer then make a map that does that for
everything and then pass it to the individual partners maps for EDI
translation. I do maintain a standard generic outbound map that has all the
different things a customer could want and all the segments activated and I use
that one as a basis for making my new customer map. In that way, much time is
still saved in bringing up new partners. Occasionally I have to update every
single outbound map for a transaction if something has changed but that can't
be helped. Testing is a matter of grabbing production files and running them
with the new map in test to make sure they match the production copies with the
exception of the change I wanted to see (if it was something I wanted to see).
On Feb 8, 2013, at 10:47 AM, shluft wrote:
> Hi.
>
> In preparation to our SAP migration I've offered my boss to migrate our
> numerous customized and mostly simple per-partner maps into centralized map
> driven by partner-based parameters configured within the EDI system (Sterling
> Integrator).
>
> My boss was challenging me whether this was within "Best practices of EDI". I
> understand this is rather conceptual issue, and question is whether it would
> be hard to maintain centralized map (whenever there is a need to change
> something for 1 partner, you'd have to retest the data for all of them, I get
> that :)))
>
> Never the less, if EDI is not ran by consulting shop, and the long term goal
> is reducing maintenance and cost - would this approach fall within "Best
> practices of EDI" and would there be any documentation out there to support
> it, other then exchange of opinions of EDI gurus on this mailing list?
>
> Yeah, and I wana fries with that!
>
> Happy Friday!
>
> :))))
>
> Thanks!
>
> Ilia.
>
>
[Non-text portions of this message have been removed]
------------------------------------
...
Please use the following Message Identifiers as your subject prefix: <SALES>,
<JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC>
Job postings are welcome, but for job postings or requests for work: <JOBS> IS
REQUIRED in the subject line as a prefix.Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/EDI-L/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/EDI-L/join
(Yahoo! ID required)
<*> To change settings via email:
[email protected]
[email protected]
<*> To unsubscribe from this group, send an email to:
[email protected]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
