Issue closing segment-group with identical segments across groups
- Dominant language
- C#
- Stars
- 490
- Forks
- 173
- PR merge metrics
- No merged PRs in 30d
Description
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.**
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with EdiSerializer and the EdiSegmentGroup declaration shown in the issue, then reproduce the BAPLIE D95B example containing consecutive groups that both include LOC. Trace how the second LOC is classified and determine whether the current toolkit can distinguish the groups; done means the behavior is corrected or the supported POCO structure and limitation are documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100