We need to know if you will have auto-generated QR for invoices as per new regulation ?!!
What information should this QR code encode?
Looks like you are interested @lubos .
How about making it dynamic, preferably using liquid so I can do my payment QR code natively.
E-invoicing_Simplified GL.pdf (1.0 MB)
Dear @lubos
please find the attached requirement for Saudi Arabia
please let me know if you need further information
This idea for QR code is legit, and I’m starting to see more and more QR codes in many governments’ documents, licenses or certificates. Even a letter for an employee to be allowed to work from the office due to covid19 restriction, the company must submit data and the printout is with scannable QR code for the police officers to scan to verify. Just a matter of time, I believe all invoices, receipts, reports, etc will require QR codes.
I think that the content of QR code for docs should be settable with liquid like a theme.
An implementation in Manager is optimal if it is easy to use for most actual requirements.
To aid this goal identifying data flow requirements would be useful. By which I mean, how may the QR code be generated.
-
Could be generated locally based on data and parameters in Manager. Only a QR image generation program is required.
-
A possibility batch processed QR code authentication code must be downloaded from a government controlled web site prior to generation of the QR code image. Both data upload and download are required. This is often done via a data process company with relatively easy to achieve data interface requirements.
-
Same as 2. except a QR code image is returned from the government controlled authority.
-
The same requirement as 2. but batch processing is not permitted. This makes implementation much harder / less countries will be supported. The reason is country specific secure communication to a government authority is required which is expensive to implement and have compliance authenticated.
-
Same as 4. except a QR code image is returned from the government controlled authority.
-
Same as 4. or 5. but the software solution must be approved by the jurisdictions tax authority.
I appreciate all users would like Manager to implement a higher level solution in their jurisdiction however if that’s all that is possible the most likely outcome is most (or all) jurisdictions will get nothing.
Alternatively there needs to be a payment structure which makes it extremely likely the return on investment for development and maintenance of a particular communication interface will be directly profitable for each individual jurisdiction.
Edit
Added option 6.
What you suggest makes complete sense, however, I don’t see why there should be a financial/feasibility issue here.
I completely disagree with the current direction of Manager’s customizability which channels all possible customizations towards a single bottle neck: The development team. A prime example for this is how report transformations were neutered, had it been buffed even more, I am sure most advanced users would’ve been able to produce and share their own country specific report packages. I am also sure that many users are willing to test and refine these customizations.
Back to the QR codes, I don’t see why not there shouldn’t be a Liquid Type custom field. The documents can be parsed for liquid code twice; once for the theme and another for the custom fields.
I don’t see Manager ever being able to meet country specific customization without offering a robust tool for templating where the community can collaborate on it.
I praise your optimism, but seriously question your conclusion. There are currently over 11,100 active forum members and nearly 27,000 newsletter subscribers. The number of current desktop users is unknowable, but is surely much larger. Only NGSoftware knows the number of active server licenses and cloud subscribers. Suffice it to say, the user base is substantial. But fewer than 10 people have actively participated in discussions about report transformations or their predecessors; 5 account for most exchanges/requests. I believe only 4 of the current transformations were initiated or substantially contributed to by anyone except the developer, with some important feedback on a couple others.
That leads me to conclude most users either cannot navigate creation of report transformations or have no interest in doing so. If what you say were true, surely there would be a longer line of happy collaborators.
I can only speculate, but I think it was the limited exposed information for report transformations, or at least that was the difficulty that I faced personally.
There wasn’t any documentation until only 9 months ago and it’s gone now so I don’t think that was sufficient time to judge it. Also, the documentation was incomplete and the exposed information was limited to transactions table.
I don’t think there’s a shortage right there. If you look at the translation project, there’s approximately 780+ contributors which is a lot if you ask me. I know that there’s at least 10-20 users in this forum that are liquid monkeys.
I also know that there’s a ton of users with decent liquid exposure or are interested to learn liquid. You can confirm this fact by searching how many times you said that this isn’t a coding forum.
If only the developer exposes more information, pre-populates some more intermediate arrays to make it easier for users and give sufficient documentation, then I reckon we can see some pretty serious improvements. But that’s not up to me.
I hope you are right.
My understanding is NG Software was generous with their time and IP but were not a charity and had limited resources.
The reason I divided up QR code data flow requirements is it is in order of NG Software investment.
-
The first three could be implemented with an extension to report transformations.
-
The bottom three require significant investment for each jurisdiction so probably only possible with a fee for that service, perhaps by third party companies.
-
option 6 is effectively required by the jurisdictions tax authority not to be produced by a report transformation so would have to be funded directly by users in that country
My point is why should NG Software bear the costs to begin with?
System are split into two camps mainly:
-
Tailored systems like SAP and Oracle will charge each customer separately for the customization to be done by them or a local partner and it works perfectly for low volume products. Getting to that level of customer service requires Manager to charge 100x more in prices, which is not going to happen.
-
Smaller systems or open source systems like QuickBooks, Zoho or Tally rely on the community or third party developers to provide localizations. This is by far the best tried and tested strategy for a high volume products.
Many systems offer both like Dynamics and Odoo.
So venturing out of these two localization strategies and attempting to providing all users with every possible customization right out of the box is a money pit at best if not impossible.
We all or anyone of us can make their Payment QR Code (Static) and put that in Invoice or in Quotation as per requirement.
I am currently using Static QR code for payment, and for that I attached QR with logo in a single Image and by that method its easy for customer to pay me by just scanning QR code.
(Note: Its a static QR.)