[Feature Request] Add option to generate Swiss QR Code after invoice

[CanardConfit]

I am Swiss and I would like to be able to generate a QR Invoice (the Swiss system for invoices in force since 2021). After generating an invoice, the system could add a page with an embedded Swiss QR code, according to the standards specified here: https://www.six-group.com/fr/products-services/banking-services/payment-standardization/standards/qr-bill.html. The page should display the necessary information in Swiss QR Code format.

Current behavior

The system currently allows you to generate a classic QR code, but this is not useful / recognized in Switzerland, hence my proposal.

Screenshot

Simple example of a Swiss QR Invoice.

Possible solution

Integrate the php-swiss-qr-bill library to generate the Swiss QR Code and add it to the invoice PDF.
I've already implemented this feature, and just made a pull request for it (#1024)

Steps to reproduce

Context (Environment)

Detailed description

The proposed change involves integrating functionality from the php-swiss-qr-bill library to generate a Swiss QR code based on invoice information, the user's IBAN and the addresses of the customer and user. The generated QR Code must comply with the standards mentioned here.

Possible implementation

Pull request #1024

Failure logs

[nielsdrost7]

Thank you for a great issue and, of course your PR!

Here's a question:
Let's say we merge your PR.
Now, tomorrow someone comes, he's from Finland and he says: well, the Swiss standards aren't the Finnish standards, then which files do we need to change to add those Finnish standards?

Same question, but now for the Italian standards, European standards, etc.

We need some kind of way to set the QR standard on the ... Settings page (?), customer edit page (?)

And we need some kind of way to add all those standards to the codebase and not overwrite the other standards, if that makes sense.

[Verony-makesIT]

The QR Code on an IP invoice is usually static text.
In fact, all data, in this type of QR-Code, is stored as a text string.
Using the format specifications (EPC QR-Code, Swiss QR Bill, etc...) you can then implement the invoice data in the QR-Code text string according to these specifications and add it to the (pdf - web) template code.
So in fact you don't need to add all those standard formats/specifications in the IP codebase either.

The European EPC QR-Code standard:
Example text/data:

Example template code:

Decoded (text/data) example 1. on Page 49 from the Swiss Implementation Guidelines for the QR-bill:

Example template code (relevant string data has to be replaced by invoice data):

Other than the logo in the QR-Code, the rest is actually strictly speaking applying the Swiss invoice layout/format specifications.
I suspect that the mentioned library (php-swiss-qr-bill) could make it easier to customize the template code though.

I hope this can help you guys a little bit...

[CanardConfit]

@Verony-makesIT Yes in the majority of cases it's static text for the QR Code. The problem is rather in the format and layout of this QR Code. Switzerland for example requires that the slips be in a certain way, and if we just present a classic QR Code, the person who has to pay might think that it is not the right QR Code or not. the right way to pay, etc... We must therefore integrate the "payment zone" more widely into the different standards, rather than just the static text of the QR Code, in my opinion.

[CanardConfit]

@nielsdrost7 Thank you for your feedback! You're right, I thought about my problem, I didn't want to do too much code at first. But I thought of the same thing as you, making a system that would make it easy to add a payment standard on the code side and to easily use/activate this standard/any standard.
I didn't want to do it right away because I wasn't sure how you were going to react to the idea, so I only did what I needed to at first, but now that we seem sure the same wavelength, I would like to create a system for these QR-Invoices and make a pull request that we can discuss together.
What do you think?
Has this ever been considered?
Do you have any ideas to submit or am I free to do as I wish and we'll see later?
Do I make a new issue/pull request or do we stay with the same one?

[0n1cOn3]

As a former user of InvoicePlane and also from CH, this is only to be welcomed.
As this comes after only one year of the introduction of the new QR system... Is a case in itself.
I had to leave InvoicePlane for this reason, because I don't have time to pack this into my Docker container.

I ask myself, why so complicated? If the invoice is issued with the country input, you could customize this so that the QR library from @CanardConfit is used for Switzerland.
Of course, for domestic shipping it makes no sense to specify the country, but if this is stored in the InvoicePlane system that the invoices are issued for Switzerland in this case, the corresponding lib could be used.
However, this is just a thought, in addition to the existing discussion.

[nielsdrost7]

@CanardConfit thank you for the great questions!

Has this ever been considered?

Anything regarding QR codes has not come up earlier, as far as I know.
Howeverrrr I also see @0n1cOn3 's remark, so it must have come up at some point.

Do you have any ideas to submit or am I free to do as I wish and we'll see later?

You're totally free to do what you want, live free, Yolo, you know

Do I make a new issue/pull request or do we stay with the same one

