<Flippant remarks deleted>
Please everyone using IMPDEF files raise your hand..... I thought so.
IMPDEF is not widely accepted in the USA and few if any widely used translators can
read in an IMPDEF file. It is
about as valuable today as SEF files. Hopefully such capabilities will be available
soon but they do not exist today.
Such discussions are totally irrelevant to people running an EDI shop.
>> generates IGs in IMPDEF
Very nice but no widely used translator can do anything with them. The software
vendors have to support them and they
will only do it if the market requires them. MegaCorp, Inc., is not going to convert
its EDI system to your
Translator to get IMPDEF import capability or automatic generation of 824s.
>> you save all the execution cycles and processor load of even hauling SAP or Oracle
> into memory ready to execute
Trust me. This is not an issue.
>> Building it in the IG where it already is.
>the quantity must be a whole number of cases
In the real world if MegaCorp Inc. wants to order 2.7 cases, they will do so and the
supplier will work it out. It is
not in their IG. Their IG indicates they ALWAYS order in gallons. IGs are external
to at least one-half of all
trading partners and therefore no predictions can be made on how they will be handled.
Besides if a customer wants
10,000 cases of widgets you don't bounce back the order because the PO requests
10,0000.5 cases. You forward it to a
functional person to get the order on the books as soon as possible.
Discount levels are so complicated that even the functional people have difficulty
with them. They can vary by
customer, order quantities, YTD & YTM quantities, ship to location.
The EDI translator is not the place to compute them. Application logic belongs in the
business application.
>>working on enabling automatic 824 generation
This may be of use to some but specs require a composite 824 which can only be created
after an inbound message has
passed through the business application. In other words you can send one 824 saying
"Account Number missing" and then
follow it up with another saying "Service not Provided".
Agreed: Computer Processable IGs would make this a better world.
My opinion: Application logic has no place in an EDI map.
----- Original Message -----
From: "Jonathan Allen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, May 22, 2001 12:32 PM
Subject: Re: Dual 997's
> Jim,
>
> > > ... encoded in the IG so that it can be processed by the translator.
> >
> > It sounds like you are talking about IGs in a computer format.
>
> Yes, IMPDEF, the international standard EDI message for IGs. At the
> risk of sounding commercial you can download a copy of our IG development
> tool that generates IGs in IMPDEF from out Website:
>
> http://www.asti-ebusiness.com
>
> It is multi-platform, written in Java, and is available in Open Source,
> The Windows binary download is only 8MByte, with 4010. You can order
> the Open Source with other standards for basically the cost of the
> distribution on CD.
>
> > Computer processable IGs would be very helpful in this real world situation.
>
> We have all the federal government IGs available in IMPDEF format, and a
> converter to pick them up from the format the government seems to currently use.
>
> > Unfortunately, IGs in computer processable format are basically non-existent
> > in most EDI shops. Obviously, they're a good idea but so far no standard
> > has been widely adopted.
>
> Is that because the people at the EDI shops won't go and get them, don't
> understand them or don't have the tools to do anything with them ?
>
> > The other issue that comes up is that, in addition to identifying business
> > rule errors such as you describe, you have to create error handling/audit
> > logging that can be used to create an 824. No translator does this
> > automatically that I'm aware of.
>
> I'm currently working on enabling automatic 824 generation from our translator
> that makes the process almost painless - simply another script command whenever
> an acknowledgement or error is required and the translator tkes care of
> assembling the 824 and the current contexts into the 824 structure and
> sending it out to the original sender.
>
> > > checking case sizes, discount levels against quantity can similarly
> > > be encoded in the IG
> >
> > You are building an application within the translator.
>
> No, not quite. Building it in the IG where it already is, but currently
> only in unparseable english words. The translator only implements the IG.
> Besides, these are simple constraints:
>
> the quantity must be a whole number of cases:
>
> assert quantity % case_size = 0;
>
> the discount level is tiered on the quantity:
>
> if quantity > 100
> assert discount = 10;
> if quantity > 1000
> assert discount = 15;
>
> > You don't want to do this. Organizations have spent 10s of millions to
> > implement SAP R/3, Peoplesoft, Oracle, etc. to do this type of processing.
>
> By using the translator to do simple automatic stuff like this, you save
> all the execution cycles and processor load of even hauling SAP or Oracle
> into memory ready to execute. You also get your EDI response straight
> back at the lowest level without needing a further translator run to
> handle outgoing 824s.
>
> Jonathan
> ------------------------------------------------------------------------------
> Jonathan Allen | [EMAIL PROTECTED] | Voice: 01404-823670
> Barum Computer Consultants | | Fax: 01404-823671
> ------------------------------------------------------------------------------
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
