BFL Update Service

Correction: the Chart of Accounts screen reported conflicts that did not exist. The previous version recognised its own accounts by their NAME. An account we delivered and that you renamed - "Bank account" becoming "GCB Bank PLC", "Mobile Money" becoming "MTN Mobile Money" - was therefore treated as a stranger, and the screen told you the software no longer posted to it. That was wrong, and alarming when the accounts concerned are the ones your money goes through. Nothing had in fact changed, and nothing had stopped: those accounts kept their role and kept receiving. Renaming a delivered account is normal, and recommended: only you know which bank it is. The software now recognises its accounts by WHO CREATED THEM, not by what they are called today. Only an account you created yourself, on a code the software also needs, is reported - and that report was always correct.

The software no longer takes over an account code you created yourself. Each release can add accounts to the delivered chart. Until now, the software recognised those accounts by their NUMBER alone: if one of your own accounts already sat on a number a later release needed, the software quietly treated it as its own. It would post to it, and count it in the labour cost on the dashboard, even though the account means something entirely different to you. Nothing failed, nothing was flagged, and the figures were simply wrong. From now on a code is only taken over when the NAME matches as well. Your account keeps its role, its meaning and its entries, and the Chart of Accounts screen tells you which codes are in this situation, what the software wanted to use them for, and that nothing has been changed. Freeing the code is your decision, and your entries follow the account, not the number. Nothing is renamed, moved or deactivated by this update.

A final settlement now pays the exact leave balance, half days included. Leave is earned in fractions: a rule granting 2.5 days a month leaves people with 17.5 or 5.5 days, and the leave screen has always shown those figures. But the departure record only accepted whole days. Whoever settled a departure had to round by hand, and nothing told them which way — half a day of pay lost by the employee, or paid twice over by the company, on every single departure, on a perfectly balanced entry. The field now takes fractions. More importantly, it no longer has to be typed: the software fills in the balance earned as at the last day, and says where the figure comes from. It stays editable, because agreements exist, and if you settle a different number the screen says so plainly instead of letting a corrected figure pass for the real balance. Nothing changes for departures already settled: their figures were frozen when they were paid.

A payroll that settled a departure could not be cancelled. Cancelling it was refused with an unbalanced entry, and the payroll stayed stuck: the departure record remained settled for a payroll nobody wanted any more. Nothing wrong was ever posted — the refusal is what protected your books — but there was no way forward. The cause: when someone leaves, their untaken leave CLEARS the debt that had been set aside month after month, and it does not take back a cost, because that cost was already recorded as it built up. The cancellation treated it as if it were an ordinary release of leave, and put back a cost that had never been there. Both entries are now written by the same rule, so the cancellation can no longer be anything other than the exact mirror of the validation.

The dashboard now shows what your workforce COSTS, not what it takes home. Until now the chart showed net payroll: the money your employees receive. That is not what you spend. Missing from it were employer contributions, overtime premiums, the leave and thirteenth-month provisions, and end-of-contract payments — all of it already committed, and none of it visible anywhere. The figures on this chart are therefore higher than before, and nothing has gone up: they are simply complete. The cost is now read straight from the ledger, so it can never drift from your accounts. A cancelled payroll takes itself back out; a manual entry is included; nothing has to be remembered. Workforce that is not on your payroll is shown SEPARATELY, and on purpose. A salary carries contributions and builds a social debt; a contractor's note or an agency invoice carries neither. Putting them in one bar would invite a comparison between two figures that cannot be compared. The total sits above both charts, with its two parts named, for the one question a director actually asks. If an account of personnel costs has not been classified as either, the dashboard says so and names it, rather than quietly leaving its money out of the total.

Someone who leaves now walks out with their papers. Two documents, and two on purpose. The CERTIFICATE OF EMPLOYMENT states the position held and the dates worked, and nothing else: no amount, and no reason for leaving. It will follow that person from one job interview to the next for the rest of their career, and a certificate that says why someone was let go harms them at every one of them. It is available as soon as the departure is recorded, because looking for work does not wait for the end of the month. The FINAL SETTLEMENT RECEIPT is the one that is signed when the money is handed over. It shows every line — untaken leave, notice not worked, severance — and the net actually paid, so that someone who disagrees can point at a line rather than at a total. It says in plain words what is NOT being paid, and why: a missing line with no explanation reads like an oversight. The receipt only becomes available once the payroll that settles it has been validated. Before that the amounts can still change, and nobody should be asked to sign a figure that is not the one they will be paid. If that payroll is later cancelled, the receipt goes away with it.

A line can no longer outlive the thing it points to. This is a correction under the hood, with nothing to see on screen. Four links between your records said one thing in the software and another in the database: if the material, the product, the employee or the team they pointed to were ever deleted, the line would have stayed behind, pointing at nothing. A production estimate with no material, a material request with a price but no material, a roster entry assigning nobody. The database was right and refused; the software promised otherwise, and the two would have parted company at the worst possible moment. The four links now say plainly that the deletion is refused, and a test keeps every future link honest.

The company now knows what it owes in leave, and the payslip shows it being set aside. A day of leave someone has earned is a debt, not a favour. So it is now set aside every month, without you having to choose: the software charges it and builds the debt on Leave payable, and a new account, Leave expense, tells you what leave costs without you hunting for it inside the wage bill. Nothing is paid twice. A day taken, a day lost at year end, and a day paid on a final settlement all release what had been set aside for it. When someone leaves, their untaken leave settles the debt instead of being charged again, and whatever the provision did not cover stays visible as the real cost of that departure. Each day keeps the price it was set aside at. A raise does not make the days already owed more expensive; only the new days take the new rate. And a day of leave is worth exactly what a day of absence costs, so the same day never carries two prices. The leave screen now shows what has been set aside next to each balance, with the total the company owes, and says plainly when a balance has days not yet set aside. One older fault is fixed with it: cancelling a payroll did not undo the thirteenth month it had set aside, so the accounts kept a charge and a debt for a payroll that no longer existed. Both provisions are now undone with the payroll.

When someone leaves, the software now closes what has to close, and pays what is owed on a normal payslip. Recording a departure closes four things at once. Time is no longer recorded past the last day, pending leave requests fall, the person no longer enters later payrolls, and any outstanding loan becomes due. Sign-in access is closed with it, and the departure record says so as a box that was ticked. None of this deletes anything: the employee record stays, with every payslip on it. What is owed is worked out before you sign anything. Untaken leave, notice that will not be worked, and severance if your scale opens it. The notice not worked is worked out from the last day and the notice owed, and stays correctable. A day of leave is worth exactly what a day of absence costs, so the same day never carries two prices. Severance is not shipped with a scale. It differs from one country and one agreement to the next, and a scale we chose for you would be wrong behind your back. Until you set yours, under Company Settings, Payroll components, a final settlement still pays untaken leave and notice, and says in plain words why severance is nil. The final settlement is a payslip, not a separate paper. It enters the gross, so it is taxed and carries contributions, and the person receives one sheet for their last month. The payroll draft shows it line by line before you validate, and the settlement is charged to Severance and termination, or to Retirement benefits when the reason is retirement: what your terminations really cost never hides inside the wage bill.

The people an intermediation agency sends to your site are now recorded, and they are never paid by the software. The agency is a supplier: you settle one invoice with it, through the door you already use. The people it sends receive nothing from the software. No payslip, no contributions, no declaration, and no amount anywhere on their file. So why record them at all: so you can say who was on your site, and on which day. On the day of an accident, an inspection or a theft, twelve people from the agency is not an answer. Each agency shows how many different people came and how many days were worked, side by side and never as an average: twelve days can be twelve people who came once or one person who came twelve times, and those are not the same problem. What an agency costs is read from the invoices you recorded against it, never worked out from the days recorded. Point those invoices at the new account 6205 Agency labour if you want the income statement to tell agency labour apart from wages and from goods. A day recorded outside the period someone was on site is refused, and the screen names the date and the period: it is a keying mistake, not a presence.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

External contractors: consultants and project workers the factory pays directly, without ever putting them on a payslip. A contractor has a file of their own, with the contract and the rate: per day, per hour, or a flat fee. A flat fee is never multiplied by days or hours, whatever quantity is entered, because it is the agreed price for the work. They are never on a payslip and never in a social declaration. No income tax, no contributions, nothing that belongs to an employee. A note records what the company owes them, and paying it settles the debt. What you owe a contractor shows on their own account, separately from suppliers and from staff, and the third-party registry carries it name by name. The company always knows what it still owes, and to whom. You record the days they worked, and those days pre-fill the note. You can still correct the figure, and the note keeps both: what the days proposed and what you kept. A day that is already on a note cannot be billed twice. Paying a note goes through the approval gate, like any other payment, with a cap of its own: what a factory allows on small expenses has nothing to do with what it allows on a consultant for a year. A note that has been validated is never erased: cancelling it reverses the entry and keeps the reason. A note that has already been paid cannot be cancelled at all, because the money has left, and the screen says so. Two new accounts carry it: 6200 External contractors and 2130 External contractors payable. The payable sits with suppliers, not with staff: a contractor is not an employee.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Two corrections found by running the payroll screens on a fortnightly and a daily payroll. Two daily payrolls could cover overlapping days, and the days in common were paid twice. A fortnightly payroll takes its dates from the half of the month it covers, so comparing the dates one for one was enough; a daily payroll takes the days you choose, so two of them can overlap without being identical. A payroll now refuses any period that overlaps one already paid, and names the payroll and the days it covers. The Bonuses figure at the foot of a payroll draft ignored allowances and overtime premiums. A payroll showed a base of 1,451.61, bonuses of 0.00 and deductions of 79.84 next to a net of 1,516.93: the three figures did not add up, and the 145.16 missing was a real transport allowance. Everything that is added to the salary is now counted there, so what the tiles add, less what they take off, comes back to the net.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Payroll can now be run twice a month, or by the day, for the people who are paid that way. Each employee carries their own pay schedule: monthly, twice a month, or daily. A payroll only ever includes the people on its own schedule, so someone paid monthly can never fall into a fortnightly payroll and be paid twice. A schedule cannot be changed once the person has been paid for the month, for the same reason. Everything that is counted is counted on the period being paid, and only on it: the salary itself, the validated attendance, the deduction an unjustified absence proposes, and what each payroll component pays. Someone on a monthly salary paid twice a month receives half of it each time, worked out on the days each payroll covers, and the two halves come back to the month exactly. Nothing a first fortnight has already paid can be paid again by the second. What is owed once a month stays once a month. A loan instalment is repaid, and the thirteenth month is set aside, on the payroll that covers the end of the month, never on each half of it. Income tax and social contributions are worked out on the month as a whole. Each payroll recalculates the month and withholds only the difference, so a salary split in two is never taxed as two small salaries, and the month always comes out right whichever payroll ends it. You decide, component by component, what a monthly allowance does when a month is paid twice: paid in full on the first payroll, or split across the periods by the days they cover. A transport allowance and a seniority bonus do not behave the same way, and the software does not guess. A monthly payroll keeps the reference it has always had. A fortnightly one adds which half of the month it covers, and so does its payslip, so two payslips of the same month are never confused. The accounting entry is dated on the end of its own period rather than the end of the month. The screen only offers the schedules your own staff actually use: until you put someone on a fortnightly or daily schedule, you will not see the option.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Three corrections found by running the payroll screens, not by a test. The Deductions figure at the foot of a payroll draft ignored the absence deduction: it showed nothing while the net had already lost the amount. Two figures on the same screen said different things. Every deduction that lowers a net is now counted there, and in the loan repayment ceiling that is worked out from it. The thirteenth month worked itself out on the base salary of someone paid by the hour. For them the base salary pays nothing, it only caps what they can borrow, so the software was building a debt on money nobody pays them. It now uses the average of what they have really been paid this year, and until there is a month to average, it sets nothing aside. The thirteenth month also set money aside for months that came before the person was hired. A May payroll was building a debt for someone who joined in August. Before the first full month somebody works, a payroll now owes them nothing, neither a provision nor a payment. The absence deduction policy card now names the payroll component that carries the deduction, and warns when none does. Payroll refuses to file a deduction that has no component, and the card was the one place that did not say so.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The thirteenth month, set up the way your company pays it. You say what it is worked out on, the base salary or the average of the twelve months paid; which month it is paid; what someone who joined during the year gets; and whether you set it aside month by month or charge it all when you pay it. Someone who joined during the year earns it pro rata, on full months only: a person hired on the 20th did not work that month. You can turn that off and pay the full amount from the first year, but it is a decision you make, not one the software makes for you. Set aside month by month, each payroll charges a twelfth and builds the debt, and the employee sees nothing that month, which is the point. When it is paid, the payment settles the debt it built; anything the debt does not cover is charged the month it is paid, so a salary that moved during the year costs what it really costs. It is paid like any other pay: it enters the net, income tax and contributions, and it prints on the payslip with the months it covers. Two new accounts carry it: 6125 Thirteenth month and 2250 Thirteenth month payable. Nothing is assumed: until you set the rule, no thirteenth month is worked out at all.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

An unjustified absence that has been validated now proposes its deduction on the payroll. Until now an absence had to be declared twice: once by the team leader on the attendance sheet, once by hand on the absences screen so that payroll would see it. The second one was easy to forget, and an absence nobody keyed cost the company a day of pay. The payroll draft now reads the validated attendance and fills in the deduction: how many unjustified days, what a day costs under your policy, and the amount. The payroll officer corrects it or sets it to zero, and zero is then a decision, not an oversight. Nothing is ever filed at random. You say which payroll component carries absence deductions, on the absence deduction policy, or on an absence type that needs its own account. Until you do, nothing is proposed and the payroll screen says why. Payroll never judges an absence again: it reads the one verdict the attendance sheet froze, which had already set aside rest days, public holidays, factory closures, approved leave and absence types that are not deducted.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A refusal no longer offers a way out that does not exist yet. When attendance cannot be reopened because payroll has already read the day, the message offered two ways out: cancel that payroll, or correct it on the payslip. Correcting on the payslip is not built yet, so only the first is offered. The second will come back with it.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A day that was reopened keeps saying so after it is validated again. The mention only showed while the day was still a draft. Once validated again it vanished, and the day looked like one validated the first time, which is exactly what reopening was meant to prevent.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A validated attendance day can be reopened, as long as payroll has not read it. A validated day used to be frozen for good. A team leader who keyed the wrong hour could do nothing about it: the mistake had to be repaired on the payslip, far from its cause, and the hours register stayed wrong for ever. It now reopens, up to the moment the payroll of the month is validated or paid. Until then the day has produced nothing, no entry depends on it, and it goes back to being a draft: hours, lateness and verdict are cleared and worked out again at the next validation. Once a payroll has read it, the day is closed for good and the screen says which payroll closed it. Reopening never hides anything. It asks for a reason, keeps who did it and when, and the row says Reopened with that reason, so a day reopened then validated again can never be mistaken for one validated the first time. The right is the one that validates attendance, because undoing is of the same order as doing.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Three screen corrections found while testing the payroll. Validating attendance said 2 day(s) when it had validated two people on one day. It now says lines, like the message that records them two seconds earlier on the same screen. Asking for a day that has not happened yet quietly showed today instead, while the address bar still showed the day asked for. Attendance is still never recorded ahead of the day, but the screen now says so. When payroll sets the hours itself, the premium shown on the grid came from attendance and was no longer the one that would be paid. It is now marked as superseded, and the simulation shows the real figure.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

