5010 PreErrata templates missing interfaces
In the latest version of EdiFabric Templates (126.96.36.199) there is a folder for the pre errata templates called HIPAA/005010/PreErrata. In order to support that version of the standard (for example, 005010X221) we copy that folder to a separate project treating it separately from the current version (for example, 005010X221A1). However, that folder PreErrata does not have the required interfaces. Could you please confirm that we should also copy the files EF_HIPAA_005010_SegmentInterfaces.cs and EF_HIPAA_005010_ComplexElementInterfaces.cs from the parent folder? Or do you have a better approach in mind with less cop/pasting? As frankly, due to the slight differences in the classes and properties names we had to copy all our code for each version. If there is a way to reuse some of them it would be better.
Yes, you can reuse the interfaces. Both 5010 and 5010 pre errata share the same interfaces. We intentionally omitted the two interface files to make this clearer, obviously, we failed.
I'm not sure what do you mean by slight differences in classes and properties, all 5010 files, pre-errata and latest, can go in the same project without any additional amendments, like this:
Thank you for clarification!
Here is what I meant by the need to copy/paste code. For example, for parsing and handling of the 837P documents we created a generic model to output shared between different versions of the documents. However, the logic of pulling the necessary properties though being very similar had to be implemented separately for each specific version of the document due to the classes being different. Here is our current project structure:
We do start with the single entry point for a file, but then had to branch out the logic based on the version of the document being parsed, still producing the same shared model.
It would be nice if we could reuse some of the code traversing the hierarchy and properties of the documents like this:
This latest release, 188.8.131.52, did provide common interfaces for all 5010 transactions. So this was an improvement compared to how it was in the prior versions. We even aligned the 4010 interfaces to match by class names/property names the 5010 interfaces.
The classes though, can't be merged any further, because of the validation attributes. These could be different for the same loop within the same transaction, that's why you get Loop_2300_2, Loop_2300_3, etc. and further merge would break validation.
You can try to modify the loops, such as 2300, to be identical for all versions, by retaining all validation properties at the correct positions, and injecting the EDI codes by code maps, see DataElementCodeMaps here. The templates are supposed to be living documents and customized accordingly, that's why we provide them as plain files.
Could you please help me how can I get more detailed info about error ("LoopID", whole segment as string where error happens) using this validation method described here https://support.edifabric.com/hc/en-us/articles/360000373811-EDI-Compliant-Validation ? I need it to easier find and understand the root caust of the error and inform clients about specific place in files where error appears.
MessageErrorContext does not provide any information about "LoopID".
In some cases when I delete for example some of "REF" segment(for testing purpose) it does not conteins any helpfull information about location of this error in the file, just code of error as "SegmentsCountNotMatching" and that's it.
Thanks in advance!
You do get all the information needed to locate and interpret the validation error. I'll need your test file and template to reproduce at our end. Frankly, the validation message looks very odd (no such error as "LoopID whole segment as string where error happens" is ever raise from our product) and I'd be curious as to how are you using the product.
Another thing to point out is that if the message wasn't parsed correctly, that is its HasErrors=true, then validation is pointless.
Please send me a test file and template to reproduce.
BTW, you'll need to raise this to our ticketing application which is monitored constantly.
Some times client sent to us files with about 100 converts with lot of transactions in each convert. And as I said if some of segments is missing It is unreal to find it by inform that we get from MessageErrorContext.
That's great; however, without an example, I'm afraid there is very little I can do to help you. There are multiple ways to get what you need; one is by generating an acknowledgment that will show you the exact location of all issues, subject to a non-corrupt interchange, of course. In case of corrupt/unparseable data, there is nothing else to do but to reject the file and return it to the sender.
Sorry, I can not send you example it is client files. Could you please provide example generating an acknowledgemnt?
In that case, there is nothing I can do. Here are all the examples:
Thank you! I hope it will help!
Please sign in to leave a comment.