Issue
----

When work orders are computed, the compute function may delete some of the previous work orders. However,
it doesn't take into account these deleted work orders when choosing whether to update or create a work order.
So it ends up issuing an update command after a delete command for the same order. This happens during splitting
and causes work orders to disappear.

Steps
-----

 - Open Manufacturing -> Create a storable product and a BoM for this product.
 - Create a product as part of the BoM.
 - For the latter product, create another BoM that is a kit.
 - Create an operation in the BoM of the kit.
 - Create a manufacturing order for the storable product (first created product).
 - Set a quantity larger than 1, say 10, and manually save the MO (without confirming it).
 - Split the MO into same quantity (e.g. 10), and after confirming the split the following traceback is triggered:

 `remaining_qty = initial_workorder_remaining_qty[index % workorders_len]
ZeroDivisionError: integer division or modulo by zero`

opw-3994583

**Steps to reproduce:**
	1- Install POS and POS restaurant
	2- Activate self ordering
	3- Create a self order from the mobile menu
	4- Create another order from the Shop POS

**Current behavior before PR:**
There is a conflict happening in order numbers between Self order and other orders where at some point we might have two orders with the same number. This is happening because when adding the order from Shop we get the sequence number from the JS side in Order class
https://github.com/odoo/odoo/blob/d82ffde0b316c52f726c247bf6f3d38e2e73e405/addons/point_of_sale/static/src/app/store/models.js#L1383 but in case of self order. We get it from ir_sequence https://github.com/odoo/odoo/blob/d82ffde0b316c52f726c247bf6f3d38e2e73e405/addons/pos_self_order/controllers/orders.py#L19 So we don't have a shared sequence between them.

**Desired behavior after PR is merged:**
We are now creating another sequence for self-order and as agreed with the PO we will have
'S' before the order number if the order is self-order

opw-3809595

**Current behavior:**
Having some product with FIFO cost method, if you use it as a
component in an MO, confirm and produce all, then unlock the MO
and adjust the component quantity to be smaller than originally
entered, the standard price of the product will be set to zero.

**Expected behavior:**
This operation should not affect the standard price of the
product.

**Steps to reproduce:**
1. Create a product with FIFO cost method and real time
     valuation

2. Create a purchase order for 10 of the fifo product, set the
     price unit on the order line to 100

3. Confirm the order and receive the product

4. Create a manufacturing order for 1 of some other product, and
     set the components to be 100 of the fifo product

5. Confirm the MO, consume the fifo product and produce all

6. Unlock the order and set the quantity of components consumed
     to 1 (from 100)

7. Observe that the standard price of fifo product is now 0

**Cause of the issue:**
A move for an MrpProduction record has a price unit == 0. Commit
https://github.com/odoo/odoo/commit/1fb4d356b5115a82dbbb004efe2e26917021b339 forces use of this when a move's picking type is
manufacturing, however it should be a narrower condition to only
do so when the move corresponds to the finished moves of a
manufacturing order.

**Fix:**
Moves for components of a production should not be able to
modify the `standard_price` of the moved product- only the final
product's cost should be able to change based on the value of
such a move.

Use a product's `standard_price` field when creating SVLs for
moves corresponding to raw production moves.

opw-4134037

Currently, an exception is generated when the user tries to open the "Cash Flow Statement" report.

Steps to produce an error:
- install 'Accounting Reports'
- Open Accounting > Configuration > Accounting > Journals
- Now delete all journals except "Miscellaneous Operations"
- change type of "Miscellaneous Operations" to sales > sale
- Click Reporting > click "Cash Flow Statement"  >>> exception occurs

Stack Trace:
```
SyntaxError: syntax error at or near ")"
LINE 28: ...            AND account_move_line.account_id NOT IN ((), ())
                                                                  ^

  File "odoo/http.py", line 2373, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1903, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1966, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1933, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2177, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 35, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 459, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 4872, in get_report_information
    'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
  File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 2275, in _get_lines
    dynamic_lines = self._get_dynamic_lines(options, all_column_groups_expression_totals, warnings=warnings)
  File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 2705, in _get_dynamic_lines
    rslt = self.env[self.custom_handler_model_name]._dynamic_lines_generator(self, options, all_column_groups_expression_totals, warnings=warnings)
  File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_cash_flow_report.py", line 16, in _dynamic_lines_generator
    report_data = self._get_report_data(report, options, layout_data)
  File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_cash_flow_report.py", line 57, in _get_report_data
    for aml_groupby_account in self._get_liquidity_moves(report, options, currency_table_query, payment_account_ids, cashflow_tag_ids):
  File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_cash_flow_report.py", line 365, in _get_liquidity_moves
    self._cr.execute(SQL(' UNION ALL ').join(queries))
  File "odoo/sql_db.py", line 347, in execute
    res = self._obj.execute(query, params)
```

This is because at the time of query building for getting liquidity moves, it gets an empty tuple from line [1] as we do not have any journals with the type 'bank', 'cash', or 'general'.

This commit will fix the above issue by returning empty report_data when payment_account_ids is empty.

[1] - https://github.com/odoo/enterprise/blob/8fa01948610809d191b75260772782e25ea3a737/account_reports/models/account_cash_flow_report.py#L195

sentry-5555757610