Set sale order and production order link on Mo. override make_mo method in sale_mrp module to set sale order reference in mo.
.and to find final destination move, i created one common private method to get parent move.
MESSAGES TO DISPLAY:
-Set a Reordering Rule (stock.warehouse.orderpoint) that creates a manufacturing order:
"This manufacturing order has been created from: OP/00001"
-Create new Sales order of manufactured product , there will be a Source Document with procurement of that Sale Order
"This manufacturing order has been created from: SO001"
-create MO for BoM items of the product, there will be a Source Document with procurement of that Manufacturing Order
"This manufacturing order has been created from: MO/00001"
Previously we had 'Inventory at Date' (debug mode) and 'Inventory Valuation'
Both have been merged into 'Inventory Valuation' that pops up a wizard asking
whether you want the current one or the one from a specific date.
Depending on which one you choose you will get either report from the previous
menus. (stock.quant or stock.history model)
* Do not assault the user with a full traceback on bug, but indicates
an error occured and allow him to toggle the traceback
* Automatically scroll the traceback to the end (better for python
errors)
* Propose the user to report the traceback by using a new "Copy"
button which correctly copies the full error + traceback
* Remove 'greater than'
* Remove 'less than'
* Rename 'greater than or equal to' with 'is after'
* Rename 'less than or equal to' with 'is before'
* Datepicker starts now by default with the current date
Before, when we consumed 3 instead of 1 in a production order, it
gave a traceback. It was because it created moves
with negative quantities. So, something was wrong with
the quantity_done/product_uom_qty set when creating the extra moves
When creating an extra move because of the procurement,
but you still need to split afterwards (e.g. procurement 10, production order 12, you do 11),
then you should have a difference between quantity_done and product_uom_qty
in the extra move and not try to change it on the original.
That way, we make sure we pass the correct quantities.
There was some code taking care of reconciling the exchange rate entris and their reversal, but it was done in the unlink of full reconciliation. It's way more logical to deleguate that in reverse_move() as we want to completly cancel any line reversed (which means that partially reconciled line should be unreconciled first then totally reconciled with their reversal, for any line with an account set as reconcile=True.. not only in case of full reconciliation with exchange rate entries)
We support 'returns' in the POS frontend by allowing the user to
specify a negative quantity. Before this patch however, the backend
would always generate a single picking per pos.order. This is
problematic when a pos.order contains both lines with a positive and
negative quantity. The generated move lines would not all have the same
source and destination location and so could not be added to the same
picking.
This commit creates an extra 'return' picking when required and assigns
the generated moves to the correct picking.
opw-690812
Closes#13929
Forward-port of 19cca50e7c
Underscore method _.each expects an array like object when a "length"
property is present.
This was an issue with a record having a numeric "length" field set to a
non-negative value. When changing a line the change would not appear on
blur.
This issue was fixed with 0e664c9e9 but introduced back with f0e331e00.
opw-691070
Forward-port of 5d17749ff4 which has been
forgotten during previous forward-port.
When a group of tax is nested inside another group of taxes, the tax
amount and base are wrongly calculated. It is also the case when a tax
is applied after a group of taxes.
This is because the recursive call doesn't reuse the previously
calculated tax amounts and base, but always use the same entry amounts.
The fix introduces this behavior, and moreover makes sure to include the
tax group in the base amount only if it should.
Closes#13995
When clicking on "Show older messages" in the bottom of the chatter, the
page would jump to the top when the additional messages are loaded.
There is already a functionality in a discuss channel to stay at the
previous scrolling position (related to the content) :
https://github.com/odoo/odoo/blob/ffe0db0d/addons/mail/static/src/js/client_action.js#L506-L521
This fix does the same steps for the chatter.
opw-692010
`id1`, `id2`, `rel` are deprecated now that we switched to the
new API, and are simply ignored.
Keeping them is confusing because the default names are being
used instead.
@rco-odoo: We should add a warning in the m2m constructor if these
unsupported parameters are still passed.
Consider that you have a custom one2many field based on a custom many2one
field, and that you delete the many2one field. From that point on, it is
impossible to load the registry of the corresponding database. To prevent this
from happening, we add a check before modifying or deleting custom fields.
When unreconciling a payment from an invoice, the link between
the payment and the invoice (in many2many invoice_ids)was kept
and then the invoice still appeared when clicking on the button
invoices in the payment form view.
The invoice must be removed from invoice_ids.
opw:691692
When clicking on the trash to remove a line (e.g. a sale order line
in a quotation form view) while editing another line, it produces a
traceback (in most cases), or behaves randomly (less frequently)
like removing both lines, or one of them, or maybe none of them.
Anyway, this feature doesn't work at all, so this commit simply disables
it when we are in edition mode.
In a perfect world, we would fix the feature instead of disabling it,
but the code of the list editable is so instable that it would most
certainly break something else.
Closes#13778
The dashboard instantiates an action manager for each view it contains.
When removing a view from the dashboard, the $el of its action manager
is simply removed from the DOM, unbinding all DOM event handlers
attached on it and its children, but the action manager isn't destroyed.
It means that Odoo event handlers (like core.bus.on(...)) aren't unbound.
This causes a traceback when removing a calendar view from the dashboard,
because such an Odoo handler is defined, and tries to access some
autocomplete stuff that doesn't exist anymore since the element has been
removed.
This commit ensures to destroy the action_manager.
Closes#13858
Since rev. 002660a, form views are instantiated with their fields_view.
This has an impact in FormViewDialog as the inner form view
instantiation is now asynchronous. The diagram view instantiates several
FormViewDialogs but doesn't wait for the form view to be instantiated
before accessing it, which produces a traceback.
Closes#13775
- Invoice a POS order => the invoice number is for example 0001
- Close the POS session
- Invoice another POS order => the invoice number is 0003
This is because the journal used for the POS closing entries is the same
than the journal used for the customer invoices. Therefore, the closing
entry consumes a sequence number of the invoices.
This affects POS orders, but potentially SO as well if they use the same
journal.
This is fixed in v10 from commit b5b0d36b31. In v9, we use a workaround
by looking first if a `ir.config_parameter` named
`pos.closing.journal_id` exists. We use this journal for the session
closing.
opw-691771
One of the behavioural divergences between "create or replace" view and
DROP; CREATE turns out to be that "create or replace" can only add
columns *at the end* of the view, and can not change the name or type of
the view during replacement, which can break migrations.
Reinstate the old drop;create as replacement is not necessary for this
specific view.
We support 'returns' in the POS frontend by allowing the user to
specify a negative quantity. Before this patch however, the backend
would always generate a single picking per pos.order. This is
problematic when a pos.order contains both lines with a positive and
negative quantity. The generated move lines would not all have the same
source and destination location and so could not be added to the same
picking.
This commit creates an extra 'return' picking when required and assigns
the generated moves to the correct picking.
Closes#13699Closes#13762
opw-690812
Foram Shah