See what a payroll will cost, and whether it will post, before you validate it. A button on the draft works out the whole month: gross payroll, net payroll, employer contributions, and the total cost to the company, which the draft never said. It then shows the accounting entry that would be posted, account by account, with its debit and credit totals and whether they balance. It is not a second calculation. The simulation runs the real validation, lets the entry be written so the accounts are resolved and the balance is checked, then undoes everything. Nothing is saved: no payslip, no entry, no notification. What you see is exactly what would be written. It also points out what deserves a look without blocking anything: an employee paid by the hour with no validated attendance would be paid nothing, days validated before night hours were recorded count as none, and hours set by payroll rather than taken from attendance are named.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Payroll can take different hours from the ones attendance recorded, and says so. A team leader can mis-key a shift, and a payroll cannot wait. The payroll officer may now set the hours of a payslip kind by kind: beyond the schedule, at night, on a rest day, on a public holiday. A night shift recorded as plain overtime is repaired by naming it, not by inflating a total, so the right premium applies. It is never silent. The payslip keeps both figures, what attendance said and what payroll retained, prints the reason, and marks the line. The right to do it is its own, Override the hours taken from attendance, and it is granted person by person in Settings, Users. Normal hours are never typed: they are what remains once the premium hours are named. Entering more premium hours than hours worked is refused, so an hour can never be paid twice.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Payroll now counts hours. An employee is paid a fixed monthly salary or by the hour, chosen employee by employee, because most factories run both at once. An hourly employee is paid on the hours of the validated attendance; a monthly one keeps his salary whatever the month holds, and receives only the premiums. Four overtime premiums, all set by you: beyond the schedule, at night, on a rest day, on a public holiday. The software ships none of its own, because they differ from one country and one agreement to the next; until you set them, no premium is calculated and the payroll screen says so. The night window is yours too, and it may cross midnight. An hour never carries two premiums. A night hour on a public holiday is paid at the higher of the two, once, so that a payslip can still be checked by hand. The payroll screen shows where the figures come from: hours worked, and how many were beyond the schedule, at night, on a rest day or a holiday. The payslip prints the same breakdown next to the premium, so an employee can recalculate it. The premium of a monthly employee is worked out from his own month: his salary divided by the hours his schedule planned, never a fixed divisor that would be wrong for a factory working six days a week. Overtime is posted to its own account, 6130 Overtime, and enters income tax and contributions like any other pay.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Payroll: five defects corrected, before any new feature. A payroll carrying an allowance or a deduction now posts, cancels and pays like any other. Five defects were found by reading the posting engine, proved one by one on the screens, and are closed here. None of them could show itself until a company configured its first payroll component, which is why they had waited. An allowance no longer blocks the payroll. The charge of a position used to carry the allowance a second time, on top of the allowance account itself: the entry came out unbalanced and the payroll simply refused to validate. A company that set up a housing allowance could not pay its staff. A deduction is taken once, not twice. The Other column of the payroll grid was typed in AND pre-filled from the employee file, from the very same records the payslip is built on. A one day absence at 60 cost the employee 120, and nothing said so: the entry balanced. The column now displays what the employee file holds, exactly as the Bonus column has done since 4.63.0. There is one source, and it is the employee file. A payroll carrying a component can be cancelled again. The reversing entry mirrored the salaries but not the components, so it came out unbalanced and the payroll stayed generated for ever. A payslip is cancelled, never erased. Cancelling a payroll used to delete its payslips outright. They now stay on the payroll, struck through and marked Cancelled, and they are kept out of the register, the payment list and the tax declaration. The Deductions figure on a payroll now counts the components too. It could show 60 next to a net that had taken 120.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Attendance, absences and leave, read against the schedule. Work Time gains three tabs: Attendance, Leave and Absence types. Attendance. A team leader records, from a tablet, the people whose file names them as supervisor: arrival, departure, or absent with a reason. Each line reminds what was expected that day, so attendance is taken against the schedule and not from memory. HR then validates the day. At validation the software works out, and freezes, the hours worked, the overtime, the minutes late and a verdict: present, absent and justified, absent and not justified, or not expected. A validated day no longer changes, so a holiday declared afterwards cannot rewrite a day the payroll will read. Nobody can be recorded on a day no work pattern covers: the software names who, instead of guessing a Monday to Friday. The rule that protects the employee is written once. An absence can only lead to a deduction on a day the person was actually due, and only if nothing justifies it. A rest day, a public holiday, a factory closure, approved leave, or an absence type your company does not deduct: never. Absence types are yours. Each one says three things: whether the day is paid, whether it is deducted from pay, and whether it uses the leave balance. A button adds the usual ones (paid leave, sick leave, work accident, special permission, unpaid leave, unjustified absence), which you then adjust. Nothing is created without you. Leave. You set how many days are earned per full month and how many can be carried over into the next year; a new rule applies from its date and leaves the past alone. Balances are computed, never typed. A request is approved or refused with a reason. Once approved, it only uses the days the person was due, so a weekend or a holiday inside it costs nothing, and it shows on the employee's schedule. The return date is worked out from the schedule, and a return that does not happen is shown as overdue, without assuming anything else. Nothing here posts an entry or touches a payslip: paying from attendance comes next.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Work Time: what each person is expected to work, day by day. A new module, switched on separately from HR & Payroll: a company that only wants payroll is not made to run attendance. Once it is on, three things can be described. The company's own calendar. You declare your public holidays and closures, each with its nature: paid and closed, worked with a premium, a rest day for everyone, or a factory closure. The software ships none: holidays change by decree and by country, and some move every year. Work patterns. A pattern is described once and assigned to many. It is either weekly, the same every week starting on Monday, or a rotation that turns over a number of days, such as morning, afternoon, night and rest. A night that ends before it starts runs past midnight: 22:00 to 06:00 counts eight hours. Once a pattern has been assigned it can no longer be changed, because changing it would rewrite the past schedules of everyone who followed it: you create a new pattern and assign it from a date. Teams and assignments. A team is the people who take turns together. A pattern is assigned to a team or to one employee, from a date, until a date or until further notice. Teams on the same rotation can start at different days of the cycle, so they never all work the same shift. An employee's own pattern overrides their team's for the days it covers. Every employee file gains a Schedule tab: the week, the month and the whole year, with working days, expected hours, paid days off and, in warning colour, the days no pattern covers. Why it comes before attendance: without it, the software cannot tell a day off from an absence. When attendance arrives, an absence will only be counted on a day the person was actually due, never on a rest day, a holiday or a closure. Nothing in this version posts an entry or touches a payslip.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Your HR team finally has its own keys, and a career leaves a trace. Until now the software had fourteen roles and not one of them was HR. The payroll module could only be reached by the accountant, so whoever kept your staff files worked under the accountant's account, with your customers, your invoices and your cash in reach. Two roles arrive. HR Officer keeps the people: files, positions, departments, careers. Payroll Officer prepares the runs, issues the payslips and pays them out. Neither can do the other's job: keeping a file is not sending money, exactly as declaring a payment has never been the same right as banking it. Paying out the cash itself still belongs to the accountant. Departments and positions stop being two labels. A department now carries a short code and the person who heads it. A position carries a level you name yourself, 1, A3, Senior, whatever your company uses, and the salary range you apply to it. The range blocks nothing: it is shown when a rise goes outside it, because a hard refusal would just be worked around with a bonus. And a career is kept. A promotion, a pay rise, a transfer or a contract change is now recorded with its effective date, its reason, and the name of whoever decided it. The rise can be entered as a new amount or as a percentage, and the percentage you granted is the one kept: recomputing it later from rounded amounts would show 4.99% where you granted 5%. The file still holds today's position and today's salary, which is what the payroll reads; the career tab holds the road that led there. Every employee file also shows seniority, computed from the hire date, and marks anyone below thirteen months as a new recruit. Neither is stored: they are worked out each time the screen opens, so the mark goes out by itself on the right day. Nothing here posts an accounting entry. A promotion costs nothing on the day it is decided; it costs on the next payroll, which reads the salary from the file as it always has.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Deleting now clears the list, and the Super Admin keeps what was deleted. Until now, a mistake stayed on the screen. A cancelled invoice, a cancelled order, a production order launched by error: they all kept their line in the list, and the screens filled up with work nobody would ever do again. Fiches had an Archive button, documents had none at all. From this version there is one word everywhere: Delete. It asks why, in at least ten characters, and the element leaves every list. Nothing is erased from the database. The reason, your name and the time are kept, and the Super Admin finds all of it on a new screen called Deleted. That screen says, for each deleted element: what it was, who deleted it, when, why, and whether the books wrote anything about it. That last column is not a stored flag: it is read from the entries themselves, so it stays true even when a reversal is posted later. The Super Admin can restore an element deleted by mistake, and the restore is recorded too. Deleting never undoes anything. A document that has already had an effect outside itself, an invoice that created a receivable, a delivery note that issued stock, an expense that paid money out, is refused until it is cancelled by its own gesture. The refusal says which gesture to use. Once cancelled, it can be deleted, and deleting it changes nothing else. The refusals that already protected your files are untouched: a product still in stock, carried by a live order, awaited by a production order or used by an active recipe still cannot be deleted, and the message names what holds it. Two screens keep their old behaviour on purpose. The chart of accounts and the entry models are deactivated, not deleted: a deactivated account still carries the balances of past years, and your accountant must be able to find it.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The products offered are the ones the chosen warehouse holds. On Free Goods Issues (protocol and staff allocation), the product list used to be the whole catalogue, whatever warehouse the goods were said to leave from. Choosing a product the warehouse did not hold passed the free stock check, which is global, and then failed when the lots were picked, at the very last click, with the whole record already typed. On the Hold warehouse, which only holds what came back damaged, the screen still offered every product you sell. From this version the warehouse comes first and commands the list: pick it, and the products offered are the ones it holds, each line showing what this warehouse holds next to the free stock. A product the warehouse holds none of stays on the list with a plain 0, because knowing it is empty here is worth more than not finding it at all. The quantity is bounded by both figures, and the tighter one wins. Changing the warehouse clears the lines: an item from one store has no reason to be valid in another, and a line silently wrong would fail at the last click. The server was tightened with the screen: what the warehouse holds is checked before the global free stock, and the refusal names the warehouse, the item and the quantity instead of failing on a lot allocation nobody could read.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Goods a customer returns damaged no longer go back to your sellable stock. When you record a customer return, each line, and each lot, now says in which condition it comes back. Good goods follow the usual path: back to the warehouse you choose, in the lots the delivery took them from. Damaged goods go to a warehouse the software keeps for them, Hold (returned goods). They still exist and keep their lots, but no sales, delivery or production screen offers them. They wait there for a decision, and there are only two. From the return note, someone allowed to declare scrap can write them off as a loss, with a written reason: they leave the stock at average cost and their value becomes an expense. Or you keep them, and issue them later as a staff allocation from Free Goods Issues, choosing the Hold warehouse, the only screen allowed to draw from it. The rule is enforced by the stock engine itself, not just hidden on screens: a delivery, a protocol gift or a transfer cannot take goods out of the hold. The return note shows what is still on hold, lot by lot, worked out from the stock movements rather than stored separately. An invoice now says what it made leave the warehouse. Its file lists the delivery notes it produced, each one a click away for a control, and the lots delivered for every item, several lots for one item included, with what was returned next to what was delivered. And while nothing has left for an invoice, it can only be cancelled in full. A partial credit note would say that goods came back when they never went out; the goods come back through a return on the delivery note, once they have gone. The rule is worked out from the real stock movements and enforced by the server, not only by the screen.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Deliveries now leave through one door: the invoice. Until now a delivery note could be issued from a ready order OR from an issued invoice. Measured on a live factory, that is how the same goods left the store twice, once for the order, once for its invoice. From this version, a delivery note is issued from an issued invoice only. An order to be delivered is invoiced first. Nothing is lost for the storekeeper who only holds the order paper: the invoice search accepts an order number and finds the invoice it belongs to. Orders are never offered as something to deliver, so the mistake cannot come back. An order that already carries an issued invoice no longer offers to issue another one: it shows the invoice instead. The delivery note now says which lots left. On the screen and on the printed note, each line lists the lots and the quantity taken from each. The lot is chosen when the goods actually leave, so a note printed before departure carries none and the note reprinted after departure carries them all, which is exactly what the customer signs. And the shipping mode a factory calls a pick-up is now named that way: Pick up (customer collects). It is the same mode as before, so nothing changes on notes already issued.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Moving stock between warehouses now has a document: the transfer note. A transfer note is composed in the warehouse the goods leave from: several items at once, raw materials and finished goods together, lot by lot. A quantity can be spread over an item's lots in expiry order with one entry, then adjusted lot by lot. Nothing moves while the note is a draft, and a draft can be changed or deleted. Shipping freezes the note. The goods leave their warehouse and stay in a system location, In transit, keeping their lots: they belong to the company for the whole journey, so the stock total and the stock account do not move, and no accounting entry is written. The storekeepers of the receiving warehouse are told the note is on its way. The receiving warehouse records what actually arrived, line by line, as many times as needed: a truck can come back. You cannot receive more than what is still in transit — goods found in excess belong to a stock count. When nothing more is coming, the receiver says so, and what is still travelling goes into dispute. Someone who manages warehouses settles it: found, and it is received where it was going, or lost, and it leaves the stock at average cost, posted to a new account, Inventory losses in transit, separate from counting differences. The transport is paid like any other expense, recorded from the note itself and linked to it, through the usual approval gate. The cost of the goods moved does not change: moving stock that is already made does not make it worth more. Also in this version: a warehouse can be of type Shop, supplied by transfer note; the old item-by-item transfer is gone, replaced by the note; a customer return now shows as Return in instead of Adjustment in, and comes back into the very lots the delivery note took out of stock; and an invoice with nothing physical to deliver is no longer offered when creating a delivery note.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Counting and seeing each warehouse, lot by lot. Inventories now count lot by lot. When a count is started, each item gets one line per lot held in the warehouse counted, plus a line for stock with no lot or an unreadable label. The counter still never sees the expected quantity: the count screen and the printed count sheet show the lot and its expiry date only. A lot found on the shelf but not listed can be added during the count, by choosing it among the lots of the item. On validation, each line corrects its own lot in that warehouse. The value is judged on the item as a whole: a lot counted short and an unreadable label counted long by the same quantity is a tidy-up, not a loss, and writes no accounting entry. The estimated impact shown before validation is now computed exactly as the validation will apply it, in the warehouse counted. An inventory started before this version finishes as before, item by item. Each warehouse has its own page, opened from its card on the Warehouses screen: the items it holds, a filter to also show items usually stored there, and for each item its lots in that warehouse, with their origin, entry date, expiry and status, and its last movements there. The page of a raw material or a finished product shows its stock by warehouse. On a delivery note, the warehouse field says how many of the note's items each warehouse holds, and suggests the only one that holds them all. On a lot's page, a transfer between warehouses no longer appears as a place the lot went to, and each stock movement of the lot names its warehouse.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Real warehouses: every stock movement now says which warehouse it touches. Until now, only a transfer chose a warehouse. Every receipt, issue to production, delivery, return, adjustment and count went, without a word, to the default warehouse, or to the first one created. Stock moved to a second warehouse could no longer be used by production. From this version, each of these gestures asks for its warehouse, filled in for you from the workshop, your own warehouse or the usual warehouse of the item, and the history of every movement names it. Lots now know where they are. Opening a lot shows how much of it sits in each warehouse, and a transfer moves the lot itself. First expired, first out now picks lots inside the warehouse the goods leave from. Warehouses screen: warehouses are created, renamed and closed by the new right Manage warehouses and who works in them. Each warehouse can list the people who work in it: a person assigned to one or more warehouses can only receive, issue, count or move stock in those, and a person assigned to none acts everywhere. The screen checks the integrity of the stock and says so, and it points out any stock sitting in a warehouse that does not accept it. Workshops: each workshop can be given the warehouse it takes its raw materials from, and optionally the one for its manufactured components. When a workshop step ends and that warehouse does not hold enough, the step still closes and the missing quantity appears in Stock, Material to Allocate. The storekeeper says how much comes from each warehouse, and can leave the rest to the next reception of that material into the warehouses they tick. A production order cannot be closed while it has material waiting there. Inventories count one warehouse at a time, and their adjustments correct that warehouse. Delivery notes say which warehouse they leave from; a note planned before this version asks for it before the goods leave. A new installation names its real warehouses during setup. At this update, stock that had been stored by default in a warehouse that does not accept it, such as finished goods in a raw material store, is moved to the only warehouse that accepts it, by transfers recorded in the movement history. No accounting entry is written: the stock stays the company's.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A Consume button in front of every raw material of a production order. On a production order, the section What the run consumed now shows a Consume button on every material of the recipe and every request, including the ones the store has not issued. The workshop enters exactly what the run used. If it holds more, the rest goes back to the store, which confirms it, as before. If the store has not issued the material, or not enough, what is missing is taken out of stock at that moment, for this order and in the name of the person who consumes, and it enters the cost of the order like any issue. The quantity cannot be more than the stock holds: the message says how much is in stock, and the missing reception or stock adjustment must be recorded first. On orders that consume automatically at each workshop, a material is consumed by hand only after its workshop has issued it. Consuming has its own right, Consume materials, in the permission matrix. It is given by default to the Production team and Methods roles, so a workshop agent can consume without being able to suspend, plan or close an order. Please check the rights of your workshop users in Settings, Users: anyone who must consume needs this box. The former Declare button is now called Consume, and a material already consumed shows Correct.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Catching up the material that closed production orders never took out of the store, and the whole recipe in front of the workshop. A new screen in Stock, Missed Consumption, lists every closed production order whose recipe was not fully issued from the store: for each material, what the recipe of the target quantity needed, what the store issued, what is already waiting, and what is left to consume. The storekeeper ticks the lines and clicks Consume. Nothing is typed: the quantity is computed, and computed again at the moment of consuming, so a line can never be consumed twice. Each line is posted on the day the order was closed, as a raw material consumption tied to the order number, one entry per order and per material. If that month is closed, the line is refused and the message names the closing that the finance administration must reopen. When the store does not hold the material, the consumption is signed and waits: the next reception of that material issues it, dated from that reception, before any material is released to running orders. A waiting consumption can be cancelled, with a written reason. On a production order, the section What the run consumed now lists every material of the recipe and every request, not only what the store has issued. A material not yet issued shows Not issued by the store, with a Request button that opens the request on that material. It still cannot be declared before the store issues it. The stock movement history now names three movements it used to show under their technical name: missed consumption, material returned from production, and expired stock.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

