search

sentier-dev / dds_registration

Django app for event registration and billing
MIT License
0 stars 1 forks source link

Refactor invoice PDF creation #94

Closed cmutel closed 6 months ago

cmutel commented 6 months ago

Any Invoice should be able to create it's own PDF without the redirection dance which occurs currently. This means that we need to populate the Invoice.data field.

lilliputten commented 6 months ago

M.b., I don't understand it (again), but it seems to be redundant: we already can generate that data programmatically at any moment by invoice parameters.

That's (should be) an idempotent function for an invoice unique data.

cmutel commented 6 months ago

M.b., I don't understand it (again), but it seems to be redundant: we already can generate that data programmatically at any moment by invoice parameters.

In general I agree with you, and you are right that we shouldn't store data more than once because we can run into sync conflicts. However, it is exactly because there could be sync conflicts that we need to store this information on the invoice. It a representation of a system state at a particular time - since that invoice was generated the prices could have changed, the person could have changed their name, etc. etc. Some of these can be short-lived effects, e.g. we give prices in a foreign currency but change that to reflect the exchange rate every month. For audit reasons we will need to keep these invoices (or the data to generate them) for years, it's better to keep a copy of the data.

lilliputten commented 6 months ago

It could make sense if your goal is to keep an invoice off for some past statr. But, on the other hand, if you plan to update the stored PDF in a sync with invoice data, then it will be pointless again. So, idk.

lilliputten commented 6 months ago

The name and the address are already stored in the invoice. But prices -- yes, they depend on the external data (options or whatever we decide to use) and could be changed.

lilliputten commented 6 months ago

And here, if we decide to save the state (states?), we will again have a choice: to store full binary data or a smaller amount of more clear data (json, for example) describing the document.

cmutel commented 6 months ago

a smaller amount of more clear data (json, for example) describing the document.

That's what the data element is for 😸

lilliputten commented 6 months ago

a smaller amount of more clear data (json, for example) describing the document.

That's what the data element is for 😸

Hmmm, ok. I thought that was reserved for future use and you suggested saving raw binary pdf data in a new model column.

So, I can use the data field to save the datastamp of the invoice document?

cmutel commented 6 months ago

Yes, exactly.