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

Reply via email to