What the workshop really consumed, declared material by material. On a production order, a new section, What the run consumed, lists every material the store has issued to the order and what the workshop still holds. The production team declares exactly what the run used. If it used less, the difference is sent back to the store as a return, which the storekeeper confirms or refuses as usual: nothing moves in stock until then. If it declares more than the workshop holds, the declaration is refused: the extra quantity must first be requested from the store. Orders that consume their materials automatically at each workshop follow the same rule. Quick Production is not concerned: it consumes its whole recipe when it is launched. A production order can no longer be closed while a material issued to it has no consumption declared, or while its declaration no longer matches what the workshop holds, for example after a new supply or a refused return. The message names the materials. The production order report now has a Material consumption table: for each material and each manufactured component, what the recipe planned, what was requested, what was consumed and, for users who can see costs, its value and the total. Anything not in the recipe, or beyond it, is marked. The production dossier and the order performance sheet carry the same mark, and the performance sheet now gives the value of each material. A correction comes with it: material returned to the store was still counted as consumed by the order, in its cost, its material variance and its dossier. It is now deducted. Please note for orders already running: declare what they consumed before closing them.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Clients without orders since a date of your choice. On the Clients screen, the new Clients without orders button asks for a date and prints the list of customers who have not bought since that day, in PDF or Excel. It is meant for your sales team: print it, call the customers back, and bring them back to you. A purchase counts whether it came through a customer order or directly through an invoice, so a customer who buys every week on direct invoices is never listed as lost. Drafts, cancelled documents, proformas and credit notes do not count as purchases. A customer who bought on the chosen day has bought since that day and is not listed. The list starts with the customers who never ordered, then goes from the oldest last purchase to the most recent. Each line gives the phone number, the contact person, the city, the date and reference of the last order or invoice, and how many days ago it was. Printing it requires the right to export the client list.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Two corrections in production, found on a real order. A production order can no longer be closed while one of its batches still has units to check or to receive into stock. Closing writes off the remaining work-in-progress as a production loss: closing too early turned the cost of goods that exist into a loss, and they never entered stock. The message now names each batch and what it is waiting for. Receive the batch first, or record in a quality control the units that were really lost, then close. Receiving a batch was refused with "Not enough value in stock" in two situations, and neither was the storekeeper's doing. When the end date of a batch was earlier than the day its materials were supplied, the reception was dated before the materials had reached the order. It is now dated on the later of the two days. And when the order had already been closed, the reception tried to take value out of work-in-progress that the closing had already written off. It now reduces that production loss instead, by exactly the value of the goods that enter stock. If a batch was refused for one of these reasons, simply receive it again: it will go through.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Three corrections found by testing the previous three versions on screen. When you create a production order and correct the quantity of a manufactured component, or remove it altogether, the Manufactured components tab now follows that decision. Until this version it still read the recipe: an order corrected to 12 was asked for 10, and an order that had removed a component was still offered a Consume button for it. A component you have already issued stays on the tab even if the order later drops it, so nothing leaves stock without showing on screen. In Quick Production, ending a production puts each declared batch into stock one at a time. If one of them is refused, the batches that already went in are now named in the message, and each batch on the screen says whether it is in stock. Ending the production again resumes where it stopped. Before, the screen looked exactly as it did before the refusal, and there was no way to tell that the first batches were already booked. Still in Quick Production, the note shown when you end below the requested quantity said the missing quantity became a production loss. The summary displayed right afterwards said the loss was zero, and the summary was right: the material has already left the store, so the whole run is carried by the units you obtained and each one costs more than planned. The note now says that.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A component your factory makes can now be requested from the store, and corrected when you create a production order. Until now, a made-in-house item (a drum, a bottle, a packaging you retouch yourself) could only be issued by the production team from the order itself. It could not be requested, and the store was never told. From this version, Request materials lists your raw materials and your manufactured components together: pick what the run needs. A request for a component reaches the Finished Goods store, where it is stored, and appears there under Component requests from production, with the same Supply gesture, partial supply included. Raw material requests keep reaching the raw material store as before, and neither store sees what the other holds. When you create a production order, the manufactured components its recipe consumes are no longer read-only: change the quantity, or remove a line if this particular run will not use it. A removed component is recorded as zero rather than erased, so the order remembers the decision: the shortage warning stops asking for it, and declaring a batch is no longer refused because of it. What does not change: the direct issue from the order (Manufactured components) stays, for the days the component is already at hand; the material release queue, the material variance and the standard cost keep counting raw materials only. Sending a component back to the store does not exist yet.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Quick Production. A new module, Quick Production, lets a production agent run a production from a single screen: no material request to the storekeeper, no routing steps, no quality check. The agent picks the product and the quantity. The screen lists the material the recipe needs with what is in stock, what the production will cost (for users who hold the Costs and valuation right), and what the finished goods are worth at the catalog price. Launch, and the whole recipe leaves the store at once and a timer starts. During the production, the agent declares each batch obtained and, if any, the waste for sale by weight. End production puts every batch into stock and closes the order, with a one-line reason if it ends below the requested quantity. Batches enter stock only when the production ends, after the waste is declared: that is how the value of the waste lowers the cost of the finished goods. For the same reason, the storekeeper does not see these batches in Batches to receive, and a quick production cannot be closed from its production order screen. A quick production is an ordinary production order, of type Quick production: it appears in Production Orders with its costs, its batches and its entries. It only works on products with an active recipe. If material is short, it is refused, unless someone with the right to launch despite a shortage writes why. A made-in-house component that is short is always refused: produce it first. The module is off until Bold switches it on for your installation. Once on, the Production team receives the right by default. Please note that the Production team does not have the Costs and valuation right by default, so agents will not see the cost on the screen unless you grant it in the permission matrix.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Waste for sale. Your factory can now declare, at the end of a production, the saleable waste it yielded (offcuts, regrind, bags of scrap), and sell it. Create a waste type from the new Waste for Sale screen (under Stock), as an item of type Waste for sale. Its unit of measure is what you count and sell, usually a bag: a new standard unit, Bag, is added for this. Its unit weight is the weight of one bag, in kg or g. And it carries a recognised value per unit, separate from its sale price: that is what one bag enters stock at, and what it takes off the cost of the production. On a production order, the By-products tab has a new button, Declare waste for sale. Pick the waste, type the weight you obtained, and the software counts the bags: 50 kg of a 10 kg bag adds 5 bags to stock. A weight that does not fall exactly is kept, not lost: 53 kg makes 5.3 bags, shown as 5 bags + 3 kg. The weight you typed stays on the order next to the bags it made. The value is copied from the waste type at that moment and frozen on the order, so changing the price later never rewrites past waste. Selling waste now credits its own revenue account, 4130 Sales of scrap and recyclables, instead of being mixed with your finished goods sales. A credit note on waste reverses it on the same account. Invoices without waste post exactly as before. Please note: declaring waste requires the right to receive finished goods into stock, as any stock entry does. By-products can no longer be entered on an order that is closed, cancelled or still in draft: declare them while the order runs. A waste type cannot be the target of a production order, and a customer order line for waste does not create one: waste is sold from stock.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

By-products now really lower the cost of the product they come from. When a production order yields a by-product (offcuts, regrind, bran, cake) and you give it a value, that value was taken off the order's cost on the order screen, but not off the finished goods in stock: they still entered at the full cost of all the material, and the difference only came back at closing, as a production gain. The order screen and the stock therefore showed two different unit costs for the same product. From this version, the finished goods received after a by-product carry the material cost minus what the by-product took. Example: 100 pipes from 500,000 of material, with 10,000 of saleable waste declared first, now enter stock at 4,900 each, not 5,000, and your margin reports read the same figure as the order screen. One case works differently, and the screen tells you when it happens. If the finished goods of the order were already received before you declare the by-product, their cost cannot be lowered any more (some may already be sold). The by-product still enters stock at its value, and the part that can no longer lower the order's cost is booked straight away as a production gain, instead of pushing work in progress below zero until closing. To get the full reduction, declare by-products before receiving the batches. Nothing changes for orders without by-products, and past entries are not rewritten.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Staff allocation, and the Protocol screen becomes one screen for both. Your factory can now record the products it hands to its own employees, alongside the goods it gives to visitors. The screen is renamed Free Goods Issues and carries the two gestures, because they are the same gesture: goods leave the store at cost, from the batches closest to expiry, and become an expense. What differs is where the cost lands, and that matters. Protocol goes to 7280 Protocol expenses; staff allocation goes to a new account, 6180 Staff allocation, in the staff costs class - it is a benefit to your people, not a general overhead. It is deliberately NOT the same account as 6170 Staff welfare: that one carries what you BUY for your teams, meals, water, transport. This one carries what you take out of your own production. Kept together, you could never read what the factory gives to the people who make it. For a staff allocation you pick the employee rather than typing a name, and the software copies their name onto the record. Renaming a staff file later never rewrites a past issue. An allocation without an employee is refused: it would be a staff cost that names nobody. Please note: staff allocation is a stock issue and nothing more. It does NOT go through payroll, and it is not treated as a taxable benefit in kind. Should you need that, it will be separate work on the payroll side. And as before, a free goods issue cannot be edited or deleted once recorded, because it has already taken goods out of the store and posted an entry.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Protocol. Your factory can now record goods given free of charge to someone who is NOT a customer - a visitor, a guest speaker, an authority. Until now there was no way to do this: every path that gave goods away needed a customer and an invoice, so a protocol gift either went unrecorded or was forced through a fake customer file. A new screen, Protocol, sits under Stock. You name who received the goods, say why, and list what was given. The goods leave the store at cost, from the batches closest to expiry, exactly as a sale would - and the cost is posted to a new account, 7280 Protocol expenses. It is deliberately NOT the same account as goods offered to customers: kept together, you could never answer 'how much did we give away in protocol this quarter?' Two things to know. The name of the recipient and the reason are both required - without them the expense line cannot be justified months later. And a protocol issue cannot be edited or deleted once recorded, because it has already taken goods out of the store and posted an entry; the day you need to reverse one, it will be a reversal with its own entry and its own return to stock, not a quiet correction. Recording a protocol issue requires the same right as writing off expired stock: it is a deliberate stock issue. Goods reserved for a customer order are never offered - they are already promised.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Settlement discounts. You can now promise a customer a discount for paying quickly, and the software applies it when the invoice is settled. Set the rules under Company settings > Settlement discounts: how many days from the invoice date, and how much - a fixed amount or a percentage. A rule can apply to everyone, to one customer, or to a named block of customers you group yourself. When several rules could apply, the most specific one wins: the customer's own rule, then a block, then everyone. At the till, the discount is announced before you enter an amount: it says what the customer should pay instead, and what the difference will be recorded as. A rule set to offer automatically arrives already ticked; the cashier can always untick it, and the amount follows. The discount only applies to an invoice settled in ONE payment, within the window. An invoice that has already received something, or an amount that does not match, is refused with a plain message rather than a greyed-out button. Please note two things. The customer's invoice is settled IN FULL: they owe nothing more, and your reminders will leave them alone. Your bank or cash receives only what was actually handed over, and the difference is posted to a new account, 8140 Discount allowed, under Financial charges - so you can read at any time what your collection policy costs you. Setting the rules requires the same right as payroll scales and the staff loan policy: it is a business rule, not a till operation. A cashier applies a discount, they do not decide it. Field payment declarations never carry a discount.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

An order and its invoice are now delivered together. Until now, if you raised the delivery note from the INVOICE, the order behind it was never settled: it stayed “ready” and kept being offered for delivery, so the same sale could end up with two delivery notes. The reverse was true as well — an invoice whose order had already been delivered kept being offered. Both lists now know about each other: once a sale has been delivered in full, it disappears from both, whichever document the delivery note was raised from. Orders left at “ready” by this fault correct themselves as soon as you update; there is nothing to re-enter. An invoice can now be delivered in SEVERAL notes, exactly as an order can. Previously an invoice disappeared from the list after its first delivery note, which made a part delivery impossible without issuing a second invoice. A part delivery or a refused one now leaves the sale available for the rest. And stock can no longer leave twice for the same sale. Issuing goods already refused to serve the same delivery note twice; it now also refuses a note covering goods that another note has already delivered in full for the same order and invoice, and it says so plainly instead of taking the stock out in silence. Please check one thing after updating: if you have a delivery note still planned that repeats one already delivered, it will now be refused at departure. Cancel it — it was never meant to leave.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Customer refunds now go through the same approval gate as supplier payments, expenses and salaries. Above the limit you have set, a refund is not recorded at all: the customer's credit is untouched, no accounting entry is posted, and the money is still in the till. It is sent to management as an approval request, and the person on the spot is told the amount, the limit and the request number. When management approves it, the refund is recorded then, with all its usual checks run again, and it stays in the name of the person who asked for it. The amount submitted is the one the software has bounded against the credit balance, not the figure typed on screen. A credit can still be refunded in several instalments: each one asks for its own approval, and the credit balance bounds them all. Please note: refunds already had a separate limit of their own, set under Company settings, which refuses the refund outright instead of sending it for approval. Both limits are still in place and the older one is checked first, so nothing you had set stops working. Having two limits for one gesture on two different screens is confusing, and we would rather bring them together than leave them side by side. Tell us which one you want to keep.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Salary payments now go through the same approval gate as expenses and supplier payments. As with expenses, the approval settings screen already let you set a limit on salaries and nothing enforced it: a payroll went straight out however large it was, so a manager who had set a limit believed they were protected and were not. From this version, a payroll above the limit is not paid at all. Nothing is recorded: no accounting entry, no payment date, and the payroll stays Generated. It is sent to management as an approval request, and the screen tells the person on the spot the amount, the limit, the request number, and that nothing has been paid yet. When management approves it, the payment is recorded then, with all its usual checks run again — the payroll must still be generated, the payment date must still not be earlier than the payroll charge, and the account you picked must still belong to the payment method. The payment stays in the name of the person who asked for it, not the person who approved it. The amount submitted for approval is the net payroll held by the payroll run itself, not a figure sent from the screen. One thing this version also prevents: the same payroll can no longer be sent for approval twice. If you try, the screen names the request already waiting. Nothing in your books is read, changed or moved, and no limit is set for you — an approval limit you have not set still means no approval is required.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Expenses now go through the same approval gate as supplier payments. Until now the approval settings screen let you set a limit on expenses, but nothing enforced it: the limit sat there and every expense went straight through, so a manager who had set one believed they were protected and were not. From this version, an expense above the limit is not recorded at all. It is sent to management as an approval request, and the screen tells the person on the spot: the amount, the limit, the request number, and that nothing has been recorded yet. When management approves it, the expense is recorded then, with all its usual checks run again, and it stays in the name of the person who asked for it, not the person who approved it. This covers the three ways an expense is entered by hand: a one-off expense, a new recurring expense (which pays its first instalment straight away), and an instalment you generate yourself, where the amount can be retyped. The nightly job that raises recurring instalments does not ask again: it can only pay the amount that was approved when the recurring expense was created, and that amount cannot be changed afterwards. One more thing this version fixes for every kind of payment: an approval can now only be used once. Nothing in your books is read, changed or moved, and no limit is set for you — an approval limit you have not set still means no approval is required.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Two fixes to payroll. First, the account you pick when you pay salaries now commands where the money actually leaves from: until now a payroll paid in cash or by Mobile Money silently left the account carried by the chart of accounts, whatever you had picked, so a factory with two cash tills saw its payroll leave the wrong one with nothing on screen to say so. Second, the Bonus column of the payroll grid now shows the month's bonuses instead of letting you type one. A figure typed there only reached the accounting charge, never the net pay, never the payslip and never the tax base, and the payroll then refused to validate at all. Add a bonus from Advances & loans and it is carried everywhere. No migration, and no past payroll is altered.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A customer who pays more than they owe no longer gets turned away. Until now the software refused the payment outright and the cashier had nowhere to put the difference, with the customer standing at the counter. Now you enter what you actually received. The screen shows you the split before you save, in plain words: this much settles the invoice, this much goes on the customer account. Nothing happens until you tick the box confirming it, so a typing mistake cannot quietly turn into money you owe someone. The surplus becomes a credit in that customer name, which you can later apply to any of their invoices or refund to them, using the screens that already existed for credit notes. A customer with no invoice and no order at all can now pay onto their account too: leave the invoice empty. Their receipt says both parts and prints the balance left on their account, so they leave holding proof of what is still theirs. Two things this update deliberately does not do. A cheque cannot be put on a customer account: the bank has not paid it yet and it may still bounce, so record a cheque for what the invoice asks and no more. And nothing is applied to other invoices automatically: the software tells you the money is there, a person decides where it goes. Taking a surplus needs its own permission, separate from recording ordinary payments, so you can let someone run the till without letting them create debts owed to customers. It is granted by default to the roles that already handle payments, and you can remove it per user. This update adds one column and one payment type; nothing already in your books is read, changed or moved.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Recording a payment now refuses anything above what the invoice actually still owes. The screen already showed the right figure, but the check behind it worked from the invoice total minus the payments received, which ignores any advance or credit note already applied to that invoice. On an invoice of 36,980 with 21,000 of advances applied, the screen said 14,480 was left to pay while the software would still have accepted 35,480, without a single warning: the payment went through and left the invoice in credit. Both now read the same figure, the one you see on screen. This is stricter than before, on purpose. If you enter more than the balance shown, you are stopped and told the exact amount that remains. Taking a payment larger than the balance, and keeping the surplus on the customer account for their other invoices, is a separate change coming in a later update. Nothing already in your books is read, changed or moved, and this update adds nothing to the database.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A workshop can now send unused material back to the store. Until this version there was no way to do it: once the store had issued material for a production order, anything the run did not use stayed with the workshop — kept on a shelf, or thrown away. The only tool that could have put it back was a stock adjustment, which is meant for correcting a count and would have made the books say the company had earned money it never earned. The gesture now takes two hands, on purpose. Production declares what is going back and says why; nothing moves at that point, and the screen says so plainly. The store then receives it and decides, with the material in front of them: take it back into stock, scrap what cannot be reused, or split between the two — a bag that has been opened is not the same as a sealed one, and only the person holding it can tell. The store can also refuse the return, saying why, and the material stays with production so they can declare it again. What comes back re-enters stock at the price it left at, so your average cost does not move; what is scrapped does not come back, but in both cases the production order stops carrying material it never used, so its cost is right. Returns are only possible while the order is running: an order cannot be closed while the store still has a return to answer, and the software says which one. This update adds one table and one column; nothing already in your books is read, changed or moved.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

