Comment by [email protected]:
* The company field in the payment seems redundant. The company is already defined in the journal where the payment is in.
Yes, but with company field it is easier to add rules related to a company (users only see the payment orders of the company they belong). It is the same that happens with invoices: invoices have a company field despite they have a journal, account and period fields that also have a company field (of course, for coherence, all of these company fields must be the same).
* As one payment always goes to one party I think there should be a party field on the payment and a constraint on the move lines to match the party. This makes it also possible to make a transfer for something not (yet) having any move line. The function field on the payment line could then be removed.
Yes, this could be an option to design this module, also Cedric said it is an important feature to be able to decide the amount to pay.
Today we have discussed with other tryton programmers in Barcelona that giving flexibility to the user to change partner and amount fields in payment lines will complicate the most simple and common cases, like pay/receive invoices (receivable/payable move lines). For example, to ensure that an account move line is not added twice in two different payment orders. So, in a first version of this module, we will no allow to generate a payment without having a account move line. With this constraint, this module could be simplified dropping the account.payment.line model and relating directly payment order to account move lines.
* I still don't see the use case for the maturity date. The maturity date is a property of payables and receivables and not of payments. If somebody wants to modify the maturity date this should IMO be implemented by customization of the account module.
Ok. I agree. Moreover, if we drop the account.payment.line model and we relate directly payment order to account move lines this is solved, maturity date could be only changed in account move lines.
* I think a description field on the payment itself will be necessary as well.
Maybe. But I think the user normally will leave empty the description field. In account statements there is not any description field for the same reason.
For more information: http://code.google.com/p/tryton/wiki/PaymentOrder
