To generate an e-faktur
1. Settings > Users & Companies/Compagnies:
- Create a new company ‘ID Indonesia’:
- Set the state (e.g Yogyakarta (ID))
- Set the country ‘Indonesia’
2. Accounting > Customers > e-Faktur
- Set a range of numbers (which are supposed to be assigned by the
Indonesian government)
3. Accounting > Configuration > Settings
- Fiscal Localization: select the Indonesian package
4. Accounting > Customers > Customers
- Create a new res.partner:
- Set the country ‘Indonesia’
- Check ‘ID PKP’ field
- Fill Tax Address field
- Fill NIK field
- Under ‘Accounting tab’: set both accounting entries (Receivable +
Payable)
- Create a delivery address
5. Accounting > Customers > Invoices
- Create a random invoice with the res.partner set in point 5. as the
Customer
- Confirm the invoice
- Action > Download e-Faktur
Under column ALAMAT LENGKAP the tax Address will be used, but the
delivery address should be used
Follows the official documentation with translation
https://www.pajakku.com/tax-guide/12490/PER_DIRJEN_PJK/PER - 03/PJ/2022
(Article 6, paragraph 6)
Translation:
Paragraph 2 : The identity of the Buyer of Taxable Goods and Services or
the Recipient of Taxable Goods and Services which includes name,
address, NPWP, NIK, and passport number as referred to in Article 5
letter b must be filled in accordance with the actual or actual name,
address, NPWP, NIK, and passport number.
Paragraph 6 : In the event that the delivery of Taxable Goods and/or
Taxable Service is made to the Buyer of Taxable Goods and/or Receiver of
Taxable Service which is the place where the VAT or VAT and STLG payable
is concentrated, but the Taxable Goods and/or Taxable Service is sent or
delivered to the place where the VAT or VAT and STLG payable is
centralized, the following provisions shall apply:
a. the name and NPWP as referred to in paragraph (2) shall be the name
and NPWP of PKP where the VAT or VAT and STLG payable is centralized;
and
b. the address as referred to in paragraph (2) shall be the address of
the place where the VAT or VAT and STLG payable that is centralized
receives the Taxable Goods and/or Services.
opw-2878096
closesodoo/odoo#114087
X-original-commit: 15dc3de31ef07a73078bbe3656f3518a1e9679fd
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
The logic of dirtyTranslatableFields is only needed in one place in
the form view. We will therefore remove this function from the model.
We'll take the opportunity to replace dirtyFields with isFieldDirty
because all uses of dirtyFields want to check with the name of a field
if it is dirty or not.
Part of Task: 3179751
closesodoo/odoo#114560
Related: odoo/enterprise#37866
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If you specify an empty VAT number in the Contacts app, it will store it
as `False` in the ORM. If a new partner is created through the shop, the
VAT number is set through HTML form submission. It will use `''` for an
empty VAT number. When evaluating the VAT number in Python code, it will
usually be converted to a boolean, so it doesn't matter if it's `False`
or `''`. But in ORM queries those are two different values and code that
checks on `False` to check for the presence of a VAT number can
misinterpret `''` as being one.
This fix replaces `''` values submitted through the address form in the
shop with `False`.
opw-3114246
closesodoo/odoo#114617
X-original-commit: 84106a1d43fa768429f555cd49a72e0fd2adee4b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>
Before this commit when the user wants to see the burndown chart of a
old large project then the report could take more than 20 sec to be
loaded.
This commit adds 2 indexes one on `mail_tracking_value` table
(`mail.tracking.value` model) and the other one on `mail_message` table
(`mail.message` model) to reduce the load of that report to less than
10 sec.
task-3177072
closesodoo/odoo#114114
X-original-commit: c6b355d471889634ae26a020e14c81e9a315b3de
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
In this commit,
-We Ease the quick creation of tasks by providing shortcuts allowing the user
to set different fields (planned_hours, tags, priority, and assign to users)
without opening the form view.
task-3145203
closesodoo/odoo#112821
Related: odoo/enterprise#37166
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In some cases, wkhtmltopdf might exit with an error (e.g.: a memory
limit). In such cases, we want to show to the user the error returned by
wkhtmltopdf. Previously, this message was only displayed in binary
format (displayed as "Message: b'My error\n'") which is not user-friendly.
We want this message to be decoded so that it is a bare string
(displayed as "Message: My error").
closesodoo/odoo#114609
X-original-commit: 5fc49f8bb24a328e7b735847795bd8e78229cbfb
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
There is a weird deeper low level misbehavior which makes concurent
click to not acts as they should.
Depending on the runbot/tour speed, the misbehavior might kick in and
makes the tour fail.
When you click on multiple options very quick back to back, their click
will be registered and processed one by one, waiting for the previous
one before considering the next one.
You can see that by simply printing a console log in both
`renderListItems` and `_computeWidgetState` method from `s_social_media`
`options.js` file. Then click quickly on the options related to this
snippet like the active toggle and/or remove custom media.
Despite respecting the click order and not overlapping, some click
results (like hidding or removing) will be rollbacked visually and only
the latest click result (starting from the DOM state before the first
click) will be applied.
Long story short: spam click on every toggle option of all the social
media, you will see that all your click will be processed one by one:
- The first media you toggled off will be toggled off
- Then the second media you toggled off will be toggled off but the
first one will be back to toggle on.
It seems to be correctly applying the click result one after the other,
but always starting from the initial DOM state/option widget state
(before the clicks), and not as it should: process the second click
based on the state of things altered by the previous click.
This will need a deeper and longer investigation to fix the root cause.
In the meantime, as this tour is failing multiple times a day, this
commit introduce a workaround to avoid this error in the tour.
task-3212519 (later fix)
runbot-16628
closesodoo/odoo#114600
X-original-commit: e9bd67672ea0517771998ec56f155709cd7c310e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Add multiple images on a product page
- Go to the shop and edit an image of this product by double clicking
on a small image on the carousel thumbnail
- Save
-> Nothing happens and the image is not updated
The goal of this commit is to ensure that a field of type image is not
`readonly` before adding the `contenteditable` attribute to its image.
task-3122670
closesodoo/odoo#114598
X-original-commit: 36fb7654b785888f100d5163e6cebd788c3c042a
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
An employee with time officer access right would receive the error "You
must be False's manager to approve this leave" even if they were manager
of all the employees.
Now the error message will list all the employee's the user is not
manager of, and it will properly check that the user is manager of all
of them.
task-3220920
closesodoo/odoo#114591
X-original-commit: 76f762008b34ed1322ab318ec3829d038ac8bbe4
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit fixes two bugs with the table of content snippet:
- Before this commit, the scrollspy position for the table of content
navbar was incorrect in fullscreen or edit mode due to the calculation
being based on the presence of the main navbar, which is not present in
those modes.
- Before this commit, when the table of content navbar contained enough
elements to exceed the height of the page, the bottom elements were not
accessible without first scrolling through the entire table of content.
This commit addresses this issue by adding a scrollbar to the navbar,
allowing for easier access to these links.
opw-3115597
closesodoo/odoo#114569
X-original-commit: e5d826e03be1fe8c617ef9a8bb8169ad196657fd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Those tests check that we do not leak legacy Widget instances.
However, as the form/list/kanban views and fields have been
converted to owl, no Widget instance is created anymore by those
tests.
closesodoo/odoo#114577
Signed-off-by: Georis François (fge) <fge@odoo.com>
The method update_state is called from cron. When the contracts are
updated couple things are checked. There are constraints set that can
throw ValidationError. As a result, none of the contract states are updated.
In this PR we do the following:
In case the ValidationError occurs when we run the cron, we update
contracts that can be updated, and silently pass the invalid contracts.
task - 3069480
bloupbloup
closesodoo/odoo#114566
X-original-commit: bce0d7d0f11d46c671bc2b902d17d80febeefa5f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the customize panel backdrop did not fully cover the
customize panel when the vertical scrollbar was scrolled to the bottom.
Steps to reproduce the bug:
- In website edit mode, add a table of content snippet to the page.
- Add a three columns snippet within the table of content.
- Click on an image in the three columns snippet.
- Scroll the customize panel to the bottom and open the filter selector
of the image.
- Bug: the backdrop does not fully cover the customization panel.
task-3090626
closesodoo/odoo#114517
X-original-commit: 672a8cb1632b2e61b87834b47e16e3b2f1c57ad9
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
PURPOSE
Fix and add tests for posting messages in multi company environment as well
as posting on readonly documents when greated by '_mail_post_access'
class parameter.
SPECIFICATIONS
Fix multicompany issues which are generally trying to answer a ping on a record
users cannot reach due to MC ACLs.
Effectively support '_mail_post_access' parameter at chatter level. On readonly
documents it is currently always deactivated while it should respect that
parameter. Some record models allow to post without write access.
Add tests to justify the various access rights avoided using sudo, notably
* check attachments: attachments check is stricter than message check
as it always require at least read and often write access on docuemnt.
This does not work when posting on unreachable documents due to
answering a notification;
* check document access: sudo some document value fetch (like display
name) as access is granted at message creation level and should not
crash due to a missing read access on document;
See sub commits for more details.
Task-3213982 (Mail: fix 'multi-company' post support)
Task-3178885 (Mail: fix 'readonly' post support)
closesodoo/odoo#114511
Forward-port-of: odoo/odoo#114464
Forward-port-of: odoo/odoo#114175
Related: odoo/enterprise#37863
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When being notified on a document they cannot read users should be able to
post, as indicated in message ACLs. However some data preparation prevents
from doing it as ACLs are raised on document level.
In this commit we sudo the call to display_name to populate record_name when
not given. Indeed access is checked at message level so no need to crash in
this specific use case.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@2d73c61136
Part-of: odoo/odoo#114511
When replying on a document they cannot read (notably when being notified)
ACLs raise when trying to check if 'main_attachment_id' is already set before
updating it. This is fixed in this commit. This fixes the recently introduced
'test_post_wo_access' test that does not pass without this fix.
Note that the update of 'main_attachment_id' was already done in sudo. As all
read or update access is now done in sudo, better call the whole method as
sudo in 'message_post' and let '_message_set_main_attachment_id' works on
the given record set environment.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@0375bb227a
Part-of: odoo/odoo#114511
When creating a <mail.message> with attachments a manual check is done on
given attachemnts to ensure user have rights to read them. Indeed otherwise
user could simply give attachments from a protected document when posting
on a document he can read and try to gain information about those.
However sometimes user can post and create messages without having read
access on the document, e.g. when being notified and answering in a multi
company environment.
In this commit we consider that creating a message with attachments linked
to the same document does not require an additional check for attachments.
The check is performed at message level (see its custom 'check_access_rule')
and is considered sufficient. However attachments linked to other documents
using model and res_id are still checked.
This fix helps greening the 'test_post_wo_access' test recently introduced.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@bab0549904
Part-of: odoo/odoo#114511
The attribute _mail_post_access='read' on a model allows user with read only
access on the model to post a message. It was not taken into account on the
client side, making the send message button disabled for user with readonly
access on such model. This commit fixes this issue and now correctly takes
into account that class parameter.
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@d2b8612cf7
Part-of: odoo/odoo#114511
The attribute _mail_post_access='read' on a model class allows to post on that
model with readonly access. But when providing an attachment such action was
throwing a security error due to the check done on the attachment. Indeed
adding an attachment to a model is modifying that model so the write access
is needed. To solve this problem, we add the attachment in sudo in the
'_message_post_process_attachments' method.
Justification
This is an internal method and we have stated in its documentation that it is
the caller responsibility to check the rights. Actually, the checks are done at
mail.message creation (to which the attachment are linked) by the override
of 'check_access_rule' which calls '_get_mail_message_access' which takes into
account that attribute (_mail_post_access). Moreover sudo is already used
in '_message_post_process_attachments' to link existing attachments. Here we
add a sudo for the new attachments as well.
Note
This fix allows the test 'test_post_with_read_access' to pass (located in
test_mail/tests/test_mail_multi_company.py). But it is currently hard to
reproduce functionally as
- answering an email works as it is executed by the cron;
- replying in discuss trigger a multi company error no matter there is an
attachment or not (so it is another problem);
- sending a message (with readonly access) on a thread from the interface
works without this fix because the attachment are created beforehand and
the part that handle already existing attachment is already in sudo;
Multicompany issues will be solved in the next commits.
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@f9a6f7f7ce
Part-of: odoo/odoo#114511
Due to misplaced / missing parenthesis some corner cases were not correctly
computed, notably when having Falsy values and using the fallback. Also
it was returning the thread ID instead of a boolean. This was not harmful
but better return a boolean "is a thread notification".
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#114511
Add message post with attachment test on record of another company than the
user company but for which the user has readonly access on. The goal is to
justify the sudo added in mail_thread:
- in '_message_post_process_attachments' method to create attachment linked
to the record (the creation of attachment linked to a record verify the
right to write to the record, so in readonly we need a sudo);
- in '_message_set_main_attachment_id' method to link the main attachment to
the record. Here we write directly on the record for which we only have
readonly access, so a sudo is needed. Here the attachment is already linked
to the model and we only "tag" it has main attachment (see odoo/odoo#30659)
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@8486c7ee05
Part-of: odoo/odoo#114511
Purpose of this commit is to add tests to post in record user cannot access
especially in multi company environment.
Main observations
* ACLs are checked when fetching record_name, then when fetching reply_to
information, adding a bit of ACLs noise in the process;
* check_access_rule of mail.message is called when creating the message
(which is the real protection);
* posting on a document user cannot see is possible when they have been
notified of a parent message. Use case is: answer a ping, even on a
document non readable, should always be doable. However it currently
crashes notably due to attachments check, who always require the read
access on the related document even if the message is authorized;
In this commit we also move other tests about multi_company in the right
file (and add a test flag) in order to have all of them in the same place
easing debug and testing.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@5656f4d20d
Part-of: odoo/odoo#114511
Purpose is to add some tests about email layout support in both comment and
email mode, as well as language support in those two modes. They are added
in a test targeting a complete template usage, testing globally the results
(outgoing notifications or emails, buttons, language, recipients, ...).
Posting in multi-languages environment with notification layout is also
tested. Finally a test about reply-to is moved into its own subtest to
avoid polluting core template tests. Other low level details should already
sufficiently tested. Normally.
Main observations
* translations are quite broken in mass mode (either batch comment either
mass mailing). Indeed translations are fetched based on <mail.compose.
message> body and subject fields, which are probably not translated
as they are linked to a transient model. Real translations are stored
at <mail.template> level when users translate their templates;
* layout translation is partly supported in comment mode, due to a small
context-based hack. However access buttons are not translated and some
use case (like using a 'res_domain') are not supported;
* mass_mail mode does not support layouting at all;
* when posting manually ('message_post') current users' language determines
the language of notification email layout e.g. a user using Odoo in French
will send a french layout to all followers, whatever their language and
whatever the language of the post (which is not known as user input);
Most of those use cases will be fixed soon.
Also update some query counters while passing by.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#114511
Allow to return <mail.mail> records and found outgoing emails when using
asserts. It eases doing checks in some specific tests e.g. checking
notification layout usage in emails. Indeed this is quite low level and
does not really deserves its own assert tooling methods.
Update tool method generating attachment data to ease name tweak when required
in tests.
Also update query counters, and fix a test not running locally.
Task-3046371 (Mail: Better Language Support in Composer)
X-original-commit: odoo/odoo@b32d937b37
Part-of: odoo/odoo#114511
Steps to reproduce
==================
- Make sure the "Work Orders" setting is enabled
- Manufacturing > Products > Bills of Materials > New
- Select a random product
- In the Operations tab, add a line
- Type something in the Operation field
- Set the workcenter to Assembly line 1
- Save and close
- Click on the "Show Instructions" action button
```
Traceback (most recent call last):
File "/home/hubert/src/16.0/odoo/odoo/models.py", line 5108, in ensure_one
_id, = self._ids
^^^^
ValueError: not enough values to unpack (expected 1, got 0)
```
Cause of the issue
==================
The action is called without in id because the record is not yet created
Solution
========
The button should display a warning in x2manys when the record is virtual.
This was actually the case before Odoo 16 but there was an option on the
button `options='{"warn": true}'`. With this commit, it will be the
default behavior.
We also remove this option from the xml since it isn't used.
sentry-3950549982
closesodoo/odoo#114505
X-original-commit: 9fc0424a4450923aa8582bdb6766e1b19cb68546
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this PR when uninstalling hr_contract, expense was uninstall automatically because of the depends, the purpose of this task is to remove the depends.
closesodoo/odoo#114120
Task-id: 3203717
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this commit, when loading the pos with pos_loyalty, even if limited product was activated, all the products were loaded to make sure that we could apply rewards.
Now, we don't load all the products but we only load the rewards by default.
closesodoo/odoo#114021
X-original-commit: 60e7cdee62cf6b19ce0b26f2c7cbe708f74a806e
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
In the model, we trigger events RELATIONAL_MODEL:NEED_LOCAL_CHANGES,
RELATIONAL_MODEL:WILL_SAVE_URGENTLY and RELATIONAL_MODEL:FIELD_IS_DIRTY
on env.bus. That means that if we have two instances of the model in //
(e.g. two views, or two Record components, or a mix...), their fields would listen and react to events
triggered for another model. Trigger those events on the model instead,
as it is an EventBus.
Because the events are directly triggered on the model, we can remove
"RELATIONAL_MODEL:".
Part of task: 3179751
closesodoo/odoo#113880
Related: odoo/enterprise#37727
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The current smartbutton is Employee(s) and it redirects to kanban view by default, no matter how many
employees a user / partner has. 9 out of 10 times a user / partner only has one linked employee, this
change renames the label to 'Employee' and redirects to the form view if there is only one employee
if there are more, the previous action is called
linked upgrade: odoo/upgrade#4363
this closesodoo/odoo#111439
Signed-off-by: Kevin Baptiste <kba@odoo.com>
PURPOSE:
Companies want to have a better integration, we need to focus on the On/Offboarding process,
to find automation and something to show to our customers.
In this commit, we add the "Fleet Manager" in the responsible list of the activities
generated from a plan.
Case 1:
If employee is not linked with fleet, `Employee XXX is not linked to a vehicle`
this warning will be appeared.
Case 2:
If employee linked with fleet but doesn't fleet manager set on fleet,
`Employee's vehicle XXX is not linked to a fleet manager.` this warning will be appeared.
task-3081261
closesodoo/odoo#108892
Signed-off-by: Kevin Baptiste <kba@odoo.com>
document_ftp, website_instantclick, pad, pad_project, note_pad, pos_cache is not currently existing in the addons, removing the non existing modules from the BLACKLIST dictionary.
closesodoo/odoo#107213
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
- In Journals/Bills/Advanced activate "Lock post entries with hash"
- Create a purchase tax of 17%
- Create a bill with a product of a cost of 30 and apply the "17%" tax
- Post it
- Export the data inalterability check report
Issue:
"Corrupted data"
Cause:
In python we have a reprentation issue
```
>>> 30*0.17
5.1000000000000005
```
We define the hash string during the `_compute_string_to_hash` at the
move creation. The issue is, at that time, the move_line tax debit
is not rounded.
Therefore, when we print the report, we take the `move.line_id.
debit` from the db which is rounded and equal to '5.10' and compare
it to '5.1000000000000005' which gives a different hash
Solution:
Implementing a V3 version that uses `repr` for monetary fields.
opw-3072693
closesodoo/odoo#114567
X-original-commit: cfd71892aabf1510273b28032ff8f2d4cfd4d1f7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
To reproduce the issue:
(Also need: account_accountant,purchase)
1. Setup a product P
- Storable
- Category:
- FIFO + Auto
2. Process a PO with 1 x P at $10
3. Process a PO with 1 x P at $50
4. Create and confirm a SO with 1 x P
- Because of FIFO, the value of the delivered product is $10
5. Process the delivery
6. Post the invoice
7. Add credit note
- Credit Method: Full refund and new draft invoice
8. Post the second invoice
Error: The cogs are based on the second received product ($50), they
should rather be based on the delivered one
When computing the anglo-saxon unit price of the product, we consume
the outgoing SVLs, and we consider the already-invoiced quantity.
Here is the issue: we pretend that this quantity is 1, because of
the first invoice, but this should be balanced with the quantity of
the credit note
OPW-3109789
closesodoo/odoo#114564
X-original-commit: e46d68562c1ec55b7838f6854c1d26f56bec9bc6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this commit:
If a payulatam payment is received from the confirmation
page (so, with the webhook). If the value have some decimals
it might be rounded in the wrong way.
As such, the generated signature to compare with is wrong
and the payment validation cancelled
After this commit
If we cross compare the signature generation documentation:
https://developers.payulatam.com/latam/en/docs/integrations/webcheckout-integration/response-page.html#signature-validationhttps://developers.payulatam.com/latam/en/docs/integrations/webcheckout-integration/confirmation-page.html#signature-validation
We notice that the `new_value` computation is slightly different
depending on the return.
The one we currently use for both method is the "return"
one which is computed differently from the "confirm" one.
With this change of code a "confirmation" page payment
will be validated as intended.
I also changed the log level from warning to exception
so that the traceback and exception message is logged.
Before this commit there was just a generic warning message
opw-3018628
closesodoo/odoo#114552
X-original-commit: ee30c21eb5189b2cfcfd6d249985c947f759eaa2
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
Since commit 17a24020ac, StateSelectionField
displays its label in all views. This was an error. It should only
display its label in list views.
closesodoo/odoo#114538
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce the issue:
1. Create a product:
- Type: Storable
- Category:
- Costing Method: AVCO
2. IN 1000 @ 0.17
3. IN 800 @ 0.23
4. OUT 1000
5. OUT 800
6. Open the inventory valuation of the product
Error: the total value is $-6.00, it should be zero
Once all products received, the standard price is $0.20. Its value
has been rounded because the real value is
`(1000 * .17 + 800 * .23) / 1800 = 0,196666667`
The standard price will create a difference when using the products,
because:
`(1800 * .20 = 360) != (1000 * .17 + 800 * .23 = 354)`
That's the reason why a feature tries to compensate such rounding
errors. So, step 4, when preparing the values of the out-SVL, we
check if there is a rounding error, and we find a difference of $6,
which is correct. However, the difference is above the treshold, so
we will not consider it as a rounding error:
https://github.com/odoo/odoo/blob/3ff51daa93a1d670b8f67f79418d4dd48e94875f/addons/stock_account/models/product.py#L197-L200
Here is the issue: the threshold is based on the outgoing quantity
(1000) while the value difference is based on the whole quantity
(1800). This difference should also be proportional to the outgoing
quantity.
Note: The fix will still not work with a small quantity. The only and
best solution is to change the type of the SVL unit cost into a
float.
OPW-3101374
X-original-commit: 35d8b4c2a223970520961bf8bfc574bb309af090
Part-of: odoo/odoo#114525
Co-authored-by: Adrien Widart (awt) <awt@odoo.com>
Since [this commit], it's possible to change the connectors style in
edit mode, unfortunately the code to determine if the connectors should
be visible or not was not compatible with small width screens. As a
result, when a user edited his site on a small screen, he saved hidden
connectors even for visitors with larger screens (while the connectors
should be visible). This commit allows the user to manage the connectors
correctly without taking into account the screen size at the time of
editing.
Steps to reproduce the fixed bug:
- Drop a steps block.
- Reduce your screen width to < 992px or Switch to mobile view from 16.0
- Activate an option of the block.
- Save.
=> The connectors are not visible anymore in desktop view/large screens.
[this commit]: https://github.com/odoo/odoo/commit/aba31e9f2d8a44ce1586403f2a621a6caeed57b4
task-2687506
closesodoo/odoo#114447
X-original-commit: https://github.com/odoo/odoo/commit/6f507a315a64529627c8805d5947ffe4a7f6f509
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
*:point_of_sale,pos_restaurant,web
A new module pos_preparation_display has been added to Odoo enterprise.
This PR is intended to add the requirements necessary for it to work
properly.
The changes are mainly related to the kitchen printer functions, as
the pos_preparation_display module reuses these flows in order to
receivethe orders to be prepared.
closesodoo/odoo#109024
Related: odoo/enterprise#35392
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Those items are no longer used since the legacy form views have
been deleted from the codebase.
closesodoo/odoo#114394
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Allow to perform multiple reconciliation at once in order to:
- ...batch the creation of records as much as possible.
Creating an account.partial.reconcile force the orm to search for amls in order to invalidate the reconciliation fields like amount_residual/amount_residual_currency.
- ...reduce the number of flush inside the orm and batch the compute.
Each call to reconcile is looking for the payment's state of invoices before/after the reconciliation.
This step is costly because this will flush all the reconciliation data and then call the computes to get the fresh value of payment_state.
- ...modify more easily the way the lines are matched together.
Before this commit, the lines were split into two batches sorted by some criteria including the currency: debit and credit.
Then, we were matching them together sequentially.
Now, we make the same things except we do that first for each batch of amls sharing the same currency in order to reduce the number of cross-currencies reconciliation.
- ...allow the orm to prefetch all the partials in the reconciliation chain all at once.
The full reconcile needs to be creating on the full reconciliation graph starting on the current amls so we need to travel the matched_debit_ids/matched_credit_ids in order to find all the involved amls.
Fetching all this data at once is also reducing the number of queries made by the orm.
Let's take an example:
Suppose 10 amls: a1, a2, ..., a10
Suppose 10 amls: b1, b2, ..., b10
You want to reconcile respectively a1 with b1, ... , a10 with b10.
Before this commit, each reconciliation was done as follow:
- Check the payment_state of invoice (on 2 amls)
- Create a partial reconcile (single record)
- Create a full reconcile (single record)
- Compute the reconciliation data to compute payment_state (on 2 amls)
All of that, 10 times sequentially.
With the new '_reconcile_plan' method, we are able to give a list of recordset [a1 + b1, ..., a10 + b10]:
- Check the payment_state of invoice (on 20 amls)
- Create a partial reconcile (10 records)
- Create a full reconcile (10 records)
- Compute the reconciliation data to compute payment_state (on 20 amls)
For a reconciliation using 2000 records (a1, ..., a1000 & b1, ..., b1000), the time to reconcile it was about +-34 seconds. Now, it's about +- 3 seconds.
closesodoo/odoo#113680
Related: odoo/enterprise#37543
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce:
- Install "Sales" module (for test purpose)
- Change company name to `בונז " ור מונד` (notice the double quotes)
- Go to "Settings > Users & Companies > Users"
- Select any user and then click on "send an invitation email" button
- Go to inbox and check the email
Issue:
No email received (at least not in main inbox).
Cause:
The email is not received in main inbox (Gmail or Outlook might flag
them since email from is not well parsed) because the `email from`
value is not escaped properly (by escaping the double quotes).
Solution:
Instead of using the company name (that is not escaped) and email to
build the `email from` value, use the company email_formatted value
instead (and fallback on user mail if not available).
opw-3097910
closesodoo/odoo#114534
X-original-commit: 0c4cb5e3cc2758cb27e94ecbbcfaa734ba5a50eb
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
- Go to Contact-Configuration-Countries
- Remove the code of a country
- Create a new contact
- Select the country from which you deleted the code
- Put any vat number starting with country code you deleted
Issue:
Traceback
Cause:
in `_run_vat_test` we want to `country.code.lower()` -> country code does not exist
Solution:
Prevent the user to delete a country code by making the field required.
sentry-3923412146
closesodoo/odoo#113207
Signed-off-by: William André (wan) <wan@odoo.com>
Andrea Grazioso (agr-odoo)