* FIX: propagate fk_warehouse from BOM line in processBOM()
When creating MO lines from a BOM, the fk_warehouse defined on each
BOM line was not copied to the corresponding MO line. This caused
produceandconsumeall() to fail with a stock movement error when a
warehouse is set on BOM lines but not on the MO itself.
* FIX: propagate fk_warehouse from BOM line in processBOM()
When creating MO lines from a BOM, the fk_warehouse defined on each
BOM line was not copied to the corresponding MO line. This caused
produceandconsumeall() to fail with a stock movement error when a
warehouse is set on BOM lines but not on the MO itself.
* Update mo.class.php
---------
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
In FormFile::list_of_documents(), when the user clicks the "+ New" button to reveal the upload form (showhideaddbutton), the JS handler triggers jQuery("input[type='file']").click(). This selector matches every <input type="file"> on the page, opening the OS file picker once per match. Users with multiple file inputs in the DOM (e.g. another hidden upload form, an editor's media browser, modules with their own attachers) have to dismiss the file dialog several times before being able to drag-drop or browse normally.
Fix: scope the selector to the form that was just shown:
- jQuery("input[type='file']").click();
+ jQuery(".divattachnewfile input[type='file']").first().click();
No regression on pages with a single .divattachnewfile. Reproduces on any *document.php tab where a hidden second <input type="file"> is present.
When a product has no row in llx_product_price (typical for products
imported in bulk where only llx_product was populated), price.php
auto-creates an initial history line on first display of the price tab
(branch starting at "We must have at least one initial line").
The two updatePrice() calls in this branch omitted parameter 11
(\$newdefaultvatcode) which defaults to ''. In Product::updatePrice()
the SQL then writes default_vat_code = NULL in BOTH llx_product and
the new llx_product_price row, silently wiping a correctly-stored VAT
code on every first display.
Symptom: "ErrorBadValueForParamNotAString" rendered next to selling
price/min selling price (because \$langs->trans(\$object->price_base_type)
is called with NULL when the row is freshly created with empty fields),
and default_vat_code persistently reset to NULL until the user manually
re-saves through the form.
Fix: forward \$object->default_vat_code (and \$object->tva_npr for the
non-multiprice branch) to updatePrice() so the auto-init preserves the
product's VAT configuration.
* Feat: Sorting of payment and invoice details
# Feat: Sorting of payment and invoice details
In compta/tva/clients.php when its better to order by payment date. Currently when there are multiple payments for the same invoice for instance, the payments are not grouped.
This fixes that.
- Added sorting functionality for payment and invoice details based on payment date and invoice date
- Implemented a helper function `cmp_fields_date` to compare and sort the details
- Applied the sorting to both payment and invoice details sections in the code
* Qual: Fix phan notice