An expense now remembers which account the money actually left. You could already say, when recording it, that a payment went out of a particular bank account or a particular till — but the software used that answer once, to write the accounting entry, and then forgot it. So when you cancelled an expense, it had nothing left to go on and put the money back on the default account for that payment method. An expense paid out of your second bank account was refunded into the first one. Nothing failed and the books stayed balanced, which is exactly why it went unnoticed: two accounts quietly became wrong, and only the bank reconciliation would ever have shown it. Cancelling now returns the money to the very account that paid it. Expenses recorded before this update do not carry the information, so they keep cancelling exactly as they do today, on the default account — nothing already in your books is rewritten or moved. This update adds one column to the expenses table.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The software now refuses to take money out of the wrong kind of account. When you record a payment, an expense, a purchase, a staff loan or a salary, you can name the exact account the money moves through. Until now, if you picked a bank account and then changed the payment method to cash, the screen stopped showing your choice but kept it underneath — and a cash payment could be posted against a bank account. Nothing failed and nothing went out of balance: the money simply left the wrong place, and you only found out at the next bank reconciliation. Every screen that moves money now checks that the account you named belongs to the method you chose, and says plainly which account it is and why it does not fit. This is a check, not a restriction: an account you have since closed is still accepted, because it really is where the money came from, and a scheduled payment recorded overnight must not fail because a bank was archived in the meantime. If you never name an account, nothing changes at all — the default for that payment method keeps being used, exactly as before.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A recurring expense can now say WHICH account it is paid from. Until now the form asked only for the payment method: a rent paid every month from a second bank account, or from a particular mobile money wallet, still went out of the default account for that family — every month, silently, and the screen never asked. One-off expenses have offered that choice for a long time; recurring ones simply had nowhere to keep it, so the question could not even be put. The account you pick is now carried by all three routes that create an occurrence: the first one recorded when you set the recurrence up, the ones you generate by hand, and the ones the software generates on its own overnight. Leaving the field on its default keeps exactly today's behaviour, so nothing changes for recurrences already in place and no figure in your books moves. One related defect was fixed at the same time, on both one-off and recurring expenses: if you picked a bank account and then changed the payment method to cash, the bank account stayed selected behind the scenes although the screen no longer showed it, and a cash expense could be posted against a bank account. The choice is now cleared as soon as you change to a different kind of payment, and falls back to the default for the new one. This update adds one column to the recurring expenses table; no existing data is read, changed or moved.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Four screens where you pick an item from a list now let you TYPE to find it, the way the sales and invoicing screens already did. Until now these lists could only be scrolled: in a factory with hundreds of raw materials or products, finding the right line meant hunting through the whole catalogue — slow on a tablet, and easy to pick the neighbouring line by mistake. You can now type any part of what you are looking for, the item code or its name, and the list narrows as you type. This applies to: requesting materials for a production order; creating a production order, for the product to make, the linked sales order and the estimated materials; the opening stock screen used when setting the software up; and the recipe screen (bill of materials), both for raw materials and packaging and for components your own factory makes. Two of those screens also stop showing their invitation — "Select item…", "Select material" — as though it were an article sitting in the catalogue next to the real ones; it now appears on the empty field instead, where it cannot be picked by accident. Nothing else changes: the same items are offered, in the same order, and what you pick is recorded exactly as before. Short lists that are not catalogues — a type, a priority, a unit of measure — keep their simple drop-down, because there is nothing to search through in three entries. The list of results also widens to fit what it shows, instead of being squeezed into the width of the field it drops from: on a recipe line, which is narrow, three raw materials whose names begin the same way used to arrive cut short and could no longer be told apart — in the very list whose only job is to tell them apart.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Fixes a defect found in browser acceptance testing. When signed in with the publisher's own support account, approving or refusing a payment failed with "This item is still used elsewhere, so it cannot be changed or removed" — a message about deleting something, on a screen that deletes nothing. The request simply stayed pending, with no way to understand why. The publisher's account is deliberately not one of your users, and the approval record has to carry the name of whoever decided, so it could never be stored. The screen now says so plainly and tells you what to do: sign in with your own super administrator account. Nothing changes for your own accounts — your super administrator, management and any designated deputy approve exactly as before.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Components your own factory makes are now issued from specific stock batches, like everything else that leaves the finished-goods store. Until now this was the only outflow that took a lump of stock without saying which batches it came from: deliveries, scrap, rebates in kind and free goods have all picked batches since a long time ago. That gap mattered most exactly where it was: this is the one place where one of your products goes INSIDE another. On a recall you could say which batches of drums you received, and which batches of bottles you shipped, but not which drums were in which bottles. The chain is now unbroken. The software also picks the batch closest to expiring first, and refuses to issue a batch that has expired or is still in quarantine, naming the batches concerned instead of quietly issuing something else. Stock that was never tracked by batch — from before batch tracking, or from adjustments and returns — still issues exactly as before: what is not tracked is not blocked. Quality was already covered and has not changed: a batch held by quality never enters stock in the first place, so there was nothing to refuse at this point. No figure already in your books moves, and nothing changes for a factory that does not manufacture its own components.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Three things about components your own factory makes. First, the software now refuses to declare a batch when the order never took out a component its recipe calls for. Declaring it would write two untruths at once: the component stays counted in the finished-goods store although it is physically inside the product, and the cost of what you made leaves it out, so the margin looks better than it is and prices get set on it. The refusal names the component and where to issue it, and it only triggers when nothing at all has been issued — a run that took two drums out of three is left alone, because it made something real. There is no override here, unlike launching an order: the remedy is one click away in the Manufactured components tab. Second, orders that already declared production without their component are now named rather than rewritten. A closed cost is not corrected — that is a rule of the house — but the order screen says its cost is incomplete and which component is missing, and the order list marks it, so you know which figures to read with caution. The warning is worked out fresh every time it is shown, so an order clears itself from the list the day the component is finally issued. Third, the plan now says what it could not price. A component you make but whose recipe you have not entered yet used to vanish from the plan in silence — not the component, not its materials, nothing — and the planned cost read as though it were complete. It is now named on the variance panel, with the quantity needed, instead of being counted as zero. Nothing is guessed: a plan that admits a hole can be used, a plan that hides one cannot. No figure already in your books moves.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Wording fixed on the new-order screen. When the product you are about to make uses a component your own factory produces, the screen used to call it a bulk good and send you to a Repackaging tab that no longer exists under that name. It now names the component for what it is and points at the right place.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A production order can now take a component your own factory makes — a drum, a bulk batch, a half-finished item — straight out of finished-goods stock, on any order. Until now the screen told you the component was needed and even that it was short, but only repackaging orders had the button to issue it, so on every other order the warning had no way out. Everything that follows was already in place and now simply happens: the component leaves stock, its cost joins the cost of what you are making, and the accounting entry moves its value into work in progress. Two things this fixes quietly: your stock stops holding components that were in fact used, and the cost of the finished product stops being understated, which was making margins look better than they were. The order screen also says what to do when the component is missing — produce it first, because a component you make is not something the material store can hand you.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Numbers on printed reports now show the decimals they actually have, instead of being padded out. A unit price of 442 was printed as 442.0000 and a quantity of 10 kg as 10.000 kg, which read like a system inflating its figures. Nothing was ever miscalculated — values are computed from the stored figures, never from the printed text — but a number that looks wrong makes people re-check books that are right, and that costs real time. Prices keep their two decimals, because a price without them no longer reads as money, and they show a third or fourth only when one genuinely exists: a cap costing 0.0125 still prints in full rather than being rounded to 0.01.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A correction to the previous update, applied before it could do any harm. The update that added payment approvals also carried instructions to remove seven database indexes on deliveries, expenses and staff positions — tables that have nothing to do with approvals. Those indexes sit on links between records, and losing them would have quietly slowed down screens that join those tables together, with nothing on screen to explain why. They are put back, and they are now written into the model itself so the same slip cannot happen again through the same door.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The regularization report now shows the opening stock, entry by entry. Until now it let you check the clients and the past invoices you had brought in, and not a single line of stock — not the detail, not even a total — although in a factory the stock is the largest part of what gets brought in. Every entry is listed on its own line with its quantity, its unit cost and the resulting value, in the order it was typed, so each one can be held against the paper inventory it came from. It is deliberately not grouped by article: a total can be right by accident, when two mistakes cancel each other out, and nothing tells them apart until you go down to the entries themselves. The two stock totals, raw materials and finished goods, are read from the same place as the opening balance sheet, so the report and the balance sheet can never disagree. Printed article lists now show their unit price. The finished goods catalog shows the unit selling price, and the wholesale price as well when the factory uses one; the raw materials catalog shows the unit purchase price, marked as a reference price when nothing has actually been purchased yet, so a declared figure is never mistaken for a negotiated one.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Management can now require its approval before a large payment leaves the company. A new Approvals space holds two things: the payments waiting for a decision, and the settings — one general limit, and a different limit for certain types if wanted. A deputy can be named to decide in your place, and a super administrator can always approve; every approval carries the name of whoever gave it. Below the limit nothing changes at all, and a limit left empty means no control whatsoever, so a factory that has set nothing is never blocked. A payment above the limit records nothing while it waits — no entry, no money moved — and the person who asked is told so instead of believing the supplier has been paid. Approving replays the original payment with all its checks; if the situation has changed in the meantime the approval is given back rather than left standing on a payment that never happened. Refusing abandons it with a written reason. This first release covers supplier payments only; the other kinds follow, once this one has been proven in real use.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The list of sales for a period can now be printed. A "Print this list" button sits above the table on both screens — the manager's Revenue page and the accountant's Sales of the period — and produces a landscape PDF with one line per invoice: reference, date, customer, invoiced, paid and still due, with the totals at the foot. The printed period is the one on screen: looking at today's sales and printing gives today's sales, not the month. The figures are the ones the screen shows, read from the same place, because a document that disagrees with the screen it came from is worse than no document at all — it circulates and outlives the screen. The button does not appear when there is nothing to print, so an empty PDF never ends up filed as proof that there were no sales.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Sales can now be read one by one, for the day, the month or the year, with what has been paid and what is still owed on every single invoice. The Revenue screen already showed trends, comparisons and the best products and customers; it now ends with the detail behind those figures, so a number that looks odd can be traced to the invoice that caused it. The same table is available to the accountant from Invoicing, under "Sales of the period" — the very same figures, so the manager and the accountant can never read two different amounts for the same invoice. Every line adds up: invoiced equals paid plus still due. Where an invoice was cleared by a credit note, an advance or a write-off, that amount is shown in its own column and never counted as money received, because no money came in; the column only appears when at least one invoice has such a settlement. What is still owed is read from the same place as the customer statement and the aged balance.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A part you manufacture yourself and use inside another product's recipe now carries a cost. Until now it showed "no cost", and the damage went further than the label: a single missing price empties the whole parent's standard cost, so a product using such a part had no cost price and no margin at all. The cost is the one actually recorded once the part has been produced; until then it falls back to the price entered on its own record, which is what a factory uses to say what the part is worth to it — material plus the electricity, moulding and machine time a recipe does not list. The recipe screen marks a cost that is declared rather than measured, so the two are never taken for one another. What a batch actually cost is untouched: ledger entries, variance and recorded cost prices still read only what was really produced, because a declared figure has no place in an accounting entry. This mirrors what raw materials have always done with their reference cost.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Extra units produced above an order's target now consume their packaging. Until now a run that declared 110 units against a target of 100 took no extra material at all — which is right for raw material, because the same batch simply yielded more, and wrong for packaging, because ten more jars need ten more caps and ten more labels, and those come out of the store. Two things were quietly false: the packaging store showed stock it no longer had, and the surplus units entered finished goods without their packaging cost, so the extra margin an over-run appeared to earn was overstated. Only recipe lines whose material category is marked as packaging are affected; raw material is still never added. Declaring a batch in several parts does not pay for the same surplus twice. The material variance screen follows: packaging is now measured against what was declared, so a correct over-run no longer shows up as over-served. Nothing changes for an order that stays within its target, and nothing changes for a recipe that carries no packaging.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

You can now decide VAT line by line, on the invoice or the order, instead of one rate for the whole document. Tick or untick VAT on each line: the tax is charged only on the lines that carry it, and a global discount is shared between taxed and untaxed lines in proportion, so the tax stays right. The customer can check the figure too: untaxed lines are marked on the printed invoice, with a note saying what the mark means. Nothing changes on documents where every line is taxed, which is the normal case — the totals are identical to the cent. The VAT fields on the product sheet have been removed: they showed "VAT · Applicable · 15%" while no invoice calculation ever read them, so a factory setting a rate there was invoicing on the company rate without knowing it. Taxing is a decision taken when you sell, not when you create an article, so it now lives on the document line where someone actually makes it. The same columns have been removed from the product import sheet.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The software now refuses to consume an opening balance you have entered but not yet posted. Until this version, shipping goods, collecting an opening invoice or settling an opening supplier debt before posting the opening balance subtracted that amount TWICE — and the balance sheet still showed "Balanced" over it, so nothing warned you. The error only surfaced weeks later, when a stock figure stopped adding up. Entering an opening balance posts no accounting entry on purpose (it is aggregated into the opening balance itself), while consuming it posts one immediately, which is where the double subtraction came from. The three operations that consume an opening position now refuse, name what they refuse, and tell you where to go: post the opening balance first. Nothing you entered is lost. A factory that has not started a migration is never blocked, and once the opening balance is posted everything works as before.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Your bank accounts, tills and mobile money accounts no longer carry the wrong warning. Until now, a money account you created yourself was marked "Manual entries only" in the chart of accounts, which told your accountant to post their own entries on it. That was exactly backwards: the software posts every receipt, every expense and every opening entry on those accounts as soon as someone selects them. An accountant following the marking would have doubled every bank movement. The marking now recognises any account you have declared as a money account, and it remains where it is true: on accounts nothing feeds automatically.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Delivery notes now tell you what a delivery costs you, and whether it has been paid. When a third-party courier delivers and you bear part or all of the fare, the delivery note shows what is yours to bear, what has already been recorded as an expense, and what is still to record. A button opens the ordinary expense form with the delivery already attached, so the cost is entered once, through the accounts, and can be checked afterwards. No entry is posted automatically, and that is deliberate: the software knows what the delivery costs, but not how you paid the courier, who is usually settled in cash or mobile money on the spot. Posting a supplier debt would open a debt to someone already paid that would never clear. Your own fleet expects no expense at all: its fuel, driver and upkeep are already recorded elsewhere, and counting them again here would overstate what delivery costs you. A new account, 7290 Delivery expenses, keeps the fare separate from your other selling costs, with a matching "Delivery & couriers" expense category. That category, and any future one, now reaches factories that are already installed: until this version, delivered expense categories only ever appeared on brand-new databases.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Delivery notes now propose the right fleet, and the right one only. When the customer collects with their own vehicle, the delivery note offers that customer's vehicles and drivers; when your own fleet carries, it offers yours. You can record a driver as belonging to a customer, the way you already could for a vehicle, so the gate no longer has to ask for the same plate and the same name at every visit. Nothing is imposed: the free-text driver and plate fields stay underneath for the truck you have never seen, and switching who carries clears the previous pairing so a delivery note never leaves with a driver the screen no longer shows. This version also fixes a vehicle form that showed "Truck" while saving no type at all, now that the type is optional: it offers an explicit blank choice.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Delivery notes now say who carries the goods, and who pays for it. Until now a delivery note had to come from an order, which shut out factories that sell over the counter: they issue an invoice and never open an order, so no delivery paper could be produced at all. A delivery note can now start from an order OR from an issued invoice. You then pick who carries: your own fleet, the customer's own vehicle, or a third-party courier such as Yango, Bolt or Uber. The fields follow that choice, and a field that cannot receive anything is not shown. Your own fleet: enter the delivery charge billed to the customer, or mark it Free. The customer's own vehicle: no amount at all, because nothing is paid or collected by the factory; you record the vehicle type, make, model and driver instead. A third-party courier: enter the cost and say who pays it, all by the customer, all by you, or shared, in which case you enter the customer's share and the rest is yours. What the customer pays goes straight to the courier on delivery, so nothing of it is recorded as owed to you. The delivery note prints all of this on its own PDF, the one the driver carries and hands over, including the amount to collect on delivery when there is one. Vehicle types are no longer fixed in the software: they are now a list your SuperAdmin keeps, seeded with the seven previous ones, so you can name the vehicles that exist in your country. Your existing delivery notes and vehicles keep exactly what they had. No figure in your books moves.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

You can now give goods away on an invoice, and the books say what it cost. Until now, giving a customer free product required a rebate scheme with tiers, and the customer had to have reached one: a manager who simply wanted to add two free jars to a sale had no way to do it. Now any invoice line can be marked as a gift. It keeps its quantity and its description, it is billed at zero, and the goods leave stock at cost when the invoice is issued — posted as a selling expense, never as a sale at zero, so your stock is no longer overstated by what you give away. The same product can be sold and given away on the same invoice, which is what "buy 10, get 2 free" needs. Every gift requires a written reason, and the gesture is guarded by its own permission, granted from the permissions matrix to whoever your company chooses — the person who invoices every day does not get it automatically. The customer reads FREE on their copy, with a note saying those goods are not billed and carry no VAT. Free lines carry no VAT in this version: check with your accountant whether your tax regime charges VAT on goods given away. This version also fixes a wording problem on documents that could start needless arguments with customers: an invoice or order carrying no VAT still printed "Total (incl. VAT)" on its last line. The label now follows the tax the document actually carries — with no VAT, the tax breakdown disappears and the total reads "Total (excl. VAT)".

Not translated yet: fr — readers in that language will be shown the English note, and told so.

