When MAIN_STORE_COMPUTED_EXTRAFIELDS is enabled, insertExtraFields() and
updateExtraField() evaluated the computed formula without setting the global
$objectoffield to the current object, so formulas relying on
$objectoffield->array_options returned a wrong value (often 0) when stored,
unlike fetch_optionals() which already sets it.
The list template also always recomputed computed extrafields, but the raw
row available in a list has no object context, giving wrong display and wrong
totals. When MAIN_STORE_COMPUTED_EXTRAFIELDS is enabled the value stored in
database is now used instead.
Signed-off-by: Dolicraft <contact@dolicraft.com>
Co-authored-by: Dolicraft <contact@dolicraft.com>
The payout.paid IPN handler recorded the bank transfer line with an empty
num_chq (a "// TODO Store the po ref from $event->data" placeholder). The
Stripe payout id is available as $event->data->object->id, so store it as
the transfer reference. This makes auto-recorded payouts traceable and
reconcilable against Stripe.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
In a January that starts with week 52 or 53 of the previous year (for
example January 2022), getFirstDayOfEachWeek() wrongly shifted week 01
to the next year, and the $year++ inside the loop then also corrupted
all the following weeks of the month: every first day returned was the
one of the next year (02, 09, 16, 23, 30 instead of 03, 10, 17, 24, 31
for January 2022). getLastDayOfEachWeek() had no year handling at all,
so the trailing/leading weeks of the other year were resolved in the
wrong year too.
This made the per-month time spent view (projet/activity/permonth.php)
display wrong week date ranges, link to the wrong week and compute the
weekly holiday overlap on wrong date ranges for such months.
Co-authored-by: Claude <noreply@anthropic.com>
When creating a credit note "with same lines" from a situation invoice,
the code always subtracts the previous situation invoice's line values
before inverting the sign, assuming lines are stored cumulative
(INVOICE_USE_SITUATION = 1, legacy mode).
In progressive mode (INVOICE_USE_SITUATION = 2), each situation invoice
line already stores its own delta amount and percent, so this extra
subtraction credits the wrong amount and percent (e.g. 60% / 1272
instead of the correct 20% / 424 on a real cycle).
Skip the subtraction in progressive mode so the credit note reuses the
source line's own delta values, as expected.
* FIX#37826 country_code must be an ISO code, not a label
On a proposal/order, the 2nd+ line got VAT 0% with the error "no vat rates
defined for country 'France'/'Suisse'". Root cause: the seller country_code
held a translated country label instead of the ISO code, so the
"c.code IN (...)" lookup in Form::load_cache_vatrates() matched nothing.
- Societe::setMysoc(): the canonical MAIN_INFO_SOCIETE_COUNTRY is
"id:code:label"; a legacy "id:label" value put the label into
country_code. Only treat the full 3-token form as "id:code:label" and
otherwise rebuild code/label from the authoritative country id.
- Form::load_tva(): defensively recover the seller ISO code from its
country id when country_code is not a known c_country code, so a bad
value can never silently force the VAT rate to 0%.
Signed-off-by: Jam Balaya <jambalaya.pyoncafe@outlook.jp>
* FIX#37826 avoid useless SQL per page: recover country ISO code from id only when code is not a 2-char ISO code
---------
Signed-off-by: Jam Balaya <jambalaya.pyoncafe@outlook.jp>
