Closed cmutel closed 6 months ago
Should we have invoice_no
in an old form (year + no) as a PK in the Invoice table? ('In Registration, invoice_no
should be replaced with a foreign key').
Should paid
and paid_date
be moved to Invoice
instead of completely removed?
Related question (probably, the most important now): do we have any changes to the man payment procedure: do we still have to change the paid
status (in the Invoice
table?) on a payment success event?
I don't understand the idea of registration options changes. I'll ask about it later.
Furthermore, I'll need explanations on a status
flow (when we should switch to which statuses).
Have seen PR #52: It'd probably be better to generate PDFs on the fly, not to store them as blobs.
What is the template
field for there?
Should paid and paid_date be moved to Invoice instead of completely removed?
Yes, this seems reasonable. These two fields are both needed, but maybe instead of paid we have status with more than on/off choices, for example.
Have seen PR https://github.com/Depart-de-Sentier/dds_registration/pull/52: It'd probably be better to generate PDFs on the fly, not to store them as blobs.
@jsvgoncalves is a big fan of this idea as well. Let's do that.
What is the template field for there?
Because we can have more than one kind of invoice :)
Should we have invoice_no in an old form (year + no) as a PK in the Invoice table? ('In Registration, invoice_no should be replaced with a foreign key').
Sure, why not? It must be unique, and doesn't need to be sequential.
Related question (probably, the most important now): do we have any changes to the man payment procedure: do we still have to change the paid status (in the Invoice table?) on a payment success event?
Yes, we will need to integrate with both Wise and Stripe to automate this - but that is not a requirement for v1 (we need to ship v1 ASAP).
Furthermore, I'll need explanations on a status flow (when we should switch to which statuses).
Almost all of that is manual, except for payment being made, and even that will be manual for now.
Sure, why not? It must be unique, and doesn't need to be sequential.
Probably, we could have the normal auto-incremented integer PK and construct invoice no by adding the year.
Development has gotten a bit hackish as the user stories were not developed enough to have a solid foundation for development. Therefore we need to refactor the app before public deployment.
Separating out
Invoice
The biggest change is that logic related to the invoice should be in a separate
Invoice
(#61) table. We can therefore remove the following fromEvent
:currency
needs to be added toRegistrationOption
(a single event can have registration in multiple currencies).In
Registration
,invoice_no
should be replaced with a foreign key. Similarly,paid
andpaid_date
should be removed.extra_invoice_text
should be a column (with a different name) inRegistrationOption
.Changing registration options
The table
RegistrationOption
should only be for registering for an event. A single person can only register once for an event. The columnadd_on
can be removed.Registration
can therefore have a foreign key (instead of ManyToMany) toRegistrationOption
.Registration
statusInstead of a column
active
, we should have a choices field (models.TextField(choices=
) calledstatus
. This can be:Discounts
This functionality is nice to have, so let's comment it out for now
Membership
The column
honorary
should be changed to a choices field with possibilities:This isn't shown to users when they are registering - board and honorary are created manually, and there is a separate signup for business members.