Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: connector_ecommerce dependency in v9
by
Sodexis, Stephane Keller
Hello All,
We started the work on porting Sale_automatic_workflow to v9. We will create a PR as soon as possible.
@Sebastien I like the idea of using jobs to run, but I think it will take more time to develop and I don't want to delay more, so we will go ahead with the way it is done in automatic_workflow_job.py.
We looked at using the automated action to take care of the workflow. That is similar to the “rule object concept” suggested by Sebastien. I think it would require an extension with a “When to Run” just based on a filter. That is not too bad, but then also all the workflows would have to use the same automated actions and so the same filters. We think that it is better to add the filters on the workflow. This way we can define specific filters for each workflow and that is much more flexible. Furthermore we can impose the workflow condition (e.g. “Validate Sales Order” is true) in the code instead of in the automated action filter, which might create issue when user try to modify the filter.
“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”. Sometimes we will need to trigger an action based on a calculated field like the Invoice Status on the Sales Order, so that will not work that well in that case. So the filter is the way to go I think.
Action that can be automated with the module:
· SO confirmation
· invoice creation and validation (one step or do we need 2?). The system should be able to create multiple invoices as items are being added to the SO.
· Register payment on the invoice: same way that it is done in Odoo base code (account.payment). As discussed before in my opinion that is what is mainly needed for the connector-ecommerce module.
· SO Done
· Validate picking (if products are available). I don’t see a need for that, does anybody use that? We can keep it not a big deal.
Each action will have its own filter. This can be extended of course to allow for the creation of a payment directly from SO if needed (using payment.acquirer or something else).
We don’t plan to port Sale_payment_method to v9. We will need the payment method object to define the fields needed when the payment is registered from the invoice. I think it make sense to define it in Sale_automatic_workflow, unless somebody object to that. We could also defined it in its own module.
We started the work on porting Sale_automatic_workflow to v9. We will create a PR as soon as possible.
@Sebastien I like the idea of using jobs to run, but I think it will take more time to develop and I don't want to delay more, so we will go ahead with the way it is done in automatic_workflow_job.py.
We looked at using the automated action to take care of the workflow. That is similar to the “rule object concept” suggested by Sebastien. I think it would require an extension with a “When to Run” just based on a filter. That is not too bad, but then also all the workflows would have to use the same automated actions and so the same filters. We think that it is better to add the filters on the workflow. This way we can define specific filters for each workflow and that is much more flexible. Furthermore we can impose the workflow condition (e.g. “Validate Sales Order” is true) in the code instead of in the automated action filter, which might create issue when user try to modify the filter.
“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”. Sometimes we will need to trigger an action based on a calculated field like the Invoice Status on the Sales Order, so that will not work that well in that case. So the filter is the way to go I think.
Action that can be automated with the module:
· SO confirmation
· invoice creation and validation (one step or do we need 2?). The system should be able to create multiple invoices as items are being added to the SO.
· Register payment on the invoice: same way that it is done in Odoo base code (account.payment). As discussed before in my opinion that is what is mainly needed for the connector-ecommerce module.
· SO Done
· Validate picking (if products are available). I don’t see a need for that, does anybody use that? We can keep it not a big deal.
Each action will have its own filter. This can be extended of course to allow for the creation of a payment directly from SO if needed (using payment.acquirer or something else).
We don’t plan to port Sale_payment_method to v9. We will need the payment method object to define the fields needed when the payment is registered from the invoice. I think it make sense to define it in Sale_automatic_workflow, unless somebody object to that. We could also defined it in its own module.
I agree with the need of a transaction for Paypal/CB.
We do the same with checks but only via the invoice and our own deposit module (modifed from a community module). We always need an invoice for the accounting.
Thanks,
Stephan.
On Wed, Apr 13, 2016 at 9:29 AM, Stephan Keller <skeller@sodexis.com> wrote:
Guewen,
Sorry could not work on this the last two weeks. The plan is to finalise the specs this week and start the work next week. Ok or you need this faster?
Thanks for your feedback.
Stephan
On Apr 12, 2016 3:38 AM, "Guewen Baconnier" <guewen.baconnier@camptocamp.com> wrote:Stephan, Atchuthan,I favor this proposition which does not preclude more advanced solutions as envisioned by Sébastien, but as you say that could be done in separate modules not required by connector-ecommerce.
Could you start to work on that or is the migration path still too hazy?
If you could, which decision did you finally took for workflows and payments? Is there a branch to review already?
I really the following proposition, I quote you Stephan: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.Regards,Guewen_______________________________________________
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
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
-
connector_ecommerce dependency in v9
byatchuthantu- 17/03/2016 16:33:31 - 1-
-
-
-
-
-
Re: connector_ecommerce dependency in v9
byAkretion France., Sébastien Beau- 02/05/2016 15:28:03 - 0 -
-
-
-
-
