Implement a PDF invoice generation

[cmutel]

2324 Magdanova.pdf

The generated invoice needs to meet these criteria:

• [x] Include logo from https://github.com/Depart-de-Sentier/dds-logo
• [x] Allow client to enter their name and address
• [x] The invoice ID should be generated by the system, and should have the form AB, where A is the two digit number of the year, and B is a zero-padded four digit number starting from 0001 and going up. The invoice number should be associated with the registration, i.e. this is a necessary new column.
• [x] Clients can add extra text which could come after the invoice if needed for their internal accounting. This is part of the invoice generation form
• [x] The Service (this should be called "Event") is specified in the Event (needs a new column called "invoice_item_text")
• [x] Acommodation can be changed to "Option", and we need to add a column to RegistrationOption for "invoice_option_text"
• [x] Invoice date is generated by the system
• [x] Payment terms deadline is another new column for the Event, "payment_deadline_days", with a default of 30.
• [x] The payment details is another new column - it will need to be adapted based on the currency. For now use what we have as a placeholder, I need to think about this.

[lilliputten]

@cmutel

I don't understand the moment: do you want to create a new model (and db) for invoices? In this case, probably, they should be linked 1-1 with registrations, right?

Or we just can extend the registration model with a few invoice-related fields? (As I see it, we don't need another table here, actually.)

Allow client to enter their name and address

Should it be stored in the user model? (I have the t/d task to allow the user to enter his data during the logon process and, probably, to edit it later, #12). Or should it be entered anew every time, for each event's registration?

Which place of an invoice form should I put this text to? Between invoice number and services/event table?

The Service (this should be called "Event") is specified in the Event (needs a new column called "invoice_item_text")

Didn't understand that. I thought that we should have smth more like to other your sample, 2333 Quintero.pdf, with a generic service column, in which zero row we list the event (without a price) and all the options -- below, with their respective prices, and a final 'total' row. Did I get it wrong?

But, mb, this scheme (with only one row) could be much simpler (but less informative, 'course).

To summarize: should we list all the options in the table?

' Invoice date is generated by the system'

Should it be the time of the registration creation? (Or of the invoice generation?)

So, I'd add to the registration (or/and to invoice?) model:

• invoice_id (non-editable for the user)
• invoice_item_text for invoice detail text
• payment_details -- what type should it be? just a free-form text field? (Some technical data for the payment?)

To user or to registration model (? -- te clarify the target model):

• name (probably, first_name and last_name to be in sync with the embedded django user model)
• address

[cmutel]

Or we just can extend the registration model with a few invoice-related fields? (As I see it, we don't need another table here, actually.)

Yes

Should it be stored in the user model? (I have the t/d task to allow the user to enter his data during the logon process and, probably, to edit it later, https://github.com/Depart-de-Sentier/dds_registration/issues/12). Or should it be entered anew every time, for each event's registration?

It can be attached to the user model. If they need to change it from year to year they can edit their profile.

To summarize: should we list all the options in the table?

No, only the registration option they chose. For now I don't want to include any add ons as we have to figure out the tax implications, so we skip this.

Should it be the time of the registration creation? (Or of the invoice generation?)

Date of invoice generation

[lilliputten]

No, only the registration option they chose. For now I don't want to include any add ons as we have to figure out the tax implications, so we skip this.

So, it should be smth in the middle? We should include all non-addon options in the following table rows?

[cmutel]

The invoice is for the registration option that they chose. We don't need to list the other registration options.

For example, for https://www.d-d-s.ch/schools/may-24/index.html you can register for a single or double room. The invoice is only for the option you chose - no need to display the other possibility.

[lilliputten]

I still don't understand: How can I distinguish the registration option from other non-addon options? Mb, do I just have to take only the first existing option?

[lilliputten]

Subtask 'Allow client to enter their name and address' has implemented in the related task #12 ('Add extra registration details'), see PR #27.

[lilliputten]

@cmutel

Invoice pdf layout:

Should we preserve a space for a client' address?

Which position of client name + address block is more correct:

1. Aligned with the logo?

2. Aligned with the dds address at right, as in your original examples?

[cmutel]

Option 2, aligned with other address.

[lilliputten]

Do we need an invoice generation form? As I see we might need it for that 'extra text' ('...which could come after the invoice if needed for their internal accounting') -- probably, it'd better to make it a part of the event registration form?

The question is: do we need to have a link to invoice generation form (with which fields? only that extra_text?) or just to an invoice download?

UP: For the moment I've added it as a part of registration form and going to implement invoice receiving as a download link rather than a form.

[cmutel]

UP: For the moment I've added it as a part of registration form and going to implement invoice receiving as a download link rather than a form.

👍🏽

[lilliputten]

I still don't understand how should we display the events table.

Where should be the event name, where -- options (add-on's, and non-add-on's), how have we to calculate the total amount?

Should I repeat the vent name on each row?

Should I include add-on options in the total price?

Can we try to discuss discounts one more time? (I think now I already ready to implement it.)

Now it looks this way (I put event name/description in each cell of 'Event' column, and quantity is always 1, payment_details is taken from 'Event' data if exists otherwise used that default text, with 'Account holder...' etc, the texts under the logo -- DdS and the address -- are constants now):

The url template for invoices is .../event/{event_code}/registration/invoice -- it's contained in the message about successful registration for the event.