| Age | Commit message (Collapse) | Author |
|---|
|
opw-2312139
The Andhra Pradesh state code change from 28 to 37
Source :https://ddvat.gov.in/docs/List%20of%20State%20Code.pdf
closes odoo/odoo#55793
X-original-commit: dceec1a565d15514d58b9792f3e9632680509042
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
|
|
Reverse charge is a mechanism under which the recipient of the goods or services is liable to pay the tax instead of the provider of the goods and services.
|
|
Task 2198388
When testing and demoing localization, it can but cumbersome to create a
Company with the right credentials and install the chart of account on
it.
This commit aims to shorten the process. The first version only contains
a valid vat (or similar) number, but we should add fields specific to
localization in the future so that we have a working environment as soon
as we install the localization.
change manifest
closes odoo/odoo#48102
Signed-off-by: Josse Colpaert <jco@openerp.com>
|
|
From saas-13.1 country_id is removed from tax.report.line and report_id is introduce from https://github.com/odoo/odoo/commit/ef0488ef91161eba5267ea29fa5c6b379c483f29 this commit.
So change accordingly in this commit
closes odoo/odoo#46651
X-original-commit: 849f39639cfe1af2c485fa0b4bab9cc4aa7ef359
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
Add zero rated tax report line so we show 0% tax line in report
here problem is when 0% tax is created then no tax line is there so this fix is needed.
closes odoo/odoo#46408
Opw: 2200619
X-original-commit: a0e2afd5c552a0703da5f94c2ea342907cd83599
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
|
|
task-id: 2028z813
|
|
- Introduce a new account.tax.report object
> Tax report lines now refer to a tax report, and the tax report to a country
- Tax report lines can share tags accross reports within the same country
> To support the cases where some report is a simplified version of another one: some of its lines can be computed in the same way as the 'bigger' report.
> This is done by giving the same tag_name to the tax report lines, and the same country_id to their parent report.
> Full support for tag name modification, and the way it impacts the shared tags (sometimes, we can overwrite them all, sometimes we must delete them, sometimes, we create new tags to replace them on some report lines).
- Support copying tax report (and the lines/tags linked to it), so that it is possible to duplicate them and change the country set on the duplicate for use in another country (coopying is way better as replacing in place, as we don't keep any link to an xmlid, and still allow using the original report in the original country it was created for).
- Make all l10n* modules compatible with those changes
closes odoo/odoo#38964
Related: odoo/enterprise#6217
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
|
|
Before this commmit:
Show wrong value in Tax report
After this commit:
Show right value of taxes in Tax report
closes odoo/odoo#37673
X-original-commit: 67ad5e1ecbcb9aee3f47c400b82b9df989c05d78
Signed-off-by: Josse Colpaert <jco@openerp.com>
|
|
closes odoo/odoo#37671
X-original-commit: d4dc7ae8285e6ab65f168e61650ef89ebdb2268d
Signed-off-by: Josse Colpaert <jco@openerp.com>
|
|
closes odoo/odoo#37372
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
closes odoo/odoo#37314
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
need seperate lines with different labels(SGST and CGST) on the invoice report and pos receipt
so use a tax group instead of repartition line
closes odoo/odoo#37080
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
|
|
|
|
- This commit moves the Payment Term "End of Following Month" from
demo data to data and adds two new Payment Terms: "21 Days" and
"30% Now, Balance 60 Days".
It allows the customer to define less Payment Terms
task-2032586
|
|
|
|
Before, we only had a public method that installed
the CoA for the current active company.
With the multi-company changes, it was not
possible anymore to install a module with a
demo company and then have the CoA installed
in that demo company correctly.
We changed that public method to be able to
put an extra optional parameter and shortened
its name to try_loading instead of
try_loading_for_current_company. The method that
it calls when there is no chart installed
is made private and renamed to _load.
closes odoo/odoo#35703
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
[IMP] l10n_*: don't define accounts or tags on tax repartition line templates anymore for 0% taxes
[FIX] account: remove old function used to migrate the former tax model, incompatible with the new one
|
|
A new feature[*] in point_of_sale (PoS) which minimizes the
creation of account.move records in closing a pos.session relies
on a receivable account made specifically for PoS.
This commit addresses this feature's requirement by adding a
new receivable account to each localization.
[*] point_of_sale: single AE for a pos.session
TASK-ID: 1862388
|
|
closes odoo/odoo#35067
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
|
|
closes odoo/odoo#35119
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Writing the country_id of the main company in demo data disables demo
data installation if installing multiple l10n, this is caused by a wrong
check of the vat field (base_vat).
Two approaches can be used here:
- Always write on country_id in all l10n demo data
NB: this also implies writing the country_id first in order for the
vat check to be done using the right country code
- Never write on country_id in any l10n demo data
The prefered approach for the moment is to never write on the country_id
of the main company.
This approach is easier to apply as it is a mimimal diff and the first
approach would require deeper changes to the code in order to allow
writing all the information in a single `record` tag in the demo data
closes odoo/odoo#34905
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
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
|
|
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
|
|
Purpose
=======
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
=============
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@odoo.com>
|
|
- 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
closes odoo/odoo#32833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
(beaa30a3d1843de43a45f419bfbc1bfa7613a920)
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
|
|
|
|
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closes odoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
closes odoo/odoo#28816
|
|
|
|
data creation is faster when done through a CSV file than an XML file, hence doing it through a CSV
was task# 1909961
|
|
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)
closes odoo/odoo#30332
|
|
- Add demo data in the field HSN/SAC Code and HSN Description into the products.
Related Task : 1948171
|
|
Before this commit, the demo data in the
Italian localization would give errors,
because it was setting fields incompatible
with the company being Indian.
It is better not to do this and leave it empty.
(Indian localization is the only to do this)
closes odoo/odoo#32781
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
This commit changes the mechanism to get the transfer account.
As the bank/cash accounts, the transfer account is now created automatically based on
a prefix.
-task: https://www.odoo.com/web#id=35857&action=333&active_id=967&model=project.task&view_type=form&menu_id=4720
|
|
|
|
aka 'Indian localization out of the box'.
Details:
GST introduced, module refactored.
Update GST chart of account, tags and SGST, CGST & IGST taxes.
Replace vat label with GSTIN in reports & views.
Added HSN Code field and display it on invoice form view & report.
Added pin number field in res_country_state.
Show the total amount in words based on Indian numbering system on form view of customer/supplier invoice/refund.
Arrange address format of India country.
l10n_in_schedule6: Introduce new GST taxes, chart of accounts & account tags.
l10n_in_sale, l10n_in_purchase, l10n_in_stock: added modules to add hsn code and replace vat with gstin in sale, purchase & stock reports
Was task: 33241. Was PR #18952
|
|
reports
Each tax is linked to a tax group. Each tax group is display separately with the corresponding amount when the business reports (invoices/sale orders) are printed.
NB: Because each tax is now linked to a tax group. Every localization have been updated according it.
task: https://www.odoo.com/web#id=30501&view_type=form&model=project.task&action=333&active_id=131&menu_id=4720
PR: #16724
|
|
Purpose
=======
Accounting reports are quite confusing for an accountant as the menuitems doesn't to have a clear structure.
Specifications
==============
Move all the localizations menuitems to the first position under `Reporting`
Put the `US GAAP` report menuitem items under the localizations and rename it accordingly
|
|
A little bit a reorganization, typo correction, menuitems uniformization between localizations, useless menuitems removal.
|
|
There was a traceback error while installing the indian accounting module.
The commit 9c77467f07c351b35035f3d75e4abf274e901c51 shouldn't have been forwarded.
This cancels some account tag ids modifications from the commit 500b73323d3bdd4eb59649d2db8864f8c2e8b9fa. (this commit refactors the account tag id numbering)
This implies that some st_tag_in_[0-9]* point to an old references that no longer exist and return an error.
To fix this problem, we replaced the old(canceled) account tag reference by those after the refactoring in saas-14.
|
|
|
|
|
|
|
|
|
|
|
|
[MIG] l10n_ae : Migrated to new API.
[MIG] l10n_ar : Migrated to new API.
[MIG] l10n_at : Migrated to new API.
[MIG] l10n_au : Migrated to new API.
[MIG] l10n_be : Migrated to new API.
[MIG] l10n_bo : Migrated to new API.
[MIG] l10n_br : Migrated to new API.
[MIG] l10n_ca : Migrated to new API.
[MIG] l10n_ch : Migrated to new API.
[MIG] l10n_cl : Migrated to new API.
[MIG] l10n_cn : Migrated to new API.
[MIG] l10n_co : Migrated to new API.
[MIG] l10n_cr : Migrated to new API.
[MIG] l10n_de : Migrated to new API.
[MIG] l10n_de_skr03 : Migrated to new API.
[MIG] l10n_de_skr04 : Migrated to new API.
[MIG] l10n_cn_small_business : Migrated to new API.
[MIG] l10n_cn_standard : Migrated to new API.
[MIG] l10n_do : Migrated to new API.
[MIG] l10n_ec : Migrated to new API.
[MIG] l10n_es : Migrated to new API.
[MIG] l10n_et : Migrated to new API.
[MIG] l10n_fr : Migrated to new API.
[MIG] l10n_generic_coa : Migrated to new API.
[MIG] l10n_gr : Migrated to new API.
[MIG] l10n_gt : Migrated to new API.
[MIG] l10n_hn : Migrated to new API.
[MIG] l10n_hr : Migrated to new API.
[MIG] l10n_hu : Migrated to new API.
[MIG] l10n_in : Migrated to new API.
[MIG] l10n_it : Migrated to new API.
[MIG] l10n_jp : Migrated to new API.
[MIG] l10n_lu : Migrated to new API.
[MIG] l10n_ma : Migrated to new API.
[MIG] l10n_mx : Migrated to new API.
[MIG] l10n_nl : Migrated to new API.
[MIG] l10n_no : Migrated to new API.
[MIG] l10n_nz : Migrated to new API.
[MIG] l10n_pa : Migrated to new API.
[MIG] l10n_pe : Migrated to new API.
[MIG] l10n_pl : Migrated to new API.
[MIG] l10n_ro : Migrated to new API.
[MIG] l10n_sa : Migrated to new API.
[MIG] l10n_sg : Migrated to new API.
[MIG] l10n_si : Migrated to new API.
[MIG] l10n_syscohada : Migrated to new API.
[MIG] l10n_th : Migrated to new API.
[MIG] l10n_tr : Migrated to new API.
[MIG] l10n_uk : Migrated to new API.
[MIG] l10n_us : Migrated to new API.
[MIG] l10n_uy : Migrated to new API.
[MIG] l10n_ve : Migrated to new API.
[MIG] l10n_vn : Migrated to new API.
|
|
[MOV] l10n_ae : Re-organized directory structure.
[MOV] l10n_ar : Re-organized directory structure.
[MOV] l10n_at : Re-organized directory structure.
[MOV] l10n_au : Re-organized directory structure.
[MOV] l10n_be : Re-organized directory structure.
[MOV] l10n_bo : Re-organized directory structure.
[MOV] l10n_br : Re-organized directory structure.
[MOV] l10n_ca : Re-organized directory structure.
[MOV] l10n_ch : Re-organized directory structure.
[MOV] l10n_cl : Re-organized directory structure.
[MOV] l10n_cn : Re-organized directory structure.
[MOV] l10n_co : Re-organized directory structure.
[MOV] l10n_cr : Re-organized directory structure.
[MOV] l10n_de : Re-organized directory structure.
[MOV] l10n_de_skr03 : Re-organized directory structure.
[MOV] l10n_de_skr04 : Re-organized directory structure.
[MOV] l10n_cn_small_business : Re-organized directory structure.
[MOV] l10n_cn_standard : Re-organized directory structure.
[MOV] l10n_do : Re-organized directory structure.
[MOV] l10n_ec : Re-organized directory structure.
[MOV] l10n_es : Re-organized directory structure.
[MOV] l10n_et : Re-organized directory structure.
[MOV] l10n_fr : Re-organized directory structure.
[MOV] l10n_generic_coa : Re-organized directory structure.
[MOV] l10n_gr : Re-organized directory structure.
[MOV] l10n_gt : Re-organized directory structure.
[MOV] l10n_hn : Re-organized directory structure.
[MOV] l10n_hr : Re-organized directory structure.
[MOV] l10n_hu : Re-organized directory structure.
[MOV] l10n_in : Re-organized directory structure.
[MOV] l10n_it : Re-organized directory structure.
[MOV] l10n_jp : Re-organized directory structure.
[MOV] l10n_lu : Re-organized directory structure.
[MOV] l10n_ma : Re-organized directory structure.
[MOV] l10n_mx : Re-organized directory structure.
[MOV] l10n_nl : Re-organized directory structure.
[MOV] l10n_no : Re-organized directory structure.
[MOV] l10n_nz : Re-organized directory structure.
[MOV] l10n_pa : Re-organized directory structure.
[MOV] l10n_pe : Re-organized directory structure.
[MOV] l10n_pl : Re-organized directory structure.
[MOV] l10n_ro : Re-organized directory structure.
[MOV] l10n_sa : Re-organized directory structure.
[MOV] l10n_sg : Re-organized directory structure.
[MOV] l10n_si : Re-organized directory structure.
[MOV] l10n_syscohada : Re-organized directory structure.
[MOV] l10n_th : Re-organized directory structure.
[MOV] l10n_tr : Re-organized directory structure.
[MOV] l10n_uk : Re-organized directory structure.
[MOV] l10n_us : Re-organized directory structure.
[MOV] l10n_uy : Re-organized directory structure.
[MOV] l10n_ve : Re-organized directory structure.
[MOV] l10n_vn : Re-organized directory structure.
|
