The default taxes for most localisations have been left undefined by
default. When loading the chart template, the model generally selects
the first sales and purchase taxes, based on the order in which the
taxes appear in the csv, for the default sales and purchase taxes
respectively.
This behaviour can be confusing to those who are not yet familiar with
it. It has been decided that it is preferable instead to specify the
default tax in _get_*_res_company function on the account chart template
model, such that the default taxes are defined explicitly for every
localisation.
task-3453997
closesodoo/odoo#130733
Related: odoo/enterprise#45531
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Prior to this, tax groups in Kenya where labeled "TVA".
The labels are changed for a version containing "VAT" instead.
task-3391884
closesodoo/odoo#127109
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Description of the problem:
When an item in an invoice is not 16% standard VAT rated, the KRA
expects an "Item Code". These "Item Code"s were formerly referred to as
HS Codes, however this was never an accurate description of what they
were, since they never shared in the nomenclature of the Harmonised
System and they refer to services (as opposed to just goods).
Examples of KRA Item Codes:
- 0001.12.00 The exportation of goods (0%)
- 0010.21.00 Tea and coffee brokerage services (exempted)
- 0001.13.14 Natural gas in gaseous state (8%)
The KRA's item code system consists of several components:
- A code, of the format 'XXXX.XX.XX' (where X is a digit [0-9])
- A description explaining the use case of the code
- The tax rate specific to code, this can be interpreted as "using this
code justifies using the tax rate that you have on the invoice line"
There are few conceptual problems with the application of these codes,
since they don't exactly match the way things are approached in Odoo. I
took care in the examples to include the "Exportation of goods" code.
Which should be used to justify all zero-rated taxes on exports. I also
included an example where, for instance, natural gas is rated at 8%.
From the two examples above, it is clear that the code does not relate
directly to the product, which is where the fields are currently
represented. Instead, the relationship is more accurately between the
code and the line that it describes.
However, to avoid putting the code on the line and complicating the
'account.move.line' model further, we can the relationship between the
code and the tax.
This means that for each code the user finds themselves using, there
will have to be a specific tax, for example (with respect to the
examples above):
- "Zero Rated Exports (0%)"
- "Tea/Coffee Brokerage (0%)"
- "Natural gas (8%)"
In this commit:
A new model representing the KRA item codes is added in l10n_ke, along
with a many2one relation to it on the account.tax.template/account.tax
models. Accompanying views for the new l10n.ke.item.code model and the
many2one field on the tax are added.
In l10n_ke/data the item codes themselves are added in csv format.
L10n_ke/security is added, and ir.model.access.csv to describe access
rights for the new l10n.ke.item.code model.
The account tax template is updated to add a default export tax with the
appropriate export item code applied to it.
In l10n_ke_edi_tremol, the move validation and serialisation (in which
invoice data is serialised for sending to the device) is updated to
handle the new schema.
The inheritance of product and the additional item-code related fields
is removed from l10n_ke_edi_tremol as they are no longer required, the
same is true of the associated views.
closesodoo/odoo#112013
Related: odoo/upgrade#4528
Signed-off-by: Josse Colpaert <jco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115521
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Removing external links from localization manifests and redirect to our own documentation. Ensure that users can learn about our standard localization modules from a source of information that we have authorship on.
closesodoo/odoo#117005
Task-id: 3248632
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Taxes have a `description` field that has been hijacked to
represent tax label on invoices. We want the description field
to be used for its original purpose, thus created a dedicated field
`invoice_label` in which we transferred `description` content.
We also make description translatable.
This is part of the Tax Taxonomy 2 rework.
Task: 3052677
Part-of: odoo/odoo#113236
There is a lot of use case where reports are exclusively in the company
currency, or have columns only in this currency. In these case, showing
the currency symbol is redundant, takes space and makes the reading
slower.
With this change, we will avoid displaying the symbol in a variety of
use case where it is not needed.
Task id #2868674closesodoo/odoo#109666
Related: odoo/enterprise#35671
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This module implements communication with the fiscal device for
submitting invoices to the KRA (Kenya Revenue Authority). The device
supported in this module is the Tremol G03.
-- COMMUNICATION FLOW SUMMARY --
1. "Send Invoice To Device" on account move is clicked
2. l10n_ke_action_cu_post triggers a client action, with serialised
invoice data. (more details below)
3. The client action uses the 'post_send' function defined in javascript
to forward the request to the /hw_proxy/l10n_ke_cu_send endpoint on
the proxy server (more details below)
4. The proxy server wraps the serialised data with the appropriate bytes
(for instance, a couple of a checksum bytes), and sends them to the
device through serial communication (more details below)
5. The data returned from the fiscal device is communicated back in the
request. The client action 'post_send' then triggers the
'l10n_ke_cu_response' with an rpc call, with the aforementioned data
from the fiscal device
(more details)
2. The module l10n_ke_edi_tremol inherits from the account_move model in
order to provide methods for serialising the data of the account_move
and sending it to the proxy server. Fields have been added to the
product template to define the HS Code and HS Name (data which is
required by the KRA in some circumstances). A field has also been added
to the company defining the address of the proxy server. The fields
added on the account move are populated by the data returned by the
fiscal device, this includes the device serial number, the invoice
number on the device, the URL of the invoice on the KRA web portal, and
the date/time the invoice was signed.
3. Communication between the client database and the proxy server is
defined using a client action defined in
l10n_ke_edi_tremol/static/src/js/send_invoice.js. This allows users who
aren't on-premise to communicate with the device, provided the proxy is
accessible on the network that the user is on.
4. The proxy server is an intermediary server that should be connected
to the tremol G03, and running the IOT drivers from hw_drivers. The
driver that supports communication between the proxy server and the
fiscal device has been defined in this commit inside of
hw_drivers/iot_handlers/drivers//L10nKeEDISerialDriver.py.
The proxy server can be run on the IOT box, or on odoo community by
running:
./odoo-bin addons-path=.... -d dbname --load hw_drivers --proxy-mode
** all messages are encoded/decoded with cp1251, as defined in the
protocol. The company vat code is sent along with the request to compare
that sent with that of the device. The 'serial_number' of the device is
always returned along with the request, since it is required for the
invoice details, and it is retrieved as part of the query to find the
registered VAT code on the device.
--- DATA and VIEWS ---
product_view:
adds HS Name, and HS Code on the product product and product template
form views.
report_invoice:
adds to the invoice qweb template such that a section including the
fiscal device / KRA details is included at the bottom of the invoice
when the invoice is rendered as a pdf.
res_config_settings_view:
adds makes the proxy address field editable from the config settings.
account_move_view:
add a tab for the tremol device details and the qr code on the account
move form view. The KRA invoice number is also added as an optional
field on the account move tree view, and the invoice search view is
inherited to make this field searchable too.
(l10n_ke) account_tax_report_data, account_tax_template_data:
The tax report is defined for Kenya, and tax tags that link to the lines
on this tax report are defined on the existing taxes. This allows the
classification of the tax, between zero-rated and exempt, during the
serialisation.
closesodoo/odoo#106654
Task-id: 2950308
X-original-commit: b0be9e074a1ecf1f6de7a03c71df0c63868501e3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Keep the manifests as light as possible, to easily see custom behavior/content.
Complete the work of previous commits cleaning the manifests content:
* 42bad1a6d2
* ef7005f524
and make sure this kind of cleanup commit is not necessary in the future
because it is now automatically verified by a dedicated test.
closesodoo/odoo#107735
Related: odoo/enterprise#34903
Signed-off-by: Julien Castiaux <juc@odoo.com>
Some updates to Kenya localization:
- Withholing taxes support
- Inventory Interim accounts are set by default when automatic valuation of stocks is used
- Default temporary account for POS
closesodoo/odoo#106527
Task: 3067646
X-original-commit: 8406484e6c463c5a4bc31f7febe5289fd26a9966
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
The early payment cash discount functionality was merged in 16.0.
This PR allows for the behavior to be as localization specific as possible.
This concerns :
The tax computation (some countries leave it untouched after the discount, some countries discount it, and Belgium has a mixed behaviour)
The account in which the cash difference resulting of the cash discount should be put.
task- 2983913
related to #99572closesodoo/odoo#102032
X-original-commit: 591757902dcdf1e3609d9c5ae23e2b134ee8e4da
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Following reportalypse, reorder the menu items in order to bring
some consistency to the report menu.
Also clean the menu items by removing all the menu items no longer
used since most reports are now selectable by going on the generic
reports and then switching to localized ones.
Task id #2965755closesodoo/odoo#99210
Related: odoo/enterprise#30854
Related: odoo/upgrade#3831
Signed-off-by: William André (wan) <wan@odoo.com>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Added CoA and account groups for Kenya.
Added taxes for Kenya
task-2809108
closesodoo/odoo#91396
X-original-commit: ac95f9f961405ed6f6b24f08a8aab05a6561e410
Related: odoo/enterprise#27344
Signed-off-by: Florian Gilbert <flg@odoo.com>
Gorash