Recently I am triying to update my Dolibarr instance from the version 19.0.2 to 23.0.3. But, I have severa problems with the TakePOS Module in the v23.0.3 that is critical for my business. Specifically I Have problems with the POS Cash Control because when I open and close a Cash control from TakePOS interface doing tests in the same day, the cash opening and closing is not stored in the POS Cash Control in the Banks module. It is like TakePOS be unsincronized with the database of the POS Cash Control database in the Bank module and each time I tried to do an opening and closing in the test, the initial cash is increased with the last cash closing amount in the TakePOS Cash Control window, despite is not a sale or bill entered in this Cash Control session.
Another problem is that the Cash Closing report do not show the billed Cash in the Cash Control Session, it just show a discrepancy between the theoretical and real cash amount.
The final and important problem / bug I found is that the closed POS Cash Control records are unable to be Re-Open as It was possible in the version 19.0.2. The Re-Open buttom disapered in the v23 and It is too important to do corrections in the Cash Control records with the administrator user. The need to do corrections is so common in the retail business and Is important that this functionality be returned to avoid to keep errors in the Cash Control history or loose the Cash Control of one or several days due to be unable to do corrections.
I attach several screenshots of the POS Cash Control closings showing the errors and discrepancies in the showed cash amout.
I was researching about this problems and I found that for the bug of the absence of the Re-open buttom in the closed POS cash control registries in the bank module is related with adjustements for a French LNE certification for Dolibarr.
I want to know if this could be considered a restriction that only applies if Dolibarr is configured with France as the operation country and, if Dolibarr is configured to operate for the other countries and regions (like in Latin America) could be returned the Re-open buttom?
Also could be considered a functionality to do corrections for the POS cash control closed that allows to maintain all inmutable but with the option to have traceable corrections.
By the other way, the other problems with the inconsistency of the cash control registries or not save cash controll registries, could be a problem of date sincronization between the TakePOS interface date and the server date, that TakePOS do not sincronize and asume that the close date is before the opening date by the different time-zones ignoring to save the cash controll registry. But as Im not an experinced developer I don’t have the details to solve it.
Good that you logged #38401 / #38402. Two of your three issues likely trace to one known bug.
The wrong balances and the carried-over amount match v23 migration bug #37790: v23 added columns to pos_cash_fence (cash/card/cheque_declared and the *_lifetime totals) but the upgrade doesn’t backfill them on older records — so closings read wrong or 0.00 and the prior session leaks in. Check those columns for a bad day; if they’re empty on pre-upgrade rows, that’s it, and backfilling them (with a backup) clears it. Your timezone hunch still fits the “not saved at all” case.
The missing Re-open button is deliberate — unalterable-records/NF525 work, gated by country + the blocked-log module — so likely relaxable outside France, though a traceable adjustment entry is cleaner than reopening. Paste what those columns show and I’ll tell you which path you’re on; I’ve handled these POS migrations for retail clients.
The Re-open button removal is intentional in v23 — Dolibarr added NF 525 (French anti-fraud law) compliance starting around v21, which requires cash control records to be immutable once closed. This is by design, not a regression. For corrections, the workaround is to adjust the associated bank register entries directly rather than reopening the POS session.
The cash accumulation between test sessions (initial amount picking up the previous closing balance) looks like a genuine sync bug — worth filing on GitHub with your screenshots if there’s no existing report. The cash closing report discrepancy is likely tied to the same issue.
I understand the adjustments required for French regulations. However, would it be possible to add a configuration option to enable these compliance rules only if Dolibarr is set up for a company operating in France, or perhaps add a toggle in the module setup to enable/disable this compliance mode?
Additionally, regarding the possibility of reopening cash control registries for corrections (or having an option to correct closed registries), this would only apply to the Cash Control module to fix operator typing mistakes. It is not necessary to modify bank registries, as the cash bank account is not affected by closing the cash control. The goal is simply to ensure accurate records within the Cash Control module without altering the accounting or bank entries, which are only modified by invoice creation or manual bank transactions.
I think both are reasonable suggestions. Making NF525 compliance configurable (or enabling it automatically based on the company country) would provide more flexibility for deployments outside France.
Allowing corrections within the Cash Control module, while leaving the accounting and bank entries untouched, also seems like a practical way to handle operator mistakes.
I pulled the actual v23.0.3 source (tag 23.0.3) and checked the GitHub history for htdocs/compta/cashcontrol/cashcontrol_card.php to see what’s really going on instead of guessing. Here’s what I found, with exact references so you can verify it yourselves.
1. Missing “Re-Open” button (#38402) — confirmed, and it’s not a permission issue
@pixodeo’s permission theory doesn’t hold for v23.0.3: in that tag, both the server-side handler and the button are hard-commented out, unconditionally, for every user:
No permission check, no country check — it’s simply disabled for everyone in 23.0.3.
Good news: on the develop branch (heading to v24), commit 1d75cdc96e (“WIP LNE”, 2026-06-17) replaces that blanket removal with a real condition:
if (!isALNERunningVersion()) {
if ($permissiontoreopen) {
print '...action=reopen...';
} else {
print '...ReOpen (NotEnoughPermissions)...';
}
}
isALNERunningVersion() (htdocs/blockedlog/lib/blockedlog.lib.php) only returns true when the blockedlog module is enabled and already has entries (i.e. your install is actually running under NF525 anti-fraud logging), gated by the CERTIF_LNE constant. So the plan is: Re-Open comes back for everyone who isn’t running under NF525/blockedlog enforcement — much closer to what you and MuhammadAli.Dev suggested (config/country based instead of a blanket removal).
Caveat: I checked the 23.0 stable branch history and this fix has not been backported yet — as of now it only exists on develop, so it will most likely ship in v24, not in a 23.0.x point release, unless someone requests a backport on the issue.
Nice digging, Grelf — good to have the exact lines confirmed. The practical takeaway for @leonm2 and @pixodeo: since the fix only lands on develop, the Re-Open button won’t come back on 23.0.x, so for now corrections still mean adjusting the linked bank/cash entry directly rather than reopening the fence. If reopening before v24 matters for your workflow, it’s worth adding a note on the issue asking for a backport — those do happen when there’s a clear operational case.
