Sample EDIFACT Orders

UNA:+.? '

never

Start of file

Can contain multiple order messages

UNB+UNOC:3+901494200:31B+0142948:31B+130620:0315+1001'

UNOC:3 -> constant value

vendorEdiOrdersExportConfig.
libEdiCode

vendorEdiOrdersExportConfig.
libEdiType

vendorEdiOrdersExportConfig.
vendorEdiCode

vendorEdiOrdersExportConfig.
vendorEdiType

current date:time

Job ID

never

Interchange header Library EDI code:Library EDI type; Vendor EDI code:VendorEDI type + datetime + file ID

seller first, recipient second, date-time of preparation, file ID (starts with 1 and can go up to 14 digits)

UNH+1001+ORDERS:D:96A:UN:EAN008'

Job ID

ORDERS:D:96A:UN:EAN008 → constant values

never

Order header = Start of order; EDIFACT message type

There would be a new UNH for each FOLIO PO in the file

BGM+220+2808+9'

compositePurchaseOrder.

poNumber

never

FOLIO PO

220 = order
224 = rush order

If at least one of the lines is rush, it's a rush order

9 = original

7 = duplicate (ie retransmission) = resend

With current implementation orders are exported only once, so qualifier is always 9.

DTM+137:20130620:102'

137 -> constant value

compositePurchaseOrder.

dateOrdered

never

Order date:Date format

Use dateOrdered or use file construction date?

DB: Use the date ordered. the vendor will probably ignore this date as they assigned their own order date when the file is processed on their end.

NAD+BY+901494200::31B'

vendorEdiOrdersExportConfig.
libEdiCode

vendorEdiOrdersExportConfig.
libEdiType

never

Library EDI code and Library EDI type

"buyer name" (according to this doc)

Can it vary within an order?

DB: No, if there is a line with a different account that is for a different EDI configuration it will be added to a different file. It think we need to ignore the Library EDI code data point that exists in the account schema.

NAD+SU+0142948::31B'

vendorEdiOrdersExportConfig.
vendorEdiCode

vendorEdiOrdersExportConfig.
vendorEdiType

never

Vendor ID and ID type

"supplier name" 

RFF+API:854674:91'

compositePurchaseOrder.

compositePoLines.[first].

vendorDetail.

vendorAccount

91 → constant value - This qualifier should actually only be used for Name and address of place/location NOT account number/buyer ID

if null

"buyer ID number"

What do we do if there are different account numbers assigned to different lines in this PO?

DB: I propose we do not allow this for the initial version of the integration. Meaning that if one of the POLs on a PO is flagged for export all flagged POLs on that PO must have the same account number. Ideally this validation can be done when opening POL. If not we will need to throw an error when building the file. The error message should include all PO numbers that could not be exported.

TODO: could you please create a UI story @Dennis Bridges Done

DB: Note it's possible that the order will have no account number. If the EDI configuration is the "Default integration" there will be no account number.

From docs: RFF REFERENCE One or two optional occurrences per segment group SG02, giving the VAT or other
tax registration number of the party named in the linked NAD segment, where
required as part of the order, or an additional identification code for the party,
normally a supplier’s account code for the customer (API) or a customer’s internal
vendor reference (IA).

CUX+2:GBP:9'

2 and 9 -> constant values

system currency from configuration module

currency from PO line

never

Order currency

If FOLIO default currency and vendor currency are not the same, this may include info about both currencies, with different qualifiers

9 = order currency

10 = pricing currency

Prevent mixed currency within an order by skipping such orders, and let the user know about an error!!!

Do we still want to prevent anything? From the example below it looks like it's fine to have different currencies.

DB: Send system currency at this level and POL currencies at the line level. GOBI shared an example of this

A recent example from an Australian customers who's default currency is AUD but item currency is USD:

UNA:+.? ‘
...
CUX+2:AUD:9’
LIN+1++9781526419071:EN’
...
CUX+2:USD:9’
...
UNZ+1+1641528578’

JR: This behavior was changed due to MODORDERS-1152: Fix additional fields in EDIFACT order syntaxClosedPreview

LIN+1++9780393966510:EN'

compositePurchaseOrder.

compositePoLines.[first].

details.

productIds.[?].

productId

check the productIdType to be one of the following (include the first one):

ISBN, ISSN, ISMN

If the product ID is 13 digits it should have a qualifier of EN

IF not:

qualifier: IB, IM or IS based on type

never

Order line 1
Product ID:ID type (EAN/UPC/barcode number)

May or may not be the same number as the POL line number, since the POLs may skip numbers, and the EDI order does not.
Since ISBNs expanded to 13 digits, they are equivalent to UPC barcode numbers
Identifier qualifier not included

From A-M: Keep in mind that the product ID is not always an ISBN. I think it's important to include the qualifier, which we should be able to identify based on the Product ID type. And if the Product ID type is not recognized, have a backstop of "other" or "unknown".

DB: "The LIN segment carries the line number within the message, and may carry an EAN-13 article number (barcode number). The PIA segment carries any other product identifiers." Documentation identifies this as the General Trade Item Number (GTIN) which for library purchases may be accepted as 13 digit ISBN as AM stated above.

PIA+5+9780393966510:EN'

compositePurchaseOrder.

compositePoLines.[first].

details.

productIds.[n].

productId

qualifier: IB, IM, IS or MF based on type

PIA+5+ for product ID from previous field

PIA+1+ for all other product IDs

if null

Product ID:ID type 

ISBN-10 is no longer necessary
PIA includes whatever Product IDs are in the POL, not just an ISBN

