Create product/variants when calculating a price for a delivery

[alexsegura]

The goal here is to improve a little bit the understanding of how the price was calculated.

Currently, when we calculate the price for a delivery, the resulting order only contains ONE item, pointing to a variant of the "On Demand Delivery" product (it is created by the setup command). This variant is named "Delivery 3km" (for example).

So, we lose track of which rules were matched, we only have the resulting price.

To improve this, we will create a variant for each matched rule, with a human readable name (depending on the rules, it may be a long name, but at least it will be understandable).

Some code needs to be refactored to implement this.

• The DeliveyManager::getPrice method will need to be deprecated, in favor of another method that implements a sort of "visitor" pattern, to return a structure with the matched rules, and the corresponding price, instead of an integer.
• Probably most of the logic should be moved into OrderFactory::createForDelivery

[Paul-Eraman-CoopCycle]

can you explain this more @alexsegura ?
@r0xsh what was your concern?

[Paul-Eraman-CoopCycle]

@Paul-Eraman-CoopCycle can you (i) explain where this information should be shown to

• clients (admin of stores)
• administrators of cooperatives
• others?

[alexsegura]

Work has been started in the pricing-rule-visitor branch

[Paul-Eraman-CoopCycle]

what would it look like to use products instead of variants?

[Paul-Eraman-CoopCycle]

We could call this:

1. Automatically converting pricing rules into human readable text feature - M
2. Let coops make descriptions of their pricing rule elements feature - M

and make 1 the backup option if the cooperative has not made a description