[Technical] PricingRule (forms) rework

[Atala]

Context

Paul :

• simplify princing rule definition for lastmile for small coops
• do as foodtech

Existing

Current implementation (Mex) :

• it is done with symfony expressions to implement your own language. so we can create any rule.
• 1st mechanism : we go through all the rules to find the match and then we get the price
• 2nd mechanism : we sum all the matching rules to get the price
• it generates an Order (as in foodtech) but with 1 product which is the delivery
• but what we want is to have multiple items in the order so the customer can see how it was calculated

Pull request to generate products to have cleaner invoices (1 line per rule matched), technically what did mex :

• creates a product that have a human readable version of the rule. but it can be complicated to generate in the most complicated cases. what is "easy" is that we can write rules.
• you can create the text from the rules if several matches

Paul : can we allow people to add descriptions to rules ? so it can be read directly without generating text from the rule.

Mex : yes we can.

Paul : I want a simpler implementation for small coops

1st way - matrixes
you have matrixes, axis : distance, axis: package size, axis : ? and for each intersection you input a price

2nd way - you ask several questions

• fast/standard/urgent
• small/large/huge
• small distance/medium distance

and you can add "supplementals" like extra services

What to if we would like to have matrix ?
-> create a new engine to calculate price this way, because we can't build on top of the old one
-> then it is easy to calculate prices with this method. we don't really calculate prices with this method, client chose their options
-> then it is easy to create product because it is a finished number of options

Mex : what if we build a simpler form on top of the existing engine ?
-> if paul wants to go this way then we will build another engine for simpler uses cases
antoine adds that we think we can generate the "matrix pricing rules" from the matrix and that they fit in the current engine

2nd topic : generating products to have better invoice

• in the matrix case we get the products easily because they are finite number
• shall we keep the "human-readable" translation for complex cases? (the work that mex started)
  -> mex will try to show something next week
  -> Paul : OK but add a "description field" to override the generated string