User tips: How do format descriptions work?

Format descriptions work in the engine room of our products. They define how EDI files must be structured and filled so that they map business processes correctly. The overriding goals here are precision and efficiency: Users must understand the specifications precisely and do so with as little prior knowledge as possible and in as little time as possible. To meet these goals for different requirements, we use three elements to build format descriptions: Syntax specifications, rules, and sub-processes.

However, it is just as important for our customers to understand how these tools work - after all, they are the ones who set the specifications for format descriptions. At this point, we would therefore like to show which element is best suited for which task and thus give you a feeling for how a good format description should be structured.

Syntax specifications refer on the one hand to the status of a segment and the data fields it contains. If these are mandatory, the data sender must use them; if they are optional, he can do so at his discretion. On the other hand, you can specify whether minimum or maximum lengths must be observed for the fields, whether the content may consist only of numbers or also of other characters, and whether it must follow a certain pattern.

Setting syntax specifications is recommended in cases where content must always be transmitted in the same way in a business process. For example, the segment in which the net total of an invoice is mapped could be given the status 'mandatory' because this information is relevant for all invoices. In a format description for delivery bills, on the other hand, you could specify a list of packaging material codes that the data sender must stick with to identify the packaging materials used. If he uses a code that is not included in this list, an error is output.

However, EDI guidelines also contain pieces of information that can be mapped in different segments of an EDI message, must only be transmitted under certain circumstances, or are mutually exclusive. Since these cannot be mapped with simple syntactic specifications, we have included logical rule checks as a second element of the format descriptions. The rules can be used, for example, to check whether calculations have been performed correctly or dates have been represented in a logical order.

Rules always make sense when important content cannot be covered by the means of syntax specifications. For example, you allow your partners to reference the purchase order number in the header or in the items of a purchase order response. Syntactically, the segments for the purchase order number at header and item level must therefore have the status 'optional'. If they were mandatory, the data sender would have to display the purchase order number at both header and item level. However, if there were only syntactic specifications, the information as a whole would be optional, since the segments are syntactically optional. A rule for this could check whether the order number was set either at the one or at the other place and indicate an error if it is not contained at all. If it is also allowed to be transmitted in both places at the same time, one could check in addition whether the value is identical.

Plausibility checks for calculations can also only be performed with logical rules: The segments with the operands can be correctly represented and still the calculation is incorrect. Only a rule that accesses the contents and recalculates them can ensure that the contents are not only formally but also logically correct.

Some EDI guidelines contain multiple scenarios of a business process. For example, a guideline for transport orders could provide specifications for both air freight and sea freight processes. Here, there are one or two criteria that logically decide what content needs to be represented. In our example, this would be the indicator of whether air or sea freight is involved. If one were to map all the logics of such a guideline into a single format description, this would lead to a large number of rules. For many segments, one would have to check whether all conditions are fulfilled that make a segment mandatory.

You can use sub-processes to divide the guidelines specifications among several variants of a format description. In the example of transport orders, you could create an 'air freight' variant in which you mark segments that are only required for this variant as mandatory in the syntax specifications. In a 'sea freight' variant, on the other hand, these segments would be optional; instead, the segments required for this would be mandatory. In this way, you save on the one hand the rules whose only condition would have been the mode of transport. On the other hand, you only have to check the necessary rules in each variant, so that users can more easily understand the respective requirements. Sub-processes are always useful if you can use them to divide your format description thematically into two to four large blocks, which can then be implemented more quickly by your partners than if all the specifications were presented in one format description.

With this article we wanted to show you which elements you can work with when creating format descriptions. But we won't leave you to do it alone: We'll be there to support you with all our experience and work with you to develop a solution that will speed up and simplify your EDI onboarding or enable you to precisely monitor your productive data.