Wednesday, May 29, 2024
25 changes
12 changes
Miscellaneous changes
Steps to reproduce: - Create a kit with components Uom set as Kg - Create an SO for the kit using packaging - Validate the delivery and try printing the delivery slip ERROR Bug: when generating the delivery slip we convert movelines qty to the packaging Uom but in the case of a kit the movelines are those of the components (in this we're converting Kg to units) Fix: Ignore kit lines (will be removed any way in _get_aggregated_product_quantities) opw-3758203 Forward-Port-Of: odoo/o
Original PR description
Steps to reproduce: - Create a kit with components Uom set as Kg - Create an SO for the kit using packaging - Validate the delivery and try printing the delivery slip ERROR Bug: when generating the delivery slip we convert movelines qty to the packaging Uom but in the case of a kit the movelines are those of the components (in this we're converting Kg to units) Fix: Ignore kit lines (will be removed any way in _get_aggregated_product_quantities) opw-3758203 Forward-Port-Of: odoo/odoo#166717 Forward-Port-Of: odoo/odoo#161920
steps to reproduce: - create a PO and buy 10 units of acoustic bloc screens from Azure interior - validate PO and picking (you now have qty_received=10 on the PO line) - create a return of 25 units and validite the picking (qty_received=-15) - change the PO line quantity to a negative amount (ex: -3) => ``` File "/data/build/odoo/addons/purchase_stock/models/purchase.py", line 392, in write lines.with_context(previous_product_qty=previous_product_uom_qty)._create_or_update_pick
Original PR description
steps to reproduce:
- create a PO and buy 10 units of acoustic bloc screens from Azure interior
- validate PO and picking (you now have qty_received=10 on the PO line)
- create a return of 25 units and validite the picking (qty_received=-15)
- change the PO line quantity to a negative amount (ex: -3)
=>
```
File "/data/build/odoo/addons/purchase_stock/models/purchase.py", line 392, in write
lines.with_context(previous_product_qty=previous_product_uom_qty)._create_or_update_picking()
File "/data/build/odoo/addons/purchase_stock/models/purchase.py", line 445, in _create_or_update_picking
line.invoice_lines[0].move_id.activity_schedule(
File "/data/build/odoo/odoo/models.py", line 5952, in __getitem__
return self.browse((self._ids[key],))
IndexError: tuple index out of range
```
opw-3941103
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#166245Some live chat sessions are available as demo data. Some of these sessions had incorrectly crafted messages, leading to small visual glitches. For exemple, some messages were missing their `subtype_xmlid`, resulting in emojis being displayed with an incorrect margin. Others assigned the `message_type` field twice. This PR fixes this issue. task-3850900 Before:  After:  After:  Forward-Port-Of: odoo/odoo#167063
Before this commit: ========== - After scanning the product barcode, the notification of the added product was not showing in mobile mode. After this commit: ========== - After scanning the product barcode, the notification of the added product will work fine. task-3877329 Forward-Port-Of: odoo/odoo#166930 Forward-Port-Of: odoo/odoo#164272
Original PR description
Before this commit: ========== - After scanning the product barcode, the notification of the added product was not showing in mobile mode. After this commit: ========== - After scanning the product barcode, the notification of the added product will work fine. task-3877329 Forward-Port-Of: odoo/odoo#166930 Forward-Port-Of: odoo/odoo#164272
Issue: ===== We can't scroll in iframe using the mouse (no scroll available) Steps to reproduce the issue: ============================= - Install events, mass_mailing - Go to any event and click invite - Choose any template - You can't scroll inside the template Origin of the issue: ==================== Many other apps inherits the view with id `view_mail_mass_mailing_form` and not the view with id `mailing_mailing_view_form_full_width` which have the logic of resizing the ifra
Original PR description
Issue: ===== We can't scroll in iframe using the mouse (no scroll available) Steps to reproduce the issue: ============================= - Install events, mass_mailing - Go to any event and click…
Issue: ===== We can't scroll in iframe using the mouse (no scroll available) Steps to reproduce the issue: ============================= - Install events, mass_mailing - Go to any event and click invite - Choose any template - You can't scroll inside the template Origin of the issue: ==================== Many other apps inherits the view with id `view_mail_mass_mailing_form` and not the view with id `mailing_mailing_view_form_full_width` which have the logic of resizing the iframe to the length of its content (introduced here [1]) so we don't really need to scroll inside the iframe. But for the other apps since they inherit from the first mentioned view, they will have the iframe class `.o_mass_mailing_iframe` but we specified in mass_mailing.ui.scss file that html that have that class we don't assign `overflow:visible` to them , that's why we can't scroll inside the iframe. Solution: ========= There are a lof of ways to solve this problem but most of them needs an xml change which requires an update of the module. The current solution is to add a special class to the full_width view using js from it's already defined js_class and then we exclude it from the scss selector. opw-3897165 [1]: https://github.com/odoo/odoo/commit/8a74c1f79340c58d62c9577f1011d9dc6a58ff70 Forward-Port-Of: odoo/odoo#164666
 This `next_serial` argument was added in https://github.com/odoo/odoo/pull/117513. Forward-Port-Of: odoo/odoo#165034
Original PR description
 This `next_serial` argument was added in https://github.com/odoo/odoo/pull/117513. Forward-Port-Of: odoo/odoo#165034
Commit 9ca10649b857f8ba4d7f212200a64f98d5e8582b corrected the opening of the "detailed operation for subcontracting stock moves but uses a wrong icon to display in the list view. 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#167051
Original PR description
Commit 9ca10649b857f8ba4d7f212200a64f98d5e8582b corrected the opening of the "detailed operation for subcontracting stock moves but uses a wrong icon to display in the list view. 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#167051
Where : In Point of Sale > Configuration > Settings The category "Product & PoS catefories" was misspelled and is corrected to "Product & PoS categories" opw-3923475 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165243
Original PR description
Where : In Point of Sale > Configuration > Settings The category "Product & PoS catefories" was misspelled and is corrected to "Product & PoS categories" opw-3923475 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165243
Before this commit, you can delete an user linked to an employee without any warning. With this constraint, you need to manually remove the user on the employee record, so it cannot be done by accident. Forward-Port-Of: odoo/odoo#166619 Forward-Port-Of: odoo/odoo#166516
Original PR description
Before this commit, you can delete an user linked to an employee without any warning. With this constraint, you need to manually remove the user on the employee record, so it cannot be done by accident. Forward-Port-Of: odoo/odoo#166619 Forward-Port-Of: odoo/odoo#166516
# Current behavior: Cancelling a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client they had PO with more than 200 lines which makes it impossible for them to cancel them. # Step to reproduce: - Install mrp and mrp_subcontracting - Create PO with more than 50 order lines or more - Confirm the PO - Try to cancel it - Take a long time or timeout # Benchmark (made in 16): | No. of PO lines | Before | After | |-----------------|:----
Original PR description
# Current behavior: Cancelling a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client they had PO with more than 200 lines which makes it impossible for them to cancel them. # Step to reproduce: - Install mrp and mrp_subcontracting - Create PO with more than 50 order lines or more - Confirm the PO - Try to cancel it - Take a long time or timeout # Benchmark (made in 16): | No. of PO lines | Before | After | |-----------------|:-------:|:------:| | 9 | 650ms | 600ms | | 91 | 1min26 | 9s | | 273 | 4min50 | 34s | | 405 | 7min13 | 55s | # Fix: Batch more actions and records to reduce the number of queries generated by the ORM. # Reference: opw-3690875 Forward-Port-Of: odoo/odoo#166728 Forward-Port-Of: odoo/odoo#151526
Problem: * If the fleet app is installed **by itself** (i.e. without hr) searching a vehicle by driver will throw an error. Notes about fix: * The error is caused by a hr_fleet child field being accessed in the base Vehicle model. opw-3858626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161821
Original PR description
Problem: * If the fleet app is installed **by itself** (i.e. without hr) searching a vehicle by driver will throw an error. Notes about fix: * The error is caused by a hr_fleet child field being accessed in the base Vehicle model. opw-3858626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161821
Issue ----- When sale orders related to a project (through service products) are counted, `_compute_sale_order_count` aggregates on `sale_order.order_id`. However, this is not done on sudo, so in multi-company setups, a user from a company won't be able to access `sales.orders` related to the same project but from another company. Steps ----- - Create a new project, say P, with the company field set to empty. - From company A, create a new service product, say R, that creates a tas
Original PR description
Issue ----- When sale orders related to a project (through service products) are counted, `_compute_sale_order_count` aggregates on `sale_order.order_id`. However, this is not done on sudo, so in…
Issue ----- When sale orders related to a project (through service products) are counted, `_compute_sale_order_count` aggregates on `sale_order.order_id`. However, this is not done on sudo, so in multi-company setups, a user from a company won't be able to access `sales.orders` related to the same project but from another company. Steps ----- - Create a new project, say P, with the company field set to empty. - From company A, create a new service product, say R, that creates a task in the project P. - From company A, create a sales order with the product R. - From company B, create a new service product, say Q, that creates a task in the project P. - From company B, create a similar sales order with the product Q. - From company B's sales order, click on the project smart button. - An access issue occurs as company B's user isn't able to compute `sale_order_count`. Cause ----- Not using sudo when computing `sale_order_count` through aggregating on `_compute_sale_order_count`. Solution -------- Although the `compute_sudo` can be used on `sale_order_count` & `sale_order_line_count` field definitions, it is more clear and secure to use sudo specifically on the compute function. opw-3850932 Forward-Port-Of: odoo/odoo#166769 Forward-Port-Of: odoo/odoo#163357
12 changes
Enhancements to existing features
The Inventory app menu has been simplified by removing a duplicate action. This reduces confusion for users and makes it easier to find the right inventory reporting option.
Original PR description
In this commit: ==================== - Remove duplicate action from Inventory menus to streamline user experience and improve functionality. task-3837207
1 change
Resolved issues and error corrections
This update ensures that the test_discuss_full_enterprise module is automatically installed when both test_discuss_full and web_enterprise modules are present. This fix resolves test failures that were occurring when these modules were used together, improving the reliability of the testing environment.
Original PR description
When `test_discuss_full` and at least `web_enterprise` are installed, `test_discuss_full_enterprise` must be installed for the tests in `test_discuss_full` to pass. runbot-65732 Forward-Port-Of: odoo/enterprise#63366
Restaurant appointment flows in Point of Sale now ignore hidden “shadow tables” used for unassigned restaurant orders. This keeps appointments focused on real dining tables and avoids confusing or incorrect table links for staff.
Original PR description
In the corresponding community commit we introduce the concept of "shadow tables", which allows us to place orders in pos restaurant that appear to not be linked to any table. In this commit we have to adapt `pos_restaurant_appointment` to ignore these "shadow tables" Task: 3908568 https://github.com/odoo/odoo/pull/164918
Resolved issues and error corrections
A Colombian localization field is no longer mandatory when it is not relevant. This prevents companies outside Colombia from being blocked by a country-specific requirement that should not apply to them.
Original PR description
This change should have been done in commit 3f798c74d7a05114f2d8390742c51bf2ac5aede6 . It was forgotten during forward porting. The field should not be required since it does not matter for non-CO companies. see https://github.com/odoo/enterprise/pull/54086#discussion_r1464762388
Code cleanup and technical improvements
This update removes unused code across several Point of Sale-related modules. It should make the codebase easier to maintain without changing day-to-day business workflows or adding new features.
Original PR description
*: l10n_cl_edi_pos, l10n_de_pos_cert, l10n_de_pos_res_cert, pos_blackbox_be, pos_iot, pos_l10n_se, pos_preparation_display, pos_settle_due, whatsapp_pos Remove dead code
Miscellaneous changes
Steps to reproduce: - go to planning app - choose a month for a user without any planned or open shifts - publish - go to frontend via the email link - error raised Source: - many attributes like default_start are not present in planning_get reponse, trying to accessing default_start = undefined and converting it to a valid date that can be used to display the calendar raises an error. Solution: - when no_data = True, start function in fullcalendar should not compute anything as the
Original PR description
Steps to reproduce: - go to planning app - choose a month for a user without any planned or open shifts - publish - go to frontend via the email link - error raised Source: - many attributes like default_start are not present in planning_get reponse, trying to accessing default_start = undefined and converting it to a valid date that can be used to display the calendar raises an error. Solution: - when no_data = True, start function in fullcalendar should not compute anything as there are no data to display. task-3906551 task-3186609 Forward-Port-Of: odoo/enterprise#63158 Forward-Port-Of: odoo/enterprise#61866
**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go to settings and enable `Centralize files attached to projects and tasks` (from 16.0, set a default folder on the project) - Go to any task and add a new activity with the new activity type - Click on `Upload Document` and select a file **Issue:** Access right error message.
Original PR description
**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go…
**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go to settings and enable `Centralize files attached to projects and tasks` (from 16.0, set a default folder on the project) - Go to any task and add a new activity with the new activity type - Click on `Upload Document` and select a file **Issue:** Access right error message. **Cause:** Simple explanation: 2 documents are created (one on the activity creation and one on the attachment upload) and the attachment is linked to the second document. When trying to fisrt unlink the second document and then link the attachment to the first document, the attachment is already unlinked. Detailed explanation: When creating the activity, if a folder_id is set on the activity, an empty document is first created with the request_activity_id. https://github.com/odoo/enterprise/blob/a23a18681bddc5995c5dac8cacfb074c06fc5ea8/documents/models/mail_activity.py#L46 When uploading the file, if the related record model is an inherit of `documents.mixin` model and the documents settings (in this case `Document Project Settings`) are activated, it will create the document with the attachment. https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/ir_attachment.py#L63 Then, in the action done, we will unlink the last document record created and try to link it's attachment (already unlinked) to the first document record (with the `request_activity_id`). https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/mail_activity.py#L33 Since the following commit, when unlinking a document, it unlink also it's attachment: https://github.com/odoo/enterprise/commit/a999f2c32ab542ca7aa44cf34970dc7cca4fdaf8 **Solution:** Override the upload route (`/mail/attachment/upload`) so that it skip the creation of the second document (by adding `no_document` to the context) if an activity ID is available and that a document with a `request_activity_id` with the same activity ID already exists. COM PR: https://github.com/odoo/odoo/pull/159943 opw-3458850 Forward-Port-Of: odoo/enterprise#63220 Forward-Port-Of: odoo/enterprise#59796
Currently, several l10n_pe_edi tests are failing every night. This is due to: - Error 98 meaning that not enough time is given to the remote sever to process cancellation requests -> wait and check several times before asserting - Duplicated name: Sometimes, some invoices have duplicated names. We make sure it is not possible by 'incrementing' the name for each invoice we create. ----- 1. `test_send_delivery_guide` was failing because the picking vehicule was not set up properly in
Original PR description
Currently, several l10n_pe_edi tests are failing every night. This is due to: - Error 98 meaning that not enough time is given to the remote sever to process cancellation requests -> wait and check…
Currently, several l10n_pe_edi tests are failing every night. This is due to: - Error 98 meaning that not enough time is given to the remote sever to process cancellation requests -> wait and check several times before asserting - Duplicated name: Sometimes, some invoices have duplicated names. We make sure it is not possible by 'incrementing' the name for each invoice we create. ----- 1. `test_send_delivery_guide` was failing because the picking vehicule was not set up properly in the test. After this was fix, another issue appeared: the company needed proper credential to connect to the SUNAT. Since those were not available, the function connecting to SUNAT has been patched to simulate a basic answer from SUNAT. 2. `test_generate_delivery_guide`'s expected document has been updated to include the vehicule set up in the previous step. 3. Since there is no more call to an external API. The `external` and `l10n_external` tags are not necessary anymore. This allows to group both tests under the same class. task-3718645 Forward-Port-Of: odoo/enterprise#63291 Forward-Port-Of: odoo/enterprise#62452
When user clicks on contracts smart button in application and if application has two contracts (one archived and one active), a traceback will appear. Steps to reproduce the error: - Install "hr_contract_salary" module - Go to Recruitment > Applications > All Applications > Create new application > Generate Offer > Select Contract Template > Send By Email > Send - Click on Offers > Salary Configurator > Fill all required fields > Review Contract & Sign > Validate & Send Completed Do
Original PR description
When user clicks on contracts smart button in application and if application has two contracts (one archived and one active), a traceback will appear. Steps to reproduce the error: - Install…
When user clicks on contracts smart button in application and if application has
two contracts (one archived and one active), a traceback will appear.
Steps to reproduce the error:
- Install "hr_contract_salary" module
- Go to Recruitment > Applications > All Applications > Create new application >
Generate Offer > Select Contract Template > Send By Email > Send
- Click on Offers > Salary Configurator > Fill all required fields >
Review Contract & Sign > Validate & Send Completed Document
- Open that application > Contracts > Create new contract > Save
- Archived one contract > Click on Contract smart button
Traceback:
```
ValueError: Expected singleton: hr.contract(27, 29)
File "odoo/http.py", line 2253, in __call__
response = request._serve_db()
File "odoo/http.py", line 1829, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1849, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1827, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1834, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2059, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 42, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.2/hr_contract_salary/models/hr_applicant.py", line 59, in action_show_proposed_contracts
"res_id": self.env['hr.contract'].search([["applicant_id", "=", self.id], '|', ["active", "=", False], ["active", "=", True]]).id,
File "odoo/fields.py", line 5182, in __get__
raise ValueError("Expected singleton: %s" % record)
```
https://github.com/odoo/enterprise/blob/504b3c66a9a8d142b89f9c873675ec65fdb43dd0/hr_contract_salary/models/hr_applicant.py#L59
Here when application has two contracts (one is archived and one is active),
So when it tries to access the id of 2 records.
It will lead to the above traceback.
sentry-5350130147
Forward-Port-Of: odoo/enterprise#62627Steps to reproduce ================== - Open a product form - Open Studio - Remove the "Internal Notes" block from "General Information" - Add a new field => The normalized view contains many operations, it should only contain one move and one insertion Cause of the issue ================== The normalization compares the original view with the view with all operations applied. To do this, it stringifies every node and then does a textual diff between the original and modified ve
Original PR description
Steps to reproduce ================== - Open a product form - Open Studio - Remove the "Internal Notes" block from "General Information" - Add a new field => The normalized view contains many…
Steps to reproduce
==================
- Open a product form
- Open Studio
- Remove the "Internal Notes" block from "General Information"
- Add a new field
=> The normalized view contains many operations, it should only contain one move and one insertion
Cause of the issue
==================
The normalization compares the original view with the view with all operations applied. To do this, it stringifies every node and then does a textual diff between the original and modified versions.
The issue in this case is that there are multiple ways to represent a diff.
In this example, we remove the first group
```xml
<form>
<group/>
<group/>
</form>
```
```xml
<xpath expr="/form/group" position="replace"/>
```
The before stringified view is represented as
```
/form/group
/form/group[@closed]
/form/group
/form/group[@closed]
```
The after stringified view is represented as
```
/form/group
/form/group[@closed]
```
There are two ways to represent this diff
```diff
- /form/group
- /form/group[@closed]
/form/group
/form/group[@closed]
```
```diff
/form/group
- /form/group[@closed]
- /form/group
/form/group[@closed]
```
In this case, we only want the first one, but the second one is generated.
Solution
========
We can assign an id to every node before performing the diff, this way, the nodes are uniquely represented.
The before stringified view will be represented as
```
/form#1/group#2
/form#1/group#2[@closed]
/form#1/group#3
/form#1/group#3[@closed]
```
The after stringified view is represented as
```
/form#1/group#3
/form#1/group#3[@closed]
```
The diff can now only be represented in one way
```diff
- /form#1/group#2
- /form#1/group#2[@closed]
/form#1/group#3
/form#1/group#3[@closed]
```
opw-3888345
opw-3924997
Forward-Port-Of: odoo/enterprise#63047**Current behavior:** If you create a SEPA report for an employee that has address information in their `hr.employee` record but not their `res.partner` record, the creditor address will not use the `hr.employee` information- the corresponding XML node will not be included. **Expected behavior:** The employee address should be in the report if they have one listed in their HR information. **Steps to reproduce:** 1. Install the `test_l10n_be_hr_payroll` module, switch to 'My B
Original PR description
**Current behavior:** If you create a SEPA report for an employee that has address information in their `hr.employee` record but not their `res.partner` record, the creditor address will not use the…
**Current behavior:**
If you create a SEPA report for an employee that has address
information in their `hr.employee` record but not their
`res.partner` record, the creditor address will not use the
`hr.employee` information- the corresponding XML node will not
be included.
**Expected behavior:**
The employee address should be in the report if they have one
listed in their HR information.
**Steps to reproduce:**
1. Install the `test_l10n_be_hr_payroll` module, switch to
'My Belgian Company'
2. In the Employee application, go to an employee (e.g., Bernice
Jensen) and make sure their listed bank account is verified
to be able to receive payments
3. In the Payroll application, create a new `To Pay` record for
the employee from step 2, register it, then create the
payment report
4. In the Exported File notebook tab, you can see that there is
no Creditor Address listed in the XML Sepa Report
**Cause of the issue:**
The report builder constructs the creditor address only from
the `res.partner` record.
**Fix:**
Extend the postal address construction such that we get an
address from a partner's employee record (when applicable). The
information should not be mix-and-matched; we will use whichever
address has the most complete information.
opw-3716705
Forward-Port-Of: odoo/enterprise#62934
Forward-Port-Of: odoo/enterprise#58743Before this commit, the journal report did not show the date for credit notes. opw-3939676 Forward-Port-Of: odoo/enterprise#63187
Original PR description
Before this commit, the journal report did not show the date for credit notes. opw-3939676 Forward-Port-Of: odoo/enterprise#63187
[REF] l10n_mx_edi: change fecha date to sent date Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769 Forward-Port-Of: odoo/enterprise#63293 Forward-Port-Of: odoo/enterprise#62108
Original PR description
[REF] l10n_mx_edi: change fecha date to sent date Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769 Forward-Port-Of: odoo/enterprise#63293 Forward-Port-Of: odoo/enterprise#62108