BEMIS - design principles

A BEMIS business document must be designed following a predefined set of rules. If these rules are not met, the business document does not comply with the BEMIS standards.

EDI message

The code of an EDI message within a business document includes the name and version (XXX999). The name is alphanumeric and the version is numeric. Both have a length of 3.

Example

The order EDI Message is called ORD 001.

Message NameVersion
ORD for Order001

 

In situations such as the following, multiple versions of an EDI message can exist:

  • 80% of the customers require a simple version and 20% require a complex version of the message.
  • Two external standards conflict.
Conversion setup

If changes are made to the EDI message within a service/feature pack, a new conversion setup is created for that feature pack.

The format of the conversion setup is XXX999, in which:

  • The first three positions are equal to the first three positions of the EDI Message
  • The last 3 positions are sequential

Each time a change is made, the number increases with 1.

Example

The order EDI Message is called ORD 001.

The first conversion setup is called ORD001 in Infor LN.

Changes are made to EDI Message ORD001 in Infor LN SP1. This results in a new conversion setup called ORD002.

In Infor LN FP2 no changes are made to EDI Messages ORD001. As a result, the conversion setup does not change and remains ORD002.

Data segment

Each data segment has a unique code within an EDI message. The format of the data segment code is SA99. The unique code of the first data segment is SA1, the second is SA2, the tenth is SA10, and so on.

Backwards compatibility - position

A business document consists of multiple EDI messages that contain multiple data segments with multiple positions. On those positions, data elements can be defined. Once the functional meaning of a position is determined, do not change it.

For example, on the data segment Order Line, position 10 contains the item (tdsls401.item). In a new version of a business document the item must still be on position 10.

Important!

To minimize the impact when implementing a new version/release or feature pack of LN, do not change positions. If the functional meaning of a position changes, you must also adapt the EDI translation software that converts the external standard into the internal (BEMIS) standard or the other way around.

Backwards compatibility - conversion setup

Within a specific LN version/release, you can use business documents of older feauture packs in new feature packs. In this way, the impact of implementing a new feature pack is reduced, because customizations on business documents need not be re-executed.

Only if you want to use new functionality, customizations must be executed on the new business document, or the new functionality must be added to existing business documents.

Backwards compatibility - generic interface

To set up a generic interface in which data can be reused and costs are reduced, you must define business documents/EDI messages that are related to different external standards.

All relevant information concerning the related business processes must be defined in the business document/EDI message in such a way that different external standards are supported. Only in case of conflicting external standards, multiple business documents/EDI messages can be defined.

Message overhead

Each EDI message within a business document always contains a data segment, called message overhead (data segment SA1).

The information of the message overhead is standardized and in accordance with the LN application. The following table displays the content of the message overhead.

SA1 Message Overhead
StatusMandatory
FrequencyOnce for each EDI message
DescriptionThe message overhead data segment contains information about the transmitter, the message type and the time of the transmission. The message reference identifies all related data segments of this message.

 

BEMIS formatMapping table fields (OUT)Mapping table fields (IN)
Pos.DescriptionKeyMandatoryCodeCode
1Data Segment-Yes"SA1"-
2Message ReferenceXYesecedi701.banoecedi702.bano
3Identification of the SenderXYesecedi020.netaecedi702.bpid
4EDI Message ReferenceXYesObject Identification, for example, tdpur400.ornoecedi702.msno
5EDI message-Yesecedi001.codeecedi702.mess
6Organization-Yesecedi003.codeecedi702.orga
7Order Type-Yesecedi011.koorecedi702.koor
8Identification of the Receiver-Noecedi028.neta-
9Transmission Date-Yesdate()ecedi702.send
10Transmission Time-Notime()-
11Identification of Test Message-No""ecedi702.test
12Data Segment End Sign-Yes"SA_END"-

 

Data segment start and end signs

Each data segment starts with a data segment identification and ends with a data segment end tag. So, the first data segment starts with SA1 and ends with SA1_END, following the data segment naming and versioning.

Data element length

The BEMIS standard uses a variable field length. A fixed field length is not allowed within the BEMIS standard.

Data record separator

The BEMIS standard uses the “LF” control character for separating data records.

Empty positions

If the delimiter is ";" and the sign around the strings is “ on the network, the BEMIS standard shows an empty position as follows:

Alphanumeric“SA1”;…;””;…;”SA1_END”
Numeric“SA1”;…;;…;”SA1_END”

 

If the sign around strings on the network is empty, no difference exists between alphnumeric and numeric. In this case, the BEMIS standard shows the empty position as shown for numeric data elements in the above table.

Single/multi file

In Electronic Commerce, you can define single and multi files. In case of a single file, the entire EDI Message is stored in one file. In case of multi files, each data segment of the EDI message is stored in a separate file.

The BEMIS standard only supports the single file option for incoming and outgoing EDI messages.