Contributors mailing list archives


Re: connector_ecommerce dependency in v9

Guewen Baconnier
- 21/03/2016 08:40:49
On Fri, Mar 18, 2016 at 9:37 PM, Stephan Keller <> wrote:
> Guewen,
>> Nice idea, could it plug with the automated actions in some way? We
>> can wonder if the automatic workflows couldn't be a simpler interface
>> for them?
> Yes, I thought about that too and that is an option.  I think you still want
> it to be asynchronous, so we would use the "based on timed condition".  My
> concern here would be the handling of exception.  If one of the record has a
> problem, I am not sure if it will be rerun.

Personally I would be delighted if it could no longer be asynchronous :)
At the very origin of this addon, it was not and it had to be changed
due to some issues:

The reason for it to be asynchronous was only a workaround due to the
workflow and subworkflows which could not be stepped in the same

Regarding the exception handling, I think that an error would be
returned to the current user, as automated actions are executed
directly during the user's request.

> Also once processed, you don't want the record to still be part of the
> original filter, because the system get all the record and then look at the
> time for each record.  So you don't want the number of records in the filter
> to grow over time.

It can probably be handled by the filter domains themselves (e.g.
ignore the 'draft' orders for the 'validate orders' action).

>> The use case was:
>>  1. A customer takes an order of 230€ on Magento
>>  2. He pays an amount by credit card, normally the full amount of 230€
>>  3. The order is imported in Odoo, it creates the payment not with the
>> amount of the invoice, but with the amount which is captured by the
>> payment service provider, so if it is different from the total
>> invoiced, the payment amount is still correct
>>  4. reconciliation, ...
>> So the original goal was really to take in account the amount really
>> paid, not the amount expected to be paid.
> I am not sure I understand.  You mean sometimes the service provider capture
> an amount that is different from the one that is asked for?

I don't know if it happens in practice, nor if it can happen that
someone pays the amount partially.

>> Another use case IIRC that is used by Akretion is that they don't
>> confirm sales order until they have a full payment by check, so they
>> use sale_quick_payment to generate manually the payments before the
>> validation.
> I was wondering where was that register payment button, thanks.
>> For us, I would say this no longer a needed feature, but we are not
>> the only ones concerned :)
> My suggestion at this point would be that the main flow for the automation
> would be to create an invoice and register a payment on the invoice.  I am
> assuming that most of the time when doing an order on a shopping cart, the
> customer pays in full (if not we could still manage that case I think).  So
> in that case we don't need the payment to be generated on the sales order.
> That would have the advantage also to create a payment record, which for the
> end user is better than just a journal entry.   The creation of a payment on
> the sales order could still be done of course but in a separate module that
> is not required by the connector-ecommerce module.  I think this would be
> faster to port to v9 and easier to maintain.

Makes sense, that would do it for this use case I guess.

> It would be great to have Akretion feedback on this, or anybody else that
> has used this in the past.
> I will send an email to Sebastien.


> Thanks and have a great weekend,
> Stephan.

Thanks to you for your work on this migration!

> .
> --
> Stephan Keller, Ph. D.
> CEO Sodexis, Inc.
> Orlando/Longwood, FL
> Odoo Certified Expert
> Phone: (407) 278-4917
> Cell: (407) 202-8998
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe: