Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Account reporting, xml file in mexican location #39683

Closed
wants to merge 6,778 commits into from

Conversation

@naomivela
Copy link

naomivela commented Oct 31, 2019

Description of the issue/feature this PR addresses:
I been using account module with mexican location, I configured the all the process that I need but when I try to export the xml file in my reports the information included there is wrong.
I change the name of some accounts included in the chart of accounts but even with any modifications the information inside in xml file is wrong and don't change any información, If i create a new account I can't see in my file, I been doing a lot of configurations but the information I see in xml is always the same.
Current behavior before PR:
The behavior is the same, the información I see in the chart of accounts even with any configuration do not match with the information inside of xml file.
Desired behavior after PR is merged:
I need that the information inside the view will be the same in xml file.
Analysis Specification xml COA Odoo 1.pdf

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Xavier-Do and others added 30 commits Aug 27, 2019
closes #36141

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
#34737 didn't go in enough depth to
ensure sections and notes don't break purchase flows.

closes #38232

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The goal is to improve the project's overview:

    1/ Switch tooltips
    2/ Increase tags size

closes #38804

Taskid: 2086664
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When a BoM is using a component with a quantity required set to 0,
tracebacks were occuring when computing the available quantities
for the kit.

Fixes #38807

closes #38890

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
after this commit :
added a separator at the end of the inherited view

task - 2082289

closes #38254

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
closes #38361

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation.  This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.

However, computing non-stored fields in superuser mode is usually not
necessary.  It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode.  That is why non-stored fields are not computed in
superuser mode by default.

