Hi Groza, That is really fantastic let me review that and understand it well, And will get back to you, as soon as possible. Regards
On Sat, Aug 31, 2024 at 10:27 AM Groza Danut <grozadanu...@gmail.com> wrote: > Tech stack proposals: > > 1. Data mapping > The proposal is to use AtlasMap for this. See > https://dzone.com/articles/implementing-low-code-data-mapping-in-java > This would allow us to have dynamic data mappings at runtime based on > different countries, suppliers etc... > > 2. Authorization > 2.1 OAuth2 > Passport plugin provides authentication using OAuth2 credentials(Github, > linkedin etc..) to the web stores. The implemented flow currently is only > Authorization Code Flow. We could use code from here, but I still have a > problem writing code for functionality that is standardized, instead of > using a library for it, especially for security libraries. My proposal is > to use a ready made library for this, for example this one: > https://github.com/dmfs/oauth2-essentials or this one: > https://github.com/scribejava/scribejava and only write the integration > code specific to Ofbiz(here we can use the passport plugin as a reference). > 2.2 x509 certificates > Didn't research much on this topic, but as I see there is some > functionality for certificates implemented in Ofbiz already, so maybe this > one can be used. > > 3. Workflow > I think the best choice here is Apache Camel. We could then have a > different route for each country, or even reuse parts of routes between > countries, if they are the same. > > The overall picture > > 1. Entity layer > - configurations > - reporting statuses > - Invoice xml(for example save received Invoice xml for archiving purposes) > > 2. Service layer > Have a standard set of apis for the base operations: > - upload invoice(report invoice) > - check status(for reported invoices) > - check received messages(for new received invoices) > - download invoice(for received invoices) > - reject invoice(for received invoices) > > This would be the layer that the clients of the plugin will interact with. > They will use these apis for reporting purposes. > > 3. Workflow layer > This is the core part of the reporting engine. This layer would do the > following: > - route the api call to the correct implementation based on different > criteria: configurations, invoice recipient, country etc... > - perform required data mappings > - perform required authorization steps > > Basically administrators would use the workflow layer to perform the > required setup for each country, and then the sales representatives or > other low level employees would use the service layer for actual invoice > reporting. > > > On Sat, Aug 31, 2024 at 9:27 AM Groza Danut <grozadanu...@gmail.com> > wrote: > > > Hi Omar, > > > > Thank you for your feedback. The eInvoicing for Romania has a different > > workflow: > > A. Boarding stage: ANAF uses OAuth to generate a token so the flow is: > > 1. Ofbiz sends a request to ANAF authorization server using OAuth2 > > Authorization Code Flow > > 2. The user is redirected to the ANAF login page, where he needs to > > present his digital signature(yes, each end user need his own digital > > signature) > > 3. Upon successful authentication Ofbiz gets a JWT access and refresh > > token from ANAF. > > > > B. Reporting stage. > > 1. Ofbiz converts the Invoice to the accepted format(UBL, CN, CII sau > RASP) > > 2. Ofbiz sends the Invoice xml to the upload api using the JWT access > > token for authentication. Note: there are 2 upload apis: one is the > testing > > environment, and one is the production environment, but you still need > > valid credentials for testing. > > 3. Ofbiz sends a request to the ANAF status api and gets the response > > whether the Invoice was accepted, or rejected and the reason for > rejection. > > Upon fixing the rejection issue, we need to resend the invoice. > > > > Based on these 2 cases, I think Ofbiz should have the following > > requirements: > > 1. Configurable Invoice data mapping for each country(and even different > > data mapping within the same country, for instance different data > mappings > > for different suppliers) > > 2. Configurable workflow for each registry. I think this would be the > hard > > part. Since one country might use Oauth and JWT tokens, another uses X509 > > for signing Invoices, so each has a different workflow. > > 3. Status tracking, so we know if the Invoice was already reported, if it > > was accepted or rejected after reporting. We already have Invoice > statuses > > in Ofbiz, we could use those. > > > > On Fri, Aug 30, 2024 at 10:57 PM Omar Abdullwahhab < > > omar.abdullwah...@gmail.com> wrote: > > > >> You are welcome Groza > >> first ZATCA uses x509 certificates, and the procedures has to be done in > >> two stages. > >> A. The boarding stage > >> 1. the reporting software ( ofbiz for example ) will generate a CSR ( > >> Certificate signing request ) > >> 2. The reporting software will send this CSR to ZATCA via rest api. > >> 3. ZATCA will respond with (CSID) X509 temporary certificate along with > a > >> secret -basic auth for further requests - ( for pre-production or for > >> proving that the software reports the invoices correctly). > >> 4. the reporting software will use this certificate to simulate the > >> reporting of different invoice types ( Simplified invoice, Standard > >> invoice, Credit Note, Debit note ...etc). > >> 5. After successful reporting, the software will send a request to ZATCA > >> API to get the production CSID ( X509). > >> > >> B. Reporting stage. > >> 1. After getting the production (CSID) X509 from the boarding stage , > >> The software now is ready for reporting real financial transactions. > >> 2. The reported invoices has to be signed by the reporting software and > it > >> have to be in compliance with UBL 2.1 > >> > >> C. Ofbiz and ZATCA > >> 1. Of course the transactions and tables of ofbiz has to be changed to > fit > >> for additional fields. > >> 2. Ofbiz transactions ( Sales Invoices, Purchase invoices ..etc) will be > >> converted to UBL Xml Invoices. > >> 3. The XML Invoices after signing it and generating QR code for it, it > is > >> saved in a local disk file / database table or whatever is applicable. > >> 4. Then the software will make a json request for the XML invoice and > >> send > >> it to the ZATCA api. > >> 5. ZATCA will responed with the status of reporting ( Reported, not > >> reported ). > >> > >> For further information here is the useful link > >> > >> > https://zatca.gov.sa/en/E-Invoicing/SystemsDevelopers/Pages/default.aspx > >> > >> Regards > >> > >> > >> On Fri, Aug 30, 2024 at 10:14 PM Groza Danut <grozadanu...@gmail.com> > >> wrote: > >> > >> > Thank you Omar! > >> > > >> > Could you share the implementation you did for Saudi Arabia? Not the > >> code, > >> > just the general structure, the workflow and the steps you do to > report > >> the > >> > invoices? > >> > Groza Danut > >> > > >> > On Fri, 30 Aug 2024, 17:51 Omar Abdullwahhab, < > >> omar.abdullwah...@gmail.com > >> > > > >> > wrote: > >> > > >> > > Ok that is good, > >> > > And after finishing it would be good if you create a new ofbiz > plugin > >> and > >> > > make the repo available at github, > >> > > So that everyone and I can also share. > >> > > So it can be a useful plugin even if its not part of the official > >> > > ofbiz-plugin repository. > >> > > And I am ready also to contribute > >> > > > >> > > > >> > > > >> > > On Fri, Aug 30, 2024 at 3:29 PM Groza Danut <grozadanu...@gmail.com > > > >> > > wrote: > >> > > > >> > > > Hi Omar, > >> > > > > >> > > > Yea I also agree that an eInvoicing plugin would be the best > choice > >> to > >> > > > implement. This plugin should be configurable separately for each > >> > > country, > >> > > > since each country will have specific requirements. > >> > > > > >> > > > Going further: > >> > > > 1. For the mapping, the library you mention is also the one I used > >> in > >> > my > >> > > > implementation, so I agree we should use it. > >> > > > 2. OAUTH client library > >> > > > > >> > > > Currently the Romanian registry uses OAUTH2 with a JWT token for > >> > > > authentication with the api. Probably other countries as well. So > is > >> > > there > >> > > > an OAUTH2 client in Ofbiz that we can use? I will investigate the > >> > > passport > >> > > > plugin to see if we can use the code in there. > >> > > > > >> > > > On Fri, Aug 30, 2024 at 2:54 PM Omar Abdullwahhab < > >> > > > omar.abdullwah...@gmail.com> wrote: > >> > > > > >> > > > > Hello Groza > >> > > > > Sorry this is another detailed Email, > >> > > > > Regarding e-invoicing or e-factura. > >> > > > > Yes this will be very helpful, because it is already adapted by > >> many > >> > > > > countries, > >> > > > > And soon will be widely used. > >> > > > > The main good thing that can be of help is > >> > > > > 1. Mapping the ofbiz Invoices to XML Invoice. > >> > > > > 2. Making the connector as configurable as possible, because it > >> will > >> > be > >> > > > > different for each Authority of Country. > >> > > > > 3. It will be nice if the information about e-invoicing > collected > >> > from > >> > > > > different countries. > >> > > > > 4. also many new IT companies have little knowledge about the > >> > > e-invoicing > >> > > > > and it will consume time to understand it, > >> > > > > So if ofbiz will offer that for them it will be nicer. > >> > > > > > >> > > > > Regards. > >> > > > > > >> > > > > > >> > > > > On Wed, Aug 28, 2024 at 4:47 PM Groza Danut < > >> grozadanu...@gmail.com> > >> > > > > wrote: > >> > > > > > >> > > > > > Hello devs, > >> > > > > > > >> > > > > > I need to consult with the community in regard to a new plugin > >> > > > > > contribution. > >> > > > > > > >> > > > > > Currently the Romanian law states that all B2B and B2G > invoices > >> > > > operated > >> > > > > > inside Romania must be reported to a national registry, called > >> > > > > > eFactura(eInvoice) operated by the romanian fiscal > >> authority(called > >> > > > > ANAF). > >> > > > > > > >> > > > > > *The workflow is:* > >> > > > > > 1. Supplier sends the Invoice to the national registry. > >> > > > > > 2. Invoice Recipient downloads the Invoice from the national > >> > registry > >> > > > and > >> > > > > > registers it. > >> > > > > > > >> > > > > > *Notes:* > >> > > > > > - printed or emailed Invoices are NOT considered valid, only > >> those > >> > > sent > >> > > > > > through this registry > >> > > > > > - the Invoices are uploaded and downloaded from the registry > in > >> xml > >> > > > > format > >> > > > > > (UBL) > >> > > > > > - the registry has a REST api with OAUTH2 authentication > >> > > > > > > >> > > > > > I have the following ideas for this plugin contribution: > >> > > > > > > >> > > > > > *1. New plugin called eFactura* > >> > > > > > > >> > > > > > This will focus on specific reporting of Invoices for > businesses > >> > that > >> > > > > > operate within Romanian boundaries. This will be very > specific, > >> but > >> > > > > > probably not used outside of Romania. Are there any known > >> Romanian > >> > > > > > developers or businesses here? > >> > > > > > > >> > > > > > *2. New plugin called eInvoice* > >> > > > > > > >> > > > > > More generic plugin that allows for generic reporting of > >> Invoices > >> > > based > >> > > > > on > >> > > > > > configurations. This would allow using the plugin for other > >> > countries > >> > > > > where > >> > > > > > Invoice reporting is mandatory. For example Bulgaria has a > >> similar > >> > > > > registry > >> > > > > > called eFaktura, as far as I know. > >> > > > > > > >> > > > > > *3. New plugin called InvoiceConnector(or some other name)* > >> > > > > > > >> > > > > > This would be the most generic plugin that has extended > >> > configuration > >> > > > > > capabilities. Basically, this would allow you to specify in > what > >> > > format > >> > > > > you > >> > > > > > want to export or import invoices(for example UBL2.1), and the > >> > method > >> > > > of > >> > > > > > exporting/importing(example: from/to file, REST api, etc...). > >> This > >> > > > would > >> > > > > > basically be similar to a data mapping tool plus a REST > >> > integration. > >> > > I > >> > > > > > haven't yet seen any possibility in Ofbiz to export or import > >> > > Invoices > >> > > > > in a > >> > > > > > format other than the standard entity xml format, is there > >> some?? > >> > > > > > > >> > > > > > *Do you think any of these contributions would be of any help > to > >> > the > >> > > > > > community?* > >> > > > > > > >> > > > > > Of course I will be maintaining the code for the eFactura > >> connector > >> > > > part, > >> > > > > > since we will be actively using this in our companies. > >> > > > > > > >> > > > > > -- > >> > > > > > Groza Dănuț > >> > > > > > > >> > > > > > >> > > > > > >> > > > > -- > >> > > > > Omar Abu-Arab > >> > > > > Java Engineer > >> > > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Groza Dănuț > >> > > > > >> > > > >> > > > >> > > -- > >> > > Omar Abu-Arab > >> > > Java Engineer > >> > > > >> > > >> > >> > >> -- > >> Omar Abu-Arab > >> Java Engineer > >> > > > > > > -- > > Groza Dănuț > > > > > -- > Groza Dănuț > -- Omar Abu-Arab Java Engineer