You can now print who is allowed to do what. Until now the software could not answer that question on paper, in PDF or in a spreadsheet, which is the first thing an auditor asks for. The document lists every account with its name, email, role and rights, and it is built for the job people actually do with it: it puts first the boxes to tick and to untick compared to the role, because that is the only work to redo by hand when rights are set up again; the full list of rights comes after, to check against. It also names any stored permission this version no longer knows, which the software silently ignores and nobody would otherwise discover. Access is computed rather than stored, so the document carries the software version and tells you to compare rather than to assume: restoring a role on a later version may give different rights while looking restored. Export it from the Users screen, in PDF or Excel; it follows the users export permission. Nothing in your books moves.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Your income statement now separates what the goods cost, what running the business costs, and what financing it costs, and it shows a gross margin and an operating result. Until now every charge landed under one heading called operating charges: bank charges, interest and inventory adjustments were all reported as if they were the cost of running your factory, so the operating result a bank reads was wrong by that much. Each account now carries the section it belongs to, and you can override it on any account of your own chart without moving it to another class. The cash flow statement stops hiding unnamed movements in an Other bucket: six operations that really move your bank or your cash, including bank charges, bank interest and cash count differences, were falling into it and now carry their own name. The period review no longer compares materials issued to production against total charges, which could never match: issued materials are not a charge until the goods are sold. The chart of accounts marks the accounts the software never posts to, so your accountant knows which ones wait for their own entries. Funds you declared as already held when the software was set up no longer count as money the period brought in: on our test factory they were 167,000 out of 195,750 of inflows, so the statement claimed the factory had generated 193,300 in a month when it had generated 26,300. They now sit in the opening treasury, where they belong, and the closing treasury does not change by a single cent. Nothing in your books moves.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Salaries are now filed by position instead of all landing in production. Every payslip went to 6110 Production salaries, so the accountant, the storekeeper and the manager were production costs: your cost per unit carried them and your gross margin was wrong by that much. The account 6120 Administration salaries shipped with the software and nothing had ever posted to it. Each position now carries the account its salaries belong to, which can be any account in your chart, and payroll posts one line per account. Existing positions keep going to production, so the update moves nothing in your books; a position created afterwards must be given an account before anyone holding it can be paid.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The inventory report PDF now shows what a count will cost before it is validated, like the screen already did. It read a column the software only fills in at validation, under a fixed heading that said estimated, so a count about to write off ten thousand printed 0.00. This is the document a finance manager reads away from the screen and decides on, so it matters at least as much. The heading now says whether the figure is an estimate or the amount posted, and the report carries the same warning as the screen when stock moved while the count was open.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Warns you when stock moved while a count was open. A count freezes the book quantity the day it is launched, and that frozen figure is what the count is meant to check. But production keeps consuming, so a count launched two weeks ago could show a shortage of 41 litres on a perfectly accurate count, and ask the storekeeper to explain ordinary consumption. The discrepancy column still compares with the book quantity at launch, as it should, and the page now names the drift, shows the stock as it stands today, and shows what validating will actually move.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The estimated impact of a stock count is now computed before you validate it, instead of showing zero. The figure came from a column the software only fills in at validation, so every count in progress claimed an impact of 0.00 — including one that was about to write off ten thousand. You decide whether to validate a count by looking at what it will cost, and that was the one moment the number was wrong. The tile now says whether it is showing an estimate or the amount actually posted, and the screen and the validation share the same calculation, so the two cannot drift apart.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Fixes a layout defect found in browser acceptance testing of 4.36.0. On four of the eight entry forms, the banner that tells you which month your entry will land in had been placed inside a two or three column grid, so it sat in a narrow cell beside the quantity field instead of spanning the full width above the date. It now sits above the fields, where it is read before the date is chosen.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Accounting entries now carry the date of the operation they record, not the moment the button was clicked. Twenty-seven entries were dated from the click: an inventory counted on 31 March and validated on 2 April corrected the stock in March and the ledger in April, and a production batch declared at month end entered stock in one month and the ledger in the next. Closing a month stopped a few of these and quietly redirected the rest into the following month, so the same closing could refuse an invoice while accepting its cost of sales. Cancellations follow the same rule: a cancellation is now dated like the entry it cancels, so both land in the same month. If that month is closed, the cancellation is refused and names the closing to lift, instead of posting itself somewhere else. Every screen that lets you choose a date now shows which month the entry will land in, warns when that is not the current month or falls before your cut-over date, and says what to do when the period is closed. The general journal accepted a date three years back without a word.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Fixes a false alarm found in browser acceptance testing of 4.35.0. The opening balance screen warns when the same money was recorded twice, once from the treasury screen and once by the regularization. It kept warning after the duplicate had been reversed, claiming assets were overstated on books that were already correct. It was looking for the label an entry carries rather than what the accounts actually hold, and a correction passed as a manual entry carries no such label. It now reads the accounts, so any correction clears the warning on its own, and an account whose declaration was reversed can be filled in again.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Shows your real money accounts on the opening balance, one by one, instead of three generic boxes for cash, bank and mobile money. A factory holding four banks and two mobile money accounts had no way to say which one held what, and any account whose opening balance was already entered from the treasury screen was silently invited to be entered a second time — counting the same money twice. Accounts that already carry their opening balance are now shown locked, with where the figure came from, and only empty ones can be filled in. If a factory already recorded the same money twice, the screen names the accounts and the amount. The opening stock is also frozen the day it is entered: it was read from live stock, so every sale made before posting quietly changed what the opening balance claimed. And the post button now says what it is waiting for instead of staying grey.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Marks the charge accounts the software already posts to on its own, so you can see it before pointing an expense category at one. Cost of sales, salaries and depreciation are figures the software computes: mixing hand-typed expenses into them changes what your income statement says. The accounts stay selectable, because some of them legitimately take both.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Adds a Staff welfare account under Personnel Costs, for meals on shift, workshop water, transport or health cover. Until now those went to Other operating expenses, which is a catch-all and the wrong class: what a factory spends on its teams could not be read anywhere. Point an expense category at it to start using it.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Lets you open your own expense classes. The list was closed at ten hard-coded ones, so there was no way to record staff meals, canteen or welfare under their own account, and an account you created yourself could not be named anywhere. An expense category now points at any charge account in your chart. The expense itself no longer asks for an account: it takes the one its category names, so the budget and the ledger can no longer disagree.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Lets you say which account the money went through, for cash and mobile money too, not just bank transfers. Until now those payments always landed on the default account of their family, so a factory holding two mobile money accounts saw one operator debit the other, silently, until the next reconciliation. The engine already accepted the choice; the screens were not offering it.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Stops offering mobile money operators you do not have. The payment mode list was written by hand in thirteen files and named operators — Vodafone, which no longer exists in Ghana, and AirtelTigo — regardless of the accounts your company actually holds. An operator is not a way of paying: it is where the money is, which the account already says. Mobile Money is now one mode, and the account names the operator. Older records keep their original wording.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Gives a cheque held on hand a way out. A post-dated cheque could only be marked as cleared, so recording one that turned out to be worthless meant first declaring money that never arrived. You can now deposit it at the bank, or write it off with a reason if it will never be paid. Screens and server now read the same table, so a button is never offered for something that will be refused.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Stops a production order from handing over more finished goods than the materials it consumed, which was driving the work-in-progress account negative on the balance sheet while it still read Balanced. The accounting engine now refuses any entry that would take out of a stock account more value than it holds, the same rule it already applied to cash and bank accounts.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Corrects the reported revenue. An inventory count surplus or a stock adjustment increase was credited to Other revenue, so a stock correction was reported as turnover and taxed as profit. Both directions now post to a dedicated Inventory adjustment account, outside revenue.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Permissions now decide what you see, everywhere. Until now a handful of screens looked at your ROLE instead of your rights, so granting a permission changed nothing: - The dashboard picked its blocks from four hard-coded lists of roles. Two shipped roles — Quality Control and Methods/Workshop — were in none of them and always landed on a two-tile page, whatever you granted them. Each block is now shown when you hold the right its content needs, so a role that had no dashboard gets a correct one without anyone writing it. - Raw material and finished goods stock alerts were emptied based on your role. They now follow your access to those modules. - Regularization: granting the module opened the screen but no menu entry ever appeared, and the Export tick returned a refusal for anyone but the Regularization team. Both now obey the permission alone. Presets are unchanged, so no existing account gains or loses anything. Also in this version: the production order screen is faster — the quality position of each batch no longer costs one database query per batch, and the reads that do not depend on each other now run together. And a production order number is no longer consumed by a creation that gets refused, so the series stops showing gaps that nobody can explain later.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Two buttons change. First, Take charge is gone. An order no longer has to be "taken in charge" before the shop floor can work on it: starting a step, declaring a step or declaring a batch now moves the order to In progress on its own, and stamps its real start date on that fact rather than on a click that could come days earlier. Request materials, Declare batch and Close are offered as soon as the order is launched. Nothing is lost — the order still records when work actually began. Second, a routing can now say which step makes the product declarable. On a line such as mixing, cooking, bottling, labelling, the product exists at bottling: labelling adds no units. Tick "Product declarable here" on that step, and the check that guards batch declarations — and the line the batch is stamped with — follow it. Only one step can carry the tick. Routings that carry none keep working exactly as before: the last step is used, and the order screen now says so on the step itself, so the rule is visible before the refusal instead of after it.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A small fix found while testing the previous version. On the printed manufacturing file, a check that sets some units aside was written in green, like a batch that went through untouched — the screen already showed it in amber. The printed file now uses the same three readings as the screen: green when everything passed, amber for a partial sort, red for a rejection. The wording and the figures are unchanged.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Quality checks now say what they are. A check that judges a batch is called a Release check: it counts what was presented and what passed, and only what passed may be received into the store. A check that records a measurement — a temperature, a setting — is called a Parameter check, and the window states plainly that it releases nothing. Every screen now names the batch a check was recorded on, instead of labelling it "Whole order": with several batches on one order, you can finally tell which one was judged, including on the printed manufacturing file. A check that sets some units aside is no longer shown as "Passed": it reads "Partially passed", with the split beside it (presented, passed, reworkable, lost). The order is not blocked — sorting is normal shop-floor work — but the screen no longer says the batch went through untouched. The Batches to check queue stops asking for batches that are already in the store: units received without ever being checked are no longer counted as waiting for a check, so the list empties and stays worth reading. Finally, creating a repackaging order now shows the bulk product it will consume, how much the target quantity needs, and how much is in stock — before the order exists. Nothing leaves stock at creation: you still declare the outgoing bulk from the order itself, under Repackaging.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A small screen fix, found while testing the previous version. When a step refused to close because it finished far ahead of its planned time, the same paragraph appeared twice in the window: once as a warning above the reason box, and again in red at the bottom. Only the first one is shown now, right where you write the reason. Other refusals still appear at the bottom of the window, as before. Nothing else changes.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A step that finishes far ahead of its planned time now asks why. This is the change your teams will meet, so tell them before it surprises them. Until now nothing ever compared the time clocked on a step with the time the routing planned for it. Ten minutes planned, five reported, and the step closed in silence. What happens now: when you close a step and the production clocked on it is under half the planned time, the software refuses once and asks for a reason. It shows both figures - what was clocked and what was planned - so you can check you are not closing the wrong step, which is the mistake this catches most often. Write a line, press again, and it closes. Nothing is forbidden, nothing passes in silence. This is the same rule you already know from declaring more than the target, and it uses the same field. Half, and not a minute less. Asking for a reason at nine minutes instead of ten would teach everyone to type ok in the box, and a reason typed without thinking is worth nothing. Two cases are deliberately left alone. A step whose routing carries no planned time is never questioned, because there is nothing to compare it with. And a step that was never clocked at all - closed without anyone pressing Start - is not questioned either: it is not early, it is unmeasured, and your teams often record their steps after the fact. The reason is kept and shown on the step screen, under Finished well ahead. A reason that is demanded and then thrown away is a formality, not a record, and the next person would write anything in the box. One detail worth knowing: the time compared is the production time alone. Machine setup has been clocked separately since the previous version, and counting it here would let a step that was set up for a long while and made in three minutes look perfectly on time.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Your TV wall now goes red when a step runs past its planned time, and the shop floor lead gets a notification. This is the change your teams will notice, so it is worth a word before they meet it. Until now an overrun only tinted one tile and wrote Overrun on it. Nothing else happened: no full screen signal, no message, and TV mode hides the controls anyway, so whoever saw it could do nothing from that screen. A wall also wakes nobody at night. What happens now: when a running step passes the time planned for it, the TV wall shows a red banner naming the order, the step and the line it runs on, so anyone looking up knows where to walk. The banner clears itself after a few minutes and the tile keeps counting the overrun, exactly as before. At the same time, one notification goes to the shop floor lead and the production team - one per step, never repeated, because an alert that repeats stops being read. How long the red banner stays is yours to set, in Settings, under Overrun alert stays on screen for. It starts at 5 minutes. Set it to 0 and there is no red wall at all: the tile still shows the overrun and the notification still goes out. We set the length of the shout, never the truth of the figure. One more thing changed, and it is the reason the alert can work at all. The tile's timer used to count from the last Start. A step that was paused and resumed went back to zero and announced its full planned time again, so it could never be seen as overrunning. The timer now counts the time spent on the step's current phase - setup, or production - including what was clocked before the pause. The totals on the step screen and the real cost do not change: they already counted every minute. Nothing else moves: same rules, same rights, same figures. If your machines and routings carry no planned times, no step can overrun and nothing on this page will ever fire.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Machine setup is now clocked on its own, before production starts. If a machine carries a setup time, the first press of Start opens machine setup rather than production, and the step shows a new button, Setup done, which starts the production clock. This is the one change your teams will see, and it is worth telling them before they meet it. Why it matters: the timer used to start at Start and compare itself against the production time the routing plans for the step. Setting the machine up fell inside that, so a step that took twenty minutes to set up showed twenty minutes of overrun before a single unit had been made. The shop floor screen said Overrun, the step screen said the same, and neither was true. An alarm that is always wrong stops being read. The step screen now shows the two phases side by side, each with its own planned and clocked time, and the total underneath. The total has not changed: it is still every minute clocked on the step, setup included, so real cost, variance and OEE report exactly what they reported before. Nothing is subtracted, it is only split in two. On the live shop floor a tile that is setting up says so, and counts down against the machine's setup time instead of the routing's. On the order sheet the step reads setup instead of live, and offers the same Setup done button so nobody is stuck. The switch from setup to production is never automatic. Flipping it after the planned setup time would record a setup that lasted exactly as long as planned, which is a guess, and the point of this change is to measure what setup really costs your factory. Setup times are entered on each machine and have been for a long time. Until now only the workload and OEE calculations read them, both averaged, so no order screen, no shop floor tile and no timer ever mentioned them. If your machines have no setup time recorded, nothing changes for you at all: steps start straight into production exactly as before, and past clockings keep the meaning they had.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Buttons now say when the software is still working, instead of going quiet. On a production order sheet, pressing Start, Pause or Finish used to hand the button straight back while the page was still catching up. That page reloads a great deal - the real cost, the variance against standard, the quality position of every batch, the reworks and the by-products - and it can take a good twenty seconds. During all that time the button looked ready, nothing on screen moved, and operators pressed again believing the first press had not registered. The button now stays busy and reads Working, Starting or Pausing until the screen has actually caught up. Nothing else changes: same rules, same rights, same figures. This is only about not leaving a team in doubt about whether their gesture went through. Worth knowing for anyone who reported this: the screen was never showing wrong information. It was refreshing on its own, just slowly, and nothing said so.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A targeted trial, on one action only. Since a recent upgrade, some screens keep showing the state from before a change until the page is fully reloaded - declaring a manufacturing step is the clearest case. This version applies the fix the framework now provides for exactly that, and applies it to that one action, so it can be measured. If the screen stops lagging there while it still lags elsewhere, the cause is proven and the same fix will be rolled out everywhere. Nothing else changes.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A delivery now serves the production orders that were waiting for it. When raw material comes in - on a supplier invoice or against a purchase order - the software looks at which orders were waiting for that material, and sets it aside for them straight away. The storekeeper is told how many lines the delivery covered, so nobody has to watch a screen to find out. When the delivery does not cover everything, it serves the first order in full rather than giving everyone half. Two half-served lines are two lines still stopped; one served in full is a line that starts again. The order is the one your factory has already declared: order priority first, then whoever has been waiting longest. What is not covered simply keeps waiting for the next delivery. This writes nothing in the accounts and moves nothing out of stock. The material has arrived and is now reserved for named orders; it has not left the store. Issuing it stays what it has always been - a gesture someone performs and signs. Two limits worth knowing. Only real deliveries feed the queue: a stock adjustment is a correction of the count, not an arrival of goods, and a transfer moves what you already have - neither will start a production. And an order that has been closed or cancelled is never served, so a delivery in March cannot go to a job that ended in January. If no order is waiting, nothing at all happens - a factory with no production on hold will see no difference.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

READ THIS FIRST: from this version, a production step cannot be started until the store has released its material. This is the change your teams will notice, and it is what was asked for. When someone tries to start a step whose material has not been released, the software refuses and names what is missing - the material, the quantity still to release, and who to ask. The screen says it before the button is pressed, so nobody discovers it from a refusal. The store lifts it from Raw Material Stock, in the section added last version: one card per order, one line per material, a Release button. If the delivery is late, the storekeeper can still let production start short by ticking a box and writing why. Nothing here issues material or writes anything in the accounts - releasing and issuing stay two separate acts. Three things this control deliberately does NOT do, and they matter. It does not touch the orders you already have in progress: orders launched before you install this version carry no waiting list, so they are never held back - your shop floor on the day of the update carries on exactly as before. It does not hold a step that has already started: once a team has the material in hand, they can always finish and declare it, because locking someone inside a job they cannot close would be worse than the problem. And a step that consumes no material - drying, resting, a control - is never held at all. The control is applied by the server on both routes that open a step, starting the clock and declaring it, so there is no way round it by using the other button.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Corrects the previous version: some production orders never appeared on the store's release list. An order can become launched by three different routes, not one. Besides launching an existing order, you can create an order that is already launched with Launch now, and a confirmed client order creates its production orders already launched when the material is there. Only the first route was building the list of what the store is waiting for, so orders created through the other two were invisible to the storekeeper. Found on the test bench before anyone relied on it, and the two missing routes are now connected. Nothing else changes, and nothing is blocked: this still only lets the store release material.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The store now sees what production is waiting for, and can set it aside. Until now the raw material screen showed only the extra requests a workshop makes during a run, and only for orders set to manual issuing. What an order needs from the start - its recipe scaled to the quantity - appeared on no store screen at all: the storekeeper had to open the production order itself, a screen they may not even have access to. A new section at the top of Raw Material Stock lists every launched order waiting for material, one card per order, with each material, the step that will consume it, what is expected and what has already been set aside. Releasing is not issuing, and the screen says so. Releasing declares that the material is there and reserved for that order: nothing leaves stock, nothing is written in the accounts. Issuing stays exactly what it is today, further down the same page. If the material is short, the storekeeper can still let production start by ticking a box and writing why - it is a decision, so it is signed, and the line then reads Short, next delivery instead of pretending to be complete. Material can also go back to the store. A release never quietly disappears, not even when an order is cancelled: it is taken back by an explicit gesture, with a reason, and the workshop is notified - because a team that was told it could start must not discover the opposite by pressing a button. Nothing is blocked yet. This version lets the store release; it does not stop anyone from working. The control that holds a step until its material is released comes in the next version, so that no factory is ever held back before the screen to release exists.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Nothing changes in your daily work with this version, and that is deliberate. It lays the groundwork for a change your teams asked for: a production step will not be allowed to start until the store has declared its material released. That control is not switched on yet. This version only creates the list of what each order is waiting for, filled in when the order is launched, and it is not shown anywhere yet. The screen for the store, and the control itself, come next. Two things are worth knowing now. Releasing material will never be the same act as issuing it: releasing says the material is there and set aside for that order, and writes nothing in the accounts; issuing remains what it is today, a stock movement with its entry. And orders already launched when you install this version keep no waiting list, so they will never be held back by the control when it arrives - your work in progress on the day of the update carries on exactly as before. This version adds a table to the database.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The shop floor gets screens of its own. Until now, the steps of a production order were a nine-column table sitting seventh down the order sheet, below the materials, the batches and the store requests. A team that just wants to know where the work stands had to scroll through a page built for a manager, then read a nine-column row on a phone. There are now two screens, reached from Open the shop floor view on the order sheet. The first lists the steps in order and, for each one, what is expected next. The second shows a single step in full: the routing it comes from, the workshop and machine it runs on, the planned time against the time clocked, what the previous step passed on, the quality control the routing asks for and whether it has been recorded, and one large button for the gesture the situation calls for. Both are built for a tablet held while walking. Nothing about the rules changes. The same rights govern the same gestures, Finish still opens the declaration and asks what was produced, and the server still refuses a step whose quality control is missing. The new screens say what will block before you press, instead of letting you find out from a refusal. One correction travels with them, and it is the reason the screens are possible. A routing records which workshop each step runs in, and the copy taken when an order is created did not carry it over: a step knew its position, its name, its machine and its planned time, but not where it takes place. It does now. Orders created before this version keep an unknown workshop and the screen says so rather than guessing - a July order must not be made to claim it ran on a line that opened in August.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Three screens stop telling you something that is not true. A production order now closes by itself as soon as its last batch is received, and not only when a quality derogation is granted. That rule was written a fortnight ago but nothing ever triggered it: an order that was entirely produced, received, sold and paid for stayed Partially received, and the Production figure your management screen reads counts closed orders only - so it showed zero for work that had been done. Nothing else about closing changes: an order that is short of its target, or whose material does not match the recipe, still waits for a person to give the reason. The software only closes what is arithmetically complete. In a product's recipe window, the workshop column no longer shows a workshop that was never chosen. When a line had none, the list displayed the first one - so a factory could believe its recipe was split across workshops when it was not, and reopening the window to pick the workshop already displayed wrote nothing. The consequence was invisible and expensive: without that split, the product is not eligible for automatic material consumption, and the option was simply never offered. Lines with no workshop now read Not assigned, and choosing one saves it. If you have recipes made before today, it is worth reopening them to check. Finally, the routing is named where the work happens: on the order sheet, above the list of manufacturing steps, and on each tile of the live shop floor. A product can hold several routings, so steps called Preparation and Filling did not say which routing they came from. Orders created before that link existed, and products with no active routing, read No routing rather than showing a blank.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

