Tuesday, April 30, 2024
26 changes · 17.0
Enhancements to existing features
When warehouse staff exit a barcode picking before completing it, the system now automatically splits incomplete items to preserve what was already picked versus what still needs to be picked. This prevents confusion about remaining quantities and ensures accurate inventory tracking for both picking operations and manufacturing orders.
Original PR description
Backport of odoo/enterprise#59212 [OPW-3797344](https://www.odoo.com/web#id=3797344&cids=1&menu_id=4720&action=333&active_id=966&model=project.task&view_type=form) Original commit message:…
Backport of odoo/enterprise#59212 [OPW-3797344](https://www.odoo.com/web#id=3797344&cids=1&menu_id=4720&action=333&active_id=966&model=project.task&view_type=form) Original commit message: ======================== When the user quits a unfinished picking, the reservation on the move lines are lost. To avoid that, uncompleted moves will be split in such case. For example: - Assume we have a move of 0/15; - The user picks 4 qty (4/15) then exit the picking: => Before this commit, we're left with only one `stock.move.line` with 4 qty and already picked (not knowing what its reservation was since this information is on the `stock.move` and not on the `stock.move.line`.) => After this commit, the line's move will be split and we'll be left with two `stock.move` and thus `stock.move.line`: - One with 4 qty, already picked (4/4); - One with 11 qty, waiting to be picked (0/11); So, the user will always know what the remaining qty they still have to pick. Same is true for manufacturing orders since they use `stock.move` and `stock.move.line` too. task-3821067
This update moves currency rate requests for Banxico (Mexican bank) to Odoo's cloud infrastructure, where daily currency rates are now cached. This improves system performance by reducing repeated requests and ensures more reliable currency data updates for businesses operating in Mexico.
Original PR description
This commit moves the call for the Banxico currency update to the IAP server, where we can create a daily cache of currency rates. Part of: task-3749574 Forward-Port-Of: odoo/enterprise#61595 Forward-Port-Of: odoo/enterprise#58685
This update enhances the Bulgarian tax report by adding missing sections D and E, which are required for complete tax reporting compliance. Additionally, line 43 has been modified to allow direct editing instead of automatic calculation, giving users more flexibility in tax report preparation.
Original PR description
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. Forward-Port-Of: odoo/enterprise#61557 Forward-Port-Of: odoo/enterprise#57367
This update removes extra padding from the website header on mobile devices, ensuring it aligns properly with the page content. Previously, the mobile header had unnecessary spacing that made it misaligned compared to the desktop view and the content below it. This improvement creates a more polished and consistent user experience across all devices.
Original PR description
Description of the issue/feature this PR addresses: In the mobile view, the header has extra padding, for this reason it is not perfectly aligned with the content of the page. Current behavior before PR: The header is not aligned with the content | Desktop | Mobile | |--------|--------| |  |  | Desired behavior after PR is merged: The header is aligned with the content like desktop view https://github.com/odoo/odoo/assets/35231827/32fbe3f1-3ba8-443f-856d-26b03a0cbe13 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customer invoices now display both the payment reference and the company's bank account (IBAN) information. This improvement provides customers with complete payment details in one place, making it easier for them to process payments accurately without needing to look up banking information separately.
Original PR description
On a customer invoice, the sentence "Please use the following communication for your payment : +++000/0000/10205+++" was changed to "Please use the following communication for your payment : +++000/0000/10205+++ on this account : BE81 3101 2528 8724" Customer invoices only had payment reference. Bank account (iban) was also needed on the invoice. task-3794432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163912 Forward-Port-Of: odoo/odoo#157503
Odoo has updated its JavaScript language support to ES2022, which requires Node.js version 16.11 or higher. This change makes that requirement explicit in the development tooling configuration, preventing developers from encountering confusing errors when using outdated Node.js versions.
Original PR description
Starting with Odoo 16.1, the ECMAScript version supported by Odoo has been bumped to ES2022, but support for all ES2022 features has only been achieved with Node.js 16.11*, making it the minimum required version to run Odoo. This commit updates the package.json to make this requirement explicit, preventing from using the tooling with an outdated version of Node.js, which would otherwise result in an unclear syntax error. *: From all the features added in ES2022, support for static initialization blocks is the latest to have been added, in Node.js 16.11, according to MDN's compatibility data. Forward-Port-Of: odoo/odoo#163787
This update enhances the Bulgarian tax report by adding two missing sections (D and E) that were previously unavailable. Additionally, a specific line item has been changed to allow direct editing instead of automatic calculation, giving users more flexibility in reporting their tax information.
Original PR description
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. task-3672445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161658 Forward-Port-Of: odoo/odoo#155223
Resolved issues and error corrections
This fix ensures that when creating a new invoice, the payment method automatically inherits from the customer's configured payment method instead of defaulting to "Por definir" (undefined). This improves workflow efficiency by eliminating the need to manually set the payment method for each invoice when the customer already has a preferred payment method configured.
Original PR description
- When creating a new invoice the payment method is "Por definir" by default, so it is necessary to check the l10n_mx_edi_payment_method_id of the customer used in the invoice before checking the…
- When creating a new invoice the payment method is "Por definir" by default, so it is necessary to check the l10n_mx_edi_payment_method_id of the customer used in the invoice before checking the l10n_mx_edi_payment_method_id of the invoice and replacing it if the customer has this value assigned or use the corresponding payment method. Description of the issue/feature this PR addresses: 1. Configure the Payment way and the Usage in the partner.  2. Create a new invoice and select the partner configured in number 1.  The payment way doesn't change, it is "Por definir" by default. Desired behavior after PR is merged: After this is merged the invoice payment method will be the same as assigned in the partner. 
A previous update incorrectly applied line grouping to all intrastat reports. This fix restricts the grouping feature to Belgian intrastat reports only, where it's needed. Users can now control this grouping behavior through report filters, with the setting defaulting to off for most countries and on for Belgium.
Original PR description
In this commit [1], we changed the way we display intrastat report lines by grouping them. We did it for all the intrastat report, it was wrong. Actually, we should only do it for the belgian report. The aim of this commit is adding a key in options to know if lines should be grouped or not. By default the option is set to False except for the Belgian report. Since version 16.4, users can change the value by using the filter. task-3892823 [1]: https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde Forward-Port-Of: odoo/enterprise#61455
Fixed an issue where the sign template editing popover would remain open even after clicking away or leaving the app. The fix ensures the popover closes appropriately when clicking outside of it, while still staying open when you're actively working with role settings in a modal dialog.
Original PR description
Before this commit: when editing a sign template and opening the sign item popover, it remained open when clicking away even when leaving the sign app. This commit addresses this issue by refining the `closeOnClickAway` to close the popover only if the click is not within an active modal, ensuring that the popover stays open when the role modal is displayed. Task: 3861496 _______________________________________________________________ Bug was introduced in this PR: https://github.com/odoo/enterprise/pull/49900 in attempt to keep the popover open when updating the sign item role. Forward-Port-Of: odoo/enterprise#60613
This fix resolves an issue where unit prices would revert to default values when editing purchase orders on mobile devices. The problem occurred because a required discount field was missing from the mobile view, causing the system to recalculate prices incorrectly. The fix adds the discount field to the mobile view and displays it when applicable, ensuring price changes persist correctly.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have `purchase` and `sale_timesheet` installed; 2. go to purchase; 3. make browser window narrow enough to trigger mobile view; 4. create an RFQ; 5. add…
Versions -------- - 17.0+ Steps ----- 1. Have `purchase` and `sale_timesheet` installed; 2. go to purchase; 3. make browser window narrow enough to trigger mobile view; 4. create an RFQ; 5. add product; 6. change the unit price. Issue ----- The unit price changes back to default. Cause ----- When changing the `price_unit` field, the `_compute_amount` method gets triggered, which depends on the `discount` field. As this field wasn't present in the mobile view, its compute method was called, which is the same method that computes `price_unit`. Normally this method skips recomputing `price_unit` if it was modified, but because `sale_timesheet` makes `uom.group_user` an implied ID of `base.group_user`, it can now access the `product_uom` field, and assumes a change from `_origin` as there is no `_orgin.product_uom` to compare it to if the PO hasn't been saved yet. Solution -------- Add the `discount` field to the mobile kanban view. Also display the discount on mobile if its value is non-zero. opw-3767765
This fix resolves an error that occurred when saving a product with a project property in the HR Timesheet module. The issue happened because the system was not properly handling cases where context information was missing during the save process. Users can now successfully create and save products with project properties without encountering errors.
Original PR description
**Steps** - Install hr_timesheet. - Create a new product. - Add a property to the product, type many2one, model Project. - Chose any project. - Save the product. ** Traceback error ** **Issue** When the product is saved, the product.template model is flushed and the context keys are all set to None. https://github.com/odoo/odoo/blob/3c7db87ade7e99eafb44228bd038fa39429fdabc/odoo/models.py#L6352 Which causes a problem when computing the display_name of project.project **Fix** Handle the case where context=None. opw-3885370
Fixed an issue preventing customers from paying with Razorpay wallet in India. The payment system now allows customers to select their preferred payment method from all available options when using wallet, ensuring transactions are properly recorded in the system. This resolves errors that occurred when attempting wallet payments.
Original PR description
Steps: - Install and configure Razorpay provider. - Install sales app. - Enable wallet india PM. - Create quote and try to pay it via wallet india. Issue: - User error when trying to pay via wallet…
Steps: - Install and configure Razorpay provider. - Install sales app. - Enable wallet india PM. - Create quote and try to pay it via wallet india. Issue: - User error when trying to pay via wallet india. Cause: - `orders` API does not take `wallet_india` as method key of payload also I tried other like `wallet` and `wallets` but they are not also working even though Razorpay response with method `wallet` when we pay via wallets so `wallet` is right value but `orders` API does not count it as one. Fix: - Do not pass any method in payload when user select `wallet` and open Razorpay form with all PM so user can pay via whichever method they want and if selected method exist in the odoo then set that PM to transaction. For master: - Add `Pay later` payment method so we can store all transaction with proper payment method in odoo. - Change code of wallet PM from `wallets_india` to `wallet` so when razorpay fix code issue it'll work automatically without any issues and we don't need to pass mapping to get proper PM via `_get_from_code`. opw-3867594
This fix resolves an error that occurred when users tried to add Spanish electronic invoicing certificates to their company settings. Previously, the system would crash with an error when attempting to save certificate information. The fix enables proper handling of Spanish certificates for electronic invoicing compliance.
Original PR description
Description of the issue/feature this PR addresses: Using an spanish certificate in res.company (field -> l10n_es_edi_facturae_certificate_id) returns error none field. Current behavior before PR:…
Description of the issue/feature this PR addresses: Using an spanish certificate in res.company (field -> l10n_es_edi_facturae_certificate_id) returns error none field.
Current behavior before PR: When trying to save the changes you get the error:
`RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1765, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1792, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1996, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/17.0/addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/home/odoo/src/odoo/17.0/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/addons/web/models/models.py", line 73, in web_save
self = self.create(vals)
File "<decorator-gen-364>", line 2, in create
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 414, in _model_create_multi
return create(self, [arg])
File "/home/odoo/src/odoo/17.0/addons/l10n_es_edi_facturae/models/l10n_es_edi_facturae_certificate.py", line 54, in create
if fields.datetime.now() > certif.not_valid_after:
AttributeError: 'NoneType' object has no attribute 'not_valid_after'`
Desired behavior after PR is merged: Save the certificate.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix corrects an issue where refunded invoices were incorrectly being added to the total amount when re-invoicing a sales order. Previously, when a credit note was created for a partial invoice and the remaining amount was re-invoiced, the down payment amount was being added instead of subtracted, resulting in incorrect invoice totals. This fix ensures refunded invoices are properly excluded from calculations.
Original PR description
Steps to reproduce: 1) Create a quotation and confirm it 2) Invoice a first down payment (fixed amount) and validate it 3) Invoice the rest of the SO amount and validate it 4) Create a credit note for the last invoice created (at step 3)) 5) From the SO, re-invoice the rest of the SO amount Issue: the amount of the downpayment is added to the total, not subtracted opw-3817440 Forward-Port-Of: odoo/odoo#161350
This fix resolves an issue where users were incorrectly redirected to an error page when saving SEO optimization settings on course pages. The update ensures users remain on the same course page after saving, improving the user experience and preventing confusing navigation errors.
Original PR description
**Description of the issue/feature this PR addresses:** This PR address the issue of redirecting to courses page with /invite_error when trying to update the optimize seo. **Current behavior before PR:** Previously, when editing Optimize SEO and clicking "Save," it redirected to /invite_error in Courses instead of remaining on the same URL after saving, which was caused due to not receiving seoName. **Desired behavior after PR is merged:** Now after saving, we stay on the same course URL without being redirected to /invite_error. This fix includes checking if the seoContext doesn't have a seoName , in which case we redirect to seoNameDefault to prevent redirection to /invite_error on the Courses page. **Task**-3688285 Forward-Port-Of: odoo/odoo#161029
This fix resolves an issue where table row and column editing controls were not displaying properly in the To-Do application. The controls were being hidden due to overflow restrictions. The fix adjusts the padding in the editor area to ensure these controls are fully visible when users hover over table cells, improving the table editing experience.
Original PR description
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to…
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to reproduce the issue: ============================= - Go to to-do - add a table on top the editable - Hover on the top left cell - The row and col ui boxes doesn't show correctl Origin of the issue: ==================== Since we forced the mentioned commit that `overflow-x` should be hidden, then the ui elements which overflows the visible area of the html field will be hdden too that's why only a small part of them appear. Solution: ========= To conserve the same ui and not add extra padding , we add padding to the `note-editable` to make it possible to display the ui elements fully (needs 16px) and decrease the padding of the padding of the formView sheet. Before: ======  After: =====  task-3861784 Forward-Port-Of: odoo/odoo#162029
This fix resolves an issue where newly created contacts were not showing their assigned pricelist information until after saving and reopening the record. The problem was particularly noticeable in version 17.0 where the system creates and reads records in a single operation. The fix ensures pricelist data displays correctly immediately when creating a new contact.
Original PR description
To reproduce the problem: - Enable pricelist feature - Create a new Contact > no pricelist shown (all versions affected) - Save > still no pricelist shown (>= 17.0 versions affected) - Exit and go back to the Contact: the pricelist is set The _compute_product_pricelist() doesn't work properly for new record, then we create a new contact, pricelist is empty (until the save for version < 17.0, until save/exit/return on the record for version >= 17.0). In 17.0, we introduced web_save, which makes create() and read() in the same request. This is why the version >= 17.0 is more problematic and more confusing for the user. Prior to 17.0, it was not great either, but was never considered a bug (some effort has been made in https://github.com/odoo/odoo/pull/153326/files). So this fix targets versions >= 17.0. Fix the issue by taking care of new ids in the _get_partner_pricelist_multi() method. Also, add a Form test case for every possible case. opw-3872299
This fix resolves an issue where calendar reminders were being duplicated for recurring daily events. The system was incorrectly creating multiple reminder notifications for the same event due to a logic error in how it determined when the next reminder should be sent. Users will now receive only one reminder per event occurrence instead of duplicate notifications.
Original PR description
Before this commit, alarms were always being set up when there was no 'next_date' specified, creating an undeterministic behavior since inside the 'get_next_alarm_date' function we check if the 'call_at' attribute from the trigger happens before 'now'. If this condition is false, i.e. if there is already an alarm set up for the future, we were returning a falsy value for the next alarm date and setting up the alarm anyway (using the current date inside '_setup_alarms', since the context was None), thus generating a new alarm with the wrong call date. After this commit, we make an extra check for recurrences in the 'get_next_alarm_date' function in order to get the correct next date for the next alarm from the next recurrent event. Additionally, if there is no next date to be called in the in the future, we skip the 'send_reminder' function which was wrongly creating another alarm using 'now' as time. Issue-from: odoo/odoo#147914 Forward-Port-Of: odoo/odoo#161941
This update corrects how rounding precision is applied in the manufacturing and inventory management systems. The system was using incorrect parameters when calculating rounded values, which could have led to inaccurate quantity calculations in bills of materials and stock movements. This fix ensures rounding is applied correctly across these critical business processes.
Original PR description
Versions -------- - 16.0+ Issue ----- `precision_rounding` values were being passed incorrectly as `precision_digits` parameters. Solution -------- Pass them as named `precision_rounding` parameters instead. Forward-Port-Of: odoo/odoo#163154
This fix resolves an issue where extra down-payment invoice lines with zero price were being automatically created when taxes were removed from the initial down-payment invoice. The solution improves the down-payment calculation logic to properly exclude down-payment lines and only consider actual sales order product lines, preventing duplicate entries in subsequent down-payment invoices.
Original PR description
… when remove the tax on first downpayment invoice Issue: ====== Extra down-payment line is creating Steps to reproduce the issue: ============================= - create an SO, then create…
… when remove the tax on first downpayment invoice
Issue:
======
Extra down-payment line is creating
Steps to reproduce the issue:
=============================
- create an SO, then create downpayment with 30% percent, remove the tax in generated INV and post the invoice.
- go back to SO create another downpayment with 30%
Solution:
=========
Typically, when calculating the value of down-payment lines,
we only consider sales order lines for products, not down-payment lines.
This is because, according to the Odoo workflow, down-payment lines are
created based on product lines in the sales order, not on down-payment
lines themselves. Therefore, I am filtering out those lines here.
closes odoo/odoo#163699
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves an issue where extra down-payment invoice lines with zero price were being automatically created when removing taxes from the first down-payment invoice. The solution ensures that down-payment calculations only consider actual sales order product lines, not previously created down-payment lines, preventing duplicate entries from being generated.
Original PR description
…erated when remove the tax on first downpayment invoice Issue: ====== Extra down-payment line is creating Steps to reproduce the issue: ============================= - create an SO, then create…
…erated when remove the tax on first downpayment invoice
Issue:
======
Extra down-payment line is creating
Steps to reproduce the issue:
=============================
- create an SO, then create downpayment with 30% percent, remove the tax in generated INV and post the invoice.
- go back to SO create another downpayment with 30%
Solution:
=========
Typically, when calculating the value of down-payment lines,
we only consider sales order lines for products, not down-payment lines.
This is because, according to the Odoo workflow, down-payment lines are
created based on product lines in the sales order, not on down-payment lines themselves.
Therefore, I am filtering out those lines here.
closes odoo/odoo#163699
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Kitchen Display app was causing testing failures when its conditional menu interacted with other applications, resulting in log errors and system failures. This fix skips the problematic menu during testing to prevent these cascading failures and improve system stability.
Original PR description
The Kitchen Display app uses a conditional menu that can leads to the frontend. In some situation, other apps are tested again during the Kitchen Display test leading to a mess in the logs and a epic failure. As no viable solution was found, the menu is now skippep with this commit.
The portal's mobile navigation menu was extending beyond the navbar boundaries on mobile devices, which could cause unwanted horizontal scrollbars in certain configurations. This fix removes an unnecessary negative margin that was causing the overflow, improving the mobile user experience and preventing layout issues.
Original PR description
The portal mobile navbar menu was overflowing its parent (the navbar) on the left and right once opened. This is because of a combination of commits [1] and [2]. Indeed, [1] added a negative margin…
The portal mobile navbar menu was overflowing its parent (the navbar) on the left and right once opened. This is because of a combination of commits [1] and [2]. Indeed, [1] added a negative margin on that menu to compensate the parent navbar's padding. However, [2] later forced that parent padding to 0 with a class. This commit removes the negative margin compensation to fix the issue. Note: the design may not seem that broken without this fix. But in custo it could look very bad as it could introduce a horizontal scrollbar: just make the portal layout use a fluid container and have `$navbar-padding-x` be higher than `$grid-gutter-width`. Also, note that the design is not perfect as the inner padding of that menu also relies on the navbar padding value... which is ok in Odoo but only because we change the default of Bootstrap, which is 0. It was chosen to ignore that problem in stable. In master, the navbar padding will be left back to the BS default (0) and another spacing value will thus be used for the portal menu. [1]: https://github.com/odoo/odoo/commit/f8940943592b696b4f27c0013f837a6cdecb0433 [2]: https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8 Related to https://github.com/odoo/odoo/pull/163996 | Before | After | | -------- | -------- | |  |  |
This update modernizes how Odoo handles Python code analysis to align with Python 3.12+ standards. The changes remove deprecated code patterns that will stop working in Python 3.14, ensuring the system continues to function properly as Python evolves. This is a maintenance fix that keeps Odoo compatible with current and future Python versions.
Original PR description
Since 3.8, some ast object and parameters changed, with backward compatibility. They are now deprecate in 3.12 and will be removed in 3.14. Keeping a compatibility between both solutions is possible but hard to do with python > 3.7, the solution was to mute the warning in odoo 15.0 since it is unlikely to make it compatible with python 3.14, but we can fix it a cleaner way in 16.0 since the minimal python version is higher than 3.8. see #162438 for 15.0 suppress warning fix part of #162438 , adaptations for ubuntu noble Forward-Port-Of: odoo/odoo#163487
This fix resolves a system error that occurred when creating sales orders with products from different company branches. The issue was in how the system validated company access, and this update corrects the validation logic to check companies individually rather than as a group, allowing sales orders with mixed-company products to save successfully.
Original PR description
Issue: A traceback error is raised when a sales order is saved with products with varying company ids. Was trying to lookup a list of ids rather than a singular id which triggered the traceback. Purpose of this PR: To check accessible company branches on a individual company rather than a recordset of companies. Steps to Reproduce on Runbot: 1) Create branch of main company. 2) Create products one with company id of the branch and the other of company id in the main company. 3) Create sale order, order lines with each of the products. 4) On save, a traceback error is raised. Notes: opw-3810770 Forward-Port-Of: odoo/odoo#162547