Gee, we did the same thing, and everyone said we were nuts. I guess the model
(using a normalized file in the middle) isn't so unusual or creative after all.
"Hurd, Richard A (Rich)" wrote:
> > It is easier to map to a field called %buyer_tech_faxno in an
> > intermediary file format. In fact the identification of a parameter in
> > your application as %buyer_tech_faxno *is* the mapping. The nasty
> > resolution to NAD/BY -> CTA/AT -> COM/FX is done by a fixed secondary
> > mapping which your friendly EDI system vendor has already set up for
> > you, and you need not know anything about.
> >
> We do somewhat the same thing with many of our maps, due to the complexity
> of the interfaces that we deal with. Most of our mappings go to a "generic"
> intermediate map, which takes a simplistic application UDF as an input file
> and generates a (much more complex) application UDF file that gets sent to
> the application gateway. Based upon our naming standards, where we use
> "UGENE" as part of the file name to indicate a "generic" map, we
> (semi-)fondly call these maps "Eugene" maps.
>
> > This doesn't impact on a mappers capability of dealing with the variety
> > of forms of application side data model; it is just simplifying the
> > perceived complexity of the EDI side. This means that mapping can be
> > performed successfully by those not wholly immersed (pickled might be a
> > better word) in the niceties of the EDI transaction itself.
> >
--
%%%%%%%%%%%%% cut here %%%%%%%%%%%%%%%
Brian Lehrhoff ([EMAIL PROTECTED])
EDI Consultant
eB2B Commerce
212-703-2121
%%%%%%%%%%%%% cut here %%%%%%%%%%%%%%%
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