5 is a constant value?

DB: One or more occurrences are used in this application to send an ISBN and/or a supplier’s own product code, either as the main product identifier (where no EAN number was given in LIN segment 39, or as an additional identifier. If no product code is available, the PIA segment is omitted, and the product must be fully identified by description in IMD segment 41. An additional occurrence may be used to identify an acceptable substitute for the product ordered.

1 = additional identification: use when the PIA segment carries an identifier which is additional to the main product identifier (eg a supplier’s own code sent in addition to the ISBN or EAN number) 1S = additional identification: an identification number for a multi-volume or multipart set to which the product belongs 2 = identification of an acceptable substitute 5 = main product identification: use when the PIA segment carries the main product code (normally the ISBN)

EN = EAN-13 article number

IB = ISBN (International Standard Book Number)
IM = ISMN (International Standard Music Number)
IS = ISSN (International Standard Serial Number): use only in a continuation order
message coded 22C in BGM DE 1001, to identify the series to which the order
applies
MF = manufacturer’s article number
SA = supplier’s article number

IMD+L+009+:::Stiglitz, Joseph E.'

L+009+::: → constant

compositePurchaseOrder.

compositePoLines.[first].

contributors.[n].

contributor

repeat for each PO line

if null

Author (Contributor)

Optional: up to 99 repeats of IMD segment 41 may be used to give bibliographic details of the item to which the order line refers. This is mandatory if the item is not identified by a code or codes in LIN segment 39 and/or PIA segment 40. Where the text of a bibliographic data element exceeds 70 characters, additional repeats of the segment, carrying the same code in DE 7081, may be used as “continuation” segments.

Multiples would be 

IMD+L+009+:::

IMD+L+009+:::

IMD+L+050+:::Economics of the public sector / Jo:seph E. Stiglitz.'

L+050+::: → constant

compositePurchaseOrder.

compositePoLines.[first].

titleOrPackage

wrap if it's longer than 70 characters

never

Title

From docs: Where the text of a bibliographic data element exceeds 70 characters, additional
repeats of the segment, carrying the same code in DE 7081, may be used as
“continuation” segments.

IMD+L+109+:::W W Norton'

L+109+::: → constant

compositePurchaseOrder.

compositePoLines.[first].

publisher

if null

Publisher

IMD+L+110+:::New York ?:'

always

Place of publication

Not available from FOLIO POL

should we use a default value for this field?

From A-M: No, omit the field. Do not use a default. Since it's not a required field, that will be OK.

IMD+L+170+:::c2000.'

L+170+::: → constant

compositePurchaseOrder.

compositePoLines.[first].

publicationDate

if null

Publication date

IMD+L+180+:::Book'

L+180+::: → constant

materialTypeService.getMaterialTypeName

for

compositePurchaseOrder.

compositePoLines.[first].

physical.

materialType

or

compositePurchaseOrder.

compositePoLines.[first].

eresource.

materialType

repeat the field for each type specified

if null

Material type

which material type should we use for mixed orders?

From A-M: If no Inventory created, material type is optional. I would use the following (but doublecheck with @Dennis Bridges )

• No material type specified: omit the field

• Multiple material types specified: repeat the IMD+L+180 field, and put each material type in a separate IMD+L+180 field.

QTY+21:1'

21 -> constant value

compositePurchaseOrder.

compositePoLines.[first].

cost.

quantityPhysical

or

compositePurchaseOrder.

compositePoLines.[first].

cost.

quantityElectronic

whichever is higher

never

Quantity ordered

should we count the sum of electronic and physical copies? or should we create a separate field for each type?

From A-M and Acq SIG:

• If P/E quantities are equal, take one of the numbers.

• If P/E quantities are not equal, take the higher number.

• DO NOT sum them.

• If strange numbers, will likely have a Note to Vendor (Can QTY be associated with material type? No. If so, then assign separately)

PRI+AAB:49.99'

AAF → constant value

compositePurchaseOrder.

compositePoLines.[first].

cost.

poLineEstimatedPrice

if null

Price

Several different kinds of qualifiers may be used; see documentation

From the documentation:

Price qualifier M an..3 AAA = calculation price net (the unit price which will actually be charged by the
supplier excluding tax but including any allowances or charges)
AAB = calculation price gross (the supplier’s unit price excluding all taxes,
allowances or charges)
AAE = information price (including tax but excluding any allowances or charges)
AAF = information price (including all taxes, allowances or charges)

DB: We only reliably capture Unit price in FOLIO so the Unit price AAB should be used here.

CUX+2:GBP:9'

2 and 9 → constant values

compositePurchaseOrder.

compositePoLines.[first].

cost.

currency

if null

FTX+LIN++::intentional duplicate'

compositePurchaseOrder.

compositePoLines.[first].

vendorDetail.

instructions

if null or empty

POL: Instructions to vendor

RFF+LI:2808-1'

compositePurchaseOrder.

compositePoLines.[first].

poLineNumber

never

FOLIO POL

compositePurchaseOrder.

compositePoLines.[first].

fundDistribution.[?].

code

depending on the configuration, this should be either replaced or followed by ?: and by expense class that we would get by calling a service and providing expense class ID found here:

compositePurchaseOrder.

compositePoLines.[first].

fundDistribution.[?].

expenseClass

repeat for each fund distribution up to 9 (10 total RFF fields)

if null

FOLIO fund code

Example:

RFF+BFN:HIST?:Elec'

Also expense class? Colon has special meaning in EDIFACT; will it be an issue that FOLIO uses colon between fund and expense class? (use ?as an escape?)