magentoerpconnect-community team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello Magentoerpconnect community,

At Akretion, we need to better deal with the status of the OpenERP
order/invoice/picking/statement depending on the Magento payment type. We
already have customizable mappings for this, but we are thinking in
formalizing some options in a more user friendly way and more generic (we
think to make it part of the base_sale_multichannels module, we already see
some need for it in a Kettle - OSCcommerce connection we made too).

Basically we know that part of this problem is solved by the recent
Zikzakmedia contrib (see the thread). However:
- some parts of the problem (like the status of the entities is not
addressed, only the order policies are addressed)
- we are not very comfortable with depending upon account_payment which is
aimed at managing supplier payment rather than customer payments, we find it
adds useless complexity
- installing account_payment is specially awkward if you deal with the
payments with statements already (for instance useless link to payments on
the right side of sale orders).

So at the end we propose a simpler solution that add no dependency (and
probably only 20 lines of code) and propose to Zikzak to package their
_account_payment and sale_payment compatible extensions as a separate
optional module.

Here is the chat I just had with Sharoon Thomas (Openlabs) about this topic;
he agrees we our view, so I invite you to comment on my mail too.

"
 me:  Hello Sharoon, time for a quick Magentoerpconnect question?
 Sharoon:  always friend
 me:  cool
so we are thinking about improving the payment management
basically we lack a few features:
 Sharoon:  ok
 me:  we would like to be able to selectively set the
order/invoice/statement status depending on the Magento payment type
(for instance it should be different for check and credit card)
 Sharoon:  yes
 me:  so we have some ideas
 Sharoon:  i think the improvement by esteves already does that
 me:  yes
we would like to ba compatible with  that
so my question is:
 Sharoon:  sure
 me:  do you know sale_payment from Zikzak ?
do you think that's good?
 Sharoon:  never used
 me:  hum
because we imagine simpler solutions than that
Sharoon:  fortunately my customers are all prepaid
 me:  hum
 Sharoon:  ok
 me:  because: sale_payment is from Zikzak
and base on account_payment
 Sharoon:  k
 me:  the issue is that account_payment itself is designed for supplier
payment
not customer payment
sale_payment on its side is for customer_payment apparently
but I find it a bit strange
 Sharoon:  ok
 me:  because it depends on account_payment wich adds complexity
 Sharoon:  its not intrinsic
 me:  that seem totally useless for custoimer payment
instead what we imagine; a simpler solution:
 Sharoon:  ?
i think its better to just manage state for that or look at invoice payment
status?
 me:  - create a new object called: ~payment.type
 Sharoon:  ok
 me:  it would have:
- a name
 Sharoon:  ok
 me:  - a many2one relation to the journal
- a selection for the order status
 Sharoon:  ok
 me:  - a selection for the invoice status
- a selection for the picking status
- a selection for the statement status
 Sharoon:  ok
 me:  now, given a magento payment method,
we match it against that payement type
and it gives us all the order/invoice/picking/statement settings
 Sharoon:  ok
 me:  and we remove the payment code from the journal (simple SQL migration
script to do)
 Sharoon:  got it
 me:  it would be part of base_sale_multichannel
it's pretty generic, we would use it in our OSCommerce connection too
no dependency upon account_payment or sale_payment
 Sharoon:  i think i get it. but not clear yet
 me:  the idea is to have more order/invoice/picking/statement settings
driven by the Magento payment type
for instance, if payment is a check
then the picking will be left in draf, same for statement
err; draft
 Sharoon:  i like that
the other modules simply complicate things
thats why i never wanted to use them
 me:  it's what I think
 Sharoon:  i think i go with ur idea
+1
 me:  then I have no problem if they do an extension module that allow
working with account_payment if they like it
for instance, our customer suddenly started to wonder what was that
"payment" link on the right of the sale_order that point to nothing
because they deal with their payment with statements instead
 Sharoon:  i dint bother installing the module
 Sent at 11:33 AM on Wednesday
 me:  well, apparently in line 21 of external mapping line .csv
we already have some customizable mapping of that logic
(I didn't remember)
 Sharoon:  k
 me:  but it's internal to Magento and not very user friendly
 Sharoon:  k
 me:  we will think about it and eventually make something in
base_sale_multichannel instead
if you have ideas or are against it, please tell us
 Sharoon:  i vote for this
 me:  cool
nice
 Sharoon:  i think this connector is so complex we need to have separate
layer on this
 me:  ok
 Sharoon:  i vote ur idea
can you put it to the mailing list
 me:  could I paste that conversation in a mail to the list or you would
mind?
 Sharoon:  i dont mind
please go ahead

 me:  fine, that's the faster
quick summary + paste then
 Sharoon:  yep
"



Raphaël Valyi
http://www.akretion.com