Dynamic length/optional/conditional fields, sub segments (Cargo-IMP)

Unfortunately, the Cargo-IMP format is not always properly defined. It happens that you get two consecutive fields of the same type with the first field having a dynamic length. Where does the first field end and where does the second start? It is impossible to know before runtime and without contextual knowledge. In that case, you simply have to merge those two fields, treat them as one, and let the profile developer deal with the splitting of the fields later.

images/download/attachments/189463645/CargoIMP_9-version-1-modificationdate-1738737659681-api-v2.png


Another problem is optional or conditional fields or subnodes. In some case that might have the effect that your data gets shifted to fields where it is not supposed to be because it affects your splitting definition or even the natural splitting by slants if an optional subnode contains slants and does not occur in your input data. It is hard to give specific advice for those cases, but generally, you will have to merge some fields in one way or another and you might even be forced to use all-purpose fields with no specific name and undefined type and length (type "String" and length "0"). Let us assume you have a segment with 3 subnodes (as shown in the screenshot above). The first (optional) subnode contains 3 fields (and two slants), the second subnode contains 3 fields, and the third subnode contains 2 fields. If the first subnode does not occur in your input data, you will get 5 fields instead of 8 and fields/tokens of subnodes 2 and 3 will end up in wrong positions. The only general solution is to use 8 all-purpose fields. They might all be filled, or just 5 of them. Let the profile developers deal with the problem, they might have additional contextual information. To be more precise, even that solution will not work, since you will not be able to define a token splitting. You only know that you will end up with 2 or 5 tokens (every slant creates a token). But if the conditional subsegment (here 4.5) does not occur in the data, the other tokens will have another position and the splitting you had defined will not work anymore. So you will have to merge fields 4.7.1-4.7.3 and fields 4.9.1-4.9.2 and work with 5 unsplit tokens, meaning with 5 all-purpose fields. Not pretty. But robust.