Brian Herner, of PHx - Premier Health Exchange, is writing some new EDI
specs. His major frustration du jour is that he needs to figure out a
way to search EDI field names (option A) or code values (option B) for
keywords:
The initial problem was to figure out a way to indicate some
product information for a food service 832. For instance, we
needed a way to indicate that an item was Kosher. Figured it
out eventually, but it would have been much easier if we had
some sort of a database that we could have searched on the
word Kosher, either as an element name or code value. We
solved the problem by manually searching the codes from the
back of the huge ANSI X.12 paper manual. Ick. Took forever.
Brian wants a more automated way to accomplish this search. He doubts
that this can be done with EDISIM, or Lord forbid, some EDISIM
knock-off.
Dear Brian:
Do you think that I'm able to do all my special tricks on EDI-L just
because I'm any smarter than the average person? No, sir... but since
my EDI tricks have yet to help me get any dates, I might as well share
them with you: I use FORESIGHT's EDISIM EDI productivity tools. In this
case, I can use the EDISIM Standards Reference. Hey, the technique is
not pretty, but it works:
You didn't specify the standard, so I just picked any old one (in this
case a relatively new one: X12 004010) and opened it up in the EDISIM
Standards Reference. As everyone knows, EDISIM has a powerful search
facility on message or transaction set, segment, composite and element
names in a transaction set or message context or within the entire
standard. But EDISIM currently only searches on text descriptions for
code values within a particular element context, making us choose a
different technique for the "kosher" search. That's where the ASCII
File | Print feature comes in: I can select the standard name, and
generate a file containing the entire data element dictionary, replete
with code values and descriptions.
Bringing the file into a text editor, I can search for "kosher", and I
come up with a number of hits. For example:
Element 246 (Certification/Clause Code) contains code value '36' -
Kosher.
Used By:
C8 Certifications and Clauses
CRV Product Origin Reference
SUP Supplementary Information
Notice how the list contains a segment cross reference which shows all
the segments D.E. 246 appears in. And this same cross reference is
available in the Standards Reference viewer. So before we can even
begin to use D.E. 246 or wonder what it's all about, we have to see if
any of the three segments in which it is used are used themselves in the
832 transaction set. So I bring up D.E. 246 in the element dictionary,
and the segment cross reference appears in the lower left hand corner
pane. Skipping some details, suffice it to say that clicking on each of
the segment tags in turn shows all the transaction sets they're used in
(e.g., the C8 is used in TS 304 and 310). Unfortunately, none of the
three segments is used in the 832, so we can rule out D.E. 246 as a
possibility.
So I continue down the ASCII file, looking for the next occurrence of
"kosher". The next one is in Element 340 (Allowance or Charge Code),
with code value '510' - "Koshering". Standards Reference shows that
D.E. 510 is used in segments G46 (Promotion Allowance/Charge) and G72
(Allowance or Charge). Neither of those segments sounds promising since
they describe charges. Besides, "koshering", the code value
description, is a gerund (i.e., ends in '-ing') , which is suspicious -
more likely to describe a process than a product. But, more
importantly, D.E. 340 can be ruled out altogether because the G46 and
the G72 segments are used only in grocery transactions (U.C.S.) and not
in the 832.
Spurned, I continue my search. Next is Element 560, the Special
Services Code, where code 'KO' stands for "Koshering." Again, "kosher"
used gerundively might limit its utility. But I do have a healthy list
of eight segments shown by Standards Reference in which the 560 is used:
AT5, CS, CSH, H6, ITA, MS, PSC, and SSS; but, alas, none of those eight
is used in the 832. As Sister Bonaventure was wont to exclaim: Oy vey!
Next is Element 750, the Product/Process Characteristic Code. Oooh -
this sounds much better. But, unfortunately, the code I found is 'BCC',
whose description reads "Beverage Contents Characteristics, (e.g.,
Kosher, No Sulfites, etc. (Industry List))". I don't like this one -
"kosher" is used as an example in the text description, as if the code
is a qualifier describing an industry list; and for beverages, no less.
Let's move on, even though D.E. 750 is used in the PID segment -
Product/Item Description - conveniently located within the 832's Line
Item loop.
The next candidate is D.E. 755, the Report Type Code, whose 'KC' code
value means "Kosher Certificate." Of the twelve segments Standards
Reference shows the element to be used in, none appear in the 832, so
it's irrelevant anyway.
Finally, my last hit, Element 1300 - the Service, Promotion, Allowance,
or Charge Code - contains code value 'E150', described as "Koshering."
Of the three segments the EDISIM cross reference shows the element to
reside in, only the SAC - Service, Promotion, Allowance, or Charge
Information - appears in the 832, albeit in the line item loop. Well, I
guess you could use the SAC to say a "koshering" service is applied to
the product!
Is this what you came up with? After getting familiar with the file
generation feature and learning how to point and click your way through
the cross reference in the EDISIM Standards Reference, this type of
exercise can be whittled down to 5 minutes or less!
William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
(614) 791-1600
Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
