Values for NCPDP field 103, Transaction Code. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ GENERAL REMARK ABOUT THE 9002313.82*** FILES: They're used much like a Fileman Set of Codes field might be used. So why aren't they implemented as a Set of Codes? 1) Sometimes the same field appears in more than one file. We avoid maintaining the same set of codes multiple times. 2) Quantity of data - some of these fields would have to be chopped and abbreviated in a big way in order to fit in one global data. dictionary node. 3) Consistency - we nevertheless want to hand all of these NCPDP fields with set of codes-like values in a consistent way, so even the ones which don't fall under the conditions 1) or 2) are handled this way. 4) Future extensions / expansions, which are at the whim of NCPDP, can be handled with no change to the Point of Sale application. 5) Backwards compatibility - many fields in 9002313.02 and .03 are already implemented as free text fields, sometimes with a two-byte field ID prefixed. It could get messy if we had to change them. ~ ~ ~ ~ ~ Now, what we might do in future development is to implement certain fields as pointers to these files. ~ ~ ~ ~ ~ Special note for Version 1.0: These fields are not used by any options reachable by users. However, they are usable in Join-type pointers with certain computed fields in 9002313.57 ABSP TRANSACTIONS, and as such, may be of interest in developing site-specific receipts now, and as a platform for developing a general receipt capability for the next version. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~