|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
RE: <Sales> XML/EDI Products
Michael,
At the height of the dot com/XML rules craze there were a few companies out
there who created such a product. Before you invest anytime in doing such you
may want to see how they fared after the dot com shake down. I can't remember
the one company's name I looked at back in early 2000, but I do remember not
really liking the way they did the conversion. My main issues was that even
though I was able to get the data in an xml format, I needed a special XSLT or
something to get that into my database schema for each trading partner. The
reason for this was that not all my trading partners implementation of the
transaction set were the exact same, in regards to segment/element used or the
same code/qualifier. Now this was problem for us because of the number or
trading partners we were dealing with and the fact that we wanted to take a
trading partners existing format and translate that into our internal format.
On a small scale this may work.
Hope this is what you were looking for,
John
-----Original Message-----
From: Michael Mattias [mailto:
Sent: Thursday, February 13, 2003 8:46 AM
To: 'EDI-L (E-mail)'
Subject: Re: [EDI-L] <Sales> XML/EDI Products
> Michael,
> You don't have to buy an expensive translator to do the things you are
> talking about. .....
I think that is exactly what I was saying. One of my long-time 'gripes' about
'EDI software' is, in general, you have to license
(pay for) way, way more capability than you will ever need. Not only that, but
all the 'big guys' offer their products only as
complete suites, requiring the user to learn and maintain a whole system. I
really think this kind of cash and human investment is a
huge barrier to "edi-enabling" for the smaller user.
Suzy User doesn't want to enter a new customer, then enter a new 'trading
partner' in another system: Suzy User wants to enter the
new customer and check the "yes" box next to "Should this customer be set up as
an EDI customer?"
I work with clients in two primary industries: Manufacturing/Distribution and
Healthcare. So what do I care about Ocean-going
freight manifests, or customs declarations, or court filings? For that matter,
how many Real Users (i.e. non-consultants) would
need BOTH the Mfg/Dist transaction sets (850, 810, 856 et al) AND the healthcare
transaction sets (835,270,837 et al)????
Well, if the big guys don't want to look at the little guy market, I will. I'd
like to do this though the applications vendors..
probably because I've seen enough really poorly-designed "EDI Modules" from
vendors of accounting, billing or inventory systems to
know they could have done a whole lot better with some kind of API approach.
Michael Mattias
Tal Systems, Inc.
Racine WI
> -----Original Message-----
> From: Michael Mattias [mailto:
> Sent: Wednesday, February 12, 2003 12:53 PM
> To: EDI-L (E-mail)
> Subject: Re: [EDI-L] <Misc>Flat File Creation - clarification.
>
> 2/11/03
>
> <SHAMELESS COMMERCIALISM>
>
> A couple of months ago I had an idea for a low-cost "generic" tool which
> would convert ANSI ASC X12 EDI into XML and vice versa; the
> idea being to take advantage of all the relatively low cost XML software
> out there to obviate the need for an expensive translator
> for those who only need to handle a couple of transaction sets.
>
> This would take an input file containing ANSI EDI and create an output
> file kind of like..
>
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 the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
[Non-text portions of this message have been removed]
|
|
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
