Dear [EMAIL PROTECTED]
If you can truely do all this with little or no programming than you are by far a
better EDI consultant than I have been. It does sound a bit too "perfect world" to
me, but maybe I am wrong here.
I do have some questions though:
1. In your point #1 you say "Then when the data base(s) are built". This indicates
to me that you are not only involved in setting up EDI for your clients, but also
involved in some of the database and application design and construction. Doesn't
this involve.... um programming? Not just for the database structure but for the
applications that use these database structures? I have worked on such projects that
involved dozens of programmers for months. What am I missing here?
2. Having work fields to accomodate differing data needs of different partners is a
great idea. This could be stored in a key/value pair array so what the field
represented was stored in the key field. This is an excellent idea and would
certainly help the application be more Trading Partner generic. Where a client has an
ERP (all that I have seen) without these features, they would still need to programmed
in, correct?
3. RE: "The advantage of these mappers (at least the ones I work
with) is that in a period of 1 week, I can train almost anyone in the office
environment to perform maintenance and/or additional mapping for new Trading
Partners without ANY assistance from a programmer."
If you can do this with almost anyone in the office environment, then I know you are a
better EDI consultant than I! Yes, people can be trained to use these good tools.
The problem is that a non-programmer will rarely make correct choices on what
conditional statements to make and what to setup and why. If you mean doing some data
input to setup the next Trading partner who is using generic EDI format, then yes.
But putting in conditionals to do something special for that TP, then I highly doubt
it.
This sounds unusually similar to the personal DB hype of the late 1980's and early
1990's. Small personal, or departmental Databases were the rage: dBase, FoxBase,
Access, etc. They were so easy to use that non-programmers could do queries and even
program them! The hype at the time was that they would make programmers obsolete and
not needed anymore. Users would do their own programming!!! WOW!!
Did that happen? Why not? It is because most users except a few power users don't
understand the science of information. Things like: the repeating nature of data
elements and thus correct ways of structuring data, what is grouped together and why,
etc. Even though it is not writing code, setting up a conditional choice in a nice
GUI tool is still programming. I have learned from experience, users are NOT capable
of programming. Hell, I have known my share of programmers who weren't that capable of
it either especially when you add design decisions into the mix. The biggest part of
programming is not writing the code. It is the design choices that go into it.
No, I have to say that your #2 statement above is too "perfect world" for me to
accept. I wish it were true, because then I could go do more interesting things with
my programming skills, than boring EDI programming.
Steve
At 10:25 AM 7/6/00 -0400, info wrote:
>Steve,
>
>If an organization is finding it necessary to do programming for each
>Trading Partner's variation of a purchase order one of two things has
>occurred.
>
>1) A failure to do complete analysis of the Order Processing system (be it
>ERP or legacy). As an EDI consultant, I compile data defining every
>possible required field for Order Processing and a separate list of all data
>that has to be returned to the Trading Partner (although not used on the
>vendor's end). Then when the data base(s) are built they are "all-inclusive"
>and will book correct orders in the Vendor's system and maintain all data
>required to return to the customer. Additionally, I provide a set of "work
>fields" that allow for variations in data requirements for that "next
>Trading Partner". After all, the receiver of a document should know what
>his/her requirements are and anything other than that constitutes
>meaningless data. If your Trading Partner insist on receiving that
>"meaningless data" back on other EDI documents (ASN etc) simply map it to
>the "store and forward fields" described above.
>
>2) A poor choice of EDI software solutions. There are currently many EDI
>software packages for various platforms which are capable of handling all
>sorts of manipulations (I call them creative interpretations) of the X12 and
>EDIFACT standards.
>
>I too have been in EDI for over 10 years and have spent the last 6 as an EDI
>consultant. I spend the majority of time installing and implementing EDI
>software for small to mid-sized companies. Typically, the only programming
>required are is any driver programs to execute the in-house (ERP or legacy)
>edit/update jobs after each communication (be it internet, VAN or direct).
>
>The mappers available in today's EDI software are fully capable of providing
>conditioned results, doing math operation and manipulation of codes and
>field differences. The advantage of these mappers (at least the ones I work
>with) is that in a period of 1 week, I can train almost anyone in the office
>environment to perform maintenance and/or additional mapping for new Trading
>Partners without ANY assistance from a programmer.
Steve Bollinger 408-853-8478
Cisco Systems GPS-IT XML/EDI Logistics & Maintenance Project
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
