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
Sodexis, Stephane Keller
- 31/03/2016 20:50:59
Sebastien asked me to forward his answers to the mailing list, so there it is:

Regarding automatic workflow
I still think we need to do it asynchronly. Indeed if we have many task linked it can make the validation slower and boring for the user.

Maybe we can use job for validating automatically the sale order (invoice, picking...). If we do thankfully to job runner the job will be executed just after the order is created. Moreover if something goes wrong we can see it because a we have a failing job.
The bad point is that if I change the configuration of my workflow (like validating order not pay yet by check), as not job have been created before my sale order will never be validated.

Using custom filter can also be an option I see to way to implement it.

First to remind, the idea of this module is to affect a workflow (automatically) to a sale order at its creation. Then if a workflow method is affected the sale order will follow this workflow.. For now the way to affect the workflow is to use the payment method, maybe we can use a more complex rule based on filter.

So the first way is to affect the right workflow based on defined custom filter.

A second way but this will change the current behaviour and remove the workflow concept and use a "rule object concept".
For exemple on sale order we can create a rule "validated order" linked to a custom filter. if that filter match we apply the rule (using cron or automatic action)
If we want to validated the picking automatically then we will need to create an other rule "validate picking" that will be linked to an other specific filter
If we want to pay automatically an invoice we will create an other rule...

I never have think before about dropping the workflow and replacing it by a "rule object" solution. But it can be a better solution (but not sure). Also after think twice maybe we can use the job for processing the "rule object" way. Indeed if we modify an object and the final state of the object match the rule maybe we can create a job to process the next step? In case of rule modification we can search all record impacted to create job for then ? Also if an job already exist and teh rule do not match anymore we can just at the start of the job processing that the rule still apply if not then the job do nothing.

What do you think?

Regarding the payment module
Complex topic :S !
For me the current solution is not good enough, and the 9 solution is not good enough too.
First I think we have 3 types (or familly) of payment.
- CB/paypal...
- Check
- Bank transfert

For CB / Paypal
Depending of you customer need you need to register a transaction. You need this if you customer use magento and capture the payment in odoo (I did it ones for a customer) or if you have an integrated e-commerce solution and you process the payment directly in odoo (we are working on it, bye bye magento)
In this case you want to register a transaction (this is not a real payment as there is no impact in accounting yet). The transaction is just here to pilote the gateway payment of your provider.
This is partially supported in odoo 9 but the mistake is that you can not create a transaction from an invoice or a refund.

For Check
For check the process I use is to create an account move line linked to the sale order paid (using sale_payment_method) or an invoice. So I really create an account move line that go to a specific accout "check_reveice" then with the module account_check_deposit I generated an other account move when I post my check to my bank.
This is partially supported in odoo 9 as you can register a payment on an invoice but not on a sale order.


For bank transfert

For bank transfert, I process the incomming bank transfer with the bank import (like before, I just use the new bank import system). Regarding the outgoing transfers, my idea is to use the supplier payment to generate sepa file. I think pedro and alexis are working on it.



What we need
Remember odoo have introduced two concept of "payment method"
- paying a sale order with payment.acquirer https://github.com/OCA/OCB/blob/9.0/addons/payment/models/payment_acquirer.py
- paying an invoice with account.payment https://github.com/OCA/OCB/blob/9.0/addons/account/models/account_payment.py
What we need is to create a module that give an uniq interface to manage this both concept of payment method. Indeed if on a sale order or an invoice you want to pay by check you need to use an account.payment if you want to pay by cb you need to pay by payment.acquirer. I do not know yet how I will do that but I will work on it as I need it for a customer.


Thanks for your feedback

On Mon, Mar 21, 2016 at 11:53 PM, Eric Caudal <eric.caudal@elico-corp.com> wrote:

Hi Stephan,
> So you seem to agree that we should leave on the side for now the creation of the payment on the SO and have separated module if needed later on, right?

I mean the contrary. Multiple ecommerce instance might be shared in Odoo (Odoo native, ebay, amazon etc.) and you want to have consistent way of treating payments. v9 allows now to have a payment information in SO and I think this is good and we should have all connectors converging to that place.

>So I am suggesting for the main flow for the base code "SO confirmation + invoice creation + invoice validation + register payment on the invoice + SO Done"
> I agree with the option to set the SO as done but based on some filter that can be customized, such that it can be executed at other places in the workflow, e.g. just after the SO confirmation such that the SO can not be edited anymore.
Agree.

>  I would leave the invoice reconciliation with a payment as a possible extension.  
No problem with that but do not see either why not keep it all in one place.
--
Eric Caudal [Founder and CEO]
Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 (Office)
Elico Shanghai (Hong Kong/Shenzhen/Singapore) Odoo Gold Partner, best Odoo Partner 2014 for APAC
On 03/21/2016 11:38 PM, Stephan Keller wrote:
<blockquote cite="mid:CAJYazoGMLXKpxQoxtvsFDCpAEmU5vMtO6jL2_-kMVw5SVP8W-Q@mail.gmail.com" type="cite">
Eric,

I have not looked in details at the embedded ecommerce platform yet, so can not really comment.
I think we should make sure that  the connector module does not depend on a module that is build for the embedded ecommerce.
The base sale_automatic_workflow module should be usable by the connector and the embedded ecommerce.
So you seem to agree that we should leave on the side for now the creation of the payment on the SO and have separated module if needed later on, right?

So I am suggesting for the main flow for the base code "SO confirmation + invoice creation + invoice validation + register payment on the invoice + SO Done"
I agree with the option to set the SO as done but based on some filter that can be customized, such that it can be executed at other places in the workflow, e.g. just after the SO confirmation such that the SO can not be edited anymore.

I would leave the invoice reconciliation with a payment as a possible extension.  

Thanks for your feedback,
Stephan.



On Fri, Mar 18, 2016 at 8:53 PM, Eric Caudal <eric.caudal@elico-corp.com> wrote:

One of the few advantages of v9 ecommerce is actually the embedded ecommerce platform: generic models are ready and payment acquirers are set up in the SO after the checkout (which was not the case before: paying a SO was not standard). For this reason, a major refactor might be expected for sale_payment_method as by default we dont need to recreate anymore the payment methods just bind them with existing payment acquirers and SO relationship.
For this reason it would make more sense to embed the payment methods in the connector directly.
sale_automatic_workflow should be able to rely on that information to continue the workflow creation.
Another thing is we should add the possibility to set the SO as done with the new 9.0 workflow. Indeed in e-sales, upsells are not usual case and having "SO validation+invoice creation+invoice validation+invoice reconciliation+SO Done" automated might be the most common workflow for ecommerce sales.

--
Eric Caudal [Founder and CEO]
Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 (Office)
Elico Shanghai (Hong Kong/Shenzhen/Singapore) Odoo Gold Partner, best Odoo Partner 2014 for APAC
On 03/19/2016 04:37 AM, Stephan Keller wrote:
<blockquote cite="mid:CAJYazoHaF6jZz-uQtf=Mj__Qfp+CL7SmXJY6V=yboTU6fBesgA@mail.gmail.com" type="cite"> 
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.

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--
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


_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--
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

Reference