On 05/11/12 23:17, [email protected] wrote:
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?
--
Jordi Esteve
Consultor Zikzakmedia SL
[email protected]
Mòbil 679 170 693
Zikzakmedia SL
Dr. Fleming, 28, baixos
08720 Vilafranca del Penedès
Tel 93 890 2108
--
--
[email protected] mailing list
