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

834 Sample interchange ONLY parsing INS segment into MemberDetail #269

Open
chowell1337 opened this issue Sep 12, 2024 · 2 comments
Open

Comments

@chowell1337
Copy link

When using the BenefitEnrollmentAndMaintenance_834 class in X12_834.cs, the Headers' MemberDetails List DOES get a single entry for every single INS segment, but the only data getting parsed into each MemberDetail object is what's in the INS segment:
image

Sample file used (sourced from here):
x12.834.txt

I managed to get it working by changing the [EdiSegment, EdiPath()] attributes on the "multi-segment" classes into [EdiSegmentGroup] attributes. For MemberDetails, I'm doing [EdiSegmentGroup("INS", SequenceEnd = "INS")] since it's meant to include all segments from one INS segment til the next encountered (until the end of the set). Similar need to be done for the other "multi-segment" classes, like Benefit, ProviderInformation, AdditionalReportingCategories, and MemberReportingCategory

Additionally, there is nothing to handle COB or LUI segments.

As a sidenote, this is the only sample interchange that has Hashtable properties, but they don't seem to work. I assume it's to allow referencing the Lists by their first element in a Dictionary-like way; is that true?

@cleftheris
Copy link
Contributor

Hi @chowell1337, in general avoid the use of SequenceEnd to break out of loops. It is a simplistic way to quickly define loops that will not get you too far. Prefer the explicit segment list alternative constructor (for example [EdiSegmentGroup("NAD", "FII", "RFF", "CTA")]).

You can see it in action in other answers regarding segment groups like #201 (comment).

@chowell1337
Copy link
Author

chowell1337 commented Sep 16, 2024

@cleftheris I see! I did use that explicit segment list syntax when correcting the wrapper classes of all the other loops; I was only hesistant to do so for MemberDetail because it includes so many segments that the Attribute parameter list would be absurdly long.

In fact, out of curiosity I just tested just removing the SequenceEnd parameter (i.e. [EdiSegmentGroup("INS")]), and to my surprise it actually still correctly parsed everything! Is that MORE valid than [EdiSegmentGroup("INS", SequenceEnd = "INS")]? or do you equally discourage that?

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

2 participants