READ THIS FIRST: the Finish button on a manufacturing step now opens the declaration window instead of closing the step on its own. It asks what was produced and rejected, then closes the step. This is the one change your teams will notice, and it is deliberate. Until now a step could be closed by two different buttons, and only one of them enforced the rules. Finish skipped all of them. Three things went wrong because of that. A step marked as a quality checkpoint could be closed with no control recorded, which unlocked the next step - Declare refused the very same thing on the very same step. On orders set to automatic material consumption, finishing a workshop did not deduct any material: the stock did not move, the real material cost stayed at zero, and the finished batch could then enter the store costing nothing, so its margin looked 100% better than it was. And the order's reject total was not recalculated. Declare always did all of this correctly, so the fix is to have one road instead of two. Two other corrections travel with it: a step can no longer be clocked on an order that was never launched, and the shop floor screens now refresh after a step is started, paused or declared - including the raw material store, which an automatic consumption empties. Nothing else changes: the same rules, the same rights, the same figures.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The permission matrix has moved out of the New user window. Creating an account now asks only for the person, their role and a temporary password: the role's defaults apply, and in most cases that is all you need. Fine-tuning one person's rights now has its own full-width page, reached from the shield icon on their row in Users & Roles. On that page each module lists only the rights that actually apply to it, and every tick box carries its own name - so there is no column heading to remember and no empty cells to read past. Groups fold away, a search box finds a module, and a banner says in one line how the account differs from its role's defaults, with a button to put it back. Nothing changed about what the rights DO: same rights, same rules (granting a right opens the module, closing a module removes all of its rights), and the same limit that you can only grant what you hold yourself. Saving still signs that person out, so their new rights load at their next sign-in.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

READ THIS FIRST: some permission tick boxes did nothing, and four document folders were open to everyone. The matrix showed a Delete column on Client Orders, Edit and Delete on Invoicing, Delete on Purchases - none of them commanded anything, because those gestures do not exist (an issued invoice is never edited or deleted; it is cancelled by a credit note). Those columns are gone. Unticking Export now really stops a document being downloaded: until now it only stopped the system e-mail being sent, while the PDF itself was governed by module access alone. A new right, 'Send to the customer or supplier', carries those e-mails. To be clear about what it is: the message is written into the software, nobody types or edits it, and the document travels as an attachment - the right governs TRIGGERING the send, not composing anything. It exists so you can let someone extract an invoice to check it without letting them send it out, because a PDF you print stays in the building and an e-mail does not come back. Nobody loses a document they could print before: the presets were widened to match what people were already doing. Finally, cheque advices, reminder letters, signed delivery proofs and supplier invoice scans were downloadable by any signed-in account, including a weighing operator; they now require their module.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

READ THIS FIRST: the weighbridge now checks WHO does what. Until now, anyone who could open the Weighbridge screen could also create a ticket, weigh it, validate it and cancel it - the tick boxes on that module controlled nothing at all. Two new rights appear in the permission matrix: Approve (validate a ticket) and Delete (cancel one). Weighing operators keep the right to validate, so a site with a single operator works exactly as before; they no longer cancel a validated ticket, the account manager does. A new line 'Weighbridge devices' now holds the right to declare and configure a scale, and it starts with exactly the people who had it before. Two other rights stop contradicting the matrix: Regularization can now be granted to someone who does not carry the regularization role, and a loan above the policy threshold is released by a new 'Loan approval (management)' right instead of being locked to the publisher account. Nothing changes for any existing account until you tick a box.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The reconciliation documents now speak the language of the account they describe. A cash count printed a statement written for a bank: it announced that every difference was named further down, where a cash box has none, it headed a section with the same title as the column just above it, and it labelled the shortage or surplus as an operation the statement shows. The paper now says what the screen says: nothing is missing and nothing is over, or how much the box is short by, with the count set out denomination by denomination so the addition can be redone months later. On both the screen and the document, a movement's reference is written once. It was appearing in its own column and again inside the description, because ledger descriptions carry their own reference and here a column already holds it. Correcting a statement or a count now shows a refusal once, inside the box where you are typing, instead of twice with one copy behind the shadow of the window. Nothing in your data changes with this version.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The printed reconciliation now reads like the screen it came from. On the statement of reconciliation, the table of timing differences was printing each movement's reference twice, once on its own and once inside a description that already contained it, and it was putting the movement's date under a column headed Kind. A fourth column, Posted, showed a dash on every line because a timing difference is never posted: that is what makes it a timing difference. The table now carries the same four columns as the screen, Date, Reference, Description and Amount, and the reference appears once. Nothing about the figures changes; this is the document saying plainly what it always meant. Nothing in your data changes with this version.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The software now looks for what explains a bank difference. When a reconciliation does not balance, the usual answer is that one movement, or two, or three, are sitting unticked and add up to exactly the amount missing. Finding them by eye on a statement of a few hundred lines takes a while. On the reconciliation screen, Search now does it: it reports the movements whose total is exactly the difference, and ticks them for you if you accept. It searches combinations of up to three movements, and it says so. If nothing is found it tells you what it looked at rather than concluding that no explanation exists, because a difference can also come from something the statement shows and your books do not, which belongs in a named difference instead. Nothing is sent anywhere to search: the movements are already on screen and the calculation is the same engine the rest of the reconciliation uses, so the answer is immediate and can never disagree with the figures above it. The other half of automatic matching, comparing your lines against the bank's own lines, is announced on the same screen as not yet available. It needs a statement imported from the bank, which the software does not read yet. Nothing in your data changes with this version.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The circularisation file, and a journal total that follows your search. At year end, an auditor asks a question the software could not answer: at this date, what proportion of your receivables did you ask to be confirmed, and what came back? Accounting, Confirmations now opens on a Circularisation file. Pick a cut-off date and you get, for customers and for suppliers, every party asked at that date, what your books said, what they said, the gap, and the answer, with disputes and silences listed first. Above the list are the four figures that decide whether the file is worth anything: how much of the balance was asked, how much came back confirmed, how much is in dispute, and how many parties did not answer. Asked and confirmed are shown separately on purpose, because they are not the same number and treating them as one flatters the file exactly where it is read. Nothing about a campaign is stored. The file is simply the confirmations carrying that cut-off date, so there is no list to keep up to date and nothing that can drift away from the confirmations themselves. It prints as a document, with signature lines. When a party does not answer, you can now record what was checked instead: subsequent payments, signed delivery notes, matched orders. Silence was already refused as an answer; it is now also possible to say what was done about it. Any non-response left without one is counted and named, on screen and on the printed file. Separately, on the general journal: the totals at the bottom now follow your search. They were showing the totals of the whole period while the line above them counted only the entries you had found, so filtering on an account and reading the total gave a figure that was not the one you were looking at. When a search is active, both totals are shown. This version adds one optional column to one existing table. No existing record changes.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

A balance confirmation is a document, and now it behaves like one on screen as well as in the database. Every confirmation a party has ever given is now listed under that party, folded away: the cut-off date, when it was asked, when it was answered, what your books said, what they said, and the answer. Until now only the latest one was visible anywhere. That mattered more than it sounds: a supplier could dispute a balance, and re-entering their statement would replace the disagreement with an agreement, on every screen, with nothing left to show it had ever happened. Two changes close that. A party can no longer have two confirmations at the same cut-off date. And when a confirmation was keyed wrong, you cancel it and say why: it stays in the history, struck through, with your name and your reason on it. It is never removed, because a document an auditor cannot read is not a document. Cancelling is only for a confirmation entered wrong. When it is your books that need correcting, correct them and open a new confirmation at a later date, as before. The old one stays exactly as the party gave it. The reconciliation table reads the latest confirmation that still stands, so cancelling one brings the previous verdict back rather than leaving a stale one in place. This version adds three optional columns to one existing table. No existing record changes, and no confirmation already on file changes state.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Ticking a bank statement is now usable on a real statement. Until now every tick went to the server, greyed out the whole list while it travelled, and rebuilt the page. On a statement of a few hundred lines, worked at the pace of one line a second, clicks were being dropped. That was worse than slow: a dropped tick left the line among the timing differences, the reconciliation no longer balanced, and you went looking for a difference that did not exist. The tick now registers immediately and is saved in the background, several at a time. The running verdict is recalculated on screen as you go, by the same engine the server uses, so the two sides can never tell you different things. If the server refuses something, the screen goes back to what it holds and says why, rather than showing a tick that was never recorded. A short line at the top of the list tells you whether everything is saved. You can also find a movement instead of scrolling to it: type an amount, a reference or a few words of the description. That is the real gesture in front of a statement, where you are looking for the line at 1,250.00 that the bank shows. Tick all and untick all are there too, and when a search is active they apply to what the search found, so you can tick a whole batch at once. Nothing in your data changes with this version.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

You can correct a reconciliation you are working on, and the balance you are shown is the one that will be used. The closing balance you take from a bank statement is a single number, typed once, and the whole reconciliation hangs on it. Until now it could not be changed. Two digits swapped, or a figure read from page one of a four-page statement, and the only way out was to abandon the reconciliation and tick every line again. A reconciliation that is not validated yet is now correctable: the balance, the cut-off date and the notes. What you have already ticked is untouched. Moving the cut-off date backwards drops the movements dated after it. If any of them are already ticked, the change is refused and the software says how many and how far back you would have to go, rather than quietly unticking your work. The balance announced when you open a reconciliation is now read at the cut-off date you chose, and it follows you when you change that date. Before, it was read across every entry on the account, post-dated ones included, and announced as today's figure; the reconciliation then worked from a different number, and nothing on screen explained the gap. For the same reason, the treasury screen and the bank accounts screen now show what you hold today rather than every entry recorded on the account. A cheque you have issued dated next week is recorded, but it is not money you hold. When such entries exist, the treasury screen says how much sits on them and why it is not counted, so that the figure never disagrees with your general ledger without a word. Correcting the balance of a reconciliation is written to the audit trail, as validating one already was. Nothing in your data changes with this version.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The cash count now speaks about cash. Counting a till is not reconciling a bank account, and the person doing it is usually not the accountant. Yet the top of the count screen announced a negative amount and told you to tick off what matched, on a screen where there is nothing to tick. It now says what it means: the box is short by an amount, or over by one, and the amount is stated positively because the words already carry which way it went. The lines about statements and timing differences are gone from the count screen and from its printed statement, because a cash box has neither. You can now break a count down by denomination. Enter the note or coin and how many of them, and the amount counted is added up for you rather than typed. It stays optional, but it is what stops a total from being guessed: a count written down denomination by denomination can be checked again weeks later, and it now appears on the printed statement so that it can be. A reconciliation or a count can no longer be dated in the future. A statement does not cover days that have not happened, and a till is not counted tomorrow, so a date ahead of today was almost always a slip on the month or the year. Balance confirmations already refused one; the two screens now agree. Two smaller things on the reconciliation and confirmation screens: the accounting tabs were being drawn twice, one above the other, and the empty confirmations list had a grammar mistake in it. Nothing in your data changes with this version.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Corrections found while re-reading the reconciliation work. A money account you had retired from service, but which still held a balance, appeared on no reconciliation screen at all. The money was still counted on your balance sheet, and nothing anywhere said it was no longer being checked. Such an account is now listed, marked as retired, and the screen tells you what to do with it: move the balance out, or put the account back in service to reconcile it. On the reconciliation table, a line whose module your company does not use no longer appears at all, and a line you do not have the right to open no longer offers a link that would quietly bounce you back to the dashboard. The heading counts the lines you actually have. The sentences that state a difference now carry your currency, as every other figure on screen does. Nothing in your data changes with this version.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Balance confirmations, for customers and for suppliers. A balance that only your own books agree with proves nothing. Two checks close that gap, and neither existed: asking a customer to confirm what he owes you, and comparing the statement a supplier sends against what your ledger says you owe him. They turned out to be the same check seen from two ends, so they share one screen: Accounting, Confirmations. For a customer, you pick a cut-off date and either email the statement straight away or record that it was printed and handed over. When the answer comes back, you record it: they agree, they disagree with the figure they state, or no answer came. For a supplier it is the other way round. Their statement is already in your hands, so you enter the balance it shows and the software tells you immediately whether the two sides agree. The figure the confirmation carries is frozen at the cut-off date, and it is read from the very statement the party receives. That matters: a confirmation that showed today's balance would drift after the party answered it, and you would be looking at his signature next to a number he never saw. For the same reason, a confirmation cannot be rewritten once it carries an answer. If a customer disputes a balance, you correct your books where they need correcting and open a new confirmation at a later date. The old one stays as it was. It is the one piece in the file that does not come from you, and it is the first thing an auditor asks for. The software will not let you record that someone agrees while carrying a different figure from yours. That is a disagreement, and it must be recorded as one. There are no automatic reminders. A balance confirmation is an audit step, not a mailing campaign, and nothing goes out in your name unless you send it. Likewise, no answer is never assumed from a delay: you say when a party did not answer, because only you know whether they called instead. The reconciliation table now lists all eight checks a factory runs, since these were the last two missing. A party who never answered counts there as never confirmed, not as agreeing. Silence is not agreement. This version adds one new, empty table to your database. Nothing existing is touched.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

All your reconciliations on one screen. A factory runs several checks that confront what the books say with something outside them: the bank statement, the cash box, the customer sub-ledger against its control account, the stock on the shelves, the asset register against the balance sheet. Most of those already existed in the software. Each of them lived behind its own screen, and a check you have to remember to open is a check nobody opens. The Reconciliation tab now opens on a table of all of them. For each one: whether it agrees today, in a sentence that carries the actual figures, when it was last done, and whether it is overdue. One banner at the top says how many need attention. Nothing on that screen is written in advance: every line calls the check that owns it and reports what it answered. Correct a difference in the ledger, reload, and the line goes green on its own. Because each line is read from the screen that owns it, the table cannot say one thing and the screen you click through to say another. How often an account should be reconciled is now yours to declare, account by account, on the same screen. A bank account defaults to every month and a cash box to every week, and you can set any of them to daily, weekly, monthly, quarterly, half-yearly or yearly. An account that has not been reconciled within its own rhythm is marked overdue. There is no delay fixed in the software: a factory that counts its cash every evening and one that counts it on Fridays should not get the same warning. One correction comes with this. On the Third-party Registry screen, the sentence at the top could read The registry matches the general ledger exactly while the detail below reported that a customer was read differently by the registry and by the screens. The check itself was right; only its headline was short-sighted. It now covers all three levels it verifies, and says which one is failing. What is not there yet: asking a customer to confirm his balance and following his answer, and confronting a supplier statement to your books. Both arrive next, and they will add themselves to this table. This version adds one optional column to your chart of accounts, for the rhythm above. Nothing existing is touched.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Bank reconciliation and cash counts. Until now the software could tell you what your books say an account holds. It could not tell you whether the bank agrees, or whether the money is actually in the box. Those are the two checks an accountant does first, and the two where a difference can sit unnoticed for months. They are the ones we had never built. Accounting now has a Reconciliation tab. It lists every money account you have, what your books say it holds today, when it was last reconciled, and how that went. An account nobody has ever reconciled says so, in as many words. For a bank account, you enter the closing balance from the statement and tick off the movements the statement shows. What you leave unticked is a timing difference, a cheque the payee has not presented or a deposit not yet credited, and the software works those out for you. You never enter them twice. If an account has few movements, you can work balance to balance instead and list the differences yourself. The choice is made per account, not once for the whole company. For a cash box, you enter what you counted. There is no timing difference in a cash box: the money is either there or it is not, and any gap is posted straight away, to its own account, with your explanation. A shortage and a surplus have separate accounts on purpose, so that a shortage in one month cannot quietly cancel a surplus in the next. The part that matters most is what happens to the difference. Bank charges, overdraft interest and interest received are posted to the ledger from the reconciliation screen itself, without going anywhere else. That is deliberate: a screen that shows you a difference and leaves you to deal with it elsewhere is a screen whose difference never gets dealt with. And a reconciliation cannot be validated while an operation is still waiting for its entry. Money a customer or a supplier moved is not posted from here. It belongs on the payments screen, which knows whose account to move. The reconciliation names it and sends you there. Doing a reconciliation and validating one are two separate rights, because the person who counts the cash should not be the one who signs off the count. On a small team the same person will hold both, and the software allows that; it simply does not assume it. Once validated, the ticks are frozen and the next reconciliation only works on what is left. Reopening a validated reconciliation is a third right, and it asks why. Every reconciliation prints as a statement of reconciliation: your balance on one side, theirs on the other, every difference named, and the two columns meeting. It is the first document an auditor asks for. Four new accounts appeared in your chart of accounts with the previous version and now have a use: Cash shortage, Cash surplus, Bank interest income, and Bank interest.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

