Follow-up to the 18.0 fix. On 21.0 and later, MoLine::fetchAll no longer
handles fk_mo/origin_id/origin_type as exact matches in the array-filter
path; every non-rowid key falls back to LIKE '%value%'. So the array
filter added for 18.0 turned into origin_id LIKE '%..%' here, which can
match an unrelated MO line and reintroduce the duplicate MO the fix was
meant to prevent.
Build the lookup with the universal-search string filter
(fk_mo:=:.. AND origin_id:=:.. AND origin_type:=:'bomline') so the class
turns it into exact equality, as requested during review of #39163.
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
The asset disposal amount was read with GETPOSTINT, casting it to int
and dropping the decimals, so a disposal at 1500.50 was stored as 1500.
disposal_amount_ht is a 'price' field, so use GETPOSTFLOAT to keep the
decimal amount, both when storing it and when re-displaying it in the
disposal confirmation form.
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
On 23.0 the generic CommonObject methods (setPaymentMethods,
setBankAccount, ...) build the trigger name from
$this->TRIGGER_PREFIX, falling back to get_class() when it is empty.
Facture does not declare it, so it fires FACTURE_MODIFY instead of the
BILL_* events the class uses everywhere else (BILL_CREATE, BILL_MODIFY,
...). Modules listening on BILL_MODIFY miss those changes.
Declare public $TRIGGER_PREFIX = 'BILL', like the other objects do
(Holiday='HOLIDAY', Workstation='WORKSTATION', BOM='BOM').
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
* Currency is the same of origin (credit note)
* Currency is the same of origin (credit note)
* Update card.php
* Update facture.class.php
---------
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
* Fix missing rollback when stock movement fails in Expedition::valid()
When STOCK_CALCULATE_ON_SHIPMENT is enabled and manageStockMvtOnEvt() fails while validating a shipment, the method returned -2 directly without calling $this->db->rollback(), unlike every other error branch in this method. Changed to increment $error instead, so execution falls through to the existing commit/rollback block at the end of valid().
Fixes#39425
* Update expedition.class.php
---------
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
The origin multicurrency exchange rate was read with GETPOSTINT('originmulticurrency_tx'), which truncates any fractional rate (e.g. 0.83, 1.27) down to an integer. As a result, creating a Supplier Invoice from a Supplier Order (or other origin) always produced an exchange rate of 0 or 1 instead of the real rate, even when the multi-currency setting to keep the source object's original rate was enabled.
This was already fixed for one of the four occurrences in this file (the credit-note/replacement-invoice path) but the other three were never backported to this branch. This commit switches all three remaining occurrences from GETPOSTINT() to GETPOSTFLOAT(), matching develop/23.0.
Fixes#39423
Adds a create_product tool to ToolProducts so the assistant / MCP
clients can reference a brand-new article or service in the catalog
(e.g. before adding it to a supplier order or a reception). Creation
goes through the Product business class (triggers, numbering, rights).
Guarded by produit|service / creer. Fields: label (required), ref,
type, price, price_base_type, vat_rate, cost_price, barcode, description.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
FactureFournisseur::addline() and updateline() force -abs() on every line of a
credit note, unconditionally. Facture (customer side) has the same forcing but
it can be relaxed since #33434 / #38730 when both FACTURE_ENABLE_NEGATIVE_LINES
and INVOICE_KEEP_DISCOUNT_LINES_AS_IN_ORIGIN are enabled. The supplier side has
no equivalent, so a supplier credit note can never hold a positive line.
Real case: a supplier withholds a fixed handling fee on every credit note it
issues. The fee reduces the credit, so on the document it is a positive amount
among negative ones. Dolibarr flips it to negative, the credit note comes out
3 EUR too large, and the only way to match the supplier document is to edit the
database by hand.
Use the same gate as Facture::updateline() in both methods, so the two classes
behave the same and default installs are untouched: with either constant unset,
-abs() still applies exactly as today.
The "credit note for the remaining amount to pay" option relied on the forcing
to sign its line: it now passes the amount already negative, which is a no-op
while the forcing applies and keeps the line correct once it is relaxed.
Tested on 23.0.3 and 24.0.0-beta: with a constant missing the fee line is still
stored at -3, with both set it stays at +3 and update_price() recomputes the
invoice totals correctly.
Co-authored-by: daGrumpf <pierre.grasswill@mediactivegroup.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
Columns llx_holiday.date_debut and date_fin are pure DATE columns: they hold a
calendar fact, not an absolute instant, so they carry no time and no timezone.
The agenda read them with jdate() defaulting to 'tzserver', then projected them
back with dol_print_date(..., 'tzuserrel') to pick the calendar day box. The
resulting shift equals TZ_user - TZ_server, so any user whose timezone differs
from the server got leaves rendered on the wrong day. Users aligned with the
server saw nothing wrong, which is why this went unnoticed. It also triggers with
no user timezone set at all, since 'tzuserrel' falls back to UTC when
$_SESSION['dol_tz_string'] is empty, shifting leaves on any server east of UTC.
Read and project those dates in GMT instead. This follows the documented core
convention for dates without time ("We suppose dates without time are always gmt
(storage of course + output)", commonobject.class.php; "For date without hour,
date is always GMT for storage and output", extrafields.class.php) and honors the
$daykey contract of $eventarray, which must be midnight GMT of the displayed
calendar day. It also makes the half-day comparison consistent, since
dol_get_first_hour() is already called with 'gmt' a few lines below and only
supports gmt/tzserver anyway.
Two further defects disappear as a side effect: the loop condition
"while ($daykey <= $event->date_end_in_calendar)" compared a user-shifted $daykey
against a server-anchored $datef and rendered one extra day box, and halfday=-1
happened to be correct while halfday=0/1 were not, because the +12h offset
accidentally compensated the timezone shift.
Regular events are untouched: llx_actioncomm.datep is a DATETIME holding a real
instant, and its block still uses 'tzuserrel', so a 9am meeting stays correctly
shifted for a viewer in another timezone. Every other render path already
excludes type_code 'HOLIDAY', so there is no display change elsewhere.
peruser.php carries a copy of the same block and is fixed identically, otherwise
the two views of the same page would contradict each other.
Tested with a real browser (Playwright) against a server running in UTC, driving
the month view as Europe/Paris, America/Cayenne and Pacific/Auckland users on
three existing leaves: 3 failures before, none after, with identical day boxes in
every timezone. A single-day leave of 2026-07-28 was rendered on both 2026-07-27
and 2026-07-28 for the America/Cayenne user before the fix.
The script tag emitted by dragAndDropFileUpload() was the only inline script of
the page without the nonce, so it was blocked by a Content Security Policy that
allows the inline scripts through it, and the drag and drop was then silently
inert on every card that enables it.
Same form as the ~25 other inline script tags of main.inc.php. getNonce() is
stable within a request, and the attribute is ignored by the browser when no
policy is defined.
ChargeSociales::update() set fk_user_modif twice in the same UPDATE
statement. PostgreSQL rejects this with "multiple assignments to the
same column", so editing a social contribution failed. Remove the
duplicate assignment. Backport of the develop fix#39389 to the 22.0
and 23.0 maintenance branches, where the duplicate is still present.
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
dol_string_unaccent() did not map the Hungarian letters o-double-acute
and u-double-acute (U+0150/U+0151/U+0170/U+0171), so they were left
untouched in sanitized filenames. Add the four missing entries so they
transliterate to O/o/U/u like the other accented variants.
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
