Friday, October 29, 2021
32 changes · master
Enhancements to existing features
This update adds an internal test model that combines phone/SMS messaging with activity management. It helps teams validate future activity-related features more reliably, especially where phone numbers, SMS, VoIP, or document workflows interact.
Original PR description
Purpose is to ease future new tests about activities management involving phone numbers and SMS sending. Task-2657021
Odoo now lets developers define a fallback action when optional visual effects are turned off. This helps ensure users still get a clear response instead of a missing or inconsistent experience.
Original PR description
## [IMP] web: improve effect service api Before: The dev creating an effect had to handle himself the fact that effects had been enabled or not. He could just ignore the best practice and make a bad experience for the end user. After: The function providing the effect can now put an `alternative` key in the returned object that is a function to execute if effects are disabled.
This update adds internal helpers that make it easier to test touch-based actions at precise screen positions. It supports upcoming mobile interface improvements by making related tests more reliable and easier to write.
Original PR description
Description of the issue/feature this PR addresses: This PR adds some touch events helper in tests/helpers/utils of web. It is used for the tests of the ActionSwiper component of web_mobile. It is linked to the tasks with IDs 2391177 and 2361187. Current behavior before PR: It is difficult to generate touch actions in tests Desired behavior after PR is merged: You can used those new events in your tests to generate touch interaction at precise coordinates. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payroll signature requests now use the document filename in their reference instead of the employee's active contract name. This makes requests easier to identify and match to the correct document for payroll teams.
Original PR description
When asking for a signature request for an employee in payroll, the reference of the signature is always 'signature request - ' + the name of active contract of that employee. This PR changes the reference to be 'signature request' + filename instead. task-2657779
Code cleanup and technical improvements
Adds a shared way to identify public website contacts so related features can avoid problems when those contacts are archived. This helps live chat, website sales, and messaging behave more consistently with public users.
Original PR description
To be use in mail, ... and prevent issue with archived partner @seb-odoo an idea for master -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this commit, if you create a new app with a custom icon with studio and you open the command palette with the namespace "/", then you will have an error message. We have this error because the home_menu does not support custom menu icons. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Before this commit, if you create a new app with a custom icon with studio and you open the command palette with the namespace "/", then you will have an error message. We have this error because the home_menu does not support custom menu icons. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79149
Steps to reproduce: 1. Create Manufacturing Order with quantity >1 of Serial Tracked product 2. Press Mark done. (One Product will be immediated produced with a new SN auto-created) 3. Create Backorder 4. Press Mark done on the backorder Expected Result: Backorder will also be able to immediate produce and auto-create a new SN Actual Result: Usererror because env is still referring to original MO and tries to produce the same SN again. Fixes: odoo/odoo#78134 -- I conf
Original PR description
Steps to reproduce: 1. Create Manufacturing Order with quantity >1 of Serial Tracked product 2. Press Mark done. (One Product will be immediated produced with a new SN auto-created) 3. Create Backorder 4. Press Mark done on the backorder Expected Result: Backorder will also be able to immediate produce and auto-create a new SN Actual Result: Usererror because env is still referring to original MO and tries to produce the same SN again. Fixes: odoo/odoo#78134 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79123
PURPOSE Update the `date_closed` field when lead is won or lost. SPECIFICATIONS The goal of this commit is to update the `date_closed` field when lead is won or lost. It used to work in prior version because we used to set `active` and `probability` together from `action_set_lost` method. But now, won and lost action are handled with `toggle_active` method. In case of the lost leads, it first sets the `active` field to False, and the `date_closed` is correctly updated by writ
Original PR description
PURPOSE Update the `date_closed` field when lead is won or lost. SPECIFICATIONS The goal of this commit is to update the `date_closed` field when lead is won or lost. It used to work in prior version because we used to set `active` and `probability` together from `action_set_lost` method. But now, won and lost action are handled with `toggle_active` method. In case of the lost leads, it first sets the `active` field to False, and the `date_closed` is correctly updated by write method. After that, it sets the `probability` to 0, and during that the write method sets the `date_closed` to False. This commit fixes the issue by updating `date_closed` field from write method, only if the `probability` is greater than zero, and thus not discarding the already set value. LINKS PR #79125 TaskID-2343223 Forward-Port-Of: odoo/odoo#79125
- Fix typo in accrued_orders.py - Remove fields.Date.today() from purchase test - Make more use of common resources Forward-Port-Of: odoo/odoo#78921
Original PR description
- Fix typo in accrued_orders.py - Remove fields.Date.today() from purchase test - Make more use of common resources Forward-Port-Of: odoo/odoo#78921
Stock.location is ordered by "complete_name" which is possible to be the same (i.e. default production locations for different companies). This may result non-deterministic order. Add "id" to avoid it. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79135
Original PR description
Stock.location is ordered by "complete_name" which is possible to be the same (i.e. default production locations for different companies). This may result non-deterministic order. Add "id" to avoid it. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79135
Remove unused file. Forward-Port-Of: odoo/odoo#79163
Original PR description
Remove unused file. Forward-Port-Of: odoo/odoo#79163
Since [1] and [2], the mobile app gets this error when trying to login on v15, while it was working fine in v14 with TOTP enabled. The 'authenticate' JSON-RPC route tries to authenticate the user and then call `session_info()`. As no UID is defined, some methods in `session_info()` raise an exception and an unexpected error is sent: * `_is_public()` -> "Expected singleton: res.users()" * `get_web_translations_hash()` -> "lang" In this fix, this exception is avoided and the proper resu
Original PR description
Since [1] and [2], the mobile app gets this error when trying to login on v15, while it was working fine in v14 with TOTP enabled. The 'authenticate' JSON-RPC route tries to authenticate the user and then call `session_info()`. As no UID is defined, some methods in `session_info()` raise an exception and an unexpected error is sent: * `_is_public()` -> "Expected singleton: res.users()" * `get_web_translations_hash()` -> "lang" In this fix, this exception is avoided and the proper result is sent, allowing the authentication process to continue. Steps to reproduce: * Try to connect to an account with TOTP on the mobile app (v15+) => BUG Refs: [1] odoo/odoo@80d74e7ee0eab83dc5100e0776df09d04b882fec [2] odoo/odoo@401fc7efe90fb99ebeef33db5d44d8b97be94ed5 Forward-Port-Of: odoo/odoo#78901
If a work center is used in any routing, a warning will be displayed when it will be archived opw-2658596 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79087
Original PR description
If a work center is used in any routing, a warning will be displayed when it will be archived opw-2658596 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79087
Description of the issue/feature this PR addresses: Fine tuning of https://github.com/odoo/odoo/pull/78062 In case you use product with variante, `display_name` is better than `name`. @ajf-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79171 Forward-Port-Of: odoo/odoo#79130
Original PR description
Description of the issue/feature this PR addresses: Fine tuning of https://github.com/odoo/odoo/pull/78062 In case you use product with variante, `display_name` is better than `name`. @ajf-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79171 Forward-Port-Of: odoo/odoo#79130
Steps to reproduce the bug: - install mrp_workorder - Create a new work center which will work every day from 8:00-9:00 - Create a BOM with component and operation, which takes 24 minutes in your work center - Create 4 MO for this bom - Set manually scheduled date > 1 MO should have a different date than others, e.g: - 3 MO → 01/dec/2021 08:00 - 1 MO → 02/dec/2021 08:00 - Plan the MO which has different date than others The ```planned_end_date``` is not calculated correctly
Original PR description
Steps to reproduce the bug:
- install mrp_workorder
- Create a new work center which will work every day from 8:00-9:00
- Create a BOM with component and operation, which takes 24 minutes in your work center
- Create 4 MO for this bom
- Set manually scheduled date > 1 MO should have a different date than others, e.g:
- 3 MO → 01/dec/2021 08:00
- 1 MO → 02/dec/2021 08:00
- Plan the MO which has different date than others
The ```planned_end_date``` is not calculated correctly
Current behavior before PR:
MO_1 : 01/dec/2021 08:00 → 01/dec/2021 08:24
MO_2 : 01/dec/2021 08:24 → 01/dec/2021 08:48
MO_3 : 02/dec/2021 08:00 → 02/dec/2021 08:24
MO_4 : 02/dec/2021 08:24 → **03/dec/2021 08:12**
Problem
The MO_4 should only last 20 minutes, while it lasts 23 hours and 48 minutes.
opw-2648065
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#78377Before this commit, the active class of the tabs snippet buttons disappeared when leaving the edition of the buttons. task-2656662 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78242
Original PR description
Before this commit, the active class of the tabs snippet buttons disappeared when leaving the edition of the buttons. task-2656662 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78242
The larger payment status `Free Admission` replacing `Free` in #61668 made it require two lines in the attendee kanban card, making it taller, and with additional and unnecessary whitespace. Task-2586017 Forward-Port-Of: odoo/odoo#78165
Original PR description
The larger payment status `Free Admission` replacing `Free` in #61668 made it require two lines in the attendee kanban card, making it taller, and with additional and unnecessary whitespace. Task-2586017 Forward-Port-Of: odoo/odoo#78165
The field `payment_credit_account_id` on `account.journal` has been removed by 04522f01e6fdbf82a657b32b312449fd7d756f79 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78612
Original PR description
The field `payment_credit_account_id` on `account.journal` has been removed by 04522f01e6fdbf82a657b32b312449fd7d756f79 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78612
When a submodule overrides an old UNIQUE constraint with a new one, records in that module may respect the new one and not the old one. As the old module is updated, it would fail giving SQL warnings, and therefore blocking the Odoo.sh CI pipeline. ``` i.e. website_sale (old): res_users_login_key -> ['login', 'website_id'] base (new): res_users_login_key -> ['login'] ``` With this patch, we check if the new constraint is overriding an old one which is more permissive. In th
Original PR description
When a submodule overrides an old UNIQUE constraint with a new one,
records in that module may respect the new one and not the old one.
As the old module is updated, it would fail giving SQL warnings,
and therefore blocking the Odoo.sh CI pipeline.
```
i.e. website_sale (old): res_users_login_key -> ['login', 'website_id']
base (new): res_users_login_key -> ['login']
```
With this patch, we check if the new constraint is overriding
an old one which is more permissive. In that case, we verify
that the records of the table won't break the new constraint
before applying it.
This approach tries to limit the performance impact of the checks
by holding a cache with all the old UNIQUE constraints in the database.
Ticket link: https://www.odoo.com/web#id=2489483&model=project.task
opw-2489483
Forward-Port-Of: odoo/odoo#79042\* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail, web_editor, website_crm_iap_reveal, website_livechat The aim of this PR is to improve/fix various flaws and limitation of the current API, to make it easier to use and more efficient. Notification are now defined with 3 distinct parts: - the channel determines which client(s) should receive it - the type determines how it should be handled - the payload determines any extra information helpful for han
Original PR description
\* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail, web_editor, website_crm_iap_reveal, website_livechat The aim of this PR is to improve/fix various flaws and limitation…
\* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
Forward-Port-Of: odoo/odoo#72937…n access issue - Go to Email Marketing - Create a new mailing with template having social media links - Save - Click on one of the social links An error is triggered: "Error: Blocked a frame with origin xxx from accessing a cross-origin frame." The traceback occurs because we try to change the content of something we don't have access to, as these sites prevent display in an iframe. opw-2599540 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/
Original PR description
…n access issue - Go to Email Marketing - Create a new mailing with template having social media links - Save - Click on one of the social links An error is triggered: "Error: Blocked a frame with origin xxx from accessing a cross-origin frame." The traceback occurs because we try to change the content of something we don't have access to, as these sites prevent display in an iframe. opw-2599540 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76890
Currently, when marking a task as done, it moves the task to the canceled stage instead of done and on duplication of the done task it will move to the new stage but still, the task will be marked as done so the buttons on task are not visible. So in this commit on mark done move the task to the done stage and on duplication of the task makes the fsm_done copy False so it should not be marked as done Task-2665826 Forward-Port-Of: odoo/enterprise#21602
Original PR description
Currently, when marking a task as done, it moves the task to the canceled stage instead of done and on duplication of the done task it will move to the new stage but still, the task will be marked as done so the buttons on task are not visible. So in this commit on mark done move the task to the done stage and on duplication of the task makes the fsm_done copy False so it should not be marked as done Task-2665826 Forward-Port-Of: odoo/enterprise#21602
Renovate demo/test certificates Forward-Port-Of: odoo/enterprise#21973
Original PR description
Renovate demo/test certificates Forward-Port-Of: odoo/enterprise#21973
\* = delivery_iot, documents_spreadsheet, snailmail_account_followup, voip The aim of this PR is to improve/fix various flaws and limitation of the current API, to make it easier to use and more efficient. Notification are now defined with 3 distinct parts: - the channel determines which client(s) should receive it - the type determines how it should be handled - the payload determines any extra information helpful for handling it Channel ======= Business code -------------
Original PR description
\* = delivery_iot, documents_spreadsheet, snailmail_account_followup, voip The aim of this PR is to improve/fix various flaws and limitation of the current API, to make it easier to use and more…
\* = delivery_iot, documents_spreadsheet, snailmail_account_followup, voip The aim of this PR is to improve/fix various flaws and limitation of the current API, to make it easier to use and more efficient. Notification are now defined with 3 distinct parts: - the channel determines which client(s) should receive it - the type determines how it should be handled - the payload determines any extra information helpful for handling it Channel ======= Business code ------------- - Record channel is introduced for ease of subscribing to and sending notifications to specific partners, channels, documents, ... - String channel is still supported (but it is converted internally to the tuple channel). - Tuple channel is still supported without any change (but should be avoided whenever possible due to its complex syntax). The channel is no longer sent to the client. When the channel was used for business purpose, the information it contained has been moved into either the new type, or the payload itself. Technical note -------------- All channels are now internally converted to the tuple (db, ...) channel, which is necessary for the platform code (saas/sh). Internally, the bus.bus table is not changed, type and payload are grouped together into what was (and still is) called message. Type ==== Type is introduced to uniformize the way notifications are sent and handled. All existing notifications already had some kind of manually-built type in them. This is now officially supported at the bus API. In client code this will allow (to be done in future commits) to register one handler per specific type, instead of having to iterate and to filter all received notifications on every handler. Payload ======= Payload (ex message) did not change, it can still be anything depending on business needs. Few adaptations: - When the type was included on the payload, the type has been moved to the new type parameter. - When the channel was used in business code, its data has been copied into the payload. task-1891151 Forward-Port-Of: odoo/enterprise#19535
Before this commit, since https://github.com/odoo/enterprise/pull/12945 introduced in 14.2, the tags that were selected when sharing a domain were not set as default tags of the share. This commit fixes this issue opw-2678743 Forward-Port-Of: odoo/enterprise#21955
Original PR description
Before this commit, since https://github.com/odoo/enterprise/pull/12945 introduced in 14.2, the tags that were selected when sharing a domain were not set as default tags of the share. This commit fixes this issue opw-2678743 Forward-Port-Of: odoo/enterprise#21955
Precises a trigger in the tour `test_put_in_pack_scan_suggested_package` to avoid non deterministic fail. Forward-Port-Of: odoo/enterprise#21938
Original PR description
Precises a trigger in the tour `test_put_in_pack_scan_suggested_package` to avoid non deterministic fail. Forward-Port-Of: odoo/enterprise#21938
CDFI edi does not support line with a negative or null subtotal but this use case is common when you want to apply a global discount. This commit modify the cfdi xml generated. The negative line are splitted on the positive line affecting the discount of the positive line. The total of the invoice and the taxes remain unchanged. Forward-Port-Of: odoo/enterprise#20636
Original PR description
CDFI edi does not support line with a negative or null subtotal but this use case is common when you want to apply a global discount. This commit modify the cfdi xml generated. The negative line are splitted on the positive line affecting the discount of the positive line. The total of the invoice and the taxes remain unchanged. Forward-Port-Of: odoo/enterprise#20636
Steps to reproduce the bug: - install mrp_workorder - Create a new work center which will work every day from 8:00-9:00 - Create a BOM with component and operation, which takes 24 minutes in your work center - Create 4 MO for this bom - Set manually scheduled date > 1 MO should have a different date than others, e.g: - 3 MO → 01/dec/2021 08:00 - 1 MO → 02/dec/2021 08:00 - Plan the MO which has different date than others The ```planned_end_date``` is not calculated correctly
Original PR description
Steps to reproduce the bug:
- install mrp_workorder
- Create a new work center which will work every day from 8:00-9:00
- Create a BOM with component and operation, which takes 24 minutes in your work center
- Create 4 MO for this bom
- Set manually scheduled date > 1 MO should have a different date than others, e.g:
- 3 MO → 01/dec/2021 08:00
- 1 MO → 02/dec/2021 08:00
- Plan the MO which has different date than others
The ```planned_end_date``` is not calculated correctly
Current behavior before PR:
MO_1 : 01/dec/2021 08:00 → 01/dec/2021 08:24
MO_2 : 01/dec/2021 08:24 → 01/dec/2021 08:48
MO_3 : 02/dec/2021 08:00 → 02/dec/2021 08:24
MO_4 : 02/dec/2021 08:24 → **02/dec/2021 08:24**
Problem
The MO_4 should only last 20 minutes, while it lasts 23 hours and 48 minutes.
opw-2648065
Forward-Port-Of: odoo/enterprise#21701In SEPA Credit Transfer XML files, some elements are using the company name (amongst other parameters that enforces unicity): MsgId, PmtInfId and EndToEndId. Before this commit, we were using the company name directly and crop it to its last 15 characters. This was creating some confusion on banks' side as some elements like EndToEndId are visible by end users. After this commit, we now crop the company name to its first 15 characters to make it easier to understand for the end user,
Original PR description
In SEPA Credit Transfer XML files, some elements are using the company name (amongst other parameters that enforces unicity): MsgId, PmtInfId and EndToEndId. Before this commit, we were using the company name directly and crop it to its last 15 characters. This was creating some confusion on banks' side as some elements like EndToEndId are visible by end users. After this commit, we now crop the company name to its first 15 characters to make it easier to understand for the end user, as well as using the creditor reference party name set on the company to allow some flexibility in case some wants to use a shorter of different name in their files. This commit also fixes a small bug when filling in the Nm element if the initiating party name is not filled in by adding a fallback on the company name instead. opw-2577875 Forward-Port-Of: odoo/enterprise#21872
When importing bank statements, we are filling in automatically the bank account id if an existing record matching the number is found. However, we should restrict the search to retrieve only bank accounts belonging to the current company, otherwise it will create a multi-company inconsistency. Forward-port of commit https://github.com/odoo/odoo/commit/f22eb970c835f90e59e9bedb95382447c6eb6e39 Code was moved to enterprise since commit https://github.com/odoo/enterprise/commit/0063d7d6a09c1
Original PR description
When importing bank statements, we are filling in automatically the bank account id if an existing record matching the number is found. However, we should restrict the search to retrieve only bank accounts belonging to the current company, otherwise it will create a multi-company inconsistency. Forward-port of commit https://github.com/odoo/odoo/commit/f22eb970c835f90e59e9bedb95382447c6eb6e39 Code was moved to enterprise since commit https://github.com/odoo/enterprise/commit/0063d7d6a09c16716dcd9125c291a1041f9ed255 opw-2602912 Forward-Port-Of: odoo/enterprise#21909
Previous to this PR: Translations used ${object.partner_id} for example, and emails sent from odoo are badly rendered. After this PR: Template rendering matches the new QWEB syntax. Also corrected the syntax of the numbering format (seemed like the used in AR) Forward-Port-Of: odoo/enterprise#21975
Original PR description
Previous to this PR:
Translations used ${object.partner_id} for example, and emails sent from odoo are badly rendered.
After this PR:
Template rendering matches the new QWEB syntax.
Also corrected the syntax of the numbering format (seemed like the used in AR)
Forward-Port-Of: odoo/enterprise#21975Behavior prior to this commit: - all operations are included on the mod347 report - the "Mod347 Invoice Type" field is available only for intracommunitary invoices Behavior after this commit: - operations within the EU are excluded by default - operations to third countries outside the EU are included by default - the "Mod347 Invoice Type" field is available to select for any operation outside of Spain, in case a specific invoice needs to be excluded It should be noted that the
Original PR description
Behavior prior to this commit: - all operations are included on the mod347 report - the "Mod347 Invoice Type" field is available only for intracommunitary invoices Behavior after this commit: -…
Behavior prior to this commit: - all operations are included on the mod347 report - the "Mod347 Invoice Type" field is available only for intracommunitary invoices Behavior after this commit: - operations within the EU are excluded by default - operations to third countries outside the EU are included by default - the "Mod347 Invoice Type" field is available to select for any operation outside of Spain, in case a specific invoice needs to be excluded It should be noted that the logic for determining whether an invoice line is included / excluded on the mod347 is a bit more complicated than is implemented in this module. - http://www.supercontable.com/envios/articulos/BOLETIN_SUPERCONTABLE_08_2016_Contenido_General_6.htm - https://www.agenciatributaria.es/AEAT.internet/Inicio/Ayuda/Manuales__Folletos_y_Videos/Manuales_practicos/_Ayuda_Folleto_Actividades_economicas/5__Impuesto_sobre_el_Valor_Anadido/5_8_Operaciones_intracomunitarias/5_8_Operaciones_intracomunitarias.html - https://github.com/OCA/l10n-spain/issues/1272 opw-2282305 Forward-Port-Of: odoo/enterprise#21867 Forward-Port-Of: odoo/enterprise#15171