B4J Question XML/JSON Fields-Values Automatic Matching

[Magma]

Hi there,

the question (not exactly only for B4J - may be a tactic how to manage something) came from Chit chat https://www.b4x.com/android/forum/threads/because-you-can.167192/ when talking with my friend @aeric who did a great job with Web Server API (Pakai Framework).

Well..
In Greece we have about 30 different E-Invoicing Providers having DIFFERENT JSON or XML (MyDATA - the old/first public invoicing for all) - the Json are having different structure and different fields but sometimes if mapping the right you need... less work to do your work...

Sometimes need loops for extracting values from a post, or need just to match..

I am attaching a WORD (docx) file in a zip with 3 different providers for the same type of invoice.. have in mind that invoice types in Greece are about ~30... the providers are also about 30 and there may be some different flow working them..

If having same API for all will be great... but is a dream...

My opinion is to use some AI tech - to magic MATCH them, feed the AI xmls, jsons, examples...
and create me templates to match them...

May be with the power of Pakai (aeric's) and the power of AI (there are many examples here how to use it in b4x) and may be some power of new Erel's features (using python)... can create a web server wrapper or offline wrapper to do my job better...

automatic converting - matching values and elements for xmls-json ...

What do you think ? - Have in mind some code will help... try to create a project like this "MAGIC-MATCH-XML/JSON" >?

 

[Magma]

I don't get it.

I still believe AI doesn't need to be involved here.
Not every time we need rely on AI.
AI can be unpredictabe and provide inconsistent results.

Ok... the user for me (for my class or service) will not be the end user of the app will use my services/or class... but a developer or an installer that want to change a provider...

May be he gonna use a ready template or matching/translations... may be will create a new template (and get money for this translation-training perhaps from me or from other users).

And he will create a template - because may be an invoice not exist at my system (for specific provider) or there is a new provider... or changes for it

 

[aeric]

Let's evaluate what is your intention.

You want to help developers to ease their job right?

What you can do is to provide a middleware with a single API to support multiple providers.

Think again.
Your middleware maybe no longer relevant anymore if one day your petition has been successful or IRS decided to enforce the standard format to all providers.

 

[Magma]

Let's evaluate what is your intention.

You want to help developers to ease their job right?

What you can do is to provide a middleware with a single API to support multiple providers.

Think again.
Your middleware maybe no longer relevant anymore if one day your petition has been successful or IRS decided to enforce the standard format to all providers.

may be...

or ... may be - I am too negative...
but is about 1 year saying and the GOV not doing anything to limit those Providers with an API standard...

so... a start of a small project like this...
without training templates... and slowly adding them..
will be nice and helpful

 

[aeric]

From my perspective or maybe true to anyone else is we should try to minimize the resources (work, cost, effort, time) and risk.

If I am you, instead of going to all providers and support all of them, I will just pickup one or two only to work with.

As you mentioned, the providers may have different agendas as why they required different API payload.
One may be because it is due to direct integration with their own product such as ERP system.

I might choose the providers who are independent to any products or more generic.

When there is a demand from any developers on a specific provider, due to a popular ERP system, then only I will consider to add a support for a new provider.

 

[Magma]

From my perspective or maybe true to anyone else is we should try to minimize the resources (work, cost, effort, time) and risk.

If I am you, instead of going to all providers and support all of them, I will just pickup one or two only to work with.

As you mentioned, the providers may have different agendas as why they required different API payload.
One may be because it is due to direct integration with their own product such as ERP system.

I might choose the providers who are independent to any products or more generic.

When there is a demand from any developers on a specific provider, due to a popular ERP system, then only I will consider to add a support for a new provider.

This is what we do now... all... but is not right... and future is unpredictable

 

[aeric]

This is what we do now... all... but is not right... and future is unpredictable

Remember the risk of your solution may come to end of no value one day.
Noone will remember what you did.

 

[epiCode]

This whole scenario is lack of a "standard invoice format", which everyone is currently living with.
The conversion tool is more of a "nice to have" but not "need to have" even for developers.
Developers will rather hardcode and move one, and let customers pay again if they need updates.

 

[aeric]

This whole scenario is lack of a "standard invoice format", which everyone is currently living with.
The conversion tool is more of a "nice to have" but not "need to have" even for developers.
Developers will rather hardcode and move one, and let customers pay again if they need updates.

Yes this problem should never existed in the first place if a standard format is being enforced.

Ultimately the format we are submitting to IRS/IRB remains as one.

Glad that our IRB or government finance department has made a good decision after a thorough study and in fact the implementation of e-invoicing is just on early phase.

 

[Magma]

This whole scenario is lack of a "standard invoice format", which everyone is currently living with.
The conversion tool is more of a "nice to have" but not "need to have" even for developers.
Developers will rather hardcode and move one, and let customers pay again if they need updates.

hardcode ?... hmmmm let me think... May be yes and may be no...
...
i am not disagree... ofcourse is a nice to have...

Standard Invoice Format... at the end is a standard... but before come to a standard... we are involved to a labyrinth (minotaurus)

... @aeric are you sure... at the end... will stay in that.. ?


Because whole world believes that Greece will follow Peppol Standards or something close... but the Devs must go through Fires and hundreds of JSONs...

The Money can change the people, and those are taking decisions... may be in start was a nice plan, and somewhere in middle change all that...

 

[Magma]

When the terrabytes of daily invoices, including every line and every value... the GOV must take a decision... is it really necessary to keep all these data? or i can keep only the hash?... I am sure that will understand that must move forward and go with p2p solutions with blockchains...

some hash sometimes is better... all these are with e-invoicing is so "experiments" in our lives... we want to follow black money... but we are using wrong tactics...

 

[vmag]

Hi there,

the question (not exactly only for B4J - may be a tactic how to manage something) came from Chit chat https://www.b4x.com/android/forum/threads/because-you-can.167192/ when talking with my friend @aeric who did a great job with Web Server API (Pakai Framework).

Well..
In Greece we have about 30 different E-Invoicing Providers having DIFFERENT JSON or XML (MyDATA - the old/first public invoicing for all) - the Json are having different structure and different fields but sometimes if mapping the right you need... less work to do your work...

Sometimes need loops for extracting values from a post, or need just to match..

I am attaching a WORD (docx) file in a zip with 3 different providers for the same type of invoice.. have in mind that invoice types in Greece are about ~30... the providers are also about 30 and there may be some different flow working them..

If having same API for all will be great... but is a dream...

My opinion is to use some AI tech - to magic MATCH them, feed the AI xmls, jsons, examples...
and create me templates to match them...

May be with the power of Pakai (aeric's) and the power of AI (there are many examples here how to use it in b4x) and may be some power of new Erel's features (using python)... can create a web server wrapper or offline wrapper to do my job better...

automatic converting - matching values and elements for xmls-json ...

What do you think ? - Have in mind some code will help... try to create a project like this "MAGIC-MATCH-XML/JSON" >?

Have you heard about how 1,000 Indian programmers deceived the world with their artificial intelligence "Natasha" for 10 years

 

[Magma]

Have you heard about how 1,000 Indian programmers deceived the world with their artificial intelligence "Natasha" for 10 years

nope..

 

[aeric]

It's actually 700?

AI company files for bankruptcy after being exposed as 700 Indian engineers - Dexerto

An ambitious company that claimed to make apps using AI has been exposed as hundreds of human workers based in India.

www.dexerto.com

This news just pops up on my recommended list