I propose we move the requirement planning and architectural design draft in a new temporary page on Confluence.
I'm not very familiar with Confluence. Do I need approval to create a new page, or do I just need to sign up for a contributor account on Confluence and fill an ICLA? Groza Danut On Sat, 31 Aug 2024, 15:22 Omar Abdullwahhab, <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> > > 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 < > > > [email protected]> 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 <[email protected]> > > >> 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, < > > >> [email protected] > > >> > > > > >> > 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 < > [email protected] > > > > > >> > > 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 < > > >> > > > [email protected]> 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 < > > >> [email protected]> > > >> > > > > 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 >
