Bug:
When an irish company without VAT invoices a Norvegian company with a 0%
tax, the category of the tax is "K" in the Bis 3 xml, which will raise:
"[BR-IC-02]-An Invoice that contains an Invoice line (BG-25) where the
Invoiced item VAT category code (BT-151) is "Intra-community supply"
shall contain the Seller VAT Identifier (BT-31) or the Seller tax
representative VAT identifier (BT-63) and the Buyer VAT identifier
(BT-48)."
Using code "G" would also raise: "[BR-G-02]-An Invoice that contains an
Invoice line (BG-25) where the Invoiced item VAT category code (BT-151)
is "Export outside the EU" shall contain the Seller VAT Identifier
(BT-31) or the Seller tax representative VAT identifier (BT-63)."
Fix:
We should only use "G" or "K" when the supplier has a VAT. If a supplier
without a VAT invoices with a 0% tax, we should use the tax category "E"
(Exempted).
opw-3785810
closesodoo/odoo#158670
X-original-commit: 357f1aec4bfa12fe476a207f2acfc1bf4a6232d5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Steps to reproduce:
-------------------
- install calendar, project and documents;
- create an activity for a task (project.task) with meeting type;
- change attendee to the meeting;
- save;
Issue:
------
The activity is not linked to the right task.
Cause:
------
When we create a `calendar.event`, when the event is at a future date,
we send an email to the attendees.
This email must include an attachment corresponding to the ICS file.
Depending on the `no_document` context key, we may or may not create a document.
When we create the document, we have a value for the `activity_ids` field (one2many)
which is the ORM command for linking the newly created document.
This will result in the document id being written to the `res_id` field
of the `mail.activity` record.
Unfortunately, the activity contains a `res_model` which is not `documents.document`.
The result is that the activity is linked to a `res_id` which is not
that of the model previously set for it (i.e. `project.task`).
Solution:
---------
Add context key `no_document` when creating an attachment for ICS files.
opw-3746857
closesodoo/odoo#158570
X-original-commit: 17ac8d3f25bad2c4f37793e06edca40793a4f3d5
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Before this commit sol field wasn't editable when user
don't have any sales access and it was editable for
timesheet page and project form view.
This commit make SOL field in task form editable to
be consistant with project form and timesheet page
of tast form.
task-3764793
closesodoo/odoo#158547
X-original-commit: 1d25d6f92d4ecf658bbbc9d39983808fa0fc9c87
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Kartik Chavda (kcv) <kcv@odoo.com>
Versions
--------
- 16.0+
Steps
-----
1. Set tax rounding method to global;
2. create a loyalty program offering 100% discount on orders;
3. create a SO with the following line subtotals & 15% tax:
1. $5.60
2. $8.92
3. $44.91
4. $217.26
5. $2400.00
4. apply the 100% discount program.
Issue
-----
Total comes down to $0.01 instead of $0.00.
Cause
-----
To calculate the `discountable` amount, any non-fixed tax is mostly
ignored, instead only looking at price totals and fixed taxes. As global
tax rounding is achieved by using increased precision in intermediary
calculations, rounding errors are introduced by only looking at totals.
Solution
--------
Use the `compute_all` method instead, to retrieve precise tax data, and
add/subtract taxes depending on `amount_type`.
opw-3710365
closesodoo/odoo#158387
X-original-commit: 09f31597163a3251e58bb7b08939301574e1f65a
Signed-off-by: Levi Siuzdak <sile@odoo.com>
The attribute cache is mainly used from the Environment class. The
ormcache attribute using the same name leads to confusion.
Related task:
task-3818968
closesodoo/odoo#155264
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Before this commit, when using a shipping method with the variable
weight*volume for price computation, the price was growing with the
square of the ordered quantities. This is because both volume and
weight were multiplied by the quantity, before being multiplied with
each other in the next step.
This commit fixes the issue by introducing the variable weight*volume
at the beginning of the computation.
In order not to break anything in stable, the new variable is added as a
kwarg to the useful methods.
OPW-3802315
closesodoo/odoo#159007
X-original-commit: 0a8db0fa14bb63abd0b2a8f0234d86700b6c1e2e
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Commit [1] was introduced to fix an issue where the website menu cache
is incompatible with having a slug url in one of its menu.
But in the enterprise build, since the website_helpdesk module is adding
one menu containing a slug url, it would disable the menu cache.
Unfortunately, the website_blog perf tests (at_install) are executed
after website_helpdesk is installed, meaning that in enterprise, the
perf test of website_blog would fail since it would require some more
SQL Queries (1 or 2 depending of the test) to render a blog post as it
would have to query the website.menu table.
It's still unclear how commit [1] was merged in the codebase since the
enterprise staging should have failed.
runbot-60466
runbot-60467
[1]: https://github.com/odoo/odoo/commit/948235079f002794f9837d3cf91e2d20e3254e20closesodoo/odoo#158666
X-original-commit: 11acdfc7d8dd0dfe146b6f7547123af94e2a0baf
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit introduces an update to the Font Awesome library,
specifically replacing the X/Twitter icon with its new design. It also
involves adjustments to a few images and SVG files to incorporate the
updated X/Twitter logo.
Technical note: It updates an existing file, originally modified for the
addition of the TikTok icon, which was not available in Font Awesome 4.
task-3463530
closesodoo/odoo#158586
X-original-commit: 34cba04a452f2da21f3418d6fc48a484da8ecd27
Related: odoo/enterprise#59147
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
* Activate multi-currency (Company currency `USD`, another currency activated 'EUR')
* Create invoice/bill in `EUR` and post it
* Archive `EUR'
* Open Invoice/Bill
Issue:
* Alert for inactivated currency is always displayed
Fix:
* Alert for inactivated currency should be displayed in draft state only
closesodoo/odoo#158802
X-original-commit: 72a0058ec748a03351ab3ad7536ff7089f84262e
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
As we imported invoices from the IAP proxy we refused files when the
same filename was already present in the database.
Import invoices sent by Company A to Company B on the same Odoo database
was therefore impeded. The CRON would try to import the Company B's
vendor bill with the same attachment's filename as the Company A's
invoice and reject the file.
Now we fill in the `company_id` field on the attachment and we search
for attachments which belong to the company we're importing for, so the
case is covered.
An import test has been added.
opw-3673508
closesodoo/odoo#157755
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
In a1f32fafa85b300e2d656a57797b8dbde6e3f065, various onchanges from the
picking types were changed into computes. However, the compute for the
`print_label` field was forgotten and never linked to its field.
closesodoo/odoo#158869
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
_read_group doesn't raise an error when we have an aggregate
specification like `order_id.create_date:min`, instead it silently
ignores the `.create_date` part.
We only add a warning in the stable version to avoid breaking any
change.
closesodoo/odoo#158777
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
commit that introduced the issue : https://github.com/odoo/odoo/commit/8e516dccac4ced7e48adfabe756a899784bac9ca
Issue:
======
valuation unit cost is wrong when we do backorder with real time unit
price computation
Steps to reproduce the issue:
=============================
- Create a kit with 2 components with product quntity to produce = 3
- Put qty = 2 for the first component and qty = 1 for the second component
- Assign product category to the kit product and the components as fifo
one with automatec price computation
- Create a purchase order with 30 quantity of the kit and price unit =
90
- confirm order and go to receipt
- Confirm 4 qty for the first component and 2 qty for the second.
- Create backorder
- Go to the confirmed receipt and go to valuation
- You will see that the total sum corresponds to the price of all the
products and not only the confirmed ones.
Solution:
=========
We need to use the bom quantities and not the order line to get the
unit_cost of each component.
opw-3790132
closesodoo/odoo#158788
X-original-commit: a72232694f68a810986e5c1c24fd0394d058af41
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
- Create PO
- Confirm, delivery and create bill
- Confirm and create reverse move via "Add credit note" (Full Refund)
- Open portal view of the PO
Issue: The credit note payment status display `Waiting Payment` badge
instead of `Paid`
opw-3806514
closesodoo/odoo#158556
X-original-commit: 66d08a484dae64f559a78ccee18b4a79f9e4e70e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
- BooleanFavouriteField wasn't translated as the component was using
an untranslated variable instead of relying on the translation of
the template.
Some other translation fixing:
- ID Azienda is very generic, the correct name is Numero REA:
See: https://www.registroimprese.it/codice-fiscale-p.iva-rea
- No one calls a mobile phone "Dispositivo mobile", we already
translate it as the more common "Cellulare" even in the same file
task-3263708
closesodoo/odoo#157949
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128` for the existance of an image on the product (`has_image` key).
Previously, the field `image_1920` was used which has two issues:
1.) The 128 sized image should be preferred because it is 15x smaller than 1920. The whole image is loaded at this point, so the smallest-sized one should be used.
2.) `image_1920` is a computed, non-stored, field. This has the implication that the image will be processed, thus consuming more memory (even leading to a MemoryError on the customer's DB). This happens like so:
a.) `_compute_image_1920` is called, which sets a value into `record.image_1920`. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/addons/product/models/product_product.py#L157
b.) Eventually `_image_process` is called, which performs memory intensive computations on the image. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/odoo/fields.py#L2550
So this can be avoided by implementing this commit, which will check the stored, non-computed fields instead.
Memory benchmarks for allocations by `_get_self_order_data`:
Done on customer DB with 1340 product.products, with a total of 776 images between them.
Before commit: 1638.4 MiB + server memory limit reached
After commit: 29.7 MiB total
Total improvement of 55x less memory usage
closesodoo/odoo#157900
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
To reproduce issue:
.create a new picking of any operation type
.save the picking (so that a name is formed)
.edit the picking and change the operation type to another type
.save manually
Expected result:
new name with matching prefix to the new operation type
Actual result:
previous name with prefix from previous operation type is still
there. This is an issue because then the name doesn't match and
this can be confusing to users
When a user create a new picking of any operation type and save the
picking, the name is formed based on your type. If the status of
picking is draft, and he needs change the picking type, the name of
picking is not changed, so, this PR solves this error. Now, when
change the picking type and save it manually, the name of picking
will be regenerated with the correct specification. Should be receipts,
workorders or delivery.
task-3703643
closesodoo/odoo#153147
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, it happens that the taxes display on the pdf were wrap,
specially when the description in the pdf were too long. This commit will add a
text-nowrap on the taxes when the len of the taxes is shorter than 10 characters
closesodoo/odoo#158774
Task: 3754824
X-original-commit: 95d0bd1794418ac8bdb4464c54304d3dcd0cb523
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Steps to reproduce:
- Create pricelist with an end date in the past for a stored product
- Click on manual replenishement
- The created PO will have a price of 0
Bug:
if no valid pricelist is found unit price is set to 0
product standard price is a better fallback
opw-3692985
closesodoo/odoo#158650
X-original-commit: ed106e70f908deda819007fc68feaa44074c0472
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
If phonenumbers library is not installed, we should display a
relevant error message, instead of the generic invalid phone number
error message.
closesodoo/odoo#154926closesodoo/odoo#158546
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Now that we check whether a participant exists on Peppol network first when they register,
we should also mock that request. Currently, since that request is not mocked,
all peppol tests are skipped.
Part-of: odoo/odoo#158546
If the participant is not active on the IAP server, the server sends back
a Participant not ready error in response without raising an error.
On the client side a user sees a traceback, because we're trying to retrieve
a message uuid of a non-existent peppol message: `response['messages'][i]['message_uuid'].
That's because we treat that error in the try block and then proceed
to the else block because technically there was no exception.
This commit moves that error handling to `else` block so that such invoices get the proper error messages.
Part-of: odoo/odoo#158546
Before this commit:
In POS online payment the usually the user is either the
logged in user/public user which ends up raising error
`The phone number is invalid` even when the customer is selected
After this commit:
Razorpay doesn't raise the error instead now we don't create
customer when it is not a tokenize request
task-3786679
closesodoo/odoo#157533
Signed-off-by: Harsh Modi (hamo) <hamo@odoo.com>
Those are optional, commit [1] mimicked the python code in JS but with a
mistake: "required" instead of "optional".
Steps to reproduce:
- Enable cookies setting on website
- Drag & drop a snippet
- Modify that snippet conditional visibility to "Utm Campaign: Sale"
- Visit in incognito /?utm_campaign=Sale, you don't see the snippet,
which is good
- Now click on "Only Essentials" in the cookies banner
- The snippet will be shown, because when accepting the essentials
cookies, the utm ones were set, since they were marked as required.
[1]: https://github.com/odoo/odoo/commit/90ada07ecfc308ad181748d3e809810bb90f3eecclosesodoo/odoo#158720
X-original-commit: 63b0606d728be949cc6cfcb0dbdf17114ec1c711
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Those master data would break the basic accounting pdf generation flow
as those are widely used and it is not expected from end users to delete
them.
Example of support ticket from that issue: 3790875
closesodoo/odoo#158637
Taskid: 3802440
X-original-commit: b1ecc922503ff3a9618e89afd13659e37eb3fbed
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Lots of tickets are issues when the end user deleted this product
category, leading to the impossibility to install another carrier
as this category is referenced by all the specific carriers products
Ticket example: 3789116
closesodoo/odoo#158626
Taskid: 3802440
X-original-commit: 9383b6f4a5ef0394588c522efcc92e6f37a245cb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
When you increase the height or width of cells in a table and subsequently
delete a row or column, the adjacent rows or columns experience an increase in
their height or width. This happens because the table preserves its overall
dimensions even after resizing individual cells.
After this commit:
Now, the table no longer preserves its height or width. When resizing the table,
the height or width of its rows or columns does not increase.
task-3636212
closesodoo/odoo#158256
X-original-commit: 9940bf3e153714022785b50cb423e52634c99202
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue:
- When adding tasks to a contact using Studio
and attempting to set a task's project to a
project linked to a Sales Order (SO),
we encounter the following error:
"TypeError: 'NewId' object is not iterable."
Steps To Reproduce (in 17.0):
- In a contact form open Studio and add a O2M field Customer (Task)
- Create a new task in the O2M and set the Project to a project
related to a SO.
- Notice Traceback Error "TypeError: 'NewId' object is not iterable"
Solution:
- The issue arises in the search domain of
_get_last_sol_of_customer , where the domain is
('order_partner_id', 'child_of',
self.partner_id.commercial_partner_id.id),
where the type of `self.partner_id.commercial_partner_id.id`
is NewId since the partner is being edited to add a task.
This action triggers the `parse` and `to_ids` methods with
a value type of NewId. thus the error.
- The operator child_of expects a list of IDs, and the ids
property refer to the record's origin ids.to resolve this,
replace `commercial_partner_id.id` with `commercial_partner_id.ids`.
opw-3760372
closesodoo/odoo#157318
Signed-off-by: Raphael Collet <rco@odoo.com>
Imagine the following situation: an automated action A is triggered when
some stored computed field F has a certain value. When a record is
created and no value is given for field F, then the automated action A
may be run twice: once when evaluating A's domain forces the computation
of F, and once again because A's domain is satisfied.
The implementation already uses context flags to reflect which automated
actions have already been run, in order to avoid automated actions to be
run recursively. The fix consists in enabling those context flags to be
shared among the evaluation of the domain and processing of the
automated actions.
opw-3731182
closesodoo/odoo#157272
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Nasreddin Boulif (bon) <bon@odoo.com>
After the fw-port of the fix in [1], it seems some references had
changed, breaking the translations again. This commit fixes that.
[1] 9d2f7f312c5d699b937bd5546085fc151a149a8f
closesodoo/odoo#158664
X-original-commit: d28189565f035cf2f84f7cb01137cece2bb90662
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
is checked but not the display name of the product.
It is not necessary for the purpose of the change and adapting
the display name on the product is very common customization
for many companies.
X-original-commit: bbba3cd6e5affff53728d877b0d426eb6c88ff38
Part-of: odoo/odoo#158621
Incorporate Christihan Laurel (CLaurelB) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at
http://www.odoo.com/submit-prclosesodoo/odoo#158729
X-original-commit: f0a0d596ab716c96de38a5c0f837da2924338d7b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If the 'cancel next move' feature is enabled, canceling a SOL could
lead to unexpected picking creation
To reproduce the issue:
(Debug mode enabled)
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Outgoing shipments: 2 steps
3. Edit the delivery route:
- For each rule:
- Cancel next move: True
4. Confirm a SO with one product
5. Set the SOL quantity to 0
Error: A third picking is created, from customer to output location
Step 4, it creates two SM:
\- SM_SO: from Stock to Ouput
\- SM_OC: from Output to Customer
Step 5, thanks to the procurement process, we create a stock move:
\- SM_OC_neg, from Output to Customer with a negative qty.
While confirming this SM, and thanks to the same process, we then
create a second stock move :
\- SM_SO_neg, from Stock to Output, with a negative qty.
Both negative SM are linked. While confirming SM_SO_neg, we merge it
with SM_SO. Therefore:
\- Dest moves of SM_SO_neg are given to SM_SO
\- SM_SO_neg is deleted (fully absorbed by SM_SO)
\- SM_SO has now a zero demand, so we cancel it:
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1024-L1025
However, because of step 3, we also cancel its dest moves:
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1740-L1745
i.e., we cancel SM_OC *and* SM_OC_neg. This leads to an inconsistency:
Back to the confirmation of SM_SO_neg. As explained, this SM has
been canceled during the procurement process. Still, we keep
processing its confirmation (we overwrite its state, we assign it to a
picking, and so on). Hence the error.
In `_merge_moves`, when deleting a stock move, we first clean it
(for instance, we disable the cancel propagation):
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1018-L1020
We should do the same with SMs we are going to cancel. That way, we
fix the root cause of the issue: when cancelling SM_SO, we don't
cancel neither SM_OC neither SM_OC_neg, so we don't have any
inconsistency when going back to the confirmation of SM_SO_neg, and
everything will work correctly.
OPW-3753453
closesodoo/odoo#158663
X-original-commit: 7f385686b35b36561cfe9d2a320ff1699547efd2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
With a SA company setup
Open a jounrnal entry
Hit 'Reverse Entry' > Reverse
Error: "For Credit/Debit notes issued in Saudi Arabia, you need to
specify a Reason"
This occurs because with SA localization we need to provide a reason for
move reversal but by default the reason field is invisible for journal entries
opw-3789732
closesodoo/odoo#157996
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Steps to reproduce:
- Open an event and go to the Community page
- Try to customize it => traceback on clicking the 'Customize' tab.
Cause:
The `_getRpcData` function called by '_computeWidgetState' method does not exist
anymore since https://github.com/odoo/odoo/commit/03c5526
Fix:
This commit eliminates the call to the `_getRpcData` function and alters
the code of 'options.js' to get rpcData for the 'allow room creation' checkbox,
through an implementation similar to that of 'website menu'.
closesodoo/odoo#158684
Task: 3805901
X-original-commit: 1ea9c23eaaab15b6e29b73b9ec530fc9baec0726
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Khushi Patel (khpa) <khpa@odoo.com>
Some taxes of skr03 and skr04 were not set for the appropriate tax group.
This was fixed, and each tax was set to its appropriate tax group.
Taxes should not be set with wrong tax groups.
task-3800915
closesodoo/odoo#158619
X-original-commit: 540f98de72c27659a6a9c938d2e75196e9b713c0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Hesham Saleh (hsal) <hsal@odoo.com>
This issue is occurring when the user tries to add a VAT number
while creating a new contact
To reproduce this issue:
1) Install "contacts" and "partner_autocomplete"
2) Create a new contact from 'Contacts'
3) Give a valid VAT number e.g:- "SK2120312645"
4) Traceback occurs in the terminal
Error:- "IndexError: list index out of range"
https://github.com/odoo/odoo/blob/382b64c2f14073cfff1a8ef9290b5c7834d52188/addons/partner_autocomplete/models/res_partner.py#L143-L156
In some cases, the expected "zip_city" value is not at the last of the address list ,
which leads to a traceback.
After applying this commit will resolve this issue by searching "zip_city"
based on regex.
sentry-5058467547
closesodoo/odoo#158580
X-original-commit: 55c605f44d3a4f280946f1c1fec3f5e1534b4ef9
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>
Steps to reproduce:
- Install contacts and base_address_extended
- Install a module adding "res.city" records (e.g. l10n_co_edi)
- Go to Contacts and create a new one:
* Name: [any]
* Country: Colombia
* City (city_id): [any]
- Create a "child" contact of "Contact" type
- Save the contact
Issue:
"city_id" field of the child contact is False.
It is not possible to set the address of a contact-type contact manually.
Some address fields ('street', 'street2', 'zip', 'city', 'state_id', 'country_id')
are synchronized with the parent contact.
"city_id" is not and is not settable at all for contact-type contact.
It could be an issue for Colombian or Mexican localizations if a child contact is
used for an invoice as some data have to be retrieved from "city_id" field to generate
the electronic invoice.
Solution:
Add "city_id" in the list of address fields to sync.
opw-3747296
closesodoo/odoo#158686
X-original-commit: ec059dfd0a3f57754bd481f0a651b01c92b10dea
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Many banks (Itaú, Santander, Caixa) don't support Pix codes without a
reference. To fix set a dummy reference of "***" when none is
set (this is what Santander bank does when generating Pix codes
without a reference). Again thanks to INGO for testing.
opw-3818534
closesodoo/odoo#158713
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce
==================
In 17:
- Install hr_holidays,project
- Switch the language to dutch
- Go to project > three dots > Projectupdates
We can see `x/y Genomen`, it should be `x/y Taken`
Cause of the issue
==================
The original term is Tasks.
When loading the views, python translates them and changes Tasks to Taken.
Owl then translates the template and transforms Taken to Genomen.
Solution
========
Since the views are already translated, we don't need to translate them with owl.
We can simply set the attribute t-translation to off on the view root node.
opw-3787336
closesodoo/odoo#158627
X-original-commit: 454760e12145f8987e443d7776a614a5eb441feb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Current state:
- Company ID field in the Contacts form view is introduced by the base module and it is put into the Purchase tab.
- l10n_cz module adds an invisibility attribute to that field which hides it if the current company is not based in CZ. It also adds another instance of the field into the main tab but also adds the same invisibility attribute for the field.
- If l10n_sk module is installed next (e.g. in a multicompany setup) it adds another instance of the field into the main tab but changes the visibility attribute of all the instances suit SK-based companies. However this means the field becomes hidden for CZ-based companies (current company). Plus the field is doubled if the current company is a SK-based one.
- A similar problem happens if the l10n_sk is installed first and l10n_cz comes after it.
Fix:
- Remove the invisible attribute so that the Company ID field on the main tab and on Sales and Purchase tab remains untouched and visible whatever the current company's country is.
closesodoo/odoo#158605
Signed-off-by: William André (wan) <wan@odoo.com>
In a multicompany setup when l10n_cz is installed after l10n_sk then the
Company ID field disappears from Contacts form view if current company
is not a CZ company (fiscal_country_codes != CZ). On the other hand if
the current company is a CZ company then the field is doubled in the
form view.
This change prevents the field from disappearing by reverting the
visibility condition change introduced by each of the l10n_sk and
l10n_cz module because they are clashing.
Part-of: odoo/odoo#158605
Julien Van Roy