This pull request addresses several minor issues impacting the shop floor experience in Odoo Enterprise. Specifically, it corrects inaccurate quantity displays during production steps and improves filtering of workorders linked to shop floor workcenters, ensuring data consistency and a more reliable workflow. These changes enhance the accuracy of production tracking and reporting.

Collection of small shop floor fixes for v17.
Please refer to the individual feature commits for details.

This update fixes a bug where the 'past' filter on the Odoo portal's appointment section was being unintentionally removed from the URL, causing users to lose their filter settings. The fix ensures that the 'past' filter remains active and persistent across multiple pages of appointments, improving the user experience. This resolves a reported issue impacting appointment scheduling functionality.

steps:
-> populate the portal user's appointments with enough appointments to have multiple pages in the portal
-> go on the portal, filter by "past"
-> go to page 2

--> the filter by "past" is removed from the url

opw-4236596

Forward-Port-Of: odoo/enterprise#71965

This update resolves an issue where Brazilian service invoices were incorrectly generating HS codes, leading to validation errors with Avalara. Avalara support clarified that service invoices require periods to be kept but leading zeroes to be removed, a change now implemented to ensure compliance with local tax regulations.

Some cities that process service invoices [1] have stricter hsCode validations than others and error on the hsCode we send.

Avalara requires periods to be removed from the hsCode field for goods transactions. This was already the case. For services they inform us that the periods should be kept but leading zeroes should be stripped [2].

[1] e.g. Belo Horizonte
[2] There's no documentation on this. This was specified by Avalara support in an internal support ticket.

opw-4009684

This fix prevents the salary configurator from overwriting existing employee user names and identifiers (like trigrams). When an employee already has a user account set up with specific naming conventions, the system will now preserve that information instead of replacing it with values entered in the salary configurator.

Purpose
=======

If there is already a user for a given employee (including a trigram for instance), we should avoid erasing it to the value the employee encodes on the salary configurator.