Providers ...There is another possibility that the Providers means they are the appointed agents or Authorized e-Invoice Issuers recognized by the government.
Business or Companies who want to generate e-Invoice must go through this Providers to generate the e-Invoices.
No, I want to make programmers life easier...If you can't draw the flow chart, can you listed out the parties from Left to Right indicate Start to End for each steps?
Since you didn't provide answers for these questions and I could not ask your government for the answers, I can only make my own assumptions.
I assume the flow is as following:
Scenario 1
1. End User (Buyer/Customer/usually consumer of the products and services) makes a purchase with --> 2. Providers (Seller/Merchant/usually business owners providing products or services) generate and send e-Invoice in the form of JSON/XML to --> 3. Government e-Invoicing API Server (MYDATA?) and the server validate the e-Invoice then send back the validated e-Invoice back to --> 4. Providers and generate a validated e-Invoice to 5. End User (who may use ERP system, apps or custom software developed by Developers).
Scenario 2
The process continues from #5 where the End User can accept or reject the e-Invoice...
There are many other scenarios but let us focus on Scenario 1 at this point.
I assume Providers are the one who concern about sales profit.
Hence they are also the party that making request or consuming the APIs provided by the government API server (MYDATA?).
Meanwhile End User concern about tax submission or claim the tax refund where the e-Invoice is a proof of purchase.
Here you want to slot in as an intermediate Middleware provider so the flow changed to this:
2. Providers (Seller/Merchant/usually business owners providing products or services) generate and send e-Invoice in the form of JSON/XML to 3. Middleware provider that accepts different types or non standard types of e-invoices then output the correct format required by the API of --> 4. Government e-Invoicing API Server (MYDATA?)
So your actual concern is to make the Providers' life easier for providing an intermediate service to make the API submission smoother.
Am I right so far?
To become provider you need at least 100K$ and take responsibility for all software using your services.It makes more sense to me now.
So the Providers concept is very similar to what we have here call Service Providers.
Would I scare you that not only 30+ but maybe we have 3,000 or 30,000+ of service providers?
As you said above, actually companies don't really need these providers.
In fact, anyone can also become one of the service providers.
Since I already registered myself as one with my country's inland revenue bureau (IRB), I can do testing in sandbox environment.
When I want, I can provide a service to help companies to submit their e-Invoice.
This also mean some companies can also submit their e-Invoice without engaging any third party service providers if they have an in-house software team.
If I understand, MYDATA used to be the only authorized provider but by time goes by, now more and more providers are available.
So let say I am in your situation, to become a middleware provider, is that mean I need to deal with 30,000+ of service providers?
The different situation between what happen in your country vs what we have here, that I can see is:
In Greece, different service providers have different "pre" e-Invoice format.
I don't know why is this happening.
By right, they (so called the Provider) should "provide" or adhere to the format required by the government API server. You call it AADE server?
They should become the Solution Provider who should "Solve" the Problem.
A Middleware provider is not required.
The government should enforce a standard API format documented in a SDK guideline where a list of mandatory fields need to be provided.
Optional fields are accepted.
If the providers are not providing the correct format then it means they are not compliant or eligible to call providers.
In Malaysia, each service providers should follow the SDK guideline or else end up their e-Invoice getting validation failure.
The role of Middleware providers are different here.
I am not 100% sure what they are doing but I see there is a company who claim its product name associated with AI can help any business or company convert their legacy ERP system or excel format invoices into e-Invoice compliant with the government API standard.
Back to your case, I have an idea to solve your problem. (maybe 2 ideas)
Idea #1
Become a Middleware provider
Either you need to communicate with the providers to get their "pre" formatted e-invoice or you get from the companies that engage services from these providers.
You need to map their fields to AADE format.
Every time there is a change of key names involving the "mandatory" fields, you need to update your middleware system.
This mean you have a database to store each provider "template" and associate with their client id.
Idea #2
Don't need to become a Middleware provider
Because your target are not service providers, so why need to focus or concern about the providers format?
Straight away build one product that can generate the e-Invoice compliant to AADE format
You can sell this product at a very minimum price or have a different business model
Lastly, I can say for both Ideas, you can use B4J to develop the server or even a standalone system.
You may also consider to build using one of my frameworks.
Actually to intergrate all the providers and "can" translate between their json/xml (including also old mydata xml's)Can you explain what's your idea at the moment?
1. You are thinking to create a new "clear" API for esoteric/internal useBefore
I thought the json/xml samples you shared are output
After
now I realize the sample is actually required API payload
The problem now indeed is on the providers part.
Let say I want to build a "translater" server as you may call it a middleware,
I need to
- Create my own set of fixed fields
- Study all providers format
- Create the template mapping my fixed fields to required fields for each provider I want to work with
- Maintain the template whenever any updates from each provider
For the matching/mapping, I think we can just use maps.Actually to intergrate all the providers and "can" translate between their json/xml (including also old mydata xml's)
May be a class, may be a service (free)...
at first:
For sure can be class
perhaps..
FromMyDataToParochos(xml) as json
or FromParochosToMyData(json) as xml
but first must create templates for matching the fields/elements/values... may be those templates can be text/ini/settingsmap
for example:
FromMyDataToParochos.template
Price|0.00=Amount|0
companyName=Name
VatNo=TaxNo
using delimeter or something... can have different conversions or Format to recognize or translate the field/element..
So this project can start with a simple tool of Matching... and can be better...
I think Matching Json Values will be helpful for other projects too.. may these templates can be a guide to convert other files formats too..
Just start with one provider first then add another.1. You are thinking to create a new "clear" API for esoteric/internal use
2. may be ...an AI first hand ?...kidding, I feel a hate for it...
3. sure
4. that's right... this is a difficult part too..
Since your "User" can have many different type of file, text, CSV, excel, access, direct db, etc ?For the matching/mapping, I think we can just use maps.
It should be one to one for each provider API.
Using class with custom type for fields also good idea. It's what I am doing.
Since your "User" can have many different type of file, text, CSV, excel, access, direct db, etc
I think you need to deal with case to case basis.
You can do charity but this is really not worth it.
This is too much of work.
There are 2 options you can provide to the developers as a Middleware provider:Since your "User" can have many different type of file, text, CSV, excel, access, direct db, etc ?
what do you mean ?
charity?
I think that is other thing to create a class translating, other thing to create templates (train the system)
Perhaps the training can be the cheese for the success of a service or an app or a class
Training/Tranlastion can be a service with a cost> For any developer or advance user wanna do that.
If you mean use AI or machine learning to help your middleware doing the matching I can understand.1st ofcourse
may be if the developer-of-an-app/user provide the same "values" or formatted "values" with examples of xmls / jsons for the same invoice type but different providerIf you mean use AI or machine learning to help your middleware doing the matching I can understand.
However, using this tool can add up a cost.
I don't see a need or feasibility in early stage.
It is more reliable if manually done by human.
Even with AI, we still want to verify again.
I don't know how advanced the AI agent can find the correct specifications from the providers.
I don't get it.may be if the developer-of-an-app/user provide the same "values" or formatted "values" with examples of xmls / jsons for the same invoice type but different provider
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?