Some parts of the translation were missing and Romanian isn't available
as a language in Transifex for this version. Therefore we add it in now.
English grammar mistakes of original string are left untouched.
closesodoo/odoo#162469
X-original-commit: f19e872698d17b93da3c2e1a3eafb20a4d098660
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Fixes a few things:
- A couple placeholders existed for non-required fields, which means in
certain cases they would be printed in real reports (i.e. not just
shown in studio)
- hide the UoM from the deliveryslip when the setting isn't active
(this is broken in earlier versions too, but fix can be backported if
someone finally complains about it since it's been there for awhile)
- Updates a placeholder that was confusing (a location instead of a
package name)
Note only `stock` reports were checked for this fix, there are probably
still other problematic reports.
See PR: https://github.com/odoo/odoo/pull/129310 for reference of when
placeholders were added in
closesodoo/odoo#161420
X-original-commit: 90104d0133ab54ac12e466c6187601029e50b4d9
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
In the German localization, "Sales Order" MUST be translated as
"Auftragsbestätigung". In all other cases it can remain as
"Verkaufsauftrag".
Term was previously corrected but then overwritten by accident during
fw-port that used old translation.
closesodoo/odoo#157496
X-original-commit: b4cd19a456242dea6ad7bddc2efaf17382ffb453
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Previous fix: odoo/odoo#139013 added in the ability to handle a use case
specific avoided due to its complexity and it being an edge case. I.e.
the ability to do a Put in Pack in a batch picking where there is a
shipping connector involved (i.e. when the `choose_delivery_package`
wizard is opened).
Because the ability to handle this situation is now added to stable, we
have to sort of support it now and handle it not breaking other flows.
Here are the flows that need to be handled (and were broken by the
previous PR): [In all cases, "Packages" setting needs to be activated
and each picking needs at least 1 move of a consumable/storable product]
Flow 1: batch picking + put in pack for single picking
- Create 2 pickings of any operation type
- Create a new batch picking with these 2 pickings
- Open 1 of those pickings directly (i.e. not in the batch)
- Click on "Put in Pack"
Expected result:
Only the move from the open picking is put into a package
Result before this commit:
Both pickings have their moves put into the same package
Additional notes: Because this is not an obvious bug, users may already
had this bug occur in their DBs without realizing it
===
Flow 2: batch picking (or multi-record calling of `action_put_in_pack`)
[different in v17 onwards due to removal of immediate_transfer boolean]
- Create 2 pickings (of different picking types)
- Select both pickings (through direct call in shell or rpc) and call
`action_put_in_pack`
Expected result:
Moves are blocked from being put into same package since this situation
doesn't make sense (i.e. the products are moved to different locations
but the package can only be in 1 location)
Result before this commit:
The moves will all be put into the same package
Additional notes:
In theory batch picking creation has checks to avoid batches where
there are pickings with more than 1 picking type or have different
`show_reserved` values, but because `_package_move_lines` is a method
that can be called in different use cases (including multi-record
pickings) via customizations/future code changes, we add in checks to
prevent put in pack from finishing in those cases to avoid unexpected
behavior/stack traces. I.e. remember to respect existing
`self.ensure_one` checks since they're probably there for a reason.
===
Flow 3: batch picking w/pickings w/more than 1 delivery carriers (where
none = a different carrier than having 1)
- Create 2 delivery pickings with different `carrier_id` values (i.e.
different shipping methods assigned to them)
- Add both pickings to a batch
- Click "Put in Pack" in the batch picking
Expected result:
None, we should not handle this case because if the products are in the
same package then the same package info will be sent to both carriers
and the user will be double charged for every move (or
charged(/potentially create the wrong shipping documents) when it
shouldn't be in case of no carrier for one of the pickings)
Result before this commit:
All moves are put in the same package and the double
charging/potentially incorrect shipping documents will occur
Additional notes:
This is the use case that was intended to be avoided when flow was
originally decided to not be handled
closesodoo/odoo#157224
X-original-commit: b3498facab77e1eed8969c018e3f966a80e62654
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Previous PR: odoo/odoo#135739 added in report placeholders for the sake
of easier editing of reports with studio. Unfortunately it didn't check
that these placeholders aren't printed with real records which results
in junk being included in the report, so we add in conditions to avoid
this situation.
Also, since the report was already being edited, clean up some of the
placeholders because they didn't make sense/ didn't do anything (e.g.
the `address` values weren't used + already have a special placeholder
in studio => remove them).
closesodoo/odoo#156674
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
When a company's annual inventory day is selected which is higher
than the number of days in that month, there are already safeguards in
the feature to ensure the latest day possible for that month is
selected. Unfortunately the related test forgot to take this into
account for leap years, so this commit modifies it to test for this
expected safeguard.
closesodoo/odoo#155987
X-original-commit: 91a6b994455b288e20c688c4e88d7d2aa5cb6f0b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
*account,hr_expense,purchase,repair,sale,spreadsheet_dashboard_*,web
In Chile, "Untaxed Amount" has its own special term that isn't used in
Spain/LATAM spanish: ~~"Total neto"~~ "Monto neto" [Chilean customer
changed what term should be once fw-port was at v17]. Therefore
everywhere that it appears (in a .pot file), we ensure that the es_CL
localization uses this term.
Also untranslated terms from the es_CL.po files that were edited have
been removed since they add no benefit and make it harder to read the
file (we expect to only add terms to the file, not translate every
term for Chile).
opw-3670297
closesodoo/odoo#154473
X-original-commit: d1d4d30ef402ce835cba892459fdceadfc9944e1
Related: odoo/enterprise#56853
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
DeepL translated "false" as "ложный" (the adjective form), but
we expect it to be "ложь" (noun form) when importing xml. This
fix will ensure that the string is correctly converted into a boolean.
I have recorded this as a separate commit for posterity and so it isn't
accidentally changed again in the future.
closesodoo/odoo#152285
Related: odoo/enterprise#55637
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
The module `pos_viva_wallet` was added in v17 stable and it's
translation file/configuration was forgetten when that happened.
Therefore we add it in now because it should probably be translated
Part-of: odoo/odoo#152285
Appending strings within a `t-out` for a website template makes it so
that it can never be translated. Instead the string should be written
like normal text so that it is correctly seen as to be translated and
`t-out` only the next step so that it's also correctly matched as to be
translated.
opw-3700815
closesodoo/odoo#152312
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
For some reason the demo data for some of the ranking motivational
messages is different from their default motivational message (in data).
Because of the way the `translate=html_translate` works, when the demo
data was installed, the original motivational message was overwritten
and therefore not exported in the .pot file so it could never be
translated. Since we want both the demo and original messages
translated, it's best that we add the original messages into the demo
data so that it's not visible to users, but is still exported to the
.pot file.
closesodoo/odoo#150306
X-original-commit: 2f3aafe55ee39a3661477934f63b2a5c90f724a5
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Missing _t to translate a string made it so the cart notification title
was always in English.
opw-3683578
closesodoo/odoo#149761
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Steps to reproduce:
1- install stock_account and account_accountant
2- activate in Settings > Accounting > Automatic Accounting
3- open a Product Category > set Inventory Valuation = Automated
[`real_time`] (optional step: can change the account stock properties
values, but doesn't matter)
4- install mrp_account
Expected result:
- Accounts already set under the Account Stock Properties
(i.e.: property_stock_valuation_account_id,
property_stock_account_input_categ_id, etc)
remain unchanged.
Actual result:
- Account stock properties for any Product Categories already set to
Automated before installing mrp_account are wiped to nothing
Issue:
`_post_load_data` was resetting all property values (i.e. the accounts)
to False since PR odoo/odoo#119564 to ensure correct accounts were used
for `manual_periodic` valuation when stock_account and mrp_account are
first installed. This was previously not an issue because no valuations
could be set to `real_time` before stock_account was installed and
mrp_account did not run `post_load_data` (i.e. an mrp account was added)
until saas-16.3. So now we avoid wiping existing assigned accounts when
mrp_account calls `_post_load_data` at its install time
closesodoo/odoo#147958
Task: 3471065
X-original-commit: cc741525f9349077aefc7d137b6199a68fc87a23
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Following quantitypocalypse (odoo/odoo#137864), a couple of
`reserved_uom_qty` and `reserved_qty` references were left over. This
was partially due to no tests for these tricky parts of the code,
therefore we both fix these references to use the newer
`quantity`/`quantity_product_uom` fields and add/update tests to ensure
we avoid breaking these 2 use cases again.
Also discovered during this fix, the remaining assigned qtys when
unassigning done incoming moves from already reserved outgoing moves
(i.e. the "1. batch reserved + individual picking unreserved" use case
in the code comments) was NOT being calculated correctly. This also
fixes that + adds a test for it.
closesodoo/odoo#147815
Related: odoo/enterprise#53536
Signed-off-by: Steve Van Essche <svs@odoo.com>
Since odoo/odoo#140898 the pickings detailed operation view has been
moved to a smart button instead of showing in a picking tab. This
included the removal of the `force_detailed_view` context since there
was no longer a detailed view to force show. This commit removes some
leftover references to this context within tests.
Part-of: odoo/odoo#147815
Previous PR odoo/odoo#143570 moved some move line ordering logic from the
model to the view to avoid recomputing of these fields since it was
causing issues with the computes occurring at the wrong time.
Unfortunately every field used in the `default_order` in the view has to
be present in the view and since v16 any fields that have a groups
attribute that isn't met isn't loaded in the view.
Therefore we have to force the `result_package_id` to always be in the
view even if `stock.group_tracking_lot` is not true (i.e. packages are
active)
Steps to reproduce:
- create +save a receipt with a tracked product
- click on the burger button to open the detailed operations of the
tracked product
- add 2 move lines + Confirm
Expected behavior:
the move lines save
Actual behavior:
JS traceback due to trying to sort on a field that isn't present in the
view
closesodoo/odoo#147188
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Previous fixodoo/odoo#139277 was added to avoid the python constraints
that didn't allow for duplicate sequence names for picking types. This
constraint is now reverted, but it doesn't hurt to keep the renaming for
debugging purposes (i.e. in case a seq name is unexpectedly duplicated).
The code order of the original fix needs to be updated though since the
seq is created before the search so one is always found and renamed in
many cases.
closesodoo/odoo#143848closesodoo/odoo#145325closesodoo/odoo#146050closesodoo/odoo#146277closesodoo/odoo#146362
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Fixes 2 bugs:
- Users were confused when creating a picking type with a duplicated
prefix name. Because of it, they were unable to distinguish between
the 2 auto-generated ir_sequences since they default to the same name
https://github.com/odoo/odoo/blob/fe29860b22563bcae58a2e118b2a5ea79637589e/addons/stock/models/stock_picking.py#L102-L115
Therefore we add a warning when they try to reuse an existing prefix
(within a company), but not reuse the same seq id. We do not want to
completely block duplicated prefixes in case the user really wants it
and/or it is duplicated programmatically by accident (e.g. doing
uninstall + reinstall of a module).
- When users duplicate an existing picking type, the auto-generated
ir_sequence could result in duplicated picking names, which can result
in a block due to the constraint:
https://github.com/odoo/odoo/blob/fe29860b22563bcae58a2e118b2a5ea79637589e/addons/stock/models/stock_picking.py#L440C1-L441
A previous solution involved linking the existing sequence_id to the
duplicated picking type, but this was NOT a good solution because it
could lead to an inconsistency between the prefix used by the picking
types due to one being changed and the other not, i.e.
https://github.com/odoo/odoo/blob/fe29860b22563bcae58a2e118b2a5ea79637589e/addons/stock/models/stock_picking.py#L123-L136
would be applied, but the user may not see that it auto-changes it for
the other picking type
Note that there are some other bugs that still exist related to these
bugs, but there's only so much time in the world to fix this mechanism,
so posterity (i.e. if someone else wants to fix them) they are:
- Previous fix: odoo/odoo#138471 ensures that the company of a picking
type correctly matches its sequence_id's company. Unfortunately it
does not take into account if the prefix has been changed (i.e. the
picking type prefix WON'T match its sequence's prefix). This mismatch
can also occur if the name of the warehouse is changed.
- Previous fix: odoo/odoo#139277 ensures that the sequence names are
unique so that they are more easily noticed/fixed, but the prefix is
left unchanged. Therefore there can still be issues with duplicate
prefixes leading to the sql_constraints being triggered for pickings
that use both the existing and the new sequence value.
Part-of: odoo/odoo#146362
This reverts commit 52219871e8d8357044763375f6f5318622e9894e.
Orig PR for ref: odoo/odoo#122838
Fix was ok for the specific bug it fixes, but then it adds the
additional bug of 2 picking types which can have different prefixes
but the same sequence_id. This on its own is not a big deal, except that
when a prefix is changed for one of the picking types, then the sequence
is updated for both picking types and the prefix of the not changed
picking type will not match anymore. For users not in debug mode, this
would be quite confusing since they cannot see that it is the same
sequence in both picking types.
A better solution is to default the sequences + their prefixes to be
different.
Part-of: odoo/odoo#146362
This reverts commit 9034602a028fb22fbd139cf41a2f5c71d9d8d032. Orig PR
for reference/auto-linking tracking: odoo/odoo#129394
Commit was intended to prevent having picking type sequences created
with the same code, but set up too strict a condition. This caused
issues with the following use cases:
- upgrades: see odoo/odoo#139277
- uninstalling and reinstalling modules that auto-create picking types
see:
- POS = odoo/odoo#138189
- stock = odoo/odoo#134032
- mrp = odoo/odoo#136755
- repair = odoo/odoo#139841 saas-16.4 onwards
For uninstall + reinstall cases, we should indeed do something better to
clean up these sequences so they do not appear to be duplicates of the
re-added operation types (i.e. unlinking them is not a good solution,
especially since the picking type still exists afterwards). That will
be part of a separate task though and low priority since we already warn
users that uninstalling and reinstalling modules can result in
unexpected behavior.
Since the original issue was only that there was no way to distinguish
between the sequences, a "_copy" will be added to duplicated picking
type records + we will add a warning if users tries to use an already
used sequence prefix (since the name is based off of this) but we won't
block them from doing it.
Also, we move the test that was added after the commit that is being
reverted to a better location.
Part-of: odoo/odoo#146362
Somehow the module disappeared from the file between versions 16.0 and
saas-16.1 even though the .po files exist (up to + including saas-16.2).
Further investigation/fixing will occur later on to check overall
consistency correctly, this commit is only a quick fix to get the
translations working properly for this specific module.
closesodoo/odoo#145044
X-original-commit: d1dfb5085b2d5c21485e75e0eb9e0c43b7e2c079
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Test was breaking during the nightly builds. Most likely due to the
same issue as the one that odoo/odoo#131389 fixes, so we apply the
same fix.
closesodoo/odoo#144031
X-original-commit: 900373b2658240570f97998a7d86a6f4c3fb67fc
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
In pickings we "pick", in mrp we "consume", so let's make the warning
message consistent even if it is probably still confusing.
closesodoo/odoo#142933
Related: odoo/enterprise#51171
Signed-off-by: Steve Van Essche <svs@odoo.com>
During previous fix: odoo/odoo#141797, the `not move.picked` check was
moved to earlier in the if statement to avoid unnecessarily looping
through the move lines, but the ( was forgotten to be moved with it.
Since we don't want to force all manual consumption marked moves to have
a lot_id, let's move the (.
Part-of: odoo/odoo#142933
Requires barcode to be installed to reproduce (or customization of
view/direct shell manipulation)
Steps to reproduce:
- create a SN tracked product with 2 serial numbers
- setup a delivery with a demand of 1 of the SN tracked product
- open the delivery in barcode
- scan the product then scan the not reserved SN
- validate
Expected result:
Only the scanned SN is marked as done
Actual result:
Both SNs are marked as done and the move quantity = 2
Issue is due to the code expecting all mls of a "picked" move to be
processed as done. Typically when this flow is done in the backend, the
user can see that they need to set the not used SN quantity to 0, but
this is not the case in barcode. Therefore since barcode will mark the
scanned SN ml as "picked", but not the other (reserved, but not scanned)
SN, we check at time of picking validation whether or not all of the mls
are marked as "picked" and if now, only count the ones that are marked.
Note that same issue can occur when multi-location quants and
non-reserved loc quantities are scanned.
closesodoo/odoo#141210
Related: odoo/enterprise#50274
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The existing `_search_product_qty` was not scaleable for dbs with many
lots, therefore we optimize it to be more clever.
Also add in the missing operator/value checks.
closesodoo/odoo#126795
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Does 2 things:
- ensure that the "free_qty" doesn't display a negative value (=>
consistent with MO overview + avoids neg "Ready to Produce" values)
- ensure that showOptions.availabilities is always a Boolean and never
"undefined" (=> avoid traceback when opening overview while in debug
mode)
closesodoo/odoo#140767
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Previous to this commit, the qty reserved was only considering the
currently reserved quantities in the MO, not the ones calculated and
displayed in the MO Overview (i.e. including the quantities reserved in
the picking during 2 step mrp). This would lead to showing reserved
quantities but a "Not Ready" status, which is confusing and
inconsistent.
Now we pass the calculated component quantities to the method that
calculates this state and ensure the calculation is consistent.
Steps to reproduce:
- enable 2 or 3 step mrp
- create an MO with a component that is in stock at the stock loc
- confirm MO and open "Overview"
Also change "Quantity" back to "Reserved" in the pdf version of the MO
Overview. This was a mistake change since this column name already
exists and "Reserved" will be hopefully less confusing for users.
Part-of: odoo/odoo#140767
Fixes 2 use cases:
- barcode redirect after picking is validated (should return to menu
instead of refreshing the validated picking). Issue was due to missing
renaming of "on_close" to "onClose" after refactor occured
- ensure the auto-print action during MO validation always has a context
because the "Shop Floor/MES" expects any returned actions from
validation to always have a context to add the extra context parameter
of "skip_redirection" to it
closesodoo/odoo#140352
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The lot and product label wizards were refactored to have diff
variables, so the auto-printing parameters need to be updated to match
Part-of: odoo/odoo#140352
A "quantity_done" removal was missed in the MO Overview report, which
made it so the report would throw an error when opened for a done MO.
Also replace "Reserved" with "Quantity" in the overview so that
it is more consistent with pickings + is more intuitive since it is
currently confusing that when the qty produced is updated, then it
appears that the qty reserved changes (rather than a qty being done)
closesodoo/odoo#140246
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Add in feature to auto-print reception (allocation) report when the
MO is done. Note that only MOs with an allocation will be printed
otherwise the form will only have the MO name/barcode and nothing
else in it (i.e. not very useful).
Part of task: 3046178 - general auto-print goal
closesodoo/odoo#126791
Related: odoo/enterprise#43362
Related: odoo/upgrade#5298
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Add in feature to auto-print reception report at validation of picking.
Note that only pickings that have an allocation will be printed
otherwise the form will only have the picking name/barcode and nothing
else in it (i.e. not very useful).
Part of task: 3046178 - general auto-print goal
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of lot/sn labels when the
`action_generate_serial` button is pushed.
Part of task: 3046178 - MRP behavior auto-printing
ENT PR: odoo/enterprise#43362
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of lot/sn labels when MO is done.
Note that this includes byproducts and does not consider the qtys done
since that is already printed as part of the product labels (which
auto-fills in their lot/SNs as their barcodes)
Part of task: 3046178 - MRP behavior auto-printing
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of reception report labels
when MO is done when there are lines assigned in the reception
report (i.e. any MTO linkages/move_dest_ids).
Part of task: 3046178 - MRP behavior auto-printing
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of Production Order report at MO
completion. Note that existing backorder view actions had to be adjusted
because lack of `views` param did not work with specialized client
action to chain actions.
Part of task: 3046178 - MRP behavior auto-printing
Part-of: odoo/odoo#126791
Steps to reproduce:
- toggle setting `mrp.group_mrp_reception_report = True`
- create a new 'mrp_operation' operation type and activate
`auto_show_reception_report` for this operation type
- create a delivery of a product (qty > 1)
- create 2 MOs for the product to deliver, one with the new operation
type and one with the built in operation type
- try to "Mark as Done" both MOs (from the list view)
Expected result:
MOs are marked as done, only 1 of the MOs shows up in the allocation
report for the delivery
Actual result:
Singleton access issue
Noticed during task: 3046178
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of product and lot labels at
picking validation.
Note that the `product.label.layout` (wizard) has a default picking
quantity value for how many labels should be printed out for each
product that makes sense for the auto-print case, whereas the
`lot.label.layout` (wizard) allows the the user to choose whether or
not to print out 1 label per lot/SN or the qty done of each lot/SN, and
both are valid options for auto-printing. Therefore the selection choices
for `product_label_format` matches it's corresponding wizard's choices
exactly, whereas the `lot_label_format` combines the `print_format` +
`label_quantity` of its corresponding wizard. Hopefully no additional
print formats are created for the lot labels...
Part of task: 3046178 - general auto-print goal
Part-of: odoo/odoo#126791
The default behavior of report_action() is to check if the currently
selected company has their document layout configured. The product
labels do NOT depend on this layout at all though, so let's make it so
the configuration never pops up when product/lot labels are being
printed.
Discovered during task: 3046178
Part-of: odoo/odoo#126791
In previous versions (v14 and earlier) there was only 1 PDF product
label that was easily customizable by users. Then we became super
fancy and created 5 PDF product label formats that are called via 2
different report actions.
Unfortunately we were too fancy and the design of the new reports was
incompatible with user customization. To remedy this, this commit:
- makes it so you can actually open the report label in studio (i.e.
`_prepare_data` in `product_label_report.py` adjusted to handle studio
case + hardcode some values that used to be required from the
`product.label.layout` wizard)
- splits out the non-dymo labels into separate report actions so they
can be individually customized more easily (i.e. individually loaded
from studio)
- splits out the show 4x12 price/no price templates so they can be
separately modified without unintentionally affecting the other
Note that we expect users to be OK with:
- the barcode auto-magic (i.e. clicking on the barcode within the label
will NOT be product.barcode as some of them may expect) since we still
want to cover the use case of SN/lots printing instead of the product
barcode for pickings
- the user will take responsibility if they overlap/delete the
`extra_html` layout wizard value from the label (since it's not
visible in studio without lots of clicking)
Task: 3046178 - split product label templates
Upgrade PR: odoo/upgrade#5298
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of reception report labels
at picking validation when there are lines assigned in the reception
report (i.e. any MTO linkages/move_dest_ids).
Note that a little fix hack was necessary for this feature (i.e.
override of ir.actions.report to ensure that the doc_ids/docs are
correctly set) since this report was originally designed to be called
ONLY from the JS + using the report link to pass the correct parameters,
which cannot be done in the same way via the standard
ir.actions.report.report_action method
Part of task: 3046178 - general auto-print goal
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of package label when "Put in
Pack" button is pushed. Note there are 2 choices for package labels and
these choices are hardcoded in as selection options to avoid complexity
of finding all relevant reports (i.e. custom report labels won't be
auto-printable) and exclude the irrelevant reports.
Unfortunately since there are different flows for "Put in Pack", a
separate "_post_put_in_pack_hook" method is needed to manually be called
in some of these cases and additional future use cases will also require
it to be called if this feature is desired in that case.
Additionally clean up _put_in_pack() since it was only called by methods
with ensure_one(), but was semi-designed to handle multiple pickings
(but only returned 1 package in the end, which didn't make sense + had
other errors in it).
Part of task: 3046178 - At package creation (put in pack)
Part-of: odoo/odoo#126791
This commit adds two linked features:
1- the ability to chain (report) actions
2- the ability to auto-print delivery report at picking validation
Because feature 2 results in the possibility of 2 actions to be returned
at picking validation (due to pre-existing auto-open reception report at
validation option), feature 1 is required to support it. It is expected
that chaining will primarily occur with report actions since chaining of
the other action types does not currently have an applicable use case.
Since this feature is only needed within stock for now, it is
encapsulated within a custom client_action for now that is a lot of copy
paste of action_service.js
This is the first commit to support a series of potential
auto-printable reports.
Part of task: 3046178 - Operation Type
ENT PR: odoo/enterprise#43362
Part-of: odoo/odoo#126791
steps to reproduce:
- activate Settings > Reception Report
- Create new storable product
- Create + confirm planned delivery of 5 of the product
- Create + confirm planned receipt of 2 of the product
- Open reception report (Allocation button) in receipt
- Assign the 2 products to the delivery
- create +confirm a new delivery with 2 products
- create + confirm a new receipt with 2 products
- Open reception report in new receipt
Expected result:
The stock.move in the original delivery will be split into 2 moves, with
Demand qtys of 2 and 3 respectively. Opening the new receipt's reception
report will allow you to assign to the remaining 2 in the original
delivery
Actual result:
Only the new delivery is displayed rather than the old delivery
Issue was due to the `reservation_date` not being copied into the newly
split move even though we would expect it to be the same (instead it is
`False` since the default reservation method for operation types is
`at_confirm` and the new move does not have `action_confirm` called on
it, so the date is never set). Since we usually don't want this date to
be copied, we only manually do it in the reception report splits.
Part-of: odoo/odoo#126791
Previous to this commit, only the return labels had a consistent prefix
for their filenames. This meant that all other shipping related
documents had their filenames manually + inconsistently created as
strings in every shipping connector. This lead to difficult to
distinguish documents across different records' chatters.
This commit adds a consistent method for the shipping connectors to use.
Part of task: 3046178 - harmonize shipping label names
ENT PR: odoo/enterprise#43362
Part-of: odoo/odoo#126791
Previous fixodoo/odoo#135784 added a test to repair that references
a sale_order_line field that only exists when the sale_margin module is
installed. Unfortunately there isn't already a common module that
requires both repair + sale_margin and runbot doesn't do single module
app tests so this test slipped through the cracks.
To avoid the error when the nightly single module tests occur, we avoid
running the test when sale_margin is installed since it will still run
during standard runbot tests and ensure that the bug doesn't return.
closesodoo/odoo#137490
X-original-commit: 6343e2f3125bb48b01bf5b1ef7be36d86ae35f86
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Previous fixodoo/odoo#131279 missed marking component lines added in
from the consumption warning wizard as "additional". This made it so the
added line was also added into the backorder when it should NOT have
been (since the backorder should only be based on the original MO's
values).
Followup of task: 3456604
closesodoo/odoo#136728
X-original-commit: 7a45b691781e2862e87da7914a8b3b9a6487b7e9
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Previous fixodoo/odoo#121602 did not correctly handle the case when not
all of the qty to manufacture is manufactured (the qtys to change to
were miscalculated in this case).
Additionally, it missed fixing a few more use cases when setting the
qtys to match the wizard's lines/qtys:
- if the UoM of a MO's component line is changed => the correct qty was
not correctly converted into the move.product_uom's qty (now it is)
- if a component's move is deleted before the MO is confirmed => the
move (i.e. the missing component) was not correctly added back into
the MO (now it is)
- if there are 2 MO component moves with the same product => both were
set to the same "correct qty" value (now we only set the first move to
that qty, others are set to 0 since we have no way of knowing how to
distribute the qtys otherwise)
Also, since an UserError needed to be added in case of a missing comp
move for a tracked product, existing error logic has been updated to
list all applicable products and the message has been improved to be
more helpful.
Note that the fix for saas-16.4 and earlier is slightly different from
this fix due to the change in how stock move original demand qtys no
longer change like they used to (see: odoo/odoo#130342) and because a
backorder bug was also exposed by this change.
closesodoo/odoo#135796
Task: 3456604
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Minor cleanup after odoo/odoo#104741 thanks to edge-cases and the fun
complexity of logistics code. Fixes include:
- removing some readonly=False that were added on computed/stored fields
that already have an inverse func or were already not readonly (i.e.
redundant => cleanup)
- fixed visibility of qty to prod in subcontractor portal view of a MO
(i.e. yay they know how much they're supposed to make again)
- remove unused imports
- adding back in readonly functionality of default dest of repair
operation type (and removing the now useless field override that used
to add in the readonly functionality)
- adding back in the `_set_product_qty` inverse function since it was
probably removed by mistake (and is still important to have)
unrelated to viewpocolypse change, also fixed:
- mobile view of PO was for some reason allowing products to be changed
in already confirmed/done POs, which could lead to some inconsistent
data => made this consistent with existing desktop view behavior
closesodoo/odoo#133502
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Previous PR: odoo/odoo#113973 assumed that if stock_accounting_automatic
setting was disabled, then the user deactivated the setting and it was
previously on => we should change all of the property_valuations to
'manual_periodic'. Unfortunately this missed the case where the
property_valuations were set to `real_time` without the setting being
active (i.e. upgraded db and the setting isn't activated or the
value is set directly via ssh or community module)
Additionally, it was causing an unnecessary search on product.category
every time a setting is changed. Therefore we now only change the
`property_valuation` if the setting was active and was changed to not
active.
OPW-3474598 for context
closesodoo/odoo#133254
X-original-commit: 96b17f9a19855a78a7b879299ea51eb5bde0acf8
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
PR #106911 added the new picking.type for repair and hide the
`show_operations` field from its form view. Unfortunately this writes
over the existing invisible attr for mrp_operation (depending on the
order of module installation, otherwise mrp will do the same to repair).
Therefore we update the attribute logic to only include the picking
types that should have the field visible (incoming, outgoing, internal,
and dropship).
closesodoo/odoo#132012
X-original-commit: 1688a8d82ce7aec32f17fc8c35295cccbb682dd6
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Add a new filter to the orderpoints view to allow filtering by vendor.
closesodoo/odoo#101090
Task: 2964309
Signed-off-by: Tiffany Chang <tic@odoo.com>
PR odoo/odoo#115197 refactored how a field's domain is read.
Unfortunately it removed the ability to use a domain with python code in
it which can lead to a "Invalid domain AST" client error since it is no
longer parsed correctly.
Steps to reproduce:
- Install mrp_workorder and quality_control
- Open Quality app
- Quality Control > Control Points > New
- Click on `product_ids` field
=> Error is thrown. Issue is due to `product_ids` domain being python
dependent (i.e. if specific record value is set => use one domain,
otherwise use other domain):
https://github.com/odoo/enterprise/blob/d2b0eacd68d6558aa9376985a72a350e20d7619d/mrp_workorder/models/quality.py#L101
which isn't correctly parsed into an AST and which results in this call
throwing the "Invalid domain AST" error
https://github.com/odoo/odoo/blob/75c71ccfa8b5daa79f82af1e492831c565ee54f3/addons/web/static/src/views/fields/many2many_tags/many2many_tags_field.js#L153-L154C13
Note that the type check is needed because sometimes the domain is
passed as an array and other times as a string and we should only
evalExpr on strings. Also for safety we ensure that we do not pass an
domain of "undefined" as well.
closesodoo/odoo#126089
X-original-commit: ffd4ee838cfddb366aa9aafa2f2d92d9a434569e
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
PR odoo/odoo#109511 added in a related expiration_date field linked to
its lot_id's expiration_date. This field was added as readonly=False,
which was a mistake due to the following issues it causes:
bug - the related dates (use_date, removal_date, alert_date) won't
correctly update, this is easily fixable
bug - [mostly a nuisance, but will be confusing for users], if there are
2 lines for the same lot (e.g. different locations) then updating
the expiration_date for one line won't show in the other lines
without a view refresh (could be fixed with custom JS, but not
ideal)
bad UX - cluttered view of editable values
redundancy - the ability to edit the expiration_date is easily done by
clicking on the lot name within the view or by opening the
list view of the lots and batch editing dates
For stable we will make this field readonly. This field and
`removal_date` would ideally be removed since they would never be
different from the lot value, but both need to remain stored since they
are used for the removal_strategy_order and gathering non-expired
lots/SNs.
opw-3328901
closesodoo/odoo#123746
X-original-commit: d21d9259aef855c900169263db90873b736f3df6
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Followup cleanup of https://github.com/odoo/odoo/pull/106620 where
Datamatrix of pylibdmtx was replaced with built-in reportlab
ECC200DataMatrix option. For stable compatibility, some parts could
only be deleted in master, so let's delete them now.
closesodoo/odoo#122704
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In the case of draft pickings/MOs, the reception_report_main
component's "Assign All" button was NOT disabled, which could result
in an IndexError if the button was pushed. Note that this issue does not
occur for the "Assign All" button within a table because the button is
correctly not shown at all when there are no assignable lines within it.
Noticed during task: 3046178
X-original-commit: 403d1ba5839d6073ee6321e77863f928336158ba
Part-of: odoo/odoo#120935
Steps to reproduce:
- activate Reception Report in settings
- create outgoing picking for a product (qty > qty in stock)
- create an incoming picking for the same product with a non-int qty
- confirm the incoming picking + click on "Allocation" smartbutton
- assign product to outgoing picking + click "Print Labels" (either at
top of report or within the table of outgoing moves)
Expected result:
Labels and created + printed
Actual result:
ValueError because int() is called on a non-int value within the label
template
Note that the the `onClickPrint` within the reception_report_line.js
already correctly did the Math.ceil rounding on the qty
Noticed during task: 3046178
X-original-commit: 69c557a5c0b407333be45cd7434448fc36de899e
Part-of: odoo/odoo#120935
PR https://github.com/odoo/odoo/pull/106414 made it so the
`product.label.layout` expecting `stock.move` ids rather than
`stock.move.line` ids. Unfortunately it missed updating this for the
batch picking case => when printing the labels for a batch picking,
only 1 label was printed per product rather than the qty done.
Note that this issue does not occur when the batch is Done + has
lots/SNs assigned in it
closesodoo/odoo#118995
X-original-commit: a5af45a8e3ff8860655351dd76a11f1dbb6d8a70
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Existing constrains method had a bug in it, so let's take this
opportunity to replace it with the more efficient _sql_constraints
check.
closesodoo/odoo#115613Fixes: odoo/odoo#92799
X-original-commit: 0751a0e27b653d5c471120ba7f5dea37a3f30a28
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Some users were updating their access rights to allow for direct
deletion of quants. This could lead to the infamous:
"It is not possible to unreserve more products of %s than you have in stock."
error since directly deleting a quant bypasses the flows of correctly
unreserving the amounts you are deleting. Therefore we now restrict
the unlinking to:
- when in sudo mode, since the automatic unlinking of zero quants always
occurs in sudo mode.
- stock manager when unlink access right = True. Normally we would allow
any user with the unlink access to do it, but since we are using the
existing `_apply_inventory` to ensure that reserved qtys of the
quant are correctly unreserved before the unlinking, only stock
managers will correctly do this unreservation.
It is expected that some custom code may break due to this restriction,
but if custom code is directly unlinking quants without a sudo or with a
non-stock manager, then the code in these cases probably need to be
fixed anyways since this will cause inconsistent db data and lead to
the error above.
X-original-commit: d1602e7ddefd59cafa1ce0a5522a53c987135858
Part-of: odoo/odoo#115613
Small copy/paste error during odoo/odoo#95332 made it so
`line.picking_id.location_id` was used when assigning `location_dest_id`
of a directly created `move.line` in a picking. Usually this would not
be noticeable due to `default_location_dest_id` in the views ensuring
the correct value, but move lines created directly will be incorrect.
In addition to adding this case to existing test, the test has also been
updated to use non-default locations to ensure no other default values
are causing the result to be correct when it may not be under other
circumstances.
Issue noticed during master refactoring to remove location_id /
location_dest_id fields from views when multi-location is not active.
closesodoo/odoo#110672
X-original-commit: 74bfa154dde72ce792428521aea128408965dcc1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previously in https://github.com/odoo/odoo/pull/88644/commits/a57be884ee625ab2d67b65f0ece0b8e9b1620369
we restricted the subcontractor locations (property_stock_subcontractor)
to locations with the new setting `is_subcontracting_location=True`. The
purpose of this new setting is primilarily to support the
mrp_subcontracting dropshipping use case though, therefore we want to
keep the previous freedom of allowing users to choose any location as a
subcontracting_location. There are some routing and filtering
errors/confusion that can occur if a user selects a location that isn't
marked as `is_subcontracting_location` (or sets this value to false
after already assigning it to a subcontractor), but since this has not
been reported as an issue in the past, we expect users to properly
configure these fields accordingly.
Part of general bugfix task: 2985735
closesodoo/odoo#110200
X-original-commit: d86df2b9cef742b6cadd294f57a855634768d039
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Incorrect variable reference + calculation for unit BoM cost for
byproduct/product (to produce) within in BoM overview report. This
was leading to the displayed value having the cost_share being multipled
into the unit cost twice.
Steps to reproduce:
- create component with cost 100
- create BoM with 1 of this component + 1 byproduct with
qty = 2 and cost_share = 50.00
- click on Overview
result before this commit:
Manufactured Product unit cost = 25.00
Byproduct unit cost = 12.50
actual result should be:
Manufactured Product unit cost = 50.00
Byproduct unit cost = 25.00
closesodoo/odoo#107410
X-original-commit: 2339bed170b5f670b1f5a6cebd533a9cee72d4db
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Issue: In the MO view, the src location for components was editable and
the dest location for byproducts was editable when neither of these
should be.
Due to the same field appearing twice in the same x2many field list,
there were 2 issues:
1. something changed (probably during OWL refactoring) that made it so
the 2nd invisible field instance of the field was overriding the
"readonly='1'" property of the 1st instance when it was in the view
(i.e. when multi-locations is active) [in previous versions this did
not happen]
2. because of the change by https://github.com/odoo/odoo/commit/168cbe66bee7824bdf389de5c6c680342e27bc6d
we ensure that these two required fields are always correctly set (to
the MO's values as per the default when multi-loc is active) when the
MO's moves are created.
Part of general bugfix task: 2985735
closesodoo/odoo#106542
X-original-commit: 1bb2c44d32e669a9b936da90cbd80721b2c897ef
Related: odoo/enterprise#34396
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previous commit 0501bbd62e made it so
the `product_uom_id` for the `line_ids` of a purchase.requsition (i.e. a
blanket order) were no longer being saved when the UoM setting is not
active. This would cause an error to occur when the "New Quotation"
button is pushed because the missing uom is expected by purchase
_onchange_requisition_id.
Steps to reproduce:
- Have UoM setting NOT active
- Create a blanket order for any product/vendor
- Confirm the blanket order
- Click on "New Quotation"
Expected Behavior:
New RFQ created
Actual Behavior:
Stacktrace
We also properly restrict the product_uom_id in the form view of the
line_ids to when the uom setting is active.
closesodoo/odoo#104900
X-original-commit: e90200a7b927ecccb8d4d6f31e3ddecba24d0b6d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Previous fix
https://github.com/odoo/odoo/commit/72dff43a4da277b002966f5fd4045b7f9a3855ad
re-exposed uoms in the view even if the setting is not active, but we
prefer to avoid this if possible. In order to do this we ensure that the
uom is set even if it is not visible in the view. Most of these are
already handled by compute methods, but except for `repair.fee` so we
only add in a guarantee for that model.
Note that the write case is included in cases when:
- the uoms were previously activated and set => deactivated again
- demo data has different uoms set and uoms setting is not active
X-original-commit: 7e64ebb3d8d3f3d3749304a325eb073777b129dc
Part-of: odoo/odoo#104900
scrap_qty was recently turned into a compute but was missing
readonly=False so scraps created from scratch were stuck on a scrap_qty
of 1.
X-original-commit: e2a2a6e2526446b6f8d041135a4e5653fa96bb47
Part-of: odoo/odoo#104900
The group unification done by https://github.com/odoo/odoo/pull/95729
missed adding the often mandatory `product_uom` into some views when
`uom.group_uom` is False. This is the case for repair and blocks the
user from saving its form view in this case.
X-original-commit: 72dff43a4da277b002966f5fd4045b7f9a3855ad
Part-of: odoo/odoo#104067
Followup to inventory back2basics task 2882539
- order stock.move.line tree (Moves History) view by "id desc" for
better performance (prev: create_date is not indexed)
- order stock.valuation.layer tree (Valuation) view by "id desc" for
better performance (prev: date is not indexed)
- hide "Moved Quantity" column when in current valuation (not at date)
- remove the action: "Set" and print: "Count Sheet" from
stock.quant.view when not in "Inventory Adjustment" related view
- Fix "Inventory At Date"/"Valuation At Date" button visibility issue
that came up due to OWL refactoring
- Don't show consumables in stock.valuation.layer (Valuation) report
view action (forgot to include domain when creating new action)
- Add stock.move menuitem back in under "reporting" in debug mode since
this view isn't accesible anywhere else and it is used a lot for qty
forecasts by users
- Add "Created By" (as "Done By") to stock.move.line history view for
easier tracking of inventory adjustments
closesodoo/odoo#102929
Task: 2965586
X-original-commit: 8904c3c4b709f94266a883bc734faad8b3b4ba3a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
OWLified qty_at_date_widget. Implementation notes:
- old popup using jquery is obsolete so a new Popup component is used
instead. Note that original widget updated the record data directly
whereas we now have a separate variable to keep the props consistent
as per good OWL practice.
- sale_stock.xml is renamed to delay_alert.xml because xml related to
this widget was moved into a separate file whereas the remaining xml
data is not directly called by JS but is still static and used by
another widget eventually
- float_round in legacy implementation is a legacy util => we leave it
off for now and maybe it will need to be fixed later
ENT PR: odoo/enterprise#32276closesodoo/odoo#102248
X-original-commit: 73155293d503e3a9dd65898b8e1ac489e279c33c
Related: odoo/enterprise#32321
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
For original specs, see [1].
Some performance changes: the best price/date/unit price fields are now
loaded by JS instead of passed via action context (allows for easier/
consistent reuse of view + now we can refresh without undoing any state
changes due to buttons being pushed).
[1] https://github.com/odoo/odoo/commit/f533e40f0e3f1cd34f1047b70dfdf95837d84501closesodoo/odoo#101502
X-original-commit: 41ae508c2e6fc3c40b29b1bfc4b5dd7c4440a719
Signed-off-by: Antony Lesuisse <al@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Commit [1] made it so the computed stock_location.warehouse_id field is
stored. Unfortunately it did not correctly add the additional depends
value of `location_id` so when this value is changed after the record
has been initially created+saved without a location_id, the warehouse
will never be correctly computed.
[1] https://github.com/odoo/odoo/commit/9978bcb366d0ea48ed25a7891e0c7653a2f96bfb
Followup to task: 2882539
closesodoo/odoo#100219
Related: odoo/upgrade#3901
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The `is_subcontracting_location` setting is intended only for
complicated route/rule use cases therefore we make it visible
only in debug mode to prevent users from setting this value and
unintentionally creating a lot of new routes/rules unnecessary.
Additionally, it is expected that users who previously set these up
manually will not want their custom rules/routes changed but will still
need the existing behavior to continue, so we restore the previous check
for subcontracting locations set as sublocations of the primary company
subcontracting location.
Follow up to task: 2720393
Part-of: odoo/odoo#100219
During the OWL refactoring, the "decoration-bf" and "decoration-it" were
not included in the standard decoration handling to convert them into
the default bootstrap classes. I.e. the previously applied commit:
https://github.com/odoo/odoo/pull/73210/commits/29390ccdc3447c3d1ef4da1d805e630d00402fbd
was not ported over to the updated OWL views/fields. Note that this
commit uses the BS5 classes of fw-bold and fst-italic and should not be
backported because of that.
Also added QUnit tests to handle these 2 decoration cases.
closesodoo/odoo#99698
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The move line form view is too technical for the average user so instead we
can to auto-magically open the reference document instead (picking or MO
only for now).
We do the same with stock valuation layers as well, but this feature
will not be available until its custom JS is converted to OWL
"product moves" part of b2b task: 2882539
closesodoo/odoo#97109
Related: odoo/enterprise#29974
Related: odoo/upgrade#3819
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit adds a generic `action="action_some_method"` attribute to
the list view to allow for a custom action when clicking on a (record)
row. This feature mirrors the existing Kanban "action" attribute.
Note that in cases where the action method does not return a valid
action then the default action `act_window_close` will be called
instead (same behavior as the kanban view and buttons in general).
Supports "magic link" part of Task: 2882539
Part-of: odoo/odoo#97109
Adds a new reporting view for [storable] product.product to allow for
easier analysis by product (rather than by quant which is location
specific).
This includes:
- adding 3 new fields for products:
- avg_cost = total svl value / total qty
- total_value = avg_cost / on hand
- company_currency_id = self.env.company.currency_id (i.e. the
currently selected company) for which currency symbol to display in
the view
- IMPORTANT NOTE:
- these variables (and some of the existing ones) do NOT support
multi-company aggregations due these values being used to calcuate
future svls which should be company specific. Larger refactoring
would be needed to ensure correct calc in both cases. Larger issue
occurs in stock.report which uses these variables in combination
with variables that do take into account multi-company records.
- A customized `SearchPanel` so that a warehouse context can be applied
to the view, rather than a filter. (viewable only when more than 1
warehouse)
"stock report" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Minor UX updates in purchase and stock:
Reworded (in stock):
- Default name location "Partner Locations" => "Partners"
- Default result for "Apply All" wizard "Inventory Adjustment" =>
"Quantity Updated"
- Individual "Apply" move reference/name updated for individual quants
(i.e. "Quantity Updated / Confirmed") so that the scheduled date is
no longer included
Removed (from purchase):
- Duplicated menuitems, i.e. "Purchase > Reporting > Purchase" showed
the same thing as Enterprise menuitem and both were being displayed in
Enterprise version. Also updated the no records found help message
since old message appeared to be slightly out of date.
ENT PR: odoo/enterprise#29974
"other" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Minor UX updates to forecast report:
- add missing space (between # and unit + before |) also removed
superfluous uoms (only need it at the end now that an equation is
displayed)
- move On Hand Value to under product link (+ variants if they exist)
and make it a link to the valuation report of the product(s) in
question
- add link from Quantity on Hand to the locations (i.e. inventory/quants)
report for the relevant product(s). Note that product template was
added to Search in order to support default searching due to
forecasting report structure
- redo the top right forecast values to be On Hand + Incoming - Outgoing
= Forecasted so we provide more explicit and transparent values.
Additionally, these values are made to not display decimal digits if
all of those digits are 0. Note that forecasted values in table are
untouched (i.e. Forecasted Inventory = Forecasted is unchanged and
Forecasted with Pending still shows in table)
Also did some t-esc => t-out replacement and other small cleanup since
templates were already being edited.
"forecasted report" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Note this is specific to the view shown when clicking on
"Reporting > Valuation", but this uses the same 'stock.quantity.history'
wizard and related custom js as "Configuration > Locations > Current Stock"
Minor UX updates to valuation report:
- don't default groupby product
- add filters incoming and outgoing (same logic as stock.move filters)
- replace "Inventory at Date" with "Valuation at Date" where appropriate
(but leave location current stock view untouched)
- create separate view for the valuation report so remaining qty/value
are displayed, but all other svl viewing actions (including the
"Valuation at Date") will remain showing the original qty/value to
support deeper analysis
- don't sum unit_cost when groupby is applied in list view since the
value won't make sense
- add "reference" to svl which is = to stock.move.reference
"valuation" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Note this includes the view shown when clicking on:
- "History" button in inventory adjustments
- "Product Moves" button in scrap/product forms
- "Reporting" > "Moves History"
At time of this commit being written. Other move line views not changed
since they are specific to inputting data rather than readonly data.
Minor UX updates to stock move lines report:
- rename "Units of Measure" column to "Unit"
- add color to quantity field (green = incoming qty into stock, red =
outgoing, black = all others [i.e. internal transfers/external
locations only, etc]
- search filter order updated + src/dest location filters replaced with
generic filter that checks if either meets condition
- add src/dest package to list view
- add status, lot, and from/to dest to kanban view and replace picking
with reference so inventory adjustments are visible as well
- order by date desc so most recent ones are first
- always display location src/dest to help understanding of moves
Specific to "History" button in Inventory Adjustments / Reporting >
Locations (i.e. inventory report), moved product_id from domain to
default_search for more user analysis flexibility/ease.
"product moves" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Minor UX updates to stock moves report:
- don't default groupby source location
- order list by date
- rename "Units of Measure" column to "Unit"
- add color to quantity field (green = incoming qty into stock, red =
outgoing, black = all others [i.e. internal transfers/external
locations only, etc]
- search filter order updated
- make to location_{dest_}id text-muted when not a physical location
(i.e. internal/transit)
- display "Quantity" instead of "Demand" for product_uom_qty and show
sum at bottom of list
"stock moves" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Inventory report has been updated to have:
- better applicability: report renamed to "Locations" and is only
visible w/Locations, Consignment, or debug mode active
- improved UX: list view rearranged, buttons added, grouping removed,
sums added to bottom of list
- improved quant "Value": instead of the accounting value, this is now
the average unit cost (i.e. sum(valuation layer values)/sum(valuation
layer quantities) per product x on hand qty (of quant).
- single click load for products
- search based on Warehouse option (including storing
location.warehouse_id to avoid overly complex search function)
- always show "Location" column in this view even if multi-locations is
not active
"inventory report" part of b2b task: 2882539
Upgrade PR: odoo/upgrade#3819
Part-of: odoo/odoo#97109
The Forecasted Inventory view has become obsolete, therefore we delete
the code associated with this view. Note that the Forecasted Report
still uses the graph view of this view so we leave it. Because the
Forecasted Report still uses this view + stock.warehouse.orderpoint
relies on the report.stock.quantity model, we leave the model as is.
"forecast inventory" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974
Upgrade PR: odoo/upgrade#3819
Part-of: odoo/odoo#97109
- reorder/rename/remove menu contents for "Inventory" and "Reporting",
including:
- removed "Forecasted Inventory" menuitem since this view is no longer
considered useful (code for view to be removed in separate commit)
- removed "Stock Moves" (moves report) menuitem
- renamed "Product Move" (move lines report) menuitem => "Moves
History", this will also be reflected in any "History" buttons that
open this view from other views.
- made "Inventory Report" menuitem visible only when applicable (i.e.
multi-location or consignment is active/debug mpde)
- made "Run Scheduler" menuitem only available in debug mode (
main_flow_tour updated to skip scheduler click since general flow is
expected to still the same/work)
Goal of renaming/ordering of menuitems is to clean them up and make them
more intuitive for users.
- "Run Scheduler" in mrp menus has also been made debug only viewable as
well to mirror the inventory change.
"menu" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974
Part-of: odoo/odoo#97109
Previous fix: https://github.com/odoo/odoo/pull/84631 missed the case
when raw_move_ids have already done move_orig_ids (i.e. when 2/3 step
MOs or subcontracting w/ resupply contractor). This made it so when
MOs are backordered, these moves would not be reserved even though they
were in the original MO.
This issue was fixed during a refactoring (reserved amounts are now
distributed to backordered MOs), but this commit will add a test to
prevent the issue from returning in the future.
Part of Task: 2777571
Original PR fix (pre-refactoring): odoo/odoo#91460closesodoo/odoo#97383
X-original-commit: a825d9ed715b369128c876174ca6ebfac72adbe5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- create a subcontracted product (i.e. create subcontract BoM)
- create and confirm PO for subcontracted product (qty > 1)
- try to decrease PO qty for subcontracted product
Expected Result:
Since receipt is not yet validated, the qty in the receipt should
decrease (it will in the subcontract MO as well, but this doesn't matter
since no one should work directly with the MO)
Actual Result:
A validation error occurs saying the qty to produce must be non-negative
We allow neg demand qtys to be proprogated from SOs and POs since
https://github.com/odoo/odoo/pull/76752 . While we added in a check to
make sure MOs are not created when a neg qty change is proprogated, we
forgot to add a check for subcontracted created MOs, hence the
validation error (i.e. the neg qty change is trying to create a
subcontracted MO of a neg amount.)
Task: 2777571 (issue 2 of additional issues)
X-original-commit: 251f146b6ecb0e2d428089669199a6deb3a6c060
Part-of: odoo/odoo#97383
Tiffany Chang (tic)