That's a good one! Let me get back to you on that one.
My initial thoughts: Merge your PR in a branch on InvoicePlane/InvoicePlane and then just keep on going with your great work

Let's ask @naui95 what he thinks.

[0n1cOn3]

Your absolutely right! @nielsdrost7

It's a mystery to me that this is only an issue after a year ^^.
Unfortunately, my boss also said goodbye to InvoicePlane and went to Bexio because of the missing QR code for Switzerland.

However, as has already been mentioned, the company SIX has introduced this form of QR code & layout together with the Swiss Post and banks. Although this software is good for non-technical people, but it can no longer be used in Switzerland without installing the QR library which is a no-go for non-tech savy people.
I work in the IT industry and we have a customer who still uses InvoicePlane today, but the effort for the QR code Lib installation was paid for by the customer. Which could theoretically be prevented. But this is a topic that is only mentioned here in passing. (Irrelevant, so to speak, but good to know)

And yes, I'm aware that this is a leisure project, so I fully understand that it won't be implemented immediately 😊

[0n1cOn3]

We need some kind of way to set the QR standard on the ... Settings page (?), customer edit page (?)

How would this be defined it via the country selection in the backend?
You have to enter your business data so that an invoice can be created. This also includes the country. 🤔

Or an additional menu where the QR template for the country can be selected. Perhaps it would also be an idea to store this in the invoicing process if you also send international invoices, so that you don't have to fiddle around in the settings but can do so when invoicing.

I can see various approaches here.
But my hands are tied here, because I can't manage to learn a programming language 🥲

[CanardConfit]

Personally I installed InvoicePlane for the first time last week because I needed to make an invoice, I saw that there was no way to make a QR Swiss invoice, so I did it added in one night and made available, telling me that if it was well received I would do more, which is the case! x)

@nielsdrost7 So I'll start working on it :D

