Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue closing segment-group with identical segments across groups #274

Open
mathias-olsen opened this issue Jan 22, 2025 · 0 comments
Open

Comments

@mathias-olsen
Copy link

mathias-olsen commented Jan 22, 2025

Hello there 👋,

First and foremost I would like to say that you've done a great job with the development of this library.

I have encountered one issue with parsing EDIFACT files of the BAPLIE template, specifically to the version D95B: https://www.truugo.com/edifact/d95b/baplie/

The issue that I am facing is that there are two consecutive segment groups:
GRP1: "TDT", "LOC", "DTM", "RFF", "FTX"
GRP2: "LOC", "GID", GDS", "FTX", "MEA", "DIM, "TMP", "RNG", "LOC," RFF"

Since the first segment group contains a mandatory LOC segment, a conflict arises once the next segment group is encountered, as that starts with LOC.

I have defined the segment-group segments like this: [EdiSegmentGroup("TDT", "LOC", "DTM", "RFF", "FTX")]

And here is an example of the EDIFACT file:

UNB+UNOA:1+XXX+8194-8195+250117:0526+39447142'
UNH+1+BAPLIE:D:95B:UN:SMDG22'
BGM++XXX+9'
DTM+137:2501170526:201'
---
See from below this line for segment group 1:
---
TDT+20+XXXX+1++XXX:172+++XXX:103::XXX'
LOC+5+XXXXX:139:6+XXX'
DTM+132:2501161400:201'
DTM+133:2501170730:201'
---
See from below this line for segment group 2:
---
LOC+147+0140586::5'
MEA+WT++XXX:8566'

When debugging the EdiSerializer, I can see that the segment-group level is not closed until MEA is encountered, since the 2nd encounter of LOC is still considered to be part of the first segment-group.

From what I can tell this issue occurs because the EdiSerializer doesn't consider ordering of the segments within a group, but I might be wrong in this observation.

Question: Is there any way to force the serializer to respect the segment-groups above with the current built-in toolkit? I am still very new to the codebase, so I haven't investigated all of the capabilities of structuring POCO's to force the structure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant