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.
The order EDI Message is called ORD 001.
| Message Name | Version |
|---|---|
| ORD for Order | 001 |
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.
The order EDI Message is called ORD 001.
The first conversion setup is called ORD001 in LN.
Changes are made to EDI Message ORD001 in LN SP1. This results in a new conversion setup called ORD002.
In 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.
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 | |
|---|---|
| Status | Mandatory |
| Frequency | Once for each EDI message |
| Description | The 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 format | Mapping table fields (OUT) | Mapping table fields (IN) | |||
|---|---|---|---|---|---|
| Pos. | Description | Key | Mandatory | Code | Code |
| 1 | Data Segment | - | Yes | "SA1" | - |
| 2 | Message Reference | X | Yes | ecedi701.bano | ecedi702.bano |
| 3 | Identification of the Sender | X | Yes | ecedi020.neta | ecedi702.bpid |
| 4 | EDI Message Reference | X | Yes | Object Identification, for example, tdpur400.orno | ecedi702.msno |
| 5 | EDI message | - | Yes | ecedi001.code | ecedi702.mess |
| 6 | Organization | - | Yes | ecedi003.code | ecedi702.orga |
| 7 | Order Type | - | Yes | ecedi011.koor | ecedi702.koor |
| 8 | Identification of the Receiver | - | No | ecedi028.neta | - |
| 9 | Transmission Date | - | Yes | date() | ecedi702.send |
| 10 | Transmission Time | - | No | time() | - |
| 11 | Identification of Test Message | - | No | "" | ecedi702.test |
| 12 | Data 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.