Re: Consultation for new plugin
Hi all, Created a new Confluence page for collaboration on the eInvoicing plugin: https://cwiki.apache.org/confluence/display/OFBIZ/eInvoicing The methodology I use to develop is the one in The Art of Agile Development Second edition, by James Shore. If you are unfamiliar with the book, don't worry. Everything you need to know is in the confluence page. The basic idea is that we work on very small increments. Currently there is no code or Jira issue. If you want to contribute add a comment or edit the Confluence page. Thank you! On Tue, Oct 1, 2024 at 10:35 PM Omar Abdullwahhab < omar.abdullwah...@gmail.com> wrote: > 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 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 authen
Re: Consultation for new plugin
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 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, > 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
Re: Consultation for new plugin
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, 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 > > >>>
Re: Consultation for new plugin
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, > > > 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 > 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 emplo
Re: Consultation for new plugin
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, 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 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 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 c
Re: Consultation for new plugin
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, 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 > 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 > > 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 re
Re: Consultation for new plugin
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 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 > 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. ZA
Re: Consultation for new plugin
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 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 succes
Re: Consultation for new plugin
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 > 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 > > > 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 w
Re: Consultation for new plugin
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 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, > > 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 > > 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 > > > > 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
Re: Consultation for new plugin
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, 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 > 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 > > > 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
Re: Consultation for new plugin
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 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 > > 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
Re: Consultation for new plugin
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 > 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ț
Re: Consultation for new plugin
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 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
Re: Consultation for new plugin
Hello Groza, Regarding the e-factura, or e-envoicing, It's the same for many other countries who adapted it. For example Saudi Arabia, Also uses the UBL currently ubl version 2.1 And if you want to use ofbiz, It's very easy you will want only ubl implementation library in Java which will help you build the xml invoice then you add more functionalities as required by the Romanian government, Then you send it to their api . Here is the best ubl implementation I found https://github.com/phax/ph-ubl Also I have done it for SA Zatca. For further information let me know Regards On Fri, Aug 30, 2024, 2:07 PM Groza Danut wrote: > As a reference here is the implementation I already did in Spring Boot for > eFactura: https://github.com/grozadanut/cloud-anaf-connector > > The functionalities implemented are: > - upload Invoice to ANAF registry > - download new messages > - download Invoice xml from messages > > Main services are here: > > https://github.com/grozadanut/cloud-anaf-connector/tree/main/src/main/java/ro/linic/cloud/service > > And the Invoice mapper to UBL 2.1 format is here: > > https://github.com/grozadanut/cloud-anaf-connector/blob/main/src/main/java/ro/linic/cloud/mapper/InvoiceMapper.java > > The main rest api to upload an Invoice is defined here: > > https://github.com/grozadanut/cloud-anaf-connector/blob/main/src/main/java/ro/linic/cloud/controller/ReportController.java > > On Wed, Aug 28, 2024 at 4:45 PM Groza Danut > 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ț > > > > > -- > Groza Dănuț >
Re: Consultation for new plugin
As a reference here is the implementation I already did in Spring Boot for eFactura: https://github.com/grozadanut/cloud-anaf-connector The functionalities implemented are: - upload Invoice to ANAF registry - download new messages - download Invoice xml from messages Main services are here: https://github.com/grozadanut/cloud-anaf-connector/tree/main/src/main/java/ro/linic/cloud/service And the Invoice mapper to UBL 2.1 format is here: https://github.com/grozadanut/cloud-anaf-connector/blob/main/src/main/java/ro/linic/cloud/mapper/InvoiceMapper.java The main rest api to upload an Invoice is defined here: https://github.com/grozadanut/cloud-anaf-connector/blob/main/src/main/java/ro/linic/cloud/controller/ReportController.java On Wed, Aug 28, 2024 at 4:45 PM Groza Danut 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ț > -- Groza Dănuț