READ THIS FIRST: three settings on the Treasury screen now actually command where your money lands. Until this version, the Treasury Configuration screen let you name a default cash account, a default bank account and a default Mobile Money account. Only the bank one was ever read. The other two were saved and then ignored by the software: a payment in cash or in Mobile Money always went to the account that shipped with your chart of accounts, whatever you had chosen. That is fixed. All three are now used. Two things follow from that, and you should know both. If you had set one of those defaults to something that is not a money account, it is ignored rather than obeyed. The same screen used to offer every asset account in the list, so it was possible to name Land as your default cash account. A setting like that would now have sent your cash takings to Land. The software checks that the account you named is an active treasury account of the right family, and falls back to the shipped account when it is not, exactly as before. Nothing moves without your knowing. And the three lists no longer offer anything but money accounts of the matching family. The cash list offers cash accounts, the bank list offers bank accounts, the Mobile Money list offers Mobile Money accounts. If a choice you had made has disappeared from a list, that choice was never being applied. This version also lays the groundwork for bank and cash reconciliation, which arrives next. Nothing of it is visible yet. Four accounts appear in your chart of accounts and stay empty until you use them: Cash shortage, Cash surplus, Bank interest income, and Bank interest, which already existed and now carries its purpose. Each has its own account on purpose. A cash shortage filed under miscellaneous expenses is a cash shortage nobody will ever find again, and a shortage in one month must not quietly cancel a surplus in the next. This version adds three tables to your database. They are new and empty; nothing existing is touched, and no data is rewritten.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Packaging you make yourself is now packaging. Some plants receive a raw material, rework it on site, and it becomes their own container: a drum, a jerrycan, a bucket. The software already let you do this. You create the item as a semi-finished product, give it a recipe of the material it is reworked from, produce it with a production order, and use it inside another product's recipe. All of that worked. What did not work is that it could never be packaging. When you opened a recipe, your in-house drum landed among the ingredients, next to the oil and the fragrance, and never in the Packaging section. Not because it does not wrap anything, but because that section asked the wrong question: it asked which materials are marked as packaging, rather than what wraps this product. An item that was not a purchased material was excluded before anyone could choose. You can now tick Packaging on a product category, exactly as you already do on a material category, and the items in it appear in the Packaging section of any recipe. The section itself is unchanged in every other way: an item marked as packaging is offered there and nowhere else, so you cannot dose it twice by accident. The sale format assistant follows. It offers your in-house packaging alongside the ones you buy, and counts its weight and its cost in what a pack weighs and costs. Without that, a pack would have carried its own drum in the recipe and ignored it in the format, and the weight would have been wrong in a way nobody would have looked for. Nothing in your existing recipes was touched, and nothing needed to be recalculated. Which section a line belongs to has never been stored: it is worked out from the marking, every time the screen opens. A line written last month will simply move to Packaging the day you mark its category. One thing to know about the in-house route: the item lives in your finished-goods store, not in your raw-material store. That is the consequence of making it with a production order, and the screens say so rather than letting you find out at stocktaking.

Your products now remember what they actually yield. Until now the software could tell you what one order had produced, but not whether that was normal. A run at 78 percent looked exactly like a run at 98 percent: a number with nothing to compare it to. The product page now carries a yield history. It shows four figures rather than one, because an average on its own misleads. A product averaging 95 percent may be hiding a run at 60 and another at 130, and it is that spread the production manager needs to see. So you get the average, the lowest, the highest, and the number of completed orders it rests on. Two orders do not make a habit, and the screen says so rather than hiding behind a threshold. The declared yield and the yield released by quality are kept apart and never merged. A plant that produces 120 and releases only 90 has a problem that a single average would make invisible, and merging the two would erase exactly what the quality team does. Since a product may have several routings, each one gets its own history. A single average across two different routings describes neither of them, and the routing is precisely what decides the yield: its steps, its machines, its scrap. An order now records which routing produced it, at the moment it is created, and that record never changes. What does not count: an order that was closed early with a reason, and an order that was cancelled. A run of 3000 stopped at 40 did not yield 1.3 percent; it did not happen. Counting it would wreck the average, and an average nobody trusts stops being read. The figures are recalculated every time, never stored, so a quality check recorded after an order was closed corrects the history instead of leaving it wrong. The screen tells you which order it goes up to, and when that order closed. Finally, while an order is running, its screen tells you what this product usually yields. It informs, it never blocks, and it appears where the workshop can still act on it.

A missing ingredient can no longer hide behind the ones that were issued. When you close a production order, the software compares what the recipe calls for against what the store actually issued, and asks for a reason when the two do not match. That check has been in place for a long time, and it worked on a single number: the total. A total is weighted by quantities, and this is where it let something through. Take a recipe for a hundred units: a hundred kilos of base and three kilos of fragrance. Issue the base, issue no fragrance at all, and the coverage still comes out at ninety-seven percent, above the five percent tolerance. The order closed itself, in silence, with every gram of fragrance missing. The heavier the rest of the formula, the more completely a light ingredient could vanish. The reason is worth stating plainly: how much an ingredient weighs has nothing to do with how much it matters. In a cosmetics plant, the most expensive and most critical ingredient is usually the one dosed in the smallest amount. The check now looks at each line as well as the total, and either one can call for a reason. The detail was already being calculated for every material; it simply was never read. And the message now names what is missing instead of quoting a percentage: it tells you that nothing was issued for Lavender Oil, or that only fifty percent of it went out, and it distinguishes the two, because a material that was never requested and a material that was under-served are not fixed by the same person. It names three at most and counts the rest. One change to expect: orders that used to close on their own, while one ingredient was entirely missing, will now ask for a reason. That is the point of the correction, but it will be noticed on the floor. Nothing else moves. Issuing more of a material than the recipe asks for is still not flagged, an order that beats its target still closes cleanly, and an order that issued nothing at all still gets the stronger warning it always had.

Your recipes can dose in grams what your store holds in kilos, and the figures finally follow. A recipe line has always carried its own unit: you may dose 500 g of a material held in kilos, and the software refuses a unit it could not convert. It promised the conversion, and it kept that promise in five places out of eight. The three that did not keep it were not failing to convert; they were never reading the unit at all. The consequences were these. The estimated materials of a new order took the recipe figure as it stood, so 500 g became 500 kg and the planned material cost of the order came out a thousand times too high, which the screen then reported as a spectacular saving. At closing, the material check compared a need read in grams against what the store had issued in kilos, found one tenth of one percent of coverage, refused to close the order and asked the workshop to justify a shortfall that did not exist. And the margin by product screen multiplied grams by a price per kilo, which made every affected product look as though it were sold far below cost. Nothing in your stock was wrong: what left the store is what your storekeeper entered and validated. What was wrong was the planning, the standard cost and the closing check. They are now right, and they correct themselves from today onward without touching a single existing record. Requesting materials also stops being a guess. Next to the quantity you now choose the unit, restricted to units of the same kind as the one the material is held in, and the screen shows you underneath exactly what will be issued: 500 g = 0.5 kg. A material with only one possible unit simply displays it. Nothing is recorded until you can see what it will be.

A run that beats its target is no longer treated as a mistake. Until now, an order for 100 that actually produced 110 could not be recorded. The software answered that you cannot declare more than the remaining quantity, and the workshop had two choices: declare 100 and lose ten units, or open a second order for a production that never happened twice. Both are wrong, and the second one is worse, because it invents a run. You can now declare the 110. The software asks you why, once, above a margin of five percent, and it shows you the numbers before you answer: what you are declaring, what was planned, and the difference. That question is not a reproach; it is the last guard against a typing mistake, since 1000 typed instead of 100 looks exactly like a very good day until someone reads the figure. Within the five percent margin nothing is asked at all, because a reason you fill in without reading protects no one. The reason you give is kept with the batch. At closing, the order says plainly that it yielded 110 percent of its target, and explains what that means for your costs: the extra units used no extra material, so they enter stock at a lower unit cost and lift the margin. If it happens on every run, the recipe's expected yield is the thing to look at. The material check at closing was corrected in the same movement. It compared what the recipe calls for against a quantity that could exceed the target, and asked you to justify a material shortfall that did not exist. It now measures the need against the target, so beating the target no longer looks like missing material.

A pack now knows what it contains, and what that costs. Open the recipe of a sale format you created, a pack of 12 for instance, and until now you saw a component line with a quantity of 12 in front of nothing at all. The line was not empty in reality: it pointed at your bottle, correctly, since the day the assistant wrote it. The screen simply refused to show it, because the list of products it offered as components held semi-finished items only, and a bottle is a finished product. The consequence was on the money. The standard cost of that pack counted its carton and its caps and nothing else, so a pack of 12 bottles came out at 9.50 instead of 40.10. The screen even added that some materials had no price, which pointed the finger at your materials while the gap was somewhere else entirely. The rule is now the simple one: a product may be a component of another product. Semi-finished still means what it always meant, an item you do not sell, and it no longer decides who may enter a recipe. Your existing recipes are untouched, nothing was recalculated in your data; what changes is that the figures on screen are now the right ones, and that the component list offers every product. Two things stay as they were. A product still cannot be a component of itself, the software refuses it. And the little badge on the line now says PF or SF depending on what you picked, instead of claiming SF on a finished product.

Your packaging is no longer given away with the pack. When you build a sale format, a pack of 12, a drum, a bag, the assistant suggests a catalog price for it. Until now that suggestion was the base price multiplied by the quantity, and nothing else. A pack of 12 bottles at 14.00 was suggested at 168.00 whether you had added a carton, a stretch film and a label to it, or nothing at all. The packaging you had just selected cost you money and was billed at zero, on every single pack, and the screen never let you see it. The suggested price now adds what the packaging costs: 12 x 14.00 plus 3.50 of carton gives 171.50, and the line under the field spells the sum out so nobody has to wonder where the number came from. It remains a suggestion, editable as before: the software gives you a starting point that does not lose money, and you decide whether the pack sells for less or for more. One point we want to be plain about: the packaging is added at cost, without margin. The base price already carries its own margin, the carton does not carry any. That is a deliberate choice, and the field is yours to raise. The pack's weight was wrong in the same place, and in the opposite way. The line under the weight field claimed packaging was included; it never was, because the packaging weights were not being passed to the calculation at all. A pack of 12 one-kilo bottles with a 0.2 kg container announced 12 kg instead of 12.2. The weight now counts the packaging, and says how much of it it counted. And when something cannot be counted, the screen says so instead of staying silent. A packaging item with no purchase price on file, or no weight on file, is left out of the total and named, rather than quietly counted as zero.

Three corrections, found by running a real repackaging order from end to end. A repackaging order was showing two different costs on the same screen. The Real production cost panel counted the bulk product the order had consumed; the Planned vs actual panel did not, and announced an actual cost of 0.00 right underneath it. The Cost var. column on the order list had the same blind spot. Both now read the same list of what an order has consumed, raw materials and bulk together. The manufacturing dossier, which printed an empty material list for a repackaging order, now prints the bulk that order used. Where an order consumed a bulk source, the material variance is no longer computed at all, and the screen says why. That half has no plan: a recipe's bulk component cannot be typed into the estimated materials of an order. Comparing a complete actual against a half plan would show a permanent overrun that does not exist. We only compare what has two sides. A batch your quality team has judged can no longer enter stock in full. Until now the release cap applied only when the product's routing carried a quality checkpoint, so a product without a routing was free: a batch of 300 declared, 270 passed, 20 sent for rework and 10 written off could still be received at 300, rework and write-off included. From now on a batch that has never been checked stays free, and a batch that has been checked is bounded by that check. Nothing blocks for a missing check where none was required: that guarantee does not move. Finally, two smaller things on the same screens. Quantities in litres now show the L your catalogue shows, where the batch follow-up tabs were writing a lower case l. And the order creation screen no longer announces pre-filled materials above an empty list when the recipe carries a bulk source and nothing else.

Quality control finally has its own workspace, and its own role. Your quality agents told us their menu made them travel. They were right, and the reason was worse than it looked: there are two different checks in the software wearing the same name. The one on the Quality Control screen measures criteria and releases nothing. The one that declares quantities — passed, reworkable, lost — is the check the store waits on before a batch can be received, and it could only be reached from inside a production order. The agent had to know the order number, open it, find the batch line in a ten-column table, and click. His screen told him he had work; it did not let him do it. The Quality Control screen now carries five sections. Batches to check is new, and it is the important one: every batch with units still awaiting the releasing check, with the order, the product, the team and how much is left, and the check itself one click away. Pending checks is unchanged. Blocking rejections now carries the derogation button that used to live only on the order. Awaiting rework is new: the units a check judged recoverable and that nobody has sent back yet. History is unchanged. Rework and reprocessing are now two clearly separate things, and the words no longer overlap. Sending recoverable finished units back into production is rework; it happens on their own production order. Rejected raw material is a scrap declaration and goes to reprocessing, a different circuit for a different material. The panel on the production order screen, which used to be titled Reprocessing, is now titled Rework — the same units, an honest name. Alongside the workspace, a Quality Control role now exists, and you create an account with it like any other. It records the checks, sends recoverable units to rework, and declares a scrap. Two things it deliberately cannot do: it cannot receive into stock what it has just judged, because the person who judges a batch should not be the person who takes it in; and it cannot grant the derogation that lifts a quality block, because the person who rejected a batch should not be able to authorise themselves past their own rejection. Both stay with the account manager and methods / workshop. Nothing is taken away from anyone. The production team and methods / workshop keep the right to record a check, so a shop supervisor still checks without changing screens, and every figure on the order screen is the same figure as before. If your factory wants the controller to hold the derogation anyway, tick the box in the permissions matrix: that is exactly what a separate right is for. The production order screen has been tidied up. Your production agents told us it carried too much at once, and they were right: it was trying to be the workstation of five trades. Its four export buttons took the first four places the eye meets, ahead of Launch and Declare batch, while they are the buttons one presses least often. They now sit together under a Documents button, and each one says what it contains, where the fourth used to be called simply Excel, a file format, which told nobody anything. Further down, three panels that stacked across the full width, repackaging, rework and by-products, now share a single tabbed section called Batch follow-ups, and a tab your order has nothing to show in does not appear at all. Nothing is hidden. No document was dropped, no button left the normal path, and every figure is the figure it was. One thing genuinely moves house: sending set-aside units back for rework now belongs to the quality control workspace, which sees them across every order at once, and the order screen keeps a one-line summary and the link that takes you there. If your account does not open that workspace, the button stays on the order, exactly where it has always been.

A product can now hold several routings, and only one of them is active. Your production team asked what happens if they create several routings for the same product. The honest answer was bad: the software replaced the first one, steps and all, without a word. Someone who wanted to keep the night line's routing alongside the day line's lost the first at the moment they typed the second, and only found out by looking for it. A product can now hold as many routings as your process needs. Each one carries a name you choose, because a reference like GAM-0007 tells nobody which one is the night line. One of them is active, and the active one is the only one production orders copy. Activating another archives the one that was active before: it keeps its steps, it stays in the list, and it can be activated again later. Nothing is destroyed any more. The routings screen now shows, for each product, the name of its active routing and how many routings it holds. Opening a product lists them all, active first, drafts next, archived last. The editor tells you, before you save, which routing you are about to archive. Orders already launched do not move. A production order copies the steps at the moment it is created and keeps them; changing or replacing a routing never rewrites what a past order did. Recipes are unchanged: a product still has exactly one. The way through the workshop can change without the materials changing, and we did not want to open both at once.

The general journal and the account mappings can now be printed, and the journal finally has a period. Your accountant asked for two printable documents. Both are now one click away, as a PDF that opens in a tab. The general journal screen used to show "the last 300 entries", all periods mixed together, with nothing but a text search. It was a window whose edge nobody knew: past three hundred entries the older ones simply vanished, and no message said so. The screen now carries the same period selector as the balance sheet, the income statement and the cash flow statement, with the same shortcuts for month, quarter and year. If a period holds more entries than the screen shows, the screen says so instead of cutting in silence. The printed journal takes that period, reads in the order the entries were written rather than newest first, and shows every entry with its account lines, then the debit total, the credit total and whether the two agree. It has no ceiling: a period holding a thousand entries prints a thousand. A document of record that quietly leaves something out would be worse than no document at all. The account mappings print as a reference sheet, the one you put on the table when someone asks how a credit sale is posted. It names the chart of accounts it was printed from, because the account numbers depend entirely on it and two sheets printed on different charts would otherwise be impossible to tell apart. Neither document is offered as a spreadsheet, and that is deliberate. A journal is read, filed and presented; it is not reworked in Excel. Every other report keeps both formats.

Erasing all data works again, and the screen no longer promises a safety backup it cannot take. Wiping an installation to start over ended on a technical message and did nothing: "Safety backup failed, erase aborted: Could not run pg_dump". The same wall stopped the Create backup button on a factory server, which nobody had noticed. Before erasing anything, the software takes a backup of the database. That backup is made by the standard PostgreSQL tool. On a factory server the application package did not carry that tool, although the software believed it did and offered both buttons on that belief. The package now carries it, so the safety backup and the on-demand backup both work. On a hosted installation the tool cannot be installed at all: the platform does not allow it, and there the backups are produced by the background service instead. Rather than failing on a wall it cannot climb, the erase screen now says so plainly, shows you the most recent backup available and how old it is, and asks you to confirm in writing that you accept erasing without a fresh one. That confirmation appears only where it means something; where the software can take the backup, nothing changes.

Receiving raw material no longer stops on a hidden time limit, a user account fills itself in from the employee you name, and the recapture screen lets you pick any customer or supplier you already have. Three things, all reported from a factory that is using the software today. Receiving goods against a validated supplier invoice could end on a message carrying a reference to quote, with nothing saved. The quantities on screen were right and the storekeeper had done nothing wrong. A reception is written in one single piece, so that the goods entering stock, the lot they carry and the accounting entry can never exist without one another, and that piece had a budget of five seconds inherited from the database library we use. One received line alone needs about fifteen exchanges with the database, and when the database does not sit next to the application, five seconds run out before the accounting entry is written. The budget is now sixty seconds, for every operation of that kind. The annual carry forward, payroll and bulk import ran exactly the same risk, silently, with the same unreadable message. Creating a user account: naming the employee now fills in the full name, the phone number and the email address that HR already holds. All three stay editable, because an account needs an email address where an employee file does not always carry one. Retyping what HR holds is how two spellings of the same name, and two numbers for the same person, end up in the software. In Regularization, the two forms that record what a customer owes you and what you owe a supplier only offered the parties created just above them, in the same screen. A customer loaded through the bulk import, or one you already work with, could not be found there, and the only way out was to create a second record for the same company, which cuts that company's ageing balance in two for good. Both forms now offer your whole directory, with a search box, and the lists of parties carried over keep showing exactly what the recapture created.