[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.

[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.

closes #38805

Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The basic ORM methods should not silently discard unknown fields, as
they may be a sign of broken code.
closes #37094

Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The nightly clickall runbot fail due to a crash of the underlying chrome
browser used to run the test suite. The problem is related to the
resources the browser is using. We leverage the problem by starting one
dedicated browser per app.

closes #39135

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Updates to the customer display were sent too often:
 - Twice when creating a new order
 - Twice when removing a payment line
 - Every time the status of a payment line with a terminal changed

closes #39179

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Chart of Accounts (COA) Template for Lithuania's Accounting (VAS-15).

Data is multi language (English and Lithuania).

This module also includes:

* List of available banks in Lithuania.
* Tax groups (to map different tax amounts).
* Most common Lithuanian Taxes.
* Fiscal positions for different countries/groups.
* Account Tags used for reporting purposes.

closes #39181

X-original-commit: 888245f
Signed-off-by: Josse Colpaert <jco@openerp.com>
Raising a python error cannot stop an uninstall, however since the
unlink stops early, the calls to super() are never reached, this
prevents the deletion of module-related data and leaves crap in the
database, not to mention that it potentially prevents the reinstallation
of a module because of duplicate data with unique IDs, which is the case
for mail.

With this patch, we let the registry delete everything related to the
mail module when uninstalling, which allows for its reinstallation.

Fixes #25138

closes #39090

Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
followup of 8a0fc64

task-2065018

closes #39200

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
closes #39193

X-original-commit: 25d6e9a
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since a5b6f31,
the current companies of the user are saved in the context as "allowed_company_ids"
context key.

In case of invalid context content, the api was computing the intersection
between the context content and the user company(ies) and falling back on user
company_id(s) when catching an error.

A sanity check was done, but no feedback was given to the user,
saying that the context change was falsy.

This commits changes this behavior to :

* raise an AccessError when trying to access self.env.company(ies) when
invalid or unauthorized companies are defined in the context.

* take sudo mode into consideration, allowing inter-company impacts,
even when current user doesn't have access to a given company,
if the code is done in a sudoed environment.

Co-Authored-By: Raphael Collet <rco@odoo.com>
Use correct company to get fiscal positions and properties

Ensure company used to fetch fiscal positions is always the correct one
when coming from a company restricted model (company_id required, or
related.required).

purchase: get_fiscal_position doesn't consider company_id ctxt key

others: properties were accessed with potentially the wrong company.
closes #38530

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When marking as done a MO, we use SUPERUSER to create analytic line
as an MRP user does not always have access to analytic items. There
is however a default value for company analytic line defined to the
user's context company, so we need to use the current company of the
real user instead.

closes #39201

X-original-commit: 14aade9
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Was comparing b'0x02' and '0x02'

closes #39213

X-original-commit: 838cb0e
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Fix: no read all records, poor performance on big database
Signed-off-by: Josse Colpaert <jco@openerp.com>
opw-2089868

closes #39215

Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Records were filtered so not every record was set in the for loop

Fixes #38992
Closes #39071

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- fixed some tax report lines by showing correct amounts
- corrected account types
- set default receivable/payable/advance tax accounts for tax groups

closes #39191

Task: 1917932
Closes: 39191
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- Create a customer invoice or a vendor bill
- Add a product with any pre-defined tax

The tax line is not added.

This is because the account 2221 is set as 'Payable' instead of 'Current
Liabilities', as it is the case in other localizations.

For reference, the tax line is created then removed because:

https://github.com/odoo/odoo/blob/db2e6bc600364c00e8a1d528d4b17ae052ecd41e/addons/account/models/account_move.py#L816

The line is part of `existing_terms_lines` instead of `others_lines`.

opw-2089955

closes #39241

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the `width` attribute was interpreted by a jQuery node generator
function as a `style="width"` property and gave an incorrect width value to the affected node.

Now, the `width` attribute is automatically plucked in the list renderer in the
specific function used to render buttons.

Task 2076721
closes #37043

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The reloading of the registry causes cache misses when creating or
modifying automated actions via Odoo Studio.  Right after the reloading
happened, some field is computed in an environment `env` that no longer
appears in `Environment.envs` (collecting existing environments),
because the latter has been explicitly reset.  Performing `sudo()` or
`with_context()` in the compute method creates a new environment that
appears in `Environment.envs`, and uses a different cache from `env`.
The recomputed field is thus stored in the other cache, and retrieving
its value from `env` issues a cache miss...

The fix consists in re-patching the registry models without reloading
the registry from scratch.

opw:2082497

closes #39233

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Reproduce the issue:
- Install eCommerce app
- Publish a product to your website
- Add the product in your cart
- Unpublish/make unsellable/archive the product

The product is still in the cart and the checkout process can be done.

Cause: There is no check for invalid products before displaying the cart

This commit remove the invalid products while loading the cart.

OPW-2092541

closes #40168

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
@robodoo robodoo removed the CI 🤖 label Nov 14, 2019
When installing requirements on MS Windows platform with Python 3.8, the
Pillow requirement is defined two times. This leads to a pip crash.

With this commit, the Pillow requirement is only defined once.

Fixes #40080

closes #40239

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Nov 14, 2019
mart-e and others added 2 commits Nov 14, 2019
Do not insert variable inside a translated message, it will not be
translated.

Fixes #40178

closes #40242

X-original-commit: 54e5779
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The title says it all -_-

closes #39779

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
@robodoo robodoo added the CI 🤖 label Nov 14, 2019
mart-e added 2 commits Nov 12, 2019
After loading the calendar view, making a search with an inactive
domain in the list will trigger a search "partner_ids not in []" which
returns zero result.
The code intention was to initialise the avoidValues, not to send an
empty list.

To reproduce the issue:
1. create an event shared between user 1 and 2
2. as user 2, open the Calendar menu
-> shared event is present
3. click on "week" tab (forcing a refresh)
-> shared event no longer appears

Fixes #39839

closes #40106

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
stdnum is not a mandatory dependency
It is often present as required to install the base_vat module but
having a system with account without the dependency should be
possible.

As the calc_check_digits is pretty small, it is easy to extract

Forward port of 6091be6 to 13.0

closes #40253

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
@robodoo robodoo removed the CI 🤖 label Nov 14, 2019
jpp-odoo and others added 3 commits Nov 12, 2019
In a view month of calendar, when moving a non-all day event from a date
A to a date B.

Before this commit, the event will be changed to an all day event type.

Now, the event will be staid unchanged, only the date will be updated.

opw-2093111

Co-authored-by: Nicolas Lempereur <nle@odoo.com>
In a view month of calendar, when seen the details of a non-all day
event.

Before this commit, the end hour was always 00h00m.
Now, the end hour is the encoded one.

opw-2093111

closes #40139

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
closes #40259

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
@JackSunI

This comment has been minimized.

Copy link

JackSunI commented on 299a6db Nov 14, 2019

@mart-e
Hi, Martin, I see the pr has already been merged to odoo 13.0, thanks a lot for your help.
#40106
But the problem comes from odoo 11.0, would you please create another pr to merge this commit to 11.0?

qle-odoo and others added 4 commits Oct 17, 2019
With this PR we can use the IoT Box with the new Raspberry Pi 4 B
using raspbian 'Buster'

With buster we remove the kiosk mode of firefox and
replace this mode with a fullscreen view of firefox.
To do that we adapt DisplayDriver to expend window with a 'call_xdotool(F11)'

We remove postgresql and patch 'odoo/odoo/http.py' for he does not return a DB.

Task id: 2089286

closes #40043

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before this fix translations of the order names missed a crusial space
that is needed to get information out of it in the front-end.

* Load Spanish-PE translation.
* Change localization preference for a user (either admin or demo) to
Spanish.
* Login to Odoo POS using the user with spanish localization.
* Go to POS, select BAR POS, select a table and place a draft order
with at least 1 order line (do not proceed to payment)
* Go back to table mgmt view and click again to the previous selected
table and the error appears.

This issue happens in any translation where pos_reference for a draft
order is not separated with white space as it happens in English. I mean
in english the pos_reference is something like "Order 00003-001-0002"
but in spanish it is "Pedido00003-001-0002" (no whitespace), so
https://github.com/odoo/odoo/blob/13.0/addons/pos_restaurant/models/pos_order.py#L143
assumes that there will always be a whitespace which is not true for
some odoo translations like spanish one.

This fix adds a variable to the translation string making it more clear
the space is part of the string. To make sure the code will also work on
languages with the words in another order `order['pos_reference'].split(' ')[1]`
is replaced by `search(r"\d{5}-\d{3}-\d{4}", order['pos_reference']).group(0)`,
we know the uid will always be formatted as nnnnn-nnn-nnnn

solves #40036

closes #40252

Signed-off-by: Gert Pellin - GPE <switch87@users.noreply.github.com>
Closes #29548

closes #40283

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Ignore exceptions when resolving dependencies in that case.
This reimplements a behavior from former versions.

closes #40286

Signed-off-by: Christophe Simonis <chs@odoo.com>
@robodoo robodoo added CI 🤖 and removed CI 🤖 labels Nov 14, 2019
@awa-odoo

This comment has been minimized.

Copy link
Contributor

awa-odoo commented on 2cab75b Nov 15, 2019

@Feyensv Looks like you beat me to it: #40202

This comment has been minimized.

Copy link
Contributor Author

Feyensv replied Nov 15, 2019

I hesitated to ping you on my pr when I did it, I should have ^^. I encountered it in one of my builds recently and made a quick fix, but without reaction from tde on the PR (in holidays i suppose), I asked nim to merge it. Sorry :3.

@mart-e

This comment has been minimized.

Copy link
Contributor

mart-e commented Nov 15, 2019

Wrong target

@mart-e mart-e closed this Nov 15, 2019
@robodoo robodoo added closed 💔 and removed CI 🤖 labels Nov 15, 2019
@veroc

This comment has been minimized.

Copy link

veroc commented on 6bc9e69 Nov 18, 2019

this only partially fixes the problem. now a future leave type is selectable but not allocatable. on allocation creation it still raises.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.