Tuesday, August 25, 2026
3 changes · 19.0
Enhancements to existing features
Bank journals now automatically receive the right outstanding payment accounts for Moroccan companies, and the same shared process is reused for India. This helps payments and related taxes appear correctly in reports even when bank synchronization is not available.
Original PR description
Reason: - Moroccan companies usually use cash basis accounting. And the cash basis entries are only made when the invoices are reconciled with the bank transactions. However, in Morocco, there is no…
Reason: - Moroccan companies usually use cash basis accounting. And the cash basis entries are only made when the invoices are reconciled with the bank transactions. However, in Morocco, there is no Moroccan bank available for bank synchronization. Before this commit: - We are not assigning the outstanding accounts on the bank journals by default. - Which is causing the issues when the user creates a payment without an entry and without having any bank transactions to reconcile it with. Therefore, the tax report won't show the moves and taxes that occurred in the period. After this commit: - Introduced a method for updating the accounts on the payment method lines of the bank journal in the account module, as we need the same functionalities in l10n_in as well. - For Moroccan localization, from now on, we are setting the outstanding accounts automatically on the bank journals. - The payment accounts are applied by default during CoA loading and whenever payment method lines are recomputed, ensuring accounts remain consistent. Task-6041119
Belgian point-of-sale blackbox connection and signing errors are now recorded in the system logs instead of only appearing in the cashier's browser console. This helps support teams diagnose client issues faster, with relevant error context kept temporarily and cleaned up after 30 days.
Original PR description
The FDM is only reachable from the browser, so an error occurring during a signature left no trace in the backend: diagnosing a blackbox issue on a client database meant asking the cashier for their console logs. Errors caught while signing or pinging the FDM are now stored as `ir.logging` entries, holding the whole context of the error, the data sent to the FDM and its answer. Logging is asynchronous and entries are dropped after 30 days when a session is closed Screenshots: <img width="1913" height="235" alt="image" src="https://github.com/user-attachments/assets/f82ad82e-0356-4f31-9d76-e80ac5ed389e" />
AI agents can now automatically move from outdated language models to the latest approved model based on their selected response style. This keeps AI features working reliably as providers retire older models, while giving users clearer visibility when an automatic or deprecated model is being used.
Original PR description
To ease the process of llm model deprecation, 2 new mappings are introduced: - A mapping from legacy model name (e.g. gpt-3.5-turbo) to a config (e.g. snappy and creative). - A mapping from the `config` the latest model (e.g. gpt-5.4-mini). - Deprecating an llm model is now as simple as changing the latest model value in the mapping from a config to a model. - The value of the latest model isn't selectable from the agent form view and so won't be stored in the DB. Thus, the mapping from legacy model name to config doesn't need to change. task-6004597