# 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.
Our suggestion is to implement one of the following changes in Odoo:
1. Implement an extra option for the fiscal position, so that each line with a mapping between taxes can be scoped to either products or services
2. Create a variation of `S-DK-25` for products and servicea and then have mapping rules for these on the reporting and data exchange

We would prefer option 1, since it can give a lot of extra features for other countries as well, where a similar challenge exists. If needed, I can attempt a separate PR for this and put a link here when it is ready.
The above also applies for purchases in relation to `K-DK-Fradrag`, where need to map 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

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.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

This commit does 2 things:

- avoids an error occurring when scanning a source location that has no
  (remaining) reserved qtys at that location to scan. Issue was due to:

https://github.com/odoo/enterprise/blob/61d3aa2d4ba7540803b88ca4f426e6ee6503e8dd/stock_barcode/static/src/models/barcode_picking_model.js#L165

  still being used by barcode_mrp_model, but this.needSourceConfirmation
  is set to `false` in the mrp model, so an error is thrown because
  booleans don't have an index. Originally it was thought this
  (picking) feature wasn't wanted for MOs, but this has been
  reconsidered and we now want it (afterall, it is better to have
  consistent behavior).

  Note that in order to add this check in, the _createNewLine in MOs had
  to be adjusted so that the assignment of the final product for an MO
  created from scratch occurred before the check:
  https://github.com/odoo/enterprise/blob/57986a41fb80deecd7c4d2a374afa801bc44a507/stock_barcode/static/src/models/barcode_picking_model.js#L51

  because the this.location will throw a cache error due to there being
  no default location to find (i.e. there are no locations for the MO
  yet). No tests were added for this because existing tours already
  failed when creating MOs from scratch.

  Steps to reproduce:
  - activate multi-locations + set barcode setting for manufacture
    picking type: `restrict_scan_source_location`=`mandatory`
  - create 2 products, 1 with stock in WH/Stock, the other with stock in
    WH/Stock/Shelf 1, both with barcodes
  - create MO using those 2 products + reserve
  - open MO in barcode, scan "Shelf 1" barcode + scan component in that
    loc
  - scan "WH/Stock"

  expected result: should switch source locations + should be able to
  scan the other component

  actual result: JS error

- adds in a test to avoid the same mistake that is fixed in the COM PR
  of this branch. Existing test has been redone so the test includes:
  + the above location switching scanning (to scan a non-reserved
    component)
  + the mandatory consumption check
  + the original test of scanning a diff lot than the one already
    reserved

COM PR: https://github.com/odoo/odoo/pull/142933

This traceback arises when the user tries to click on Recent in Softphone

To reproduce this issue:
1. Install `VoIP`
2. Open `Discuss/Softphone/Recent`
3. Try to search for something in the Voip search bar

Error: 

```  ValueError: too many values to unpack (expected 3)
  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1960, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 24, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 462, in call_kw
    result = _call_kw_model(method, model, args, kwargs)
  File "odoo/api.py", line 435, in _call_kw_model
    result = method(recs, *args, **kwargs)
  File "home/odoo/src/enterprise/17.0/voip/models/voip_call.py", line 85, in get_recent_phone_calls
    return self.search(domain, offset=offset, limit=limit, order="create_date DESC")._format_calls()
  File "odoo/models.py", line 1604, in search
    return self.search_fetch(domain, [], offset=offset, limit=limit, order=order)
  File "odoo/models.py", line 1627, in search_fetch
    query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
  File "odoo/models.py", line 5366, in _search
    query = self._where_calc(domain)
  File "odoo/models.py", line 5081, in _where_calc
    return expression.expression(domain, self).query
  File "odoo/osv/expression.py", line 788, in __init__
    self.expression = domain_combine_anies(domain, model)
  File "odoo/osv/expression.py", line 597, in domain_combine_anies
    domain_any = _anyfy_leaves(domain, model)
  File "odoo/osv/expression.py", line 371, in _anyfy_leaves
    left, operator, right = item = tuple(item)
```

When the user tries to search for something in the search bar an invalid domain format is formed in `get_recent_phone_call`method. Which leads to the traceback from here

https://github.com/odoo/enterprise/blob/5c42708683905cfb5fe8c1005aabbbc9fb016fa2/voip/models/voip_call.py#L79-L85

After applying this commit will resolve the issue by giving a valid domain format to search.

sentry-4644858097