Some sale work-flow like online sale requires to have the payment before validating the sale (and so before having an invoice). Indeed the payment is the validation of the quotation.
Proposition
We add an origin on the payment which can point to a sale.
The sale can not be validated if there are payments linked to it and they are not succeeded for the amount of the sale.
When an invoice for the sale is posted, we link the existing succeeded sale payments to the payable line. To work properly, the invoice should not have a payment term (neither the sale) and the invoice method must be “On Order Processed” to ensure that only one payable line will be created.
Indeed I think we should not add this constraint but instead not link the payment if its amount is bigger than the payable line. In this case the successful payment will be reconciled later using the reconciliation wizard.
I am well into making an implementation of this feature and had programmed in that constraint upon your suggestion. However, in my use case (e-commerce web app) all of the created sales followed those constraints already so it wouldn’t really be a factor.
I added a boolean field to the sale called “prepaid” to indicate a sale is intended to be paid before it is invoiced, and when that value is true it performs extra processing. On payments that reference a sale I do a check against the total amount of the sale less the total amounts of any previously created payments that aren’t in failed state (including pending payments–those that have not yet gotten past the processing state):
sale.prepaid_remaining = sale.total_amount - sum(p.amount for p in successful_payments)
sale.prepaid_pending = sum(p.amount for p in pending_payments)
This way we can remind the user of an over-payment before the creation and posting of an invoice and do some automatic stuff like automatically create new payments with the amount set to max_amount and so on. It is still possible to force over-payment.
Anyways once our sale_payment module is functioning reasonably well (hopefully by the end of the month) I will be submitting it for proposed inclusion in Tryton. If you have already got something in the works let me know and perhaps we can combine our efforts
With respect to the “origin” field, I added the field itself in a separate module from the sale_payment module I am making, then just add sale to the model selection in the sale_payment module itself. My reasoning is that the payment origin field could be used to reference other models in the future, including other payments
Perhaps it would make sense for me to instead patch the account_payment module to add the origin field and submit for review so it is included in future versions of account_payment (probably 4.5 and onward)?
I will need to feature by the end of the week, So you must publish your work ASAP otherwise I will implement it myself.
Otherwise I do not make any comment on implementation without seeing the code.
Thanks for the quick reply (since it looks like you want this feature in the 4.4 release timeframe then I uderstand why…)
As per my other question regarding the origin field being incorporated directly into account_payment I could submit a patch for review today if you are fine with that, and publish my account_payment module shortly thereafter (thinking tomorrow for that given the time differences, but ASAP as you suggest).
I am ready to submit the code for the sale_payment module now, however I have not contributed a whole new module to this project before. Can you tell me (or send me a link to) the preferred method of submitting a new module for review?