For myself, I'd never pre-build the transactions. I'd use a query that calculates the total amount paid and the next payment date. I also wouldn't break out tax in the individual transactions as that should be in the parent based off of the total amount, unless there is a regulatory reason to break it out by transaction.
This means your child just has
--Parent ID (Agreements should be a child to the customer, so should just have the agreement ID)
--Date/Time of transaction
--Type for transaction
--Transaction amount.
--Notes
For your payment schedule, you can work out "Total due divided by number of payment" to tell you how much should be paid each month. Total of all credit less debits would give you the customers balance. Balance divided by your calculated monthly payments tells you how many months they are paid through.
This approach lets you calculate not only the next month payment is due, but the same methodology helps calculate what the amount due is.
As a scenario, say a customer owes $1800 to be paid over 60 months. Each month they need to pay (1800/60) $30. Customer pays $100 up front. Next payment is due month (100/30) month 4 with an amount of $20 due.
If you tried to create all of the records ahead of time, your user would need to go in and try and allocate this on their own. More difficult AND tends to add human errors.
This means your child just has
--Parent ID (Agreements should be a child to the customer, so should just have the agreement ID)
--Date/Time of transaction
--Type for transaction
--Transaction amount.
--Notes
For your payment schedule, you can work out "Total due divided by number of payment" to tell you how much should be paid each month. Total of all credit less debits would give you the customers balance. Balance divided by your calculated monthly payments tells you how many months they are paid through.
This approach lets you calculate not only the next month payment is due, but the same methodology helps calculate what the amount due is.
As a scenario, say a customer owes $1800 to be paid over 60 months. Each month they need to pay (1800/60) $30. Customer pays $100 up front. Next payment is due month (100/30) month 4 with an amount of $20 due.
If you tried to create all of the records ahead of time, your user would need to go in and try and allocate this on their own. More difficult AND tends to add human errors.
