[FIX][IMP] l10n_bo: Refactor chart of accounts and tax setup for Bolivia #196344
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We update quote detection for gmail and outlook: - gmail has simple wrapper divs with explicit classes - outlook has a mix of div ids and simple pattern-based quoting (everything under "<hr><div id="divRplyFwdMsg"/> seems to be considered a quote) Previously gmail just used blockquote, which still works but does not capture "On xx:xx:xx X <X@gmail.com> wrote:" headers, which are caught for outlook. Previously outlook had a wrapper div around divRplyFwdMsg which would set data-o-mail-quote-container on it, and propagate to children. However it seems that outer div was either removed or is not always present, a heuristic is thus needed. task-4381505 X-original-commit: 34f19e4 Part-of: odoo#194722 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Blank spaces following a quoted node should also be quoted. This avoids having long trailing spaces below a signature and having unquoted blank spaces between two quoted blocks task-4381505 X-original-commit: 118b1a2 Part-of: odoo#194722 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Since html_normalize is now run multiple times on the same body in mail it has become apparent that the heuristics for tag_quote are not suited to multiple passes on the same body. tag_quote is used to detect and tag nodes in a document that are likely mail signatures. So that they may be hidden in the front-end. The detection of the signature using the "-- <br>" sets the parent of the element where is is detected to be a "quote container". However a quote container will set all of its children to be quotes too. If the signature is in the main div of the email, as is the case in most templates this means the whole content is marked as being inside a "quote container". Because the processing of the elements is done in order of their appearance in the document, this does not lead to the entire document becoming a quote the first time html_normalize is called. As the signature is typically the last element, the "container" attribute is only set after the whole body was already processed. However if the body is normalized again, the main div is now marked as a "quote container" and the whole body becomes a quote. - `<div><p>body</p><div>--<br>John</div></div>` - `<div quote-container><p>body</p><div quote>--<br quote>John</div></div>` - `<div quote-container><p quote>body</p><div quote>--<br quote>John</div></div>` We now check whether a quoted sibling exists in the container before marking a node as "quote". All nodes following the original quote and their children will be quoted as before, all nodes before will not be quoted anymore. triggered by 2473193 task-4381505 Part-of: odoo#194722 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
The "read more" button a block display instead of the default inline display. This is clearly intended from the d-block class however as messages are inside shadow divs, bootstrap has no effect. Simply set the style attribute directly. task-4381505 Part-of: odoo#194722 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
We update quote detection for gmail and outlook: - gmail has simple wrapper divs with explicit classes - outlook has a mix of div ids and simple pattern-based quoting (everything under "<hr><div id="divRplyFwdMsg"/> seems to be considered a quote) Previously gmail just used blockquote, which still works but does not capture "On xx:xx:xx X <X@gmail.com> wrote:" headers, which are caught for outlook. Previously outlook had a wrapper div around divRplyFwdMsg which would set data-o-mail-quote-container on it, and propagate to children. However it seems that outer div was either removed or is not always present, a heuristic is thus needed. task-4381505 closes odoo#194722 Forward-port-of: odoo#194615 Forward-port-of: odoo#192875 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Before this commit: =================== - The purchase tour was failing because the tour's JavaScript used an incorrect class selector (targeting 'partner_id'), which prevented it from locating the intended DOM element. Consequently, the sequence of actions was interrupted, causing the tour to break midway. After this commit: =================== - The issue has been resolved by updating the tour to use the correct and unique class selector. This ensures the tour accurately targets the intended element, allowing it to proceed without interruptions. As a result, the purchase tour runs successfully and achieves its intended purpose. closes odoo#194780 Taskid: 4268662 X-original-commit: 81ebde1 Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com> Signed-off-by: Dhaval Hadiya (dhha) <dhha@odoo.com>
Before this commit, when a user accesses a sub-thread of channel made from a message for the 1st time, the format of the message body shows html as textcontent rather as inner html. Steps to reproduce: - Post a message as user A - Create a thread from this message as user B - User A accesses this sub-thread and posts a new message -> User A sees 1st message with bad formatting This happens because on sub-thread join, the data of sub-thread info are fetched, and since the sub-thread is created from a message, the channel info data also contains the message data. This data was inserted without `html: true`, leading to message body being inserted in a non-trusted way in JS models, causing this formatting issue. This commit fixes the issue by flagging the insert with `html: true`, as this is from trusted origin and content is trusted, so the message body is inserted to be used properly in message component. Note that this behaviour applies to html fields, which message body is. The insert `html: true` is assessed for data on all targeted html fields. task-4506489 closes odoo#194732 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In the Tasks' and Tasks Analysis' chart and pivot views, some default measures were not translatable after [this commit]. The [previous fix] only solved one case. We make them translatable again here so they can be localized. [this commit]: odoo@e82567f [previous fix]: odoo@e7381c3 opw-4421055 closes odoo#193609 X-original-commit: a7dafb5 Signed-off-by: Vincent Larcin (vila) <vila@odoo.com> Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
This commit add few data on the report_invoice for Mauritius localization. task-4379202 closes odoo#194590 X-original-commit: 69dfde0 Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com> Signed-off-by: Igor Bertrand (igbe) <igbe@odoo.com>
Steps to reproduce: - have two companies A and B - create a new partner - create a new payment term for Company A - In Company A, set the customer's payment term the newly created one - Configure aliases for invoice in company A and B - Make sure the default company for OdooBot is COmpany A - Send an email to company B Issue: Access Error Cause: payment_term is pre-compute and the company context is the one of OdooBot opw-4103229 closes odoo#184482 X-original-commit: db78061 Related: odoo/enterprise#73668 Signed-off-by: John Laterre (jol) <jol@odoo.com> Signed-off-by: William André (wan) <wan@odoo.com>
The combo configurator works with `product.product` records, so previously, we only allowed to configure `no_variant` PTALs. However, we should also allow to configure the `product.product`'s custom PTAVs (which can be `always` or `dynamic`). Moreover, we always allowed to configure `no_variant` PTALs, even if they weren't configurable (i.e. PTALs with a single, non-custom, non-multicheckbox PTAV). However, such PTAVs should be preselected and non-configurable in the combo configurator. closes odoo#191130 Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
Before this commit: When multiple types of lists were selected and the deleteBackward operation was performed, the list type remained unchanged. After this commit: When deleteBackward is pressed with multiple types of lists selected, and all selected content is removed, if the anchor node's list item is empty, the list type will change to match the type of the list where the deleteBackward operation started. task:4187739 X-original-commit: 906ff3a Part-of: odoo#192446 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit: When multiple types of lists were selected and the deleteBackward operation was performed, the list type remained unchanged. After this commit: When deleteBackward is pressed with multiple types of lists selected, and all selected content is removed, if the anchor node's list item is empty, the list type will change to match the type of the list where the deleteBackward operation started. task:4187739 closes odoo#192446 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The name search on the account field (account.account on account move line) looks for frequently used accounts for the partner. When no search text is provided, the name search suggests accounts that were previously used. When there are no frequent accounts, the name search returns nothing. To reproduce - create a vendor bill - select a partner that has never been billed - add a line - click the account many2one field dropdown Since no account options are available, the dropdown flashes open and quickly disappears. closes odoo#194303 X-original-commit: de718ad Signed-off-by: William André (wan) <wan@odoo.com>
**Problem**: When typing `@` in a non-collapsed selection (`a[b]`) and selecting an item from the mention list, the selection state becomes stale. This happens because `handleObserverRecords` calls `updateHints`, which relies on `getSelectionData`. However, `this.activeSelection` retains the outdated selection due to conditions like `documentSelectionIsInEditable` and `!this.activeSelection.anchorNode.isConnected` being `false`. As a result, `this.activeSelection` reflects `a[b]` while the DOM selection has already updated to `a[]`, leading to invalid offsets. **Solution**: Call `this.dependencies.selection.focusEditable();` during `onSelect` to ensure the selection is updated to reflect the editor state rather than the mention state. **Steps to Reproduce**: 1. Open the chatter. 2. Add some text. 3. Select a portion of the text. 4. Type `@`. 5. Select an item (person) from the mention list. 6. Observe a traceback error. opw-4498165 closes odoo#194480 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce: - Create SO and add a product. - Apply discount coupon to SO. Issue: - Traceback occurs when the delivery module is not installed. Cause: - The line.is_delivery attribute is not accessible when the delivery module is not installed, leading to an error. Fix: - Use the line._is_delivery() method to correctly check for delivery lines. opw-4509360 closes odoo#194839 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
…quests Steps to Reproduce: • Install the Time Off app. • Create a new user and corresponding employee without any group in Time Off. • Create a new time off request with a start date < today's date. • Attempt to change the date, which results in a validation error. Issue: - Users are unable to modify time off requests, even if they are not yet approved. Fix: - Added a check to ensure that modifications are allowed for time off requests that are not in an approved state. task-4236572 closes odoo#194814 X-original-commit: ff07c30 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit makes use of the ir.cron.progress feature in the stock
scheduler. The first approach is to simply count how many tasks have
been completely done among the 5 currently available
stock
trigger orderpoints
merge quant & delete 0 quant
reserve confirm stock move
point_of_sale
close session
product_expiry
make alerts on expired lots
They will be split in 5 different crons later to be able to count
exactly the remaining records number to manage in each sub tasks.
closes odoo#189708
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
….BALANCE Problem --------- There is currently no formula to get the residual amount of accounts nor to get the balance of a partner in a given period of time in spreadsheets. Objective --------- Add the formula ODOO.RESIDUAL and ODOO.PARTNER.BALANCE that do just that ODOO.RESIDUAL should take the following parameters: - account_codes (mandatory)(can be more than one separate by ,): could be optional, in that case it could set the domain to all receivables/payables accounts - due_date_range or expected_date (optional): date range referred to due dates (not AML date) - offset (optional): adding the possibility of the offset to be not only “Year” but also, a specific date or other periods like Month, Quarter. - company_id (optional) - include_unposted (optional) (default: false) ODOO.PARTNER.BALANCE should take the following paramters: - partner_ids (mandatory) (can be more than one separate by ,) - accound_codes (optional) (the prefix of the account(s)) - date_range (optional) (21/12/2022,Q1 2022, 12/2022, 2022) - offset (optional) (default: 0) - company_id (optional) - include_unposted (optional) (default: false) Solution --------- 1. Define the spreadsheet function with the correct parameters in `accounting_function.js` 2. Hook it to the data source so that it can perform server calls 3. Craft that server python function to returns the list a residual amounts for the given list of parameters. 4. Adds some tests. Task-3679808 closes odoo#194567 Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce: - Install Accounting - Configure a Check Layout in Accounting settings - Go to Bank journal configuration - Make sure that "Checks" payment mehtod doesn't have an Outstanding Payment account - Create a bill - Register a Check payment for the bill - Print the check Issue: All the data about the bill are missing from the check. Cause: These data were retrieved from the journal entry linked to the check payment. As there is no journal entry in this case, they cannot be computed. Solution: Compute these data from the amount of the check and the linked bills. opw-4482589 closes odoo#194404 Signed-off-by: William André (wan) <wan@odoo.com>
Adds a configuration that can be used to mitigate PostgreSQL
transactional errors with long-living connections and the
`LISTEN/NOTIFY`[1] functionality by re-establishing the database
connection periodically.
In the case that a connection outlives the transaction wraparound[2]
mechanism of postgres, the `LISTEN/NOTIFY` internal queue might contain
references to transactions that have already been deleted by the
system's (or a manual) `VACUUM`[3] as it has its own transaction
validity mechanisms (roughly comparing transaction ids).
This can be reproduced by:
- Triggering a wraparound _AND_ cleaning of pg_xact between the cron's
`LISTEN` + `COMMIT` and its recyling.
- Having done at least one `NOTIFY` during that time period (?).
- Try to `LISTEN` to the same channel on the same database (transaction
id must be < than the first connection's transaction id).
The following is an example error message:
```
ERROR database odoo.service.server: Worker (3194772) Exception occurred, exiting...
Traceback (most recent call last):
File "/home/user/odoo/service/server.py", line 1089, in run
self.start()
File "/home/user/odoo/service/server.py", line 1235, in start
self.dbcursor.commit()
File "/home/user/odoo/sql_db.py", line 480, in commit
result = self._cnx.commit()
^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedFile: could not access status of transaction 1194816979
DETAIL: Could not open file "pg_xact/0473": No such file or directory.
```
[1: LISTEN/NOTIFY](https://www.postgresql.org/docs/current/sql-notify.html)
[2: wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)
[3: VACUUM](https://www.postgresql.org/docs/17/sql-vacuum.html)
[LISTEN/NOTIFY code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c)
[Connection being kept](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L2167-L2191)
[See more](https://www.postgresql.org/message-id/flat/VE1PR03MB531295B1BDCFE422441B15FD92499%40VE1PR03MB5312.eurprd03.prod.outlook.com#7e36d1fdca921b5292e92c7017984ffa)
closes odoo#194937
X-original-commit: 278ce01
Related: odoo/documentation#11835
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Part-of: odoo#191402 Related: odoo/enterprise#77563 Signed-off-by: Laurent Smet (las) <las@odoo.com>
Part-of: odoo#191402 Related: odoo/enterprise#77563 Signed-off-by: Laurent Smet (las) <las@odoo.com>
-------------------------------------------------------- Fix the "same_tax_base" on tax totals. -------------------------------------------------------- Suppose 2 lines: - 100 with 13% - 100 with 23% => The base are not displayed when printing the PDF because 'same_tax_base' is True. However, the untaxed amount is 200 and both taxes have a base of 100. -------------------------------------------------------- Fix the base amount when there is no tax. -------------------------------------------------------- Suppose 2 lines having quantity=12.12, price_unit=12.12 => The expected base amount is round(12.12 * 12.12 * 2) ~= 293.79 However, the current dispatching of taxes is only done when there is a tax set. -------------------------------------------------------- Automatic fallback of the currency. -------------------------------------------------------- When converting the record to a base line, automatically compute the currency_id by looking to a company_currency_id or company_id field. -------------------------------------------------------- Fix the untaxed amount in case of cash rounding line. -------------------------------------------------------- Suppose a line of 15.68, cash rounding 0.05 half-up. The untaxed amount returned by the tax totals was 16.70 with a cash rounding amount of 0.02. However, 16.70 + 0.02 = 16.72... it's confusing for the user. Let's subtract the cash rounding amount from the untaxed amount to get 16.68 + 0.02 = 16.70. -------------------------------------------------------- Add a global delta base amount -------------------------------------------------------- Dispatch the delta of base amounts accross the base lines. Suppose 2 lines: - quantity=12.12, price_unit=12.12, tax=23% - quantity=12.12, price_unit=12.12, tax=13% The base amount of each line is computed as round(12.12 * 12.12) = 146.89 The expected base amount of the whole document is round(12.12 * 12.12 * 2) = 293.79 Currently, the base amount has already been rounded per tax. So the tax details for the whole document is currently: 23%: base = 146.89, tax = 33.79 13%: base = 146.89, tax = 19.1 However, for the whole document, there is a delta in term of base amount: 293.79 - 146.89 - 146.89 = 0.01 This delta won't be there in any base but still has to be accounted. In mexico, this is absolutely necessary to make the CFDI passing all the time. -------------------------------------------------------- Start the test suite for the Portuguese certification. -------------------------------------------------------- To use Odoo in Portugal, we have to get a certification that is mainly based on the results given by our taxes computation. This is currently a work in progress but this commit contains the beginning of the test suite to get this certification. closes odoo#191402 Related: odoo/enterprise#77563 Signed-off-by: Laurent Smet (las) <las@odoo.com>
In error_service, event.preventDefault() is required to prevent uncaught error message due to latest Chrome version (132) compatibility. closes odoo#194861 X-original-commit: 9667852 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Signed-off-by: Pierre Pulinckx (pipu) <pipu@odoo.com>
closes odoo#194898 Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Before this commit: Using the button command in the powerbox resulted in the creation of a regular link instead of a button. After this commit: Executing the button command now correctly creates a primary button as intended. task-4380129 closes odoo#189893 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- With an EG Company setup
- Create an invoice with a '3% WH' tax
- Confirm invoice and send for validation
Issue: Validation will fail with error
```
{'code': '2', 'message': 'Validation Error', 'target': 'INV/2025/00001', 'propertyPath': None, 'details': [{'code': None, 'message': 'ArrayItemNotValid', 'target': '[0]', 'propertyPath': '#/invoiceLines[0]', 'details': None}, {'code': None, 'message': 'ArrayItemNotValid', 'target': '[1]', 'propertyPath': '#/taxTotals[1]', 'details': None}]}
```
This is caused by the withholding tax amount being reported as negative,
while it should be reported as positive
opw-4453002
closes odoo#194708
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Before this commit, it could happen that the autocomplete does not find the option to select. Now, we give the option to select so we're sure that the option exists when we select it. runbot errors: 5759, 102534, 111418 closes odoo#194904 X-original-commit: 3f597d9 Signed-off-by: Julien Carion (juca) <juca@odoo.com> Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
It was failing in single module builds /locally and the reason was due to the fact that project not having a analytic account. task-4500108 closes odoo#194701 Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce: 1. Go to Website -> Edit -> Theme section. 2. Choose a predefined font family for the paragraph, such as "Arvo". 4. Return to the font family dropdown and click on "Add a Custom Font". Notice that the selected font reverts to the "default/system" font. Solution: The issue is that the we-button with the o_we_add_font_btn class does not have a value, i.e., its data attributes are not set. As a result, we want to avoid reloading the bundle. To prevent the reload, we set data-no-bundle-reload="true" on the we-button of the add_font_btn template. task-4373983 closes odoo#195848 X-original-commit: 1a6291b Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com> Co-authored-by: Mohammed Shekha <msh@odoo.com>
The $0 placeholder in templates is highly useful, but it is not considered when saving a view. For instance, the search icon in the shop search bar has an incorrect xpath: `/data/xpath[3]/form/t[1]/div[1]/button[1]/i[1]`, where the inner `t[1]` actually points to another view through a `<t>$0</t>` containing the inherited view. The method responsible for handling this replacement fails when the element is editable, causing a crash. This commit ensures that when an xpath jumps to another template, it disallows the branding. task-3609835 closes odoo#195875 X-original-commit: 64e43e5 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com> Signed-off-by: Serge Bayet (seba) <seba@odoo.com>
Upon zooming in on the elearning slides view from the mobile by finger pinch, the whole page zooms in and not just the content, which causes the content quality to be still blurry. To Reproduce on Runbot: 1.Go to eLearning module. 2.Go to "Edit" on any of the courses. 3.Add a pdf content. 4.From the phone, go to the website elearning for the same course. 4.Click on the pdf content we uploaded. 5.Try finger pinch zooming in, the document gets still blurry. 6.The issue seems to be that there's no finger pinch zoom in and out, and when you try doing that the whole page zooms in and out, not changing the quality of the document. So, the solution was to make zoom in and out icon available on small screen devices as well. opw-3893275 closes odoo#195789 X-original-commit: 07d982b Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
In odoo#127877, the active field was removed and replaced with state: cancel. This domain was modified but removed the check for the cancelled state. opw-4420347 closes odoo#195846 X-original-commit: e756937 Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
### Contains the following commits: odoo/o-spreadsheet@f505971d4 [REL] 18.0.13 Task: 0 odoo/o-spreadsheet@9d5251d0d [PERF] formulas: add a cache on linear search functions Task: 4080146 odoo/o-spreadsheet@4ef9f2da1 [FIX] auto-complete: hide auto-complete when selecting a cell Task: 4022927 odoo/o-spreadsheet@d131f1585 [FIX] locale: wrong parsing with "." thousand separator Task: 4525746 odoo/o-spreadsheet@7793d0931 [FIX] ui_sheet: batch resize commands in `AUTORESIZE_ROWS` Task: 4504918 odoo/o-spreadsheet@07ee8ab47 [FIX] pivot: use displayed value in computed measure Task: 4517312 closes odoo#195933 Signed-off-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
The b2b fields are still required in the portal form even if the "Show b2b fields" is deactivated Steps: - From the website editor, on the checkout form, unselect the "Show b2b fields" setting - Log out and go to ecommerce - Add a product to card and checkout - Fill the address form with a Brazilian address -> Error: "Some required fields are empty." With this commit, we remove the fields `vat` and `l10n_latam_identification_type_id` from the mandatory fields if the option "Show b2b" fields is not activated. opw-4403161 closes odoo#195888 X-original-commit: 128e7c3 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com> Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Steps to Reproduce: =================== - Open a POS session and go offline. - Create orders and print receipts at the receipt screen. - Restore the internet connection and bring the POS online. - A traceback occurs during synchronization. Before this commit: ===================== A traceback occurred when making a POS order, printing a receipt in offline mode, and later going online. The issue arose because the nb_print field was updated via a backend write call to restrict payment method edits. However, during offline mode, the order_id was a string, causing the traceback. After this commit: =================== - The backend write call for nb_print is bypassed in offline mode. Instead, the `nb_print` count is updated on the frontend. When the order syncs after going online, the increased `nb_print` value prevents payment method edits as expected. - Removed the nb_print validation constrains from payment lines. Validation is already handled in the write method of pos.order. This change avoids validation errors when syncing orders from offline to online, where nb_print = 1 and payment lines exist. The write method ensures proper handling during order creation. - A `Connection Lost` error message is displayed when attempting to send orders to the kitchen while in offline mode. Task-4504625 closes odoo#194694 Signed-off-by: David Monnom (moda) <moda@odoo.com>
steps: - create an accrual plan with: - 21 days per year alloc - start immediate - 28 days cap - carryover with max 7 days - create allocation for the current year (1/1/XXXX) - take 15 days holidays -> 6 days left on the alloc - check the leaves left for next year -> 28 days, should be 27 (21 + 6) This happened because the carry-over calculation didn't take into account the number of days left on the allocation and always carried over the cap. X-original-commit: a4a257c Part-of: odoo#190917 Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com> Signed-off-by: Loïc Leloup (lole) <lole@odoo.com>
steps: - set the carry over to "carry over with maximum" - set a number of days to carry over and save - set the carry over type back to "None" -> You still carry over the amount of days you typed in instead of 0 closes odoo#190917 X-original-commit: 1f99b44 Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com> Signed-off-by: Loïc Leloup (lole) <lole@odoo.com>
add intercalate unsubscription page Email clients have begun implementing security measures to protect users from phishing by analyzing email links, and interacting with them (see task-3972953). This has the side effect of automatically unsubscribing email recipients from mailing lists by clicking the link in the footer of the emails. This commit adds an intermediate step to the process, by requiring users to click on a button before they are unsubscribed. -- The current unsubscription destination page for emails makes it unclear for the user whether they've been unsubscribed or not. This is because the "unsubscription confirmed" box is placed below the "manage subscription settings" box on the confirmation page. To avoid confusion, while ensuring current Studio customizations to stable instances are not impacted, the unsubscription confirmation page will clarify that the user is unsubscribed and offer the option to manage unsubscriptions by reaching the destination page. task-4364446 closes odoo#195913 X-original-commit: 52b3f53 Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Versions -------- - saas-17.4+ Steps ----- 1. Create a `next_order_coupons` loyalty program; 2. go to eCommerce as Public User; 3. add products to cart so that the program gets applied; 4. on checkout, log in as Portal User during delivery step; 5. finalize payment. Issue ----- Two coupons were created: one for Public User with 0 points, one with no partner and 1 point. There should only be one coupon, and it should be linked to the logged in user. Cause ----- Commit 804dc10 changed `next_order_coupons` programs to set a partner when created. Issue is when they get created as Public user, the next call to `_update_programs_and_rewards` when logged in will remove the point entries for that coupon, as it's linked to partner that doesn't match the sale order's. Solution -------- Before checking whether to unlink the point entries, update the coupon's `partner_id` if it was created for Public User and the sale order itself is no longer linked to Public User. Also when generating new coupons in `_update_programs_and_rewards`, link `next_order_coupons` to the customer to make it behave identical to coupons created via `__try_apply_program`. opw-4397753 closes odoo#195915 X-original-commit: 1d04105 Signed-off-by: Levi Siuzdak <sile@odoo.com> Co-authored-by: Demesmaeker <edm@odoo.com>
Before this commit, the error_checker asserting that a JS unit test run failed performed a strict equality with an outdated string on error logs. Now, error checker only checks for the [HOOT] prefix to determine whether an error should end the test run, as to not rely on an arbitrary error message. closes odoo#195947 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When settling a quotation (unconfirmed sale order) from the POS, the delivered quantity was not updated in the quotation. Steps to reproduce: ------------------- * Make a sale order but don't confirm it * Go to the POS and settle the quotation > Observation: The delivered quantity is not updated in the quotation Why the fix: ------------ If the quotation was not confirmed no move lines were created, so the `has_valued_moves` was False and no move lines were created for the PoS order. And because the pos order has no move lines the quotation was not updated with the delivered quantity. opw-4479862 closes odoo#194420 Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, refreshing the browser and creating a new order could yield a duplicate tracking number, causing confusion. This commit addresses the issue by preventing the sequence from resetting within the same session on a single device. opw-4501048 closes odoo#194495 Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In this commit, we fix multiple tours on step that can cause non deterministic behaviors by adding additionnal steps to ensure tour is well on the way to taking the right path. closes odoo#195973 Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Versions -------- - 16.0 Backport of 3dd487f Issue ----- Use `float_compare` to compare floating point amounts on reward validation. closes odoo#195974 X-original-commit: d8b02fe Signed-off-by: Levi Siuzdak <sile@odoo.com> Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Colorless tags are always hidden in the frontend interface, this allows to manage them in backend without showing them. Since there's no filter on the `websiteEventTrackProposalFormTags` widget, those tags were still selectable from the website, resulting in the following issues: - Adding useless noise in the selection. - Letting users select tags that are not intended to be selected. - Users could also wrongly select a tag instead of the intended one. closes odoo#195856 Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
This commit fixes the width of unavailable items inside the search results list. Note: this fw-port adds a CSS fix to counter the effect of an utility class. This has to be removed in the master fw-port. opw-4444222 task-4517564 closes odoo#195813 X-original-commit: ffe0da6 Signed-off-by: Serge Bayet (seba) <seba@odoo.com> Signed-off-by: Antoine Sougné (anso) <anso@odoo.com>
Issue: When using the enterprise version, and configuring an accounting report with the report builder, issues might arise when changing the sequence of lines (using the drag and drop feature). Combined with the enterprise PR, this commit solves the issue by returning the lines ordered by sequence. Enterprise PR: odoo#187907 (review) task-4328098 closes odoo#195851 X-original-commit: a45ebe1 Related: odoo/enterprise#78218 Signed-off-by: Olivier Colson (oco) <oco@odoo.com> Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
This commit fixes an issue where if the user applies a group by on an aggregatable field (an integer like color_index for example), this field is also registered as an aggregator in the webReadGroup call and this leads to nonsensical results by the orm. After this commit, the group by field is automatically excluded from aggregators so the issue cannot happen. task-4491839 closes odoo#195871 X-original-commit: 08a4eb8 Signed-off-by: Julien Mougenot (jum) <jum@odoo.com> Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Before this commit, the resource_ref field of a server action can disappear when the action is saved. This is due to the following: - the update_related_model_id is a computed stored READONLY field which leads to it not being included in the web_save rpc and is therefore not saved on the record The fix consists to ensure the update_related_model_id is saved by making it readonly=False, which is usually what we want when we have a computed stored field. closes odoo#195367 Task: opw-4513803 X-original-commit: 13f95cf Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com> Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before we had no solution to test the synchronisation of the pos. In classic tours websocket are not supported. And we cannot launch two tours in parallel. This commit add the possibility to load test assets in the PoS during our development. That's allow us to launch tour in loop in two different browser and test the synchronisation by creating orders, payment etc. Tour assets are only added by adding `&tours=True` in the URL of the PoS interface. closes odoo#195344 Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Refactored the Bolivian localization module to comply with local requirements, replacing the previous implementation. Key changes include: - Updated `account.account-bo.csv`, `account.group-bo.csv`, `account.tax.group-bo.csv`, and `account.tax-bo.csv` files. - Expanded the Chart of Accounts to include 661 accounts. - Added 67 tax configurations to align with Bolivian tax regulations. - Implemented 9 tax reports analog to Bolivian tax declaration reports. - Added Bolivian banks information. - Included the states of Bolivia. - Improved language formatting for better localization support. These updates ensure compatibility with Bolivian accounting requirements and improve the overall accuracy of financial reporting.
|
|
Signed the Contributor License Agreement (CLA) to contribute to Odoo. This commit adds the signature to the CLA file as per the guidelines provided.
SimonCapriles
changed the title
Adding the use of anglo saxon accounting in bolivian localization
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
125 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the issue/feature this PR addresses:
The previous implementation of the Bolivian localization was based on Peruvian accounting standards, making it incompatible with local regulations. This PR refactors the module to align with Bolivian accounting and tax requirements.
Current behavior before PR:
Desired behavior after PR is merged:
This update ensures the module is fully adapted to Bolivian requirements, improving accuracy and usability for businesses operating in Bolivia.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr