Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this change we were letting the user to create a journal with a
AFIP POS Number they like, and where they try to post an invoice in that
jounrals they receive an error message telling that the document has not
valid POS Number.
In order to avoid this we add as part of the constraint where we check
the validity of the AFIP POS Number which is: should be greater that 0,
and should be 5 digits max.
closesodoo/odoo#44433
X-original-commit: 3e991fb4ceb02eeb41ed6579ac409f9595663c41
Signed-off-by: Josse Colpaert <jco@openerp.com>
The law itself said that you can use 4 or 5 digits, but some customers
complains that they want 5 (for eg. 00001) because some suppliers reject
the invoice if only 4 digits (that is wrong, but suppliers do anything
to avoid paying).
We've check and AFIP online invoices use 5 digits always. So, to satisfy
customers/suppliers and make code simpler, we think using 5 digits is a
better option.
X-original-commit: a475de89568c8274bb556d672948b25a95996599
When create an invoice for a foreign customer, the document types are not showed and filtered. This is happening because there is not journal defined for exportation operations. Once this one is created all the proper filters for the document types and journals are working ok.
This PR add a redirect warning when trying to create an invoice for a foreign partner when we do not have defined the expo sale journal. This also alert the user that is a missing configuration that is affecting to the compute of the available document types. I applied the same for the local/intern case
closesodoo/odoo#43913
X-original-commit: c7bd13bbd2879dded677bb223ff857fb9c959c60
Signed-off-by: Josse Colpaert <jco@openerp.com>
This kind of companies (because of the AFIP responsibility type) should not have purchase tax defined by default and before this commit we have a default purchase tax named perception with actually is a optional tax that the user could set if needed but should not be set automatically set as default in all the invoice lines. This commit remove this default purchase tax when loading the chart of account to avoid this bad behavior.
closesodoo/odoo#43832
X-original-commit: b6df9291555ac79b6f1d64cb27235d8191d710b8
Signed-off-by: Josse Colpaert <jco@openerp.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The exportation invoices demo data was created in the "Sales Journal" journal instead of the "Exportation Sales Journal". To fix this we have added the xml id of the journal explictly to fix this.
closesodoo/odoo#43329
X-original-commit: 4ab91233d64990cd9991d2f8c4fb1ba4a1a51a67
Signed-off-by: Josse Colpaert <jco@openerp.com>
The Foreign partner used in demo data was wrognly configure, it was set as "IVA Responsable Inscripto" when actually should be "Cliente / Provedor del Exterior".
After fix this in demo we updated the demo data of the vendor bills of this partner to match with the new responsibility.
Also apply and imporve in the way we are setting the fiscal position in the demo invoices, now qw use the onchange instead of setting the fiscal position explicitly in the demo invoices (and removed commented demo data that is not used)
closesodoo/odoo#43301
X-original-commit: 23e2824794b64624c8dbb1b8132d443657781830
Signed-off-by: Josse Colpaert <jco@openerp.com>
This will be use to make testing of the MiPyme FCE document types
closesodoo/odoo#43080
X-original-commit: 4365bd25512082bfd70229272c7248720f0383ca
Signed-off-by: Josse Colpaert <jco@openerp.com>
Now use direclty the posted state from account move.
* This was changed in a constraint in l10n_latam_invoice_document module, also extend the constraint docstring
* This old states where also in a view domain in l10n_ar module for account.move view. We remove the field for the view (AFIP Responsibility) instead of fix the state name.
closesodoo/odoo#42982
X-original-commit: 33a5cfe068323f7fc4c92f42fadb8e236954d93a
Signed-off-by: Josse Colpaert <jco@openerp.com>
The purpose of this partner is that we do not need to report to AFIP the identification number.
Since this partner identification was configured as DNI it was throwing an error when validate an invoice for that partner in AFIP, AFIP was requesting us to sent the DNI number.
Now we activate the Sigd "Sin identificar/venta global diaria" identification type (code 99), proper configure the it to Anonymous Final Consumer partner, with this change AFIP validate the invoice directly and does not request us the identification number.
Now we set this partner sequence to the biggest one so far to show this identification type as the last in the list of identifications types
closesodoo/odoo#42981
X-original-commit: 842306b06984f4357f9e3cfdbb58bad828a1a627
Signed-off-by: Josse Colpaert <jco@openerp.com>
This is usefull for tests invoicing cases.
closesodoo/odoo#42169
X-original-commit: 32b443752dd0fb1ceda3e05da0d878bf908ebf8a
Signed-off-by: Josse Colpaert <jco@openerp.com>
Commit 2106dd3cd1 changed the model of
account.move.reversal but didn't change the demo data of l10n_ar
X-original-commit: ea4bfe662c4a9f5a033712ed3e4d17e9e8252ca0
It's only for some use cases like paying a hotel or buying food
closesodoo/odoo#41888
X-original-commit: d076973fa48af000ead55019448de5261e2a766e
Signed-off-by: Josse Colpaert <jco@openerp.com>
When creating vendor bills, it was considering this two numbers as different but actually are the same invoice number
* 01234-00000001
+ 1234-00000001
To avoid this we remove the zero to the left always if the pos number > 4.
closesodoo/odoo#41436
X-original-commit: 15543ebbdeb7fac2cbf60bdcafef22a84b937bfb
Signed-off-by: Josse Colpaert <jco@openerp.com>
If avaliable will use the stdnum.ar.cbu.validate functionality, if not
we defined our own validate method.
closesodoo/odoo#40998
X-original-commit: 9c389525e1c334505c8edf7276826c1b37ae0a1c
Signed-off-by: Josse Colpaert <jco@openerp.com>
Currently all the countries that match between odoo and AFIP list where
set with the respective value.
This commit add the AFIP code field to both tree (for consult) and form
view (in developer mode only) to let the user the posibility to set/edit this
field for any of the next cases:
* need to consult the code.
* need to be changed.
* need to create a new country that exist in AFIP list and not in odoo
and need to add the related AFIP code
closesodoo/odoo#40532
X-original-commit: 1b95bfe202576583d6458c6bd1a707dd988e6d95
Signed-off-by: Josse Colpaert <jco@openerp.com>
Since stdnum.ar.cbu is not available in odoo saas enviroment because is
using an old version of stdnum package, we add a try exept in order to
catch this and manage the error properly which is raise an exception and
leave a message in the log telling the user that the cbu was not able to
validate.
closesodoo/odoo#40383
X-original-commit: 25d483fc3fc05fd47c72c3d96c02fed12b998b0d
Signed-off-by: Josse Colpaert <jco@openerp.com>
This ones were inactive by default, we think that need to be active in
order to be able to be added to vendor bills.
Also change the amount from 0.0 to 1.0 of all the perception tax
templates to make it appears in the manual taxes widget when they are
addes to the invoice/bills lines.
closesodoo/odoo#39400
X-original-commit: ff70835db4f6354de62a00dc717682c2835a105c
Signed-off-by: Josse Colpaert <jco@openerp.com>
60 is different of 060. The 060 is the correct value for the afip code
in this case (EUR). Apply to all the numeric values in the currency afip
codes.
closesodoo/odoo#38953
X-original-commit: 8c47c7f0342b985287da86f7955a52ef05a6ba0d
Signed-off-by: Josse Colpaert <jco@openerp.com>
companies.
We revert the change we apply in order to let the user to define their
own fiscal positions, now the fiscal position will be set depending on
the afip responsability.
With this change we fix the error that the fiscal position is properly
setted for the customers that are of type "Responsable Inscription" and
"Consumidor Final".
Before this change the "Compras / Ventas en el Exterior" fiscal position
was wrongly seted, now the fiscal position is leave empty so the related
invoice taxes are properly matched
closesodoo/odoo#38830
X-original-commit: 74f172041351e03f60b1aff0f0eb925e896cd1fa
Signed-off-by: Josse Colpaert <jco@openerp.com>
- AFIP code in UOMS saved as char
- fix missing account_id in demo data
- Remove demo data that was throwing error
- merge res country data to csv file.
- move res currency AFIP code data to csv file
closesodoo/odoo#37457
Signed-off-by: Josse Colpaert <jco@openerp.com>
l10n_latam_base:
* update translations
* extend manifest
* update manifest, delete new menus/fields/models from manifest
l10n_latam_invoice_document:
* update translations
* remove filter journals for recipts
* make method private
* extend manifest
* update manifest, delete new menus/fields/models from manifest
* misspelling error in ValidationError
* fixup missing change apply before merge/rebase
l10n_ar:
* make method private
* update translations
* catch error when stdnum.ar.format
* fiscal position with criteria diff from Responsibility
* Install AR CoA now set properly the company values.
* add meaning of CUIT when mentioned in code.
* unse a simplier elif and less conditions to evaluate
* only get concept for invoice lines that are not section/note
* remove TODO comments, this will be not implemented in this version
* update to sincular al the AFIP POS System options
* return match responsability type directly
* improve of manifest
* reference to tax group
* remove old not used file fot tax report
* update comments from spanish to english
* only set afip serive date when post the account.move
* unused file
* sum recordsets instead of union
* method name and remove log
* update manifest, delete new menus/fields/models from manifest
* Simply extra steps when loading AR COA: check directly
get_ar_responsibility_match in order to apply the extra verifications
and the extra configs in the company
* update demo refences to new demo for odoo
* return missing fix about _l10n_ar_create_document_sequences
* fixup missing change apply before merge/rebase
* set journal data as no update data.
closesodoo/odoo#36137
Signed-off-by: Josse Colpaert <jco@openerp.com>
Now, it depends on l10n_latam_base for the identification
types and on l10n_latam_invoice_document for the invoice
numbering.
It is the AFIP responsibility on the partner that
determines the document type.
There are also 3 demo companies for the most important
responsibility types for yourself.
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.
closesodoo/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
- 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>
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28896
Were no longer synchronized since 9.0
Commit 710f67ad4b mistakly reexported them too
Remove the .pot, keep only a few one like it actually makes sesne to have
translated content such as l10n_be_invoice_bba
wan