Closed lilliputten closed 7 months ago
@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 textpayment_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
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
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?
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.
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?
Subtask 'Allow client to enter their name and address' has implemented in the related task #12 ('Add extra registration details'), see PR #27.
@cmutel
Invoice pdf layout:
Should we preserve a space for a client' address?
Which position of client name + address block is more correct:
Option 2, aligned with other address.
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.
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.
👍🏽
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.
2324 Magdanova.pdf
The generated invoice needs to meet these criteria:
AB
, whereA
is the two digit number of the year, andB
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.Service
(this should be called "Event") is specified in theEvent
(needs a new column called "invoice_item_text")Acommodation
can be changed to "Option", and we need to add a column toRegistrationOption
for "invoice_option_text"Event
, "payment_deadline_days", with a default of 30.