Dinar POS · project status · 9 September 2026, evening
M1 checkpoint, 9 September
Six of the milestone's eight tasks are merged into the branch. This page is what a shop can do there today, what the reviews caught before each task landed, and what still needs an answer from Anouar or the comptable.
Branch m1/2026-09-09
T3, T4, T5, T7, T8 merged · branch merged into main how the work runs
7 / 8
M1 tasks merged into the branch
3
languages live, Arabic right to left
80 mm
ticket width, IFU prints no TVA
green
every check on every merged task
What a shop can do today
A cashier can sell at the till. They find a product by search or barcode, ring a whole item or a weighed one, apply a discount, take cash or a card, and hand back the right change. Every sale becomes a numbered fiscal ticket, and the stock behind it drops the moment the sale is saved. The ticket prints at 80 mm in French, English or Arabic; under the IFU regime it carries no TVA line, since a shop on IFU has none to show. Settings hold the store's own details and its tax regime, réel or IFU, dated from when each took effect. The whole database backs up once a day, thirty days are kept, and a saved copy restores from the same screen. Every screen reads right to left in Arabic, not only the ticket.
The eight tasks
Task
Status
What it is
T1 Products
done
Add, edit and deactivate what the shop sells.
T2 Settings
done
The store's own details and its tax regime, saved once, read everywhere a document is printed.
T3 Sale & documents
done
A sale becomes a numbered ticket and stock moves with it; the facture arrives with customers in M2.
T4 Till
done
The screen a cashier rings a sale on: search, barcode, weight, discount, cash or card.
T5 Ticket template
done
The 80 mm ticket, one reference file per language, merged after its review round.
T6 Printer
blocked
Printing on the real thermal printer. Waits on the printer being at Samir's laptop.
T7 Three languages
done
French, English and Arabic on every screen, Arabic right to left.
T8 Backups
done
A daily copy of the shop's data, kept thirty days, and a way to bring one back.
Reviewed before merge
Every merged task went through the same three passes before it landed: money, reach, test quality. Each finding shipped with a test that fails without its fix.
A minus button on a weighed line rounded the wrong way: taking half a kilo off the cart could leave a full kilo on it, charging for weight the shop never sold.
Restoring a backup could leave the old database's leftover journal file next to the new one, so rows from before the restore could reappear under whoever read it next. The restore now clears that journal before the swap.
A facture where every line sits at an exempt rate was dropping its TVA column, when the rule governing the layout keeps that column even at zero.
A backup written while the machine restarted mid-copy could leave a torn file in place of a good one. The copy now lands under a temporary name and only replaces the real file once it is whole.
Open for Anouar and the comptable
Does a cheque payment need a stamp, and how should it be recorded? Only cash and card are live at the till today.
How should a weighed line round for the fiscal record?
Does the ticket series reset every calendar year, or run without a break?
Can an IFU ticket say plain "Total", since IFU has no TVA to name on it?
Does a line taxed at 0% still need its own row on the ticket?
Which Arabic abbreviation is correct for TVA?
Should an English ticket say "DA" or "DZD"?
Keep the on-screen hint that a stamp starts at 300 DA, next to the amount tendered?
Two to confirm, not decide: credit sales stay off until M2 brings customers; a price override at the till needs a permission once M4 brings roles.
Next
Done since this page was first written: T5 merged after its review round, and the whole M1 branch is merged into main (pull request 15).
T6 waits on the printer being at Samir's laptop.
M2 has started on its own branch: customers, credit, the facture. Its first task, the customer and debt tables, is being built.
Lessons for the way we work
One heavy build runs on the box at a time. Two agents building at once is what took the box down today.
Every commit gets pushed right after it lands, so a branch survives past any one machine.
One session owns the loop at a time. A second one started by hand runs alongside only until it hands off.
A merge that crosses a database migration needs every "table doesn't exist yet" assertion grepped before the gate run, not after.