Add a new field to every transaction that is written when the transaction is created and is returned by every read of the transaction.
This field (called "reason") should contain a json document that stores the invoice itemization at the moment a dues transaction was created.
Right now, it is not processed by the payment-service in any way, but it allows fully reproducing how the change in dues amount came to be. Which packages were selected, how often, and at what price when the dues transaction was created. What was the value of the manual dues field? What was the manual dues comment?
Currently, this is a labor-intensive manual process in the historization tables of the attendee service. And this is the wrong place because the payment-service holds the definitive accounting history of all bookings, dues and payments. Which means, it must also be the place to hold their decomposition into invoice items.
Add a new field to every transaction that is written when the transaction is created and is returned by every read of the transaction.
This field (called "reason") should contain a json document that stores the invoice itemization at the moment a dues transaction was created.
Right now, it is not processed by the payment-service in any way, but it allows fully reproducing how the change in dues amount came to be. Which packages were selected, how often, and at what price when the dues transaction was created. What was the value of the manual dues field? What was the manual dues comment?
Currently, this is a labor-intensive manual process in the historization tables of the attendee service. And this is the wrong place because the payment-service holds the definitive accounting history of all bookings, dues and payments. Which means, it must also be the place to hold their decomposition into invoice items.