I was actually thinking of adding a field in the management of an invoice to create or not an associated "payment" (a Swiss QR Code, a classic QR code, the European standard, etc.) (because in some invoices we don't need it, in others if, ...)

On the code side, a folder where there are all the standards that we would like to implement, in the form of a PHP class, with an abstract class to respect. All loaded automatically to be selectable by the user afterwards.

In this way it should be flexible enough to meet all needs.

[CanardConfit]

@0n1cOn3 If I do this feature you will have to go back to InvoicePlane! (Joke)

[0n1cOn3]

@0n1cOn3 If I do this feature you will have to go back to InvoicePlane! (Joke)

Welp 🥲😂

[Verony-makesIT]

@CanardConfit, As a supplier, you can (in the EU) add a QR-Code to your invoice template to simplify the payment process for your customer.
The payment of the bill using a QR-Code in this case depends on which "QR-Code standard" the customers bank uses and thus does not depend on the country where that customer is located.
With my remarks, I just wanted to assist by providing some clarification....

[nielsdrost7]

@0n1cOn3 If I do this feature you will have to go back to InvoicePlane! (Joke)

Well, you can at least be the master of returning users if you're willing to do that.
No pressure.

But my hands are tied here, because I can't manage to learn a programming language

Just don't worry about that. We can use the help of everyone, it's up to the maintainers to ask the users at which area those users can help (with or without programming language knowledge)

[0n1cOn3]

@0n1cOn3 If I do this feature you will have to go back to InvoicePlane! (Joke)

No look, I gotya. I really would come back but yeah, Swiss QR code is essential 🥲

[nielsdrost7]

You have to enter your business data so that an invoice can be created. This also includes the country

Exactly!

I was actually thinking of adding a field in the management of an invoice to create or not an associated "payment" (a Swiss QR Code, a classic QR code, the European standard, etc.) (because in some invoices we don't need it, in others if, ...)

That's 1 option ...

because in some invoices we don't need it, in others if, ...

Explain this one, please.

So, I'm your customer, I live in ... Austria.
Do I need that QR code?

Now I'm your customer and I live in ... Geneva
Do I need that QR code?

On the code side, a folder where there are all the standards that we would like to implement, in the form of a PHP class, with an abstract class to respect. All loaded automatically to be selectable by the user afterwards.

Perfect.
I think that we should deliver those standards IF they have a composer package for it (like I think you used in your PR and like @0n1cOn3 's customer used)
IF package (which means new standard), then just include him in your PHP Class

IF I want a QR code and my country is ... I don't know ... Luxembourg and my standard does not have a package ... well then I'm out of luck and then we select the default?

[CanardConfit]

(@nielsdrost7 Thank you very much for making me the project developer, you have placed a lot of trust in me!)

Looking at the system as it is currently done I realized that a brick was perhaps already used/created: The "payment method" area! (here: index.php/payment_methods/index)

If we modify this element so that it can be associated with a specific payment method, Cash, credit card, swiss qr code, generic qr code, finnish qr code, ... It could work well! You understand me?

If I take your examples, I create an invoice for my Australian customer, who must have an Australian payment method, I specify in the payment method field "QR Australian invoice" which I would have configured beforehand in the control panel. payment_methods configuration.

If I come from Geneva (which is my case by the way, Vive la Suisse Romande!), then I choose a QR Invoice Swiss payment method.

If my customer ultimately wants to pay by cash, I choose Cash and the invoice will not have an unnecessary/default payment method.

If the company I have to invoice must have standard x but only for this particular invoice, I just have to choose the right payment method, and that's it. (Like @Verony-makesIT 's example)

In this way we must be able to cover all people's cases. What do you think?

[nielsdrost7]

Well, I like it, of course.
Wouldn't it be, that for the customer the payment_method he wants stays the same?

So it would then be chosen on the customer card, and then used while generating the invoice.
Or am I thinking too far into this.

A default setting for default QR method would be nice.
I'll think about payment_method with QR code.

[CanardConfit]

We can make a kind of general default "payment method", a default payment method for a given customer, and always with the possibility of choosing on the invoice itself.

Well, tomorrow I'll get to work! :D

[CanardConfit]

I'll create an issue tomorrow with a summary of what we said here, so it will be clean :)

[naui95]

My initial thoughts: Merge your PR in a branch on InvoicePlane/InvoicePlane and then just keep on going with your great work

I would also go this way.

More in general, for the discussion, couldn't the QR bill be handled thorough the invoice template system?

[novafirst]

I think this should be handled through PDF invoice template system. However in order to make it more flexible for different requirements, we should have a list of all pdf templates within each module. The user can than select which template to use while generating quote or invoice. Example, open invoice and on the right side have a list box where user can select specific pdf template and click on export to pdf. Similar to Vtiger.

[CanardConfit]

The problem with this solution is that it only applies to the PDF format, therefore for the web format or other formats in the future, if this is necessary. And moreover we would therefore have no trace of what type of invoice (Swiss QR Code, etc.) we used for such client etc... I personally find that it would be less good. I am therefore more of the opinion to stick with the idea that we built with @nielsdrost7.

Honestly, there would be 10,000 ways to do it/integrate it, I choose one, we'll see what that gives, and we'll advise at that point, otherwise we'll never move forward :)

[CanardConfit]

My initial thoughts: Merge your PR in a branch on InvoicePlane/InvoicePlane and then just keep on going with your great work

I would also go this way.

How do I do this? And I don't think I have merge permission, so I'll let you take care of that part, but I'm still going to create an issue for that, it's too different to stay under "[Feature request] Add option to generate Swiss QR Code after invoice"

[nielsdrost7]

How do I do this?
So ... on the right hand side of the issue, there's a little wheel icon
I've clicked on it and I've clicked on create branch
It showed me a branch name and I've changed that name to my liking.
Then I created that branch
It's this one
feature/1023-qr-codes

And I don't think I have merge permission
We'll have to figure that one out next time ...

So ... If you clone github.com/invoiceplane/invoiceplane and then checkout feature/1023-qr-codes
You have your own personal branch to work on.

Work on your chosen option and enjoy yourself.

[CanardConfit]

Thank you!

[eliassader]

@CanardConfit @nielsdrost7
Thank you for your great works, a question, how is it possible to merge back the work done with @CanardConfit on the feature/1023-qr-codes to the main development branch as truly only there are two standards the normal QR and the Swiss one for the payments currently in the world

[eliassader]

@CanardConfit is the fork you that you have done is it working?
what are the key files that needs to be changed in the official release to include the Swiss QR code functionality?
We are happy to further support this feature as it is key for the Swiss Market
Thank you strongly for your effort.

[nielsdrost7]

@eliassader what you can do is work on PR #1037
there's already branch 1023 for this in the repository.

@CanardConfit did an amazing job and I think the PR is ready to be merged, but, for example, you can test branch 1023 to see if it fully meets your QR-Code standard.

[eliassader]

@eliassader what you can do is work on PR #1037 there's already branch 1023 for this in the repository.

@CanardConfit did an amazing job and I think the PR is ready to be merged, but, for example, you can test branch 1023 to see if it fully meets your QR-Code standard.

Hi, I am happy to so, I have downloaded the code from (https://github.com/InvoicePlane/InvoicePlane/tree/feature/1023-qr-codes), it is patch, can any of you share a link to a proper compiled version i can run on the hosting. to do all the tests and come back with feedback, or any instruction to correctly build the project
Thanks and greetings from Geneva

[nielsdrost7]

any instruction to correctly build the project

You could clone the repository and then check out the branch, then you'll have the complete project.

To build:

• composer install, it will give you the vendor directory (I don't know if your host allows composer install)
• yarn install
• yarn run build, it will give you .css and .js files

To develop locally:
docker-compose up -d, it will get you all kinds of Docker containers that will help you develop locally

[eliassader]

Thank you @nielsdrost7 for your prompt reply.
Although i run it on IIS, the main branch works wonderfully, also i managed to run all the commands
There is a bug that remains as follows in the settings (Invoice)
A PHP Error was encountered
Severity: Warning
Message: Undefined variable $payment_method_types
Filename: views/partial_settings_invoices.php
Line Number: 419
@CanardConfit what did I miss in the settings or can you please share a working version, I assume there is a DB value missing somewhere

[nielsdrost7]

@eliassader great job on building the project, especially on IIS.
I think you've found a little bug.
And it's in the 1023 branch, correct?
Can you show screenshot?

As long as I have the steps to reproduce (the steps that you wanted to do before you got this error message), we'll be fine.

If you want you can reply in the 1023 pull-request.

I'll take a look this weekend.

[eliassader]

I hope this helps.
This is running on IIS11, windows server 2022, php 8.1.27
Composer and Node JS are installed.
Database on MySql

[nielsdrost7]

Yes, perfect.
I'll let you know this weekend

[CanardConfit]

@eliassader @nielsdrost7 The current feature/1023-qr-codes branch isn't ready yet. The aim of this branch is to incorporate a system of "QR Code types" through the existing Payment Method system. I've started to make some modifications but it's not finished, hence the error and the title of the commit: 28b2ef0 "Start to try something".

If you want a working branch, you need to go back to the merge of the PR I made, i.e. to d2471b9, and then the code will work correctly. The thing to know is that on d2471b9 the QR Code is added in addition to the original QR Code, on the same principle. This had been discussed before, to be more generic and avoid the ten thousand specific parameters of each QR Code type.

Unfortunately I haven't had the time to devote to it, but I still have the project in the back of my mind ;)

[nielsdrost7]

Ah, understood.
Thank you for the clarification!

And if you want, you can still work on the 1023 branch in the invoiceplane repository instead of your own repository.
It might be your preference to work on your own repository, which is totally ok.

We were just a little too eager, I guess

[CanardConfit]

No worries, I'd like to do it faster but I'm not used to working in PHP, and even less so with a framework like codeigniter. So it takes time :)

[CanardConfit]

Hello everyone! (@nielsdrost7) I just pushed some changes to this issue (b252298)!

I added the way to modify the "general" settings of a payment type! This means that in the "Invoices" tab of the parameters there is a new category of parameters depending on what is implemented in the Mdl_payment_methods file. this therefore allows us to have new payment types in the future and it will be easy to add (For the two "examples" of this, look at Mdl_qr_code and Mdl_qr_code_swiss).

Note: The custom type in Mdl_payment_methods is to define "no particular type"

I also deleted how Qr Code and Swiss Qr Code was done until now.

All that's missing is to get the choice of payment method for the invoice, and process the payment method! (not finished yet)
What I want to add is to have the possibility (on the code side) to choose or display your payment method (so that it fits with the current system which adds the simple QR code to the current page and not on a page a him alone, but depending on the case, it can be practical, in short you see I guess...)

I'm slowly getting used to this style of PHP (which I definitely don't like, my IDE puts errors everywhere because it doesn't understand that this or that variable will be filled in runtime, in short... xD)

Possibly if those who are familiar with this framework and these conventions can review my way of doing things a little, I would not be against it. To be sure that what I did didn't end up in the trash because that's not how it should have been done ;)

See wou next commit!

[nielsdrost7]

I'm slowly getting used to this style of PHP (which I definitely don't like, my IDE puts errors everywhere because it doesn't understand that this or that variable will be filled in runtime, in short... xD)

I understand what you mean and it's only until we get version 2 up-and-running.

At some point I actually had tears in my eyes from this poor old CodeIgniter 3 framework, but it's all we have at the moment...

I really appreciate your efforts and it won't end up in the trash.

At the end we need something (some documentation) to accommodate someone in, let's say, a European country like Belgium, Finland, etc.
Which buttons do they click to get a Payment Method?

[lxwulf]

Hey there folks,

Is there any new update to this, or can I help to test this feature so we can release it to the stable version?

😊 ✌️

[nielsdrost7]

Hey @lxwulf,
Thanks for offering to test.
The pull-request is being handled here: #1037
It's not done yet.
As soon as it's done, I'll be happy to tag you, so you can start testing, is that ok?

[lxwulf]

Oh, yes please! That's more than okay, that's fantastic! I'm very happy to contribute with testing! 😃 💪