Sale Advance Payments

Feature
1

This Blueprint is the continuation of the Money Deposit discussion related to Sale Deposit.

The issues with the current design

  • account_deposit considers all the money on the deposit account as a whole. When in the sale case each deposit is related to a sale and only a sale.
  • The current design does not handle the cancellation of deposit invoices ; worst than that issuing a credit note for a deposit invoice might trigger the creation of the shipment
  • The creation of the shipment allows modification of this shipment.

A new module: sale_advance_payment

We came to the conclusion that the module should not use a deposit account in order to fix the first point raised. But instead the party will still have a link to an account of type other. The new module will not make at all use of the account_deposit functionalities hence its new name: sale_advanced_payment.

The second point will be solved by adding a warning when the user post an invoice containing a line related to an advanced payment condition. This warning will inform the user of the risks of opening such an invoice.

On a related note, the statement lines should allow reference to validated customer invoices. When processing this statement those invoices will be automatically posted (and partially or completely paid).

The shipping process will be modified to create draft moves once the conditions to supply are met and the creation of the shipment containing those moves in the waiting state will be triggered once the conditions to ship are met.

##Implementation
https://bugs.tryton.org/issue5215

2

This should be done in the account_statement module as it wanted behaviour for all cases.

3

This should care to update the planned date of the moves (and shipment).

4

Well it was obvious wasn’t it?

5

Indeed I was thinking about how the shipping date is computed as with this module the shipping creation can be long after. But I think this is probably for another topic.

6

The module should also follow the same behaviour as Issue 5916: Add support for taxes on deposit - Tryton issue tracker

7

I do not think it is needed to have a different account per party.

Indeed as there is no way to know if it is a valid request to post or not (we do not know the intention of the user). We can not raise correctly a warning.

Except that such invoice does not have a amount to pay and so the statement will create a new line with the remainder of “0 to pay”.

I think the user will have to manually post the paid invoice to be able to encode the payment on statement linked to the advance invoice.