A Dilluns, 5 de desembre de 2011 00:48:53, Cédric Krier va escriure: > On 05/12/11 00:29 +0100, Jordi Esteve wrote: > > Al 04/12/11 23:55, En/na Cédric Krier ha escrit: > > >On 04/12/11 19:45 +0100, Albert Cervera i Areny wrote: > > >>Next thing we'll need in our localization is being able to assign > > >>payment types to parties, sales and purchase orders, invoices, and > > >>account move lines. > > >> > > >>A payment type defines how an invoice is going to be paid. Some > > >>examples can be: credit card, bank transfer or cheque. > > >>So the question is: do other countries need similar features and have > > >>some specific requirements? > > > > > >It is very difficult to answer this because I don't see the usage of > > >such informations. > > >Of course in some cases, you can add some facilities to pay an invoice > > >(like pre-filled bank transfer form) but for me, customers are always > > >allowed to pay the way they want. > > > > Not always. There are lot of cases that the customer invoices are > > paid when the supplier wants, normally by an automatic process throw > > the banks. For example, when you pay the electricity or the water > > invoices. The customer don't say "I want to pay my electricity > > invoice this day". The electricity company, as supplier, takes the > > order to get the money of their customers, normally by a automatic > > process between the company bank and the customer bank. > > Ok this is a special cases where the customer allow the supplier to take > money from his bank account. So the company know about that. > But this is just one special process for such customers. I don't see it > is useful to get this information on any of the proviously described > document.
Again, this is country-specific stuff. When companies make an agreement, they agree on both payment-term and payment type. Usually the customer is free to pay that they want but suppliers take note about how they're going to be paid. The payment method described by Jordi is extremely usual here (not only for water or electricity companies). There are bank transfers and other methods such as cheques and pagares and suppliers want to have some control how the invoice is going to be paid, although the most important thing is to distinguish between those "to be sent" and those "to be received". You need that information in sales/purchases and invoices because you may usually expect bank transfers but for some one specific invoice you may have to send it yourself to the bank so you need to have control of that. > > >>Do you think account.payment.order should go to its own > > >>module or better moved into account_payment_type? > > > > > >What is an "account.payment.order"? > > > > A payment order is an order to get the money of several debit > > customers. Or an order to pay money to several suppliers. > > First, I think it is important to distinct both types. They certainly > don't have the same workflow. The difference is the same as for customer and supplier invoices. The "payment order" is basically the same. What differences do you think there are? Note that we're talking about payment orders *only* when we (the company) has to be the one to send the document to the bank. If we have to wait for bank transfers from the customer or the supplier directly asks for payment to our bank we do not need a "payment order". > > With a > > payment order you can obtain a file with a certain format that you > > can sent to your bank to automatically process these payments, as I > > explain before. > > So you mean it is only linked to bank? I think it is better to speak > about "financial intermediaries". Yes, it's only linked to the bank. > I think such feature must be designed very well because it defines the > way to manage the cash flow of the company. So it must be flexible, > customizable, generic etc. Yes, and we have some really tricky things to solve in Spain regarding all this stuff... That's why I wanted to discuss the details in another e-mail ;) -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- tryton-dev@googlegroups.com mailing list
