magentoerpconnect-community team mailing list archive

[Jordi Esteve <jesteve@xxxxxxxxxxxxxxx>]

I forward this email about payment types to magentoerpconnect-community 
email list because you are aware of it.

========

Hello Raphaël,

I was waiting your mail since two weeks ago, this commit is old, so I 
suppose you were glad with it. I think that it is a good contribution, I 
argue in your email:

En/na Raphaël Valyi ha escrit:
> Hello Jordi,
>
> We thank you very much for all your contributions but I should say I 
> don't feel very comfortable with one of your commit:
> http://bazaar.launchpad.net/~openlabs-akretion-consortium/magentoerpconnect/magentoerpconnect_generic/revision/288 
> <http://bazaar.launchpad.net/%7Eopenlabs-akretion-consortium/magentoerpconnect/magentoerpconnect_generic/revision/288>
>
> So you add a dependency upon "account_payment" and seems to use it a 
> bit like we currently use statement for customers payments (I'm not 
> sure I get it all, but it seems that this is the big picture).

Well, not exactly. You can create account statement in different 
journals to encode the several payments types, but you lose the payment 
type information in invoices and sale orders. Yes, you can optionally 
install sale_payment module (depends on account_payment) to add the 
payment type in sale orders; this payment type then is flushed to the 
invoices. If you look inside the code of this commit, you'll see it 
checks if sale_payment module is installed or not.

account_payment (official module) and sale_payment (addons extra module) 
help a lot to control the payment type in sales and invoices. All the 
Spanish companies use them.

> The reason why I'm not sure this is good is:
> - we already deal with customers payments by making a statement on the 
> proper journal thanks to the sale_order#generate_payment_with_pay_code 
> method brought by the base_sale_multichannels module. It might not be 
> very sophisticated but it looks it cover everything Magento do in 
> relation with payments (or do I miss something?)

This is Ok for prepaid payments like paypal or credit card. With 
postpaid payments it is not good because the account statement will not 
be created. In postpaid payments is better to encode a payment type 
entity in the sale order and invoice. I think that having payment type 
entities in OpenERP will help Magento users.

PostPaid or Manual payments avaible in Magento, for example:

* Check / Money order. It is an in-the-box payment type. This payment
is typical for send money from Costumer Bank to Partner Bank (or check notes)
* Cash On Delivery. Available by magentoconnect. This payment is used when you
send the package and the coustomer pay to the postman.

> - we do not depend on any other module, so it's kind of minimalist

I agree with you. If at the end of reading this email and testing this 
commit you are not convinced, a solution will be encode it as an extra 
module of magento-openerp-connector to avoid this dependency.

> - but mostly, looking at the account_payment documentation, it looks 
> like this module is mostly aimed at managing your suppliers payments 
> and not your customers payments. Indeed, from the doc:
> http://doc.openerp.com/book/3/3_7/accounting_entries.html?highlight=account_payment
>
> "The system lets you enter a series of payments to be carried out from 
> your various bank accounts. Once the different payments have been 
> registered you can validate the payment orders. During validation you 
> can modify and approve the payment orders, sending the order to the 
> bank for electronic funds transfer or just printing cheques as you wish.
>
> For example if you have to pay a supplier’s invoice for a large amount 
> you can split the payments amongst several bank accounts according to 
> their available balance. To do this you can prepare several Draft 
> orders and validate them once you’re satisfied that the split is correct."
>
> So I wonder: why are the exact reasons why you bring the whole 
> "account_payment" module here?

No, it is not all true, account_payment defines the basis payment 
entities (payment type, payment order) for customer and supplier 
invoices. account_payment also offers the management of payment orders 
to pay. And account_payment_extension module extends it to management 
payment orders to receive easily.


> BTW, just in case, here is the process we do to deal with payments: we 
> often use intermediary accounts to receive customers payments, so the 
> statements (generated according to Magento payment method codes) will 
> then send money to those intermediary accounts when validated. On the 
> other side of the pipe, we receive the bank files, in our case we use 
> TermniatOOOR http://github.com/rvalyi/terminatooor (but everybody odes 
> as we wants, nothing mandatory) to create the bank statements, we then 
> use the automatic OpenERP mass reconciliation system to reconcile most 
> of those payments statements and bank statements automatically. I 
> don't see what kind of benefit account_payment would bring here, but 
> may be it's just that I miss something.

As I told before, helps a Magento user to see the Magento payment type 
in sale orders and invoices.

> So, would you please explain us why you introduced the account_payment 
> dependency, has it some big advantage over the existing method 
> I described ? If not, I suggest to package it as an independent 
> optional module. What do you all think about that?

As I told before, this could be a solution. Tell me about your opinion 
after you have read this.

> PS: we are pushing a bunch of multi's fixes as you can see with the 
> Sebastien's branch 
> here https://code.launchpad.net/~akretion-team/magentoerpconnect/Multi-website-fix 
> <https://code.launchpad.net/%7Eakretion-team/magentoerpconnect/Multi-website-fix> 
> and there is more to come, I'll propose some 
> base_external_referentials refactoring here later on.

Excellent! I did not know, I wondered that there was little activity in 
the main branch. So, you will merge the Sebastien's branch to the main 
branch early?

Regards,

Jordi

--
Jordi Esteve
Consultor Zikzakmedia SL
jesteve@xxxxxxxxxxxxxxx
Mòbil 679 170 693

Zikzakmedia SL
Dr. Fleming, 28, baixos
08720 Vilafranca del Penedès
Tèl 93 890 2108