Re: connector_ecommerce dependency in v9

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.

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.

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.