The Live indicator in the top bar now lights up on hosted installations, and when it does not, it tells you why. It had never worked on either of the two installations that are online. The cause was in our packaging, not in your setup. The realtime bus can be protected by a shared token: the deployment template asks you to fill it in twice, once for the bus and once for the browser. The bus received its copy, the browser never did. A value of that kind has to be built into the JavaScript the browser downloads, and ours was only supplied when the container started, which is far too late. So the bus started demanding a token, every browser presented none, and every connection was refused. The software said nothing at all: the indicator simply stayed dark, which reads like a feature that was never built rather than a door that is locked. Three things changed. The token now reaches the browser, so a protected bus works. The indicator now reports what it tried: hover it and you see the address of the bus and, if the connection was refused, the exact reason. And a check now reads our own browser code, finds every value it needs at build time, and refuses to ship if the deployment does not carry it. That check immediately found a third value missing, which nobody had noticed. If your installation is hosted, rebuild the application after this update so the token reaches the browser. On a factory server on your own network, nothing changes.

The spreadsheet you use to load customers, suppliers, materials and products now reads in English, carries every field the item form carries, and tells you what already exists before it creates anything. Four things changed, and each one came from watching what a factory actually does with that file. The column headings are in English. They used to be our internal field names, half French, in camel case: designation, categoryName, unite, coutStandard, poidsEquivalentKg, tauxRecuperationAttendu. That was the only part of the software that had never been translated, because it is not a screen, and it is precisely the part you handle outside the software with nobody to help you. Headings now read Designation, Category, Unit, Reference cost, Equivalent weight (kg). A file you already prepared still imports: the old names are still accepted. The closed lists are now drop-downs, filled from your own data at the moment you download the template. Nothing used to tell you that the unit is written pc and not pcs, piece or unit; you found out row by row, after the fact. A Reference sheet lists your units, your customer types and your existing categories, and the columns that must hold one of those values offer them. Categories are offered without being forced, because the import still creates a category you have not used yet. Six fields that existed on the item form were missing from the file, so you had to reopen every imported item to fill them in by hand. The wholesale price and its own floor, delivered two days ago, were among them. So were shelf life, expiry warning, quarantine, returnable packaging and its deposit, and whether a product is finished or semi-finished. They are all in the file now, and the file refuses exactly what the screen refuses: a wholesale floor above the wholesale price is rejected before import rather than blocking every later order from that wholesaler. And the preview now says, line by line, New or Already exists. Importing a corrected file a second time is the normal thing to do, not the exception, and until now it created every record again: two hundred duplicate customers, with no way to remove them in bulk. Existing lines are skipped, the button says how many will actually be created, and lines duplicated inside the file itself are caught too. Skipping is not updating: nothing you already have is overwritten. Finally, the recapture agent can now use the import from the recapture screen itself, at the top, where it belongs: opening stock and past invoices can only be recorded against items and parties that already exist.

Lot codes are now written by the software, and cannot collide between a raw material and a finished product. Every item carries a short code that is printed on all of its lots: the VICT of VICT260818-A1. Until now you typed it, with the screen suggesting one from the item name. That worked while somebody created items one at a time. It stopped working the moment a spreadsheet loaded two hundred of them at once, because the spreadsheet had no column for it: those two hundred items arrived with no code, and all their lots fell back to the old numbering LOT-PF-2608-00042, which says nothing about which product, which day, which team or which line. The software now assigns the code, on every path: the item form, a spreadsheet import, and a change to an existing item. You can still type your own, and it is worth doing when your factory already uses codes it knows. What this release really fixes is the collision. Nothing prevented a raw material and a finished product from both holding VICT, and that is the ordinary case, since a factory names its material and its product after the same range. The lots of both then ran in one series: the material's delivery came out as VICT260818 and the finished product's entry as VICT260818-02, which reads like the material's second lot. No error appeared anywhere, and on the day you had to trace a lot back, you would follow the wrong chain. Codes are now checked against both catalogues at once, under a lock, so two people creating items at the same second cannot be handed the same one. In Settings you choose the alphabet: letters and digits, letters only, or digits only. Letters and digits is the default, because the code keeps a meaning: it is derived from the item name, so an operator reading a label with a box in their arms recognises the product without opening the software. Digits only is offered for factories that already use numeric codes, and the screen states what it costs before you pick it: 9 999 items in total, and a lot that reads 0042260818-A1. Changing the format renumbers nothing, and lots already issued keep their reference, which may be printed on a label at a customer's site. Items that have no code are listed on both catalogue screens with a button to give them one, so nothing changes in your workshop until you decide it does.

The spreadsheet template you download to load customers, suppliers, materials and products no longer carries a sample row that could be imported by mistake. Until this release the template opened on a single sheet holding the column headings and, just below them, one filled-in example. You typed your own rows underneath and sent the file back. The example went with it, and it was a perfectly valid row, so it was created: a customer called Acme Stores, a supplier called Global Resins Ltd, a material called HDPE Resin, a product called Victory Bowl 1L. One column made it worse. The reference column showed the words "auto if empty" as its example. That is a sentence, not a value, and the field accepted it, so the product was created with "auto if empty" as its reference. That reference then printed on delivery notes, and importing the same template a second time failed with a message nobody could act on. The template now has two sheets. The first one, the only one the import reads, carries nothing but its headings. The example moved to a second sheet named Example, where it can still be looked at and can no longer be sent back. What a column means is now attached to its heading as a comment rather than written into a cell, because a sentence sitting in a cell eventually gets imported as a value. The heading row also stays visible while you scroll, which matters when you paste two hundred lines. If you already imported a template without clearing the sample row, look for those four names in your lists and for any article whose reference reads "auto if empty", and delete them before you go further.

Recording what a customer already owed you, when you do not have their old invoices, now takes three fields. Most factories arriving on this software know what each customer owes, and know it as a single figure rather than as a stack of invoices. Until now the only way in was to enter each historical invoice with its original number. That is right when you have them, and unrealistic when you do not. The recapture screen now opens with a quick entry: pick the party, type the amount, say since when. The same thing exists in the other direction, for what you owe a supplier. Their old reference is asked for but optional, and it is worth giving when you have it, because that is the number the party will quote on the phone. What matters is what those three fields produce. They do not store a figure somewhere; they build a real opening document, dated, numbered, with a due date worked out from the payment terms. That is what lets the ageing report age it, the statement print it, a part payment be applied to it, and a reminder quote a number. A figure on its own can do none of those, and a balance that cannot be explained line by line is how two screens end up disagreeing about the same customer. Related fix in the same release: opening invoices entered the detailed way carried no due date at all. The ageing report fell back on the issue date and reminders had nothing to work from, so a carried-over receivable was aged wrongly from the first morning. They now carry a due date like every other invoice. The date stays filled in between two entries, since a recapture is usually done party after party at the same cut-off.

Posting an opening balance now stops and shows you what it is about to write. The opening entry sets your starting position, and its last line is opening equity: whatever does not add up lands there. That is normal accounting, but it has a consequence nobody was warned about. A typing mistake cannot unbalance this entry. It simply becomes equity. Twenty thousand keyed instead of two thousand on one customer went through without a word, leaving eighteen thousand of a receivable that does not exist facing eighteen thousand of equity that was never invested. The entry balanced. The balance sheet balanced. And it was wrong. Before posting, the screen now shows the opening equity figure in large type, with the assets and payables it comes from, and underneath it the full breakdown: every carried-over customer with what they owe, every supplier with what is owed to them, largest first. A wrong amount stands out beside the name it belongs to, which is where it can actually be recognised; it never stands out inside a total. To post, the agent types the equity figure rather than ticking a box. A box is ticked without reading. Copying a number forces you to look at it, and this figure is the only check the factory can make on its own recapture: if it does not resemble what the business owns, one of the carried-over amounts is wrong. The server recalculates the figure and compares, so the check cannot be skipped by any other route. The screen also states plain facts where they exist, without judging: amounts that name no customer or supplier record, an opening equity that comes out negative, or a recapture where nobody owes anything at all. It sets no thresholds and calls nothing abnormal. Deciding that belongs to whoever knows the business.

Historical data recapture now feeds the customer and supplier sub-ledger, and the last gap in the reconciliation is closed. When a factory starts on this software, an agent records the invoices its customers still owe and the debts it still owes its suppliers, then posts one opening balance. Until this release that opening entry moved the collective customer account and the collective supplier account with a single figure each, for all parties at once, and nothing was written into the party-by-party sub-ledger. A factory opening with 40,000 of receivables therefore started with a collective account saying 40,000 and a sub-ledger saying nothing: the statement of a carried-over customer was empty while the general ledger insisted the money was owed. The opening balance now breaks its figures down customer by customer and supplier by supplier. The amounts are exactly the same, nothing moves in your accounts; what changes is that every carried-over party now has its opening line on its own statement, its own ageing, and its own reminder. The daily reconciliation between the sub-ledger and the general ledger, which had to be told to ignore the recapture module, no longer needs the exemption. That list of exempted modules is now empty, and the warning it printed on the reconciliation screen disappears on its own. One case is handled openly rather than quietly. A carried-over debt that names no supplier record cannot produce a party line, but its amount is real and stays in the opening balance and in the general ledger. The entry is then marked as having an unidentified party, so the reconciliation counts it and names it instead of hiding it. If you have already completed a recapture on an earlier version, this release does not rewrite it: entries are never rewritten. Ask us before starting a new one.

You can now sell at a wholesale price, and the software works out on its own who gets it. Each item can carry a wholesale price next to its catalog price, with its own minimum. It is set per item, which means per pack size: three sizes are three records, and each one has its own wholesale price. There is nothing to tick when taking an order. Under Settings you say which client types buy at that price. Wholesaler is ticked to start with; supermarkets and modern trade accounts often negotiate the same terms, so tick them too if that is your case. From then on, choosing such a client on an order prices every line from the wholesale price, the screen says so in plain words, and the order carries a WHS tag in your list. Prices stay editable exactly as before. We deliberately did not add a checkbox on the order. A box is something a person has to remember, and the day it is forgotten a wholesaler is invoiced at retail without anyone seeing it before the complaint. A wholesaler is a wholesaler: it belongs on the customer record, not on every order. An item with no wholesale price falls back to its catalog price, and the screen says which items did, both at the top of the lines and on the line itself. Falling back in silence is exactly what would let a wholesaler be charged full price unnoticed. The two minimum prices are kept apart, and this matters. If the wholesale price had to clear the ordinary minimum, a wholesale price of 1,200 against an ordinary minimum of 1,400 would see every wholesale order refused by a guard written for excessive discounts. Each price list has its own floor. The tariff is frozen on the order and on the invoice the moment they are created. Reclassifying a customer months later does not rewrite what was already agreed with them, and a credit note carries the tariff of the invoice it credits. This release changes the database, so it is applied with the usual backup beforehand.

The software now tells you when an item runs low, instead of waiting for you to go and look. Until this release, low stock and out of stock were shown on the dashboard and on the stock screens, and nowhere else. Nothing reached you: you had to think of opening the screen, which is exactly what nobody does on a busy day. From now on a daily sweep, every morning at 07:05, puts the alert in your notification bell, for raw materials and for finished goods alike. Only the items you asked to be watched are watched. An item is watched when its alert threshold is set to something above zero on its record; left at zero, the item is simply not monitored. This is deliberate: on a new installation every article sits at zero stock with no threshold, and alerting on all of them would have filled your bell on the very first morning. You will not be told twice for the same thing. An item that stays below its threshold for three weeks raises one alert, not twenty one. You are told again only when the situation gets worse, when an item that was low becomes empty, or when it improves without recovering, when an empty item is partly restocked. Once the item is back above its threshold the alert clears itself, quietly: being told that all is well is noise, and noise is what makes people switch a bell off. Each alert carries the numbers, not an adjective: how much is left, and what the threshold was, so it can be judged from a phone without opening anything. Raw material alerts go to the raw material manager and the account manager, the people who can order more. Finished goods alerts go to the finished goods storekeeper and the account manager. Finished goods are judged on their free quantity rather than their total, so stock already promised to an order does not hide a shortage from the next one. One thing worth knowing if you compare screens: the alert recalculates the level rather than reading the status stored on the stock record. That stored status is only refreshed when stock moves, so an item whose threshold you changed and which has not moved since could show as normal on a screen while the alert correctly reports it as low. The alert is the one that is right. This release changes the database, so it is applied with the usual backup beforehand.

Your customer records gain four new types and a country. Until now a customer could only be an individual, a reseller or a wholesaler. You can now also record a retailer, a supermarket, an online customer and a modern trade account. Nothing changes for the customers you already have: they keep the type you gave them, and the three original types keep their meaning. The new types appear everywhere the old ones did, including the customer directory export and the bulk import from a spreadsheet. The online type is there for what comes next. It has no special behaviour today; it exists so that a factory selling through a website can already say so, before we connect the software to an online store or an online payment tool. A customer can now carry a country, and the field is optional on purpose. Left empty it means the country of your own company, which is what it is for almost every customer of a factory that does not export, so there is nothing to fill in for them. The list is the same one used to set up your company, and the country only shows on the customer record once you have actually chosen one: a blank line saying nothing would read like a missing detail rather than an answer. This release changes the database, so it is applied with the usual backup beforehand.

READ THIS FIRST: the software now refuses to pay out money an account does not hold. A payment, an expense or a salary run that would take more than the cash box, the bank account or the mobile money account contains is declined, and the refusal says exactly how much is missing. If one of your accounts already stands below zero, expect that refusal on your first payment after the update: it is not a fault. The remedy is on the same Treasury screen, where you now declare the funds your accounts already hold, with the reason. It is the first thing to do after installing this version, and it takes a minute. A second refusal, on the payroll screen: a salary payment can no longer be dated before the payroll charge it settles. Paying on the eleventh a payroll recognised on the twenty eighth left salaries payable carrying a negative balance between those two dates, which reads on a balance sheet as money your staff owes you. The refusal names both dates, so you know what to change. If you genuinely paid before the payroll was recognised, date the payment on the day it was recognised. Your balance sheet now answers the question a banker asks. Assets and liabilities are split into current and non current, so what falls due within the year stands apart from what does not, and the screen states your working capital and your current ratio underneath. The total is the one you had before, grouped differently: a regrouping neither gains nor loses a penny. Where an amount had to be assumed rather than known, the screen says so instead of presenting a figure as certain. Every account follows its group on its own, and you can move a single account elsewhere if your accountant classes it differently. The inventory total also stops leaving out inbound freight capitalised into stock. Buying a machine no longer means calling it a service. A purchase line can now be declared a fixed asset: it goes to an asset account instead of an expense account, so it stops weighing on your result and on your budget the day the invoice is validated, and it no longer sits in the receiving queue waiting for goods that will never be unloaded there. Such a machine is then capitalised either from the expense that paid for it or straight from the supplier invoice. Your taxes and contributions can now be paid from the software. The VAT you collected, the income tax withheld from salaries, the social contributions and what you withhold from suppliers stop piling up on a balance sheet that never says they were paid. The screen shows what you owe, calculated from your own entries and never from a figure typed in, and you settle all of it or the part you can afford this month. The receipt from the authority is filed next to the payment, and everything you have ever remitted stays readable. Your income tax is calculated and no longer forgotten. You enter your rates: the software ships none, because they change by decree and differ from one country to the next. The charge is recognised before the year is closed, the liability appears on the balance sheet, and the income statement now shows the profit before tax, the tax, then the profit that is yours. A minimum based on turnover is handled, including in a year you lose money, and the passage from accounting profit to taxable profit is entered line by line, each line with its reason. Tax withheld at source stops leaving a phantom receivable. A customer who settles 92,500 on a 100,000 invoice by paying 7,500 to the Treasury in your name now clears the invoice: your reminders stop asking for it, and the 7,500 come off your own tax instead of vanishing. The receipt you hand back says exactly what was paid to you and what was withheld. What you withhold from your own suppliers is remitted from the same screen as your other taxes. And if such a cheque bounces, the invoice reopens for what the cheque was worth and not a penny more. The tax already paid to the Treasury in your name stays settled, because the bank refusing the paper does not undo the payment your customer made to the authority. Until this release your ageing report and your reminders asked that customer for the withheld amount on top, while your customer control account, which was right, said nothing was due. If you have been chasing someone for an amount you could not explain, or if your annual report told you receivables and the control account disagreed, look at it again after the update. Your machines stop being a charge of a single year. A new Fixed assets screen holds what you own for years: an expense that paid for a machine moves onto the balance sheet, where it is written off month by month over the useful life you decide, and its original cost stays readable beside what has already been depreciated. The monthly charge is posted in one gesture, and it only ever posts what is missing, so an asset recorded late catches up on its own. Land is not depreciated and the software refuses to give it a useful life. Selling or scrapping an asset takes it off the balance sheet together with its depreciation, and the gain on a sale is kept out of your sales figures: selling a machine is not your trade. Update packages now carry the whole server, not just the web application. Until this release a package replaced the web build alone, while the background worker and the engine kept running the previous code: scheduled jobs, alerts and new chart of accounts entries stayed behind without any sign of it. Installing a version now backs up the database first, checks that backup, stops all three services, applies the code, runs the database migrations and restarts. If anything goes wrong the previous version is restored on its own. The Software updates screen also stops showing the version this installation was set up with as though it were the state of the database, and shows the last migration actually applied instead. Separately: company legal name, currency and country are no longer editable on site. They are set by Bold Redhok Tech, so a Super Admin who no longer finds them under Settings is not looking at a fault.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Replacing the credential this installation uses with the publisher is now reserved to Bold Redhok Tech. A Super Admin still sees the identifier and the fingerprint, and can still report to the publisher, but replacing a credential cuts the installation off until it reports again, which is a repair the publisher performs.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

The software now asks the publisher on its own whether a newer version exists, tells the Super Admin once per release what it brings, and records the decision to accept or decline it. Required releases cannot be declined, but the hour they are applied always remains yours.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

An installation can report the version it runs to the publisher, so support knows what is deployed without asking. The report carries the version and the company name, and nothing about the business itself.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Gives every activated installation a credential of its own, so it can prove its identity to the publisher rather than merely state it. The credential is never displayed in full, never written to the audit log, and can be replaced if it is ever exposed.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Publishes this update service. Installations can now read the list of released versions from the publisher instead of receiving whatever the code repository happens to hold.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Adds a Software updates screen: the version this installation runs, its update history, and the hours during which it is allowed to restart to take a new version.

Not translated yet: fr — readers in that language will be shown the English note, and told so.

Corrects the net profit figure. Payroll was posted on the 28th of the month regardless of when it was validated, so from the 1st to the 27th the reported profit was overstated by the whole payroll. Also closes a production order automatically once everything it asked for has been declared and received.

Not translated yet: fr — readers in that language will be shown the English note, and told so.