Reconsider structure of Invoices and Receipts

[charlesjhill]

The current database schema involves a one-to-one relationship between Asset and PurchaseInfo and many-to-one relationship with MaintenanceReport to Asset. The logic here is that each asset cannot be purchased more than once, but an asset can be maintenanced more many time.

This schema is defective however. In both cases, an invoice can surely be for multiple assets at once. If you purchase 10 Tubas, you will have 10 assets each with the same PurchaseInfo object associated with. As such, similarly you might send many things into the shop at once for repair. Therefore, it makes sense to move these relationships over to a FK on Asset for PurchaseInfo, and a Many-To-Many on MaintenanceReport to Asset.

Per guidance on the Django docs, the ManyToManyField should be on the model whom you'll be interacting with in the form. In my design ideas, typically you add a maintenance report to an instrument, but a more reasonable workflow is probably the opposite: A staff member gets the receipt, then punches it in the system in one place.

The Issue

The model can't handle per-asset information. An invoice records the price for the entire transaction, but not the price associated with each asset. With maintenance reports, you can write notes containing ALL the work performed, but that data cannot be delineated on a per-asset basis.

For purchases, the canonical solution would be to place the purchase price as a field of the asset itself, then the PurchaseInfo entity tracks the "total" price (computed) and shared data, like the date of purchase, receipt number, etc. However, I would be hesitant to say "purchase price" is a property of an asset speaking colloquially.

As for maintenance, it seems the solution is to introduce a "through" model to track the per item maintenance-performed and cost, the use the Maintenance object as the container.

Moving forward

For now, we'll be shifting the relationships as described in paragraph 2 above. However, deciding how we should handle the issue of per-asset knowledge in a receipt will need to occur before the application moves into production.