1. Mailing Lists
  2. Contributors
  3. Re: connector_ecommerce dependency in v9

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: connector_ecommerce dependency in v9

Re: connector_ecommerce dependency in v9

Avatar

Re: connector_ecommerce dependency in v9

by
Guewen Baconnier
- 21/03/2016 08:40:49 
On Fri, Mar 18, 2016 at 9:37 PM, Stephan Keller <skeller@sodexis.com> 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
transaction:
https://github.com/OCA/sale-workflow/blob/1d28d0b146c874f3b0011634dbaedafaf22b3b97/sale_automatic_workflow/automatic_workflow_job.py#L31-L41

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.

Yes!

>
> 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
> www.sodexis.com
> Odoo Certified Expert
> http://www.linkedin.com/in/stephankellersodexis
> Phone: (407) 278-4917
> Cell: (407) 202-8998
>
> _______________________________________________
> Mailing-List: http://odoo-community.org/groups/contributors-15
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: http://odoo-community.org/groups?unsubscribe

Reference