eForms support
jonatanprins opened this issue · comments
We are working on a preliminary implementation for handling invoices based on (TED) https://github.com/OP-TED/eForms-SDK. They've built their documents on the UBL23 standard. We'd like to use ph-ubl for reading and creating of the documents.
Are there any plans to support eForms? Maybe an extra package like you have for DIAN or PE?
Regards,
Hi @jonatanprins no plans so far, but that seems to be a quick win...
Hi @phax, that would definately benefit us. If it were to be added, how would this go?
Well what I would do, from the top of my head, is something like this:
- Create a new submodule
- Integrate the custom XSDs in the pom.xml
- Create Marshaller Wrappers like in UBL21Writer etc. based on the Jaxb created classes
- Find test files and test
- Document and release....
Alright, so we had a go at it. Ran into a some issues.
EForms has custom versions for:
- UBL-ContractAwardNotice-2.3.xsd
- UBL-ContractNotice-2.3.xsd
- UBL-PriorInformationNotice-2.3.xsd
It would not generate the classes for them when it depends on ph-ubl23, so I omitted it for now and used the XSDs supplied by TED (https://github.com/OP-TED/eForms-SDK/tree/main/schemas). Browsing stackoverflow got me here: https://stackoverflow.com/questions/50176111/maven-jaxb2-plugin-reusing-commons-xsd-within-same-project.
Not sure what the way to go is here.
The other issue I ran into when running mvn clean install:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project ph-ubl23: Compilation failure [ERROR] /home/jonatan/projects/ph-ubl/ph-ubl23/target/generated-sources/ubl23/oasis/names/specification/ubl/schema/xsd/commonaggregatecomponents_23/DocumentDis tributionType.java:[800,42] incompatible types: oasis.names.specification.ubl.schema.xsd.commonaggregatecomponents_23.CommunicationType cannot be converted to oasis.names.specification.ubl.schema.xsd.commonbasiccomponents_23.ValueType
Looks like the generated code uses a CommunicationType getter where, to make it compile, it should probably use the CommunicationTypeValue getter.
When building on a Windows it does not happen for ph-ubl23, but does for ph-ubl-eforms.
I opened a PR. If you have time maybe you can have a look.
@jonatanprins well, it was a bit of pain in the a but I think I finally managed to get it working.
Please see the https://github.com/phax/ph-ubl/tree/eforms branch for details.
What I did: depend on the ph-ubl23 project - that gives the most synergies and avoids "double code" generation.
The only problem: the specifically modified file https://github.com/OP-TED/eForms-SDK/blob/main/schemas/common/UBL-ExtensionContentDataType-2.3.xsd cannot be used. I found no way of "replacing" the ph-ubl23 type with this type.
What I did instead is to create a helper class EformsUBLHelper to get and set from a UBL 2.3 ExtensionContentType - I hope that works for you as well.
Merry christmas
Hello @phax,
First of all: thank you for your answer/fix. Hope you've had a nice christmas!
In @jonatanprins his absence.. i'm giving it a whirl (co-worker). Looks like all is compiling and running fine. The helper class will suffice for now 👍. Having some troubles with running EformsUBLFuncTest#testUpdateInstanceAndAddExtension() in intellij, but command line isn't complaining.
What to do next? how can we promote to master? which hurdles to take :)
@DKamerbeek thanks for your feedback. The problem with IntelliJ is, that the base directory differs from the Eclipse one. If the base directory is set to the project directory and not src it should work.
If this suffices, I will just merge it :)
Yes this is fine, thanks in advance
Part of the 6.7.0 release. Thanks for your contribution!