Hi Groza, Happy to know that you have a new child, congratulations. Take your time, All the best
On Tue, Oct 1, 2024 at 9:37 PM Groza Danut <grozadanu...@gmail.com> wrote: > Hi Omar, > > Thank you for your interest. > > You said downloading invoices is not supported in SA. Does that mean you > only use the registry for reporting purposes, and you need to send the > invoice to both the registry and to the customer(say via email for > example)? > > Having our second child born a few days ago, I will not be able to work on > this implementation for a while. However I thought about the architectural > design a bit, and there are quite a lot of details to be able to produce a > design upfront. > That's why my suggestion is to work on the implementation incrementally. > > I will create a new Confluence page when I get some time in the following > days, where we could coordinate our requirements, planning and > implementation efforts. > Groza Danut > > On Tue, 1 Oct 2024, 14:10 Omar Abdullwahhab, <omar.abdullwah...@gmail.com> > wrote: > > > Hello Groza, > > I am still following up with your suggestions, > > I have reviewed your message. > > And my notes are as follows > > The common and difficult things are. > > 1. Authentication. > > 2. Boarding > > 3. Reporting > > All other things still little easy to manage > > So what do you suggest about these three things ? > > > > You mentioned ( Downloading received invoices ), > > Currently in SA it is not yet implemented. > > but I am sure it will be, > > sooner or later. > > Regards > > > > > > On Sun, Sep 8, 2024 at 11:20 AM Jacques Le Roux < > > jacques.le.r...@les7arts.com> wrote: > > > > > Hi Groza, > > > > > > I have given you the right access. You can now add yourself at the > bottom > > > of the list at > > > > > > https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors > > > > > > You may ask for an ICLA but as long as it's only Confluence it's not > > > mandatory. > > > > > > AFAIK, the PMC has not defined yet if an ICLA is required for GH PRs. > > > > > > Welcome :) > > > > > > Jacques > > > > > > Le 07/09/2024 à 20:27, Groza Danut a écrit : > > > > Hi Jacques, > > > > > > > > Requested a Confluence account just now. Waiting for approval. > > > > > > > > The registered username is: danut > > > > The registered email is this one: grozadanu...@gmail.com > > > > > > > > Thank you! > > > > Groza Danut > > > > > > > > On Sat, 7 Sep 2024, 20:14 Jacques Le Roux, < > > jacques.le.r...@les7arts.com > > > > > > > > wrote: > > > > > > > >> Hi Groza, > > > >> > > > >> You need a Confluence write access. Have you created a Confluence > > > account? > > > >> If you did, what is your Confluence username? > > > >> > > > >> HTH > > > >> > > > >> Jacques > > > >> > > > >> Le 07/09/2024 à 19:05, Groza Danut a écrit : > > > >>> 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, < > > > >> omar.abdullwah...@gmail.com> > > > >>> 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 < > > 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 > > > >>>> > > > > > > > > > -- > > Omar Abu-Arab > > Java Engineer > > > -- Omar Abu-Arab Java Engineer
