These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
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>
For Mexican localization, activate by default the setting display_invoice_amount_total_words for the Mexican localization. As this localization uses its own amount to words function, the related commit enables an override of the generic function to use it correctly with Mexican localization.
For the other mentioned localizations (ua,in,dz,ma), the setting was already activated but overriding the create method was not a proper way of doing.
task - 3367243
closesodoo/odoo#124909
X-original-commit: 6ee9842764e0b1244927cb8ece1f6407ccec20d5
Related: odoo/enterprise#42510
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: hupo-odoo <hupo@odoo.com>
* l10n_ae, l10n_ar, l10n_at, l10n_au, l10n_bg, l10n_br, l10n_ch,
l10n_cl, l10n_dk, l10n_es, l10n_hu, l10n_in, l10n_mn, l10n_nl, l10n_no,
l10n_pt, l10n_sa, l10n_se, l10n_sg, l10n_si, l10n_uk
Some localizations do not have any default account for tax closing.
This leads to the opening of a RedirectWarning when trying to do a tax
closing.
task-3082332
closesodoo/odoo#124003
X-original-commit: 14abe7acb11d522fb2b4a274ac0eb06d41e637ed
Related: odoo/enterprise#42071
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
With this commit, Made the tree line clickable instead of clicking View Related
Document Button. Updated the description, to be similar to chatter in audit trail
tree view. Also Updated error message while deleting entries once it's posted for
Indian Company.
closesodoo/odoo#122566
X-original-commit: 8833329191acc56468a62b3f00171c14d0252eb7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nishant Jain(niai) <niai@odoo.com>
Cash basis taxes use a distinct transition account on their tax lines; the tax account set on the repartition lines is only used when the payment is received, on the cash basis move.
In enterprise, the bank reconciliation widget allows setting a tax on the manual write-off done for a statement line. When doing so, we expect the tax to behave just like on an invoice. For cash basis taxes, this means the "final" tax account has to be used instead of the transition one ; it wasn't the case.
OPW 3255511
X-original-commit: 991fa46081296c3560bd7ca195996693a81a46b8
Part-of: odoo/odoo#120924
In Indian government required audit trail report for private limited companies
So from this commit user can't delete journal entries after posting once.
Create an audit trail report from mail.message to show a full log of journal entries
task - 3239932
closesodoo/odoo#118945
X-original-commit: f4365ee1c6e979e352ece66b03f3c00e830f2117
Signed-off-by: Josse Colpaert <jco@odoo.com>
A lot of the separate files were kept up to now because it made the
process easier while applying the script to rebase.
The files can now be merged.
Some code is also cleaned by using CSV instead of a python dict.
Part-of: odoo/odoo#114164
1. Install [Expenses], [Indian - Accounting], [Accounting] on Apps
2. [Settings] [Users & Companies] [Companies]
- create a company based in India with address there
3. Enter [Expenses], [CREATE]
- create and add an employee w contact info (private address) in India
- set paid by: Company, write an amount, category > [CREATE REPORT]
- [SUBMIT TO MANAGER] [APPROVE] [POST TO JOURNAL ENTRIES]
4. Click on the [Journal Entry] created at the top right corner
Issue: Missing pos field hinders revising it by [reset to draft]
Resolve by: change the requirement in view and enable further revision
Impacted versions: 16.0 up to master
opw-3168426
closesodoo/odoo#113270
X-original-commit: bc08a6e9d0cc42d1586913bf95d01d4547c13b05
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
As it is now possible to activate the total amount of an invoice in letters, these localizations (dz,in,ua,ma) need by default the feature to be activated. In addition, some of them had aleady such feature which has therefore been removed to accommodate the new generic feature.
The indian localization also has a different message on the right side of QR code on invoices
closesodoo/odoo#107714
Task: 3097097
Pr: 107714
Related: odoo/enterprise#35959
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
After this commit GST treatment will be only assigned to Indian invoices/bills.
closesodoo/odoo#111738
X-original-commit: 6ede766eab05b621bfee6e6af259c7d2d0bfbd94
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit
==================
GST Treatment will not be assigned to those invoices/bills
whose partners don't have GST Treatment.
After this commit
=================
GST Treatment will be assigned to those invoices/bills whose
partners don't have GST Treatment.
closesodoo/odoo#111528
X-original-commit: de944b54715db0a0b6898fb9b049449c5ced29c9
Related: odoo/enterprise#36555
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit
==================
all the settings of Indian integration like E-waybill,and e-invoice were
having different setting blocks.
After this commit
=================
all the Indian integration settings will be shown in one setting block.
closesodoo/odoo#111175
Related: odoo/enterprise#36382
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Currently, the Place of supply value is set from the partner state for all journal types.
So in this commit, we set the partner state in `Place of supply` only when
the journal type is a sale. Also added the country domain in XML view.
Part-of: odoo/odoo#109717
We just set a place of supply(state_id) from partner_id in the Invoice/Bill if partner country is india because there are many complex cases so we can't get it automatically in all cases like
(a) where the supply involves movement of goods, whether by the supplier or
the recipient or by any other person, the place of supply of such goods shall be the
location of the goods at the time at which the movement of goods terminates for
delivery to the recipient;
(b) where the goods are delivered by the supplier to a recipient or any other
person on the direction of a third person, whether acting as an agent or otherwise,
before or during movement of goods, either by way of transfer of documents of title
to the goods or otherwise, it shall be deemed that the said third person has received
the goods and the place of supply of such goods shall be the principal place of business
of such person;
(c) where the supply does not involve movement of goods, whether by the
supplier or the recipient, the place of supply shall be the location of such goods at the
time of the delivery to the recipient;
(d) where the goods are assembled or installed at site, the place of supply shall
be the place of such installation or assembly;
(e) where the goods are supplied on board a conveyance, including a vessel, an
aircraft, a train or a motor vehicle, the place of supply shall be the location at which
such goods are taken on board.
we add new state "Other Country" to set place of supply(state_id) incase of partner country is not India
for more details check CHAPTER V here https://www.cbic.gov.in/resources//htdocs-cbec/gst/igst-act.pdf;jsessionid=63D695F612B9972934E8131415FEBA28closesodoo/odoo#82011closesodoo/odoo#109286
X-original-commit: https://github.com/odoo-dev/odoo/commit/b76ee098e2a4c4d26d6d1c689bb0750e770201dc
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
In this commit, the following points are covered
- updated error messages
- remove renaming the `Customer Invoices` journal name
- updated Fiscal Opening Date and Year End for Indian localization
- updated Indian E-Invoicing report and settings setup
Part-of: odoo/odoo#109396
In this commit, we have removed the multi-GSTIN feature from the journal.
Multi-unit is created if there is a different branch with the same GSTIN(vat) so
now we decided to create a multi-company instead of this.
because functionally we discuss with Indian CA and we find out that it's good
practice if we create a different company.
The main problem is one company and the same Bank account but we also find a
functional solution using a transfer balance to another company.
so we remove this so our other integrations do not have complexity
like E-invoice, E-waybill, GST E-filing
TaskID - 2723109
closesodoo/odoo#107234
Related: odoo/upgrade#4107
Signed-off-by: Josse Colpaert <jco@odoo.com>
Companies only get a tax credit on the bill to GST number(vat), not on the shipping GST number.
task - 2723111
closesodoo/odoo#81977
Related: odoo/upgrade#3493
Signed-off-by: Josse Colpaert <jco@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
With this commit: we are changing fiscalyear_last_month to March if
chart template is Indian chart template as fiscal year ends in 31 March
in India.
task-2723849
closesodoo/odoo#81982
Signed-off-by: Josse Colpaert <jco@odoo.com>
add get warehouse address method
needed in Indian EDI to pass value of dispatched address
improve demo data and bypass one GST number from validation because that GST number use to test EDI
Add Non GST Supplies and State CESS tax report line
Non-GST Supplies and State CESS is required to get related value from the invoice for send EDI
Part-of: odoo/odoo#79995
Unify taxes computation between 'account', 'sale' and 'purchase' including:
- computation of price_subtotal/price_total.
- computation of business models total (using the json field)
closesodoo/odoo#80231
Task: 2654784
Related: odoo/enterprise#25620
Signed-off-by: Olivier Colson <oco@odoo.com>
l10n doesn't depend of stock so move it to l10n_stock to have
correct dependencies
closesodoo/odoo#84173
X-original-commit: f1c55ec86102bfd52730f34eb19d002d4e22a3d2
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The commercial invoice is usually only needed when the country of the
sender is different from the country of the recipient, however, for india,
commercial invoice is mandatory, even if the goods dont leave the country:
https://cleartax.in/s/commercial-invoice/#commercialclosesodoo/odoo#82084
Signed-off-by: Arnold Moyaux <arm@odoo.com>
How to reproduce:
- Switch to an Indian-based company
- Create a non-Indian customer and set gst treatment
- Create a subscription for the new customer
- Generate an invoice for the subscription
- The gst-treatment field will be empty
Bug:
When creating a new account.move object, the gst treatment is not copied.
closesodoo/odoo#80966
Opw: 2662308
X-original-commit: a1f0ae25f8b96a5ff5691aa0b9ffeb62033932bf
Signed-off-by: Laurent Smet <las@odoo.com>
Slightly change the view of account_invoice_report to add
a CTE to prefilter rows before joining with account_move_line.
Add a multicolumn for (product_id, move_id) on account_move_line
to speed-up cess_amount computation.
closesodoo/odoo#77952
X-original-commit: 7b743fbb7a98c45f12979c6c5ac7baa7c34d421a
Signed-off-by: Josse Colpaert <jco@openerp.com>
We need quantity in tax line and we added from this PR https://github.com/odoo/odoo/pull/73402
but after it creates a problem in tax amount
because in tax line, the unit price is set base on quantity and by default is 1 but after PR 73402 it's the same as invoice line so rounding issue is there and this rounded amount is multiplay by quantity so this creates a big difference
before PR 73402:
Name | unit price | quantity | taxable amount |
=====================================================
Product A | 5.55 | 8000 | 44400 | (invoice line)
Tax 5.0% | 1 | 8000 | 2220 |
```
After PR 73402:
Name | unit price | quantity | taxable amount |
=====================================================
Product A | 5.55 | 8000 | 44400 | (invoice line)
Tax 5.0% | 0.27 | 8000 | 2160 |
So in this PR we remove quantity from grouping key
closesodoo/odoo#74818
X-original-commit: aa160f4c0a04500bd91eea8da2cec165a15270a6
Signed-off-by: Josse Colpaert <jco@openerp.com>
This is already there before refactoring in saas-12.4
you can check here https://github.com/odoo/odoo/blob/saas-12.3/addons/l10n_in/models/account_invoice.py\#L73
also add id in group by becouse if there is invoice line have same product,qty and uom then qty is wrong.
For example:
we have there is the same product with the same quantity and UOM like
```
Product | quantity | UOM
=========================
Mobile | 2 | Unit
Mobile | 2 | Unit
```
then tax line is not split so report count qty is 2
opw-2563120
closesodoo/odoo#73803
X-original-commit: 49e6bc9c499a511d479282dc67c1560e1c6bae5b
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Jigar Vaghela <jva-odoo@users.noreply.github.com>
Before, account_fiscal_country_id was only use for tax operations; and country_id was used for all the other accounting stuff. Now, with the new ability to use foreign tax reports (with foreign VAT fiscal positions), we can generalize the fiscal country, sot that it is the one that needs to be used for the whole accounting. Since foreign tax reports were not supported before, account_fiscal_country_id is already set on existing database as the country for the "main" accounting, so the impact of this change is small.
closesodoo/odoo#68349
Related: odoo/upgrade#2322
Related: odoo/enterprise#17299
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This below case is not working before this commit:
when Bill to Ship to where Delivery address partner is not registered and not have GSTIN
closesodoo/odoo#65599
X-original-commit: d9b409247303c6b165a7df381169f2480a19900f
Signed-off-by: Josse Colpaert <jco@openerp.com>
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
GST Treatment:
* Is show that how This invoice or partner is treated in GST
* Set default value in customer
* This is help in GST retrun filing.
* Value of treamtmnet as below
- Registered Business - Regular
- Registered Business - Composition
- Unregistered Business
- Consumer
- Overseas
- Special Economic Zone
- Deemed Export
* GSTIN is required in
- Registered Business - Regular
- Registered Business - Composition
- Special Economic Zone
- Deemed Export
GSTIN:
* GST identification number or GST number
* There can be multiple GSTIN for a single person, being an assessee under the Income Tax Act for every State or Union Territory in which such person operates from
* Add Validate of this number using regular expression
remove field l10n_in_export_type and l10n_in_import_export becouse it's covered by GST Treatment
remove field l10n_in_partner_vat becouse not use anyware.
There are few fields added on settings and on company form view
by various l10n modules which are meant for particular country's
user and are of no use to others. Such fields should be hidden
from unrelated users. With this commit, it will be the case.
closes odoo/odoo#35755
Task: 2049977
Closes: #35755
Related: odoo/enterprise#5158
Related: odoo/enterprise#5158
Signed-off-by: Josse Colpaert <jco@openerp.com>
tax grouping key from base and tax line that will be used as a key to group taxes together
so both functions must have the same dictionary key. (you can check comment here https://github.com/odoo/odoo/blob/13.0/addons/account/models/account_move.py#L412)
here we have three key (product_id,product_uom_id,quantity) in _get_tax_grouping_key_from_base_line
and only one key (product_id) in _get_tax_grouping_key_from_tax_line
so we get wrong tax calculation
now we remove that extra key(product_uom_id, quantity) because we don't need group by these key values.
closesodoo/odoo#41340
X-original-commit: a758e5eace55bad0c11f8a27ba83e8367d293487
Signed-off-by: Josse Colpaert <jco@openerp.com>
Fine tuning of 7bea912
In india there are as many tax lines on an invoices as there are
repartition lines (classic) * products
So, before this commit, preventing adding the base if tax was already seen
was not enough, the base was still added many times
After this commit, hopefully, the based on amount is correct for each tax
Forward port of #37390closesodoo/odoo#37784
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
=======
Purpose
=======
government rule that "GST registration should be obtained by a taxable person under GST in each of the State or Union Territory, from where the taxable supply of goods or services is made"
So we managed this using journal
User create journal and partner for other states
After user can select journal in Sale order, Purchase order and warehouse
========
Solution
========
-Add a field on the journal to define the GSTIN
-Add sale and purchase journal field in warehouse
-On the SO/PO, add the journal field and based on the warehouse journal it set automatically fill if warehouse journal is set.
task 1917619
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
- Add repartition lines on taxes
- Link account tags directly to account.move.line; remove the tag_ids field from account.tag
- Add a new report engine dedicated to tax reports, directly generating account tags. It is called as an alternate mode of generic tax report, with a dedicated "Use tax grids" toggle.
>> The biggest change lies in the way the new tax report computes its values.
Everything is now aggregated directly using the tags set on the account move lines. Thanks to that,
modifying the configuration of a tax today will not impact the report for the previous periods anymore.
This is a big improvement, as it means the report will keep on reflecting the values that were submitted
to the state before, whatever the configuration change.
- Add an audit char field to account.move.line telling with tax grids are impacted by the line, with the corresponding amount
- Modify the behavior of cash basis taxes: the cash basis account is now used as the transition account, while the regular account given in tax declaration is used to store the final entry (it was the opposite before)
- Modify every l10n_* module in order to keep them consistent with these changes
closesodoo/odoo#32833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Purpose
=======
GST Invoice Report required to show tax amount product line wise.
This Tax amount is divided in CESS and IGST or CGST and SGST.
Improve GST Tax, Tax Groups and Tag.
Reverse charge under GST
As per GST rules tax will have to be paid directly by the receiver to the Government instead of the supplier.
Reseller(E-commerce) under GST
If you sale through ecommerce then need to specify ecommerce GSTIN.
Import/Export goods under GST
If you export the goods then need to specify
-Export Type
-Shipping bill number
-Shipping bill date
-Shipping port code
Credit or Debit Note
If u give Credit or Debit note then need to specify Refund reason.
Place of Supply is the state of customer.
Added GSTR reports
GSTR Invoice report covers below GSTR-1 sections(this report is grouped by tax rate and journal entries
B2B, B2CL, B2CS, EXP, CDNR and CDNUR
GSTR payment report
This report is covered under GSTIR-1 section called AT(advance payment) and ATADJ(advance payment adjustment)
GSTR HSN report(it is based on the product HSN code)
GSTR Exempted report(it is based on nil rated and exempt tax)
This report is covered under GSTIR-1 section EXEMP
Added demo data to to have GSTR-1 reports out of the box
Solution
========
fetched values of CESS, IGST, CGST and SGST amount in invoice report from tax groups
added new taxes called "Nil Rated" and "Exempt" and also added it's related tax groups and accounts
added tax tags related to GST tax percentage
Set Reverse charge in negative tax
Improved account move line creation grouping machenism:
Now, move lines related to tax are grouped by product and uom instead of grouping them just by tax(this is for better reporting)
closesodoo/odoo#30332
Gorash