An update made to the tremol device has changed the expected content of
the price field. It now expects up to 15 characters in this position,
with a maximum of 5 decimal places.
At present we can send prices with a decimal position greater than 5,
doing so will result in an error from the fiscal device.
This commit adapts the content that gets serialised in order to ensure
that the decimal provided is no longer than 5 decimal places.
closesodoo/odoo#161804
Task-id: none
X-original-commit: 3373ac3a7945d25fee70d114816ce23a16d6e0ef
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
With Kenya localization installed
Create an invoice
Send&Print
Issue: The sytem will issue the final pdf before the invoice has been
send to the fiscal device, so the legal information is actually missing
Solution:
1. If the allow_fallback_pdf is True (in case of transaction from the
e-commerce for example) we generate a proforma pdf invoice.
2. Else we raise an error to prevent the user to send invalid invoice.
Also added a warning to let the user know that a proforma will be
generated because the invoice was not sent to the Fiscal Device.
opw-3599869
closesodoo/odoo#151751
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Co-authored-by: Claire Bretton (clbr) <clbr@odoo.com>
The existing implementation for the fiscal device applies a number of
limitations to the content of the invoice in order to ensure the invoice
can be regularised and serialised in such a way as to make it
transmissible to the device.
One of these checks was ensuring that only one tax can be applied per
line. This check was implemented as the device itself only accepts one
tax per line.
This check isn't entirely accurate, since the user should be able to add
taxes such as levies, service charges etc (non-vat taxes) to the the
line, and have them skipped when transmitting the invoice data to the
device.
As such, this commit adapts the code to alter the checks (allowing for
only one 'VAT' tax, and any number of other taxes). The way the price
total is determined is altered to use only the "VAT" tax and base amount
to get the price_total for the line from the corresponding line's tax
details.
This commit also adds a test.
closesodoo/odoo#148397
Task-id: None
X-original-commit: bb3a32c7f45ac5adb3dddf560f6af33f9bca3780
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
These test rely on default generated name of account invoice
that contains the year, e.g. `INV2023`. These tests were passing
in 2023 but no longer on January 1 2024.
closesodoo/odoo#147873
X-original-commit: 94f093c9ae532eb12ef17dc0f37dc5da64a6d7ed
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@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>
Exporting Kenyan invoices in a format readable by the Kenyan fiscal
device creates some complex output. The data is significantly modified
in order to represent an odoo invoice in the native format of the
communication with the device (for instance global discount lines must
be distrubuted accross the existing positive lines of the invoice, since
the device is incapable of representing negative lines).
This commit adds a series of tests designed to ensure the format of the
export is correct, and that the values of these invoices are
represented in a way that best reflects the data on the invoice, whist
being readable by the device.
closesodoo/odoo#116615
X-original-commit: dec8e7e3fefc8e00b916f4be9227a789c2a40b65
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Daniel Kosky (dako)