|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
RE: Another beginner question from a Mercator novice
Hi,
I don't know Mercator, but generally speaking I disagree with having a
different map for every trading partner. While you need a map for each
structure (e.g. standard pack vs. pick and pack) and for each standard
version, within that I prefer to use if..then..else logic and tables to
accommodate the differences by trading partner, just like I do with all
the other transaction sets.
Even though there is more to each map this way, maintaining fewer maps
is its own reward. In my time with EDI I have been through, several
times, the cycle of buy the "best" product, watch it get bought by
someone else and either "merged into" the purchasers existing product
(i.e. killed off) or outright just killed off. I would much rather
support and convert 45 maps rather than 450 maps. Also, sometimes just
when you think you've got it right and you've cloned all of those maps,
oops, there's another field you have to add (which now must be added in
100 maps).
There are exceptions, such as someone whose requirements are very
different from everyone else's. These are a good candidate for a
customer specific map, but this should be the exception (I know that
standards are guidelines, not requirements, but still . . . ). But when
the maps are ninety-something percent the same, a little if..else logic
goes a long way.
I've always heard good things about the power of Mercator (the downsides
being price and learning curve), but I would consider it a bad thing if
there was some compelling reason why you must create trading partner
specific maps instead of multi-partner maps.
Ken Cox
Brach's Confections
-----Original Message-----
From: Michael Mattias [mailto:
Sent: Thursday, January 16, 2003 8:12 AM
To:
Subject: Re: [EDI-L] Another beginner question from a Mercator novice
> I'm wondering what the easiest way is to map an inbound or outbound
Well, I'd ask for "best", not "easiest," but that said...
> Then, for each customer you have to create an outbound
> ASN for, you just modify that general map with any customer-specific
> info, and save the changes under a different name.
That's as good as any other method. I'd lean toward separate map files
for each partner for one reason: maintenance.
Unless, of course, you can be totally certain that all your partners
will update their IG's on the same dates.
FWIW, you will probably end up creating several output type trees for
ASNs, because one partner will be pick-and-pack and another
standard-pack; one partner will request shipment-level tare info (CLD
segment) another will request part number-level tare info,etc.
What I've always done is create one physical type tree file with various
'generic' ASN structures, then for each partner the map file uses the
appropriate output type tree.
That is, while I believe in separate MAP files for each partner, I
believe in common type tree files.
My view may be jaundiced a bit by the way I work, which is to set up the
"first" of a particular document for a client with a specific goal of
making it easy for the client to do his own second and subsequent
versions of that document. I've found my customers can like to do new
maps themselves, but not one of them does enough type trees that they
are at all interested in doing it. (Creating and maintaining type trees
is, IMO, far more challenging than creating and maintaining maps).
YMMV.
Michael Mattias
Tal Systems, Inc.
Racine WI
To unsubscribe from this group, send an email to:
Message Identifiers: <SALES>, <JOBS>,
<LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the list online at:
http://groups.yahoo.com/group/EDI-L
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
|
|
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
