Comment by [email protected]:
I don't see why it should have 2 types of payment. For me, it should be
seen like this: statements are messages received from bank and payments
are messages sent to the bank.
If I understand you, you say that the type in payment orders (payable,
receivable) is not necessary because a payment order could have a mix of
payment lines of different type? Normally a payment order contains only one
type: you create a payment order to pay to several suppliers or you create
a payment order to receive from several customers, for example. If you
think this is not enough general, we can remove it.
The module should not depend on payment type, this concept is very
unclear.
In the introduction of the blueprint I explain in detail with examples the
concept of payment type. In short, payment type is the way you receive/pay
the money.
Ok, we could remove it and create an account_payment_order_type module
including it that depends of account_payment_order and account_payment_type
modules.
I think payment mode should not be a Model but just a selection field on
the payment which will be filled by modules that will implement bank
communication protocol.
As Albert, I'm not sure we don't want payment.mode in the standard module.
I think payment mode is the equivalent to account.statement.journal. In
fact it should probably be called 'account.payment.journal'. So, if you
agree, we could change the name from 'account.payment.mode'
to 'account.payment.journal', removing some fields like payment_type and
bank.
It not only defines how you will communicate the payment, it also contains
the journal where to create the account moves if you want to create them
directly from the payment order, for example. Also, if we define the new
object 'account.payment.journal', the modules that will implement bank
communication protocols will have an object to extend with specific
information to configure.
The payment should not be linked to a bank, it is a concept that should
come with the communication protocol.
Ok, like payment type, we could remove it and create an
account_payment_order_bank module including it that depends of
account_payment_order and party_bank.
In Tryton, "order" is never used for naming Models.
I have chosen it for clarity, to distinguish account.payment.order from
account.payment.type.
I don't like account.payment (it is the first part of account.payment.line
and account.payment.type model names). Would you prefer
account.payment.payment (like sale.sale)?
In "account.payment.order":
- "name" should be renamed into "number" to follow standard naming of
Tryton. And no need to get a unique constraint (less constraint == more
generic).
Ok
- "user" is not needed, if logging is required it could be done with the
history feature.
Ok
- "currency", I don't see the usage ? I think in many cases, it will be
allow to sent payment with mixed currencies.
Ok
- "done_date" idem as for "user".
I think this field is important, it annotates the date the payment order is
confirmed and we can see it in the payment order form. It is like the
sale_date field in sale orders or invoice_date in invoices. If you want we
could change the name to "payment_date".
In "account.payment.order.line":
- "name", it could be dropped.
Lots of bank communication protocol for payment need one unique identifier
for each payment line. So it is a number (I rename it as number) filled
with payment.order.line sequence.
- "maturity_date" seems duplicate information with the "move_line"
Yes, it seems but it gives more flexibility. It is filled with the
maturity_date of the move line but sometimes you want to change the
maturity date afterwards.
- "party" idem
Ok
- "bank" should be in custom module
Ok
- "move_line", why not a Many2One ?
Ok. First I thought to group several account.move.lines to one payment.line
but I agree will be easier to manage with a Many2One.
I think it should be possible to change the amount.
Wizard "account.payment.order.add", it should define how the lines will
be selected and how it will prevent to select many time the same line.
Yes, this is one of the critical problems of this module. We must ensure:
1) An account.move.line it is not puttwice in two different payment orders
2) It will be difficult to know the amount to pay in an invoice, because
some payments will be partially done and other will be included in
confirmed payment orders.
Some ideas how this could be achieved?
For more information:
http://code.google.com/p/tryton/wiki/PaymentOrder
--
--
[email protected] mailing list
