Dolibarr amortizáció: amikor az időzóna elnyel egy évet

2026. szeptember 20. · Pénzügy

Az óra, amely elnyelt egy évet: időzóna-hiba a Dolibarr amortizációs tervében

Egy friss javítási javaslat szerint a szerver időzónája szélsőséges esetben egy teljes évnyi értékcsökkenést hagyhatott ki a tárgyi eszköz amortizációs tervéből.

← Vissza a blogbejegyzésekhez

Elveszhet-e egy teljes év egy pénzügyi tervből pusztán azért, mert a szerver más időzónában jár? A Dolibarr egyik friss hibajavítási javaslata szerint igen: az amortizációs terv számítása a szerver időzónájától függhetett, és ez szélsőséges esetben egy egész éves leírás kihagyásához vezethetett.

A #40343 számú pull request 2026. szeptember 11-én nyílt meg „Depreciation plan depends on the timezone of the server and can lose a whole annuity” címmel. Rövid mondat, súlyos következmény: ami a képernyőn dátumkezelési részletnek látszik, az a pénzügyi ütemezésben már hiányzó év lehet.

Miért különösen érdekes ez a hiba?

Az időzónahibákat többnyire egyórás eltérésként képzeljük el: egy esemény 9:00 helyett 10:00-kor jelenik meg. Az amortizáció viszont időszakhatárokkal dolgozik. Ha egy dátum a konverzió során az előző vagy a következő naptári napra csúszik, az év eleji vagy év végi logika már más időszakba sorolhatja. A PR címe szerint itt a következmény nem puszta kijelzési eltérés, hanem akár egy teljes annuitás kiesése.

A Dolibarr hivatalos dokumentációja szerint az Asset modul tárgyi eszközök életciklusát kezeli, amortizációs táblát készít, és a kapcsolódó tranzakciókat a főkönyv felé is továbbíthatja. Ezért az amortizációs tervet nem díszítő riportként, hanem ellenőrzendő pénzügyi alapadatként érdemes kezelni.

Az ERP-ben három külön idő létezik

• Üzleti dátum: például az aktiválás napja vagy az értékcsökkenési időszak vége.
• Szerveridő: a PHP és az operációs rendszer által használt időzóna.
• Felhasználói idő: amelyben a kezelő a dátumot látja és értelmezi.

Egy dátum típusú üzleti értéket nem szabad észrevétlenül időpontként kezelni. A „2026. január 1.” nem ugyanaz a fogalom, mint a „2026. január 1. 00:00 UTC”, majd annak helyi időre alakított változata. Utóbbi bizonyos zónákban még december 31. lehet. A hiba általános tanulsága ez: az időzóna-konverzió nem semleges művelet az időszakhatárokon.

Mit ellenőrizzünk most?

1. Ne változtassuk meg vakon a szerver időzónáját; előbb rögzítsük a PHP-, adatbázis-, Dolibarr- és felhasználói beállításokat.
2. Válasszunk ki néhány tárgyi eszközt, különösen év eleji és év végi aktiválási dátummal.
3. Egyeztessük az amortizációs terv sorainak számát, időszakait és összegét a jóváhagyott számviteli tervvel.
4. Ellenőrizzük, hogy a részletek összege kiadja-e az amortizálható alapot, és nincs-e kihagyott vagy megkettőzött év.
5. Frissítés előtt reprodukáljuk a számítást tesztpéldányon; frissítés után ugyanazzal a mintával végezzünk regressziós ellenőrzést.

Mit nem bizonyít a javítási javaslat?

Önmagában nem bizonyítja, hogy minden Dolibarr-telepítés hibás amortizációt készített. A tényleges hatás függhet a verziótól, a szerver beállításától, az eszköz dátumaitól és az alkalmazott számítási módtól. A helyes reakció ezért nem a pánik, hanem az ellenőrizhető egyeztetés.

Ugyanakkor a történet fontos figyelmeztetés: egy ERP pénzügyi eredményét nem elég azért helyesnek tekinteni, mert a felület rendezett és a végösszeg hihető. A dátumhatárok, a részösszegek és a könyvelési átadás együtt adják az ellenőrzési láncot.

Források

• Dolibarr #40343 – az amortizációs terv szerveridőzóna-függésének javítási javaslata (GitHub, megnyitva: 2026. szeptember 11.; ellenőrizve: 2026. szeptember 20.)
• Dolibarr Wiki – Module Asset (modulfunkciók, amortizációs tábla és könyvelési tranzakciók)
• Dolibarr nyitott pull requestek (a javaslat aktuális állapotának ellenőrzéséhez)

Ez a Dolibarr.hu szerkesztett, magyar nyelvű útmutatója.