Tuesday, November 28, 2023
3 changes · 17.0
Resolved issues and error corrections
The Danish localization has been updated to align with the Danish government's standardized chart of accounts and the new Danish Bookkeeping Act. This refreshes account mappings and tax setup so Danish businesses can stay compliant in Odoo.
Original PR description
# In General The localization has been redefined as per the standardized chart of accounts from the Danish Government (Erhversstyrelsen):…
# In General The localization has been redefined as per the standardized chart of accounts from the Danish Government (Erhversstyrelsen): https://erhvervsstyrelsen.dk/sites/default/files/2023-02/2023-01-31-Standardkontoplan.xlsx This is unfortunately only defined in Danish so in order to keep features of Odoo where the various parts of the localization are defined in English, I have translated the various Danish text into English and provided as the source and then provided the Danish text as a translation in the CSV-files. Below is an overview of the individual areas with changes as well as some points of consideration in terms of the requirements from the government and how things work in Odoo This PR is a joint operation between us and Odoo S.A. as agreed with Olivier Maessen in order to be compliant with the new Danish Bookkeeping Act ## Chart of Accounts In general the CoA only required some minor adjustments The CoA was reviewed based on the above file using hte sheet named `II) Kontoplan`, where all entries with value in column `B` (`Overskrift`) have been ignored. In most existing Danish Accounting software, the chart of accounts is also what defines the formula for how to P&L report and balance sheet are rendered. This is different in Odoo, since the reports are defined spearately within `odoo/enterprise`. Some accounts have been removed, since the `code` conflicted with some of the above The below shows what accounts are used, but now under different numbers/names Before: ``` 5960 - Accounts receivable 5961 - Accounts receivable (PoS) ``` After: ``` 6190 - Trade and other receivables ``` Before: ``` 7180 - Creditor ``` After: ``` 7440 - Suppliers of goods and services ``` Before: ``` 7681 - Reverse chargeable business tax ``` After: ``` 7680 - Sales tax ``` The internal transfer account is currently set to the prefix of `683`, so this needs to find a new home. A good suggestion would be to have it be `6479` or `6489`, but since we define a prefix and not a specific account, it is hard to lock it to a specific number and there is no gap in the numbering sequence within bank + cash. ## Taxes For taxes there are 69 tax codes that must be possible to handle. While some of the are straight forward, others are more dynamically computed, for which changes in other parts of Odoo might be required first All taxes are defined in the previously linked file on the sheet named `III) Momskoder Bruttoliste`. The following rules have been applied to map the sheet to Odoo: - `Overskrift` -> `description@da_DK` (The english translation is put in ) - `Momskode betegnelse` -> `name` - `Salg/køb` -> `type_tax_use` - `Momskode` -> `id` (Prefixed with `tax_` and the lowercase value of this field) - `Momssats` -> `amount` (The `amount_type` field is set accourding the value here as well as the information from the column `Vejledning`) The column `price_include` is explicitly set to `False` or `True` so that a fallback/default is not used and causing issues in future versions of Odoo in case the default value of the field changes The column `active` is explicitly set to `False` or `True` so that a fallback/default is not used and causing issues in future versions of Odoo in case the default value of the field changes. Here the rule is that if the code is marked with `x` in the column `5. Særkoder` of the above Excel sheet, then the value will be `False`, as the code is then there, but should not be usable out of the box. Customers needing these codes can enable them in relevant companies on their Odoo instance. Codes not marked with `x` in the column `5. Særkoder` will have `True` by default, since they are expected to used by most companies. Upon processing the rules, we found the following tax codes where a challenge is found and that needs handling: `S-DK-25` handles within Denmark regardless of whether we sell products or services. This is fine in terms of taxes and tax reporting, since there are no rules that state a requirement to split these on the tax reporting for the government. It does however give a challenge when handling international sales, since `S-DK-25` has to be mapped to `S-EU-V-0` for products and mapped to `S-EU-Y-0` for services. Odoo has a field called `tax_scope`, which allows us to restrict the usage of taxes based on the product type, but it does not help with the above. To handle this, we create a variation of `S-DK-25` for products and services and then have it use the same account and tax grids. The above also applies for purchases in relation to `K-DK-Fradrag`, where we have done the same variation for `K-EU-V-Fradrag` for products and `K-EU-Y-Fradrag` for services. `S-DK-Brugtmoms` is a special code, as noted by the column `5. Særkoder`. The computation of the tax amount here is based on the following official explanation (translated to English): ``` This code is used for the sale of goods that can be covered by the rules for calculating VAT on used goods and where VAT must therefore be settled on the difference between the selling price and the purchase price. ``` The above means that if purchase a used Meeting table for DKK 1000 and sell it for DKK 2000 a week later, then the taxes are calculated based on what I have earned on this sale. Compute the difference between my purchase and my sale: ``` 2000 - 1000 = 1000 ``` Compute the tax based on the above difference ``` 1000 * 0.25 = 250 ``` When using Odoo inventory management, the above is quite simple when running manual inventory valuation and with standard price. If we however use automated valuation with FIFO, then we need to track each item and these do not always use lot/serial numbers. A way is needed to handle this code in Odoo `S-DK-Marginmoms` is quite similar to `S-DK-Brugtmoms` and has the following official explanation (translated to English): ``` This code is used by travel agencies etc. that have to settle VAT on the profit margin. ``` `S-DK-brugtbil` is also a bit special, as it computes similar to `S-DK-Brugtmoms`. Here is the official explanation (translated to English): ``` This code is used for the sale of used cars, where the seller can make a deduction from the calculated sales tax, on the basis of a calculation based on the purchase price of the used vehicle. ``` `S-Lokalmoms` is quite strange and needs to be handled, but should not go in the tax report. I have set the tax rate to 0, but realistically it must be dynanmic and it is needed to find a way for handling this in Odoo. Here is the official explanation (translated to English): ``` This code is used for sales made in or to customers in other countries where sales are carried out with local VAT. ``` There is also some challenges around `OSS` or One-Stop-Shop taxes in Europe, since special codes are given. I have not defined these as Odoo already has a method of mapping the various taxes from the localization of each country. There are however some requirements for the reporting, which might need to be handled by Odoo. If required we can add the codes, just to ensure that they are there. It is however quite a challenge to get usable responses from the Danish government on how these are supposed to be handled On the purchase side there are also a series of quite special codes, which we do not often see used, but the government does not list these as special codes, so we need a way to handle these in Odoo. `K-DK-SkønsmæssigFradrag` is a special code that needs to reported the same as `K-DK-Fradrag`, but the percentage to be deducted is variable. So the tax rate is still 25 %, but how much of the 25 % can be deducted on our VAT statement is dynamic, based on the following official explanation (translated to English): ``` This code is used for the purchase of goods or services that are used both in connection with the activities subject to VAT and for purposes beyond the company's control and where the right to deduction must be calculated based on an estimate of the actual use. This can, for example, be the acquisition and use of mobile phones, internet access at employees' private addresses and the like. ``` The following taxes are not required to go in the tax report, but it should be possible to find them later for audit: - S-DK-U - S-DK-MF - S-LokalMoms - S-EU-MF - S-%EU-MF - K-DK-IngenFradrag - K-DK-Brugtmoms - K-DK-Marginmoms - K-DK-brugtbil - K-DK-leasingbiler mm - K-EU-Momsfritaget A written guide must be provided for how to find these journal entries or they must somehow be tagged. This PR is a new iteration of #141989 with a few of the previously requested changes from @FlorianGilbert and @RicGR98 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from merging accounting records in the data cleaning tool, which was causing invoice data to become corrupted. The system now blocks account merges and partner merges when they're linked to locked accounting entries, protecting financial data integrity. Users can still clean up duplicate accounts using safer alternatives like multi-edit and archiving.
Original PR description
Steps to reproduce: - Enable the merge on account.account in data cleaning APP (in debug) - Create an invoice with a receivable account = A - Define a lock date after the invoice date - Go to chart of accounts - Select your receivable = A et receivable = B - Action = Merge accounts where B is the MASTER Issue: Upon revisiting the customer invoice: Notice that the journal items have been updated. Solution: We simply prevent ~~the use of a nuclear weapon~~ the merge of `account.account` as there other possibilities less dangerous such as multi-edit + archiving We also prevent the merge of `res.partner` if this one is used in hashed entries OC: https://github.com/odoo/odoo/pull/134634 opw-3389157 Forward-Port-Of: odoo/enterprise#48761 Forward-Port-Of: odoo/enterprise#47053
The mobile app was crashing when users pressed the back button or used the back gesture on iOS and Android devices. This fix removes outdated code that was causing the crash, allowing the back button to work properly again in the mobile apps.
Original PR description
During the removal of jQuery BBQ library [1], an `Event.getState()` call was unfortunately left. This resulted in a crash when using the device's back button/gesture, which triggers a 'hashchange' event, but only in the mobile apps (iOS and Android). This commit properly converts the related event handling to use the native window.location API. Steps to reproduce: - Open the backend using the mobile app - Go to an app - press the back button/execute the back gesture => error: e.getState is not a function opw-3602245 [1]: odoo/odoo@507c36883675a45a15485ce5c73aa4557ba23639