search

phax / ph-ubl

Java library for reading and writing UBL 2.0, 2.1, 2.2, 2.3 and 2.4 documents
Apache License 2.0
110 stars 40 forks source link

eForms support #42

Closed jonatanprins closed 2 years ago

jonatanprins commented 3 years ago

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,

phax commented 3 years ago

Hi @jonatanprins no plans so far, but that seems to be a quick win...

jonatanprins commented 3 years ago

Hi @phax, that would definately benefit us. If it were to be added, how would this go?

phax commented 3 years ago

Well what I would do, from the top of my head, is something like this:

jonatanprins commented 2 years ago

Alright, so we had a go at it. Ran into a some issues.

EForms has custom versions for:

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.

phax commented 2 years ago

@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

DKamerbeek commented 2 years ago

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 :)

phax commented 2 years ago

@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 :)

DKamerbeek commented 2 years ago

Yes this is fine, thanks in advance

phax commented 2 years ago

Part of the 6.7.0 release. Thanks for your contribution!