What we shipped, in plain language.

Because the mother tongue now decides which language a personnel form prints in, a typo in it is a form in the wrong language. Application Particulars therefore offers the language list instead of a free-text box — the same list the Languages tab uses, so the two screens cannot spell the same language differently — and a value already recorded stays selectable, so opening the dialog can never blank it.

A starting list of languages is seeded, and the dropdown can add to it from its own dialog for a language that is not on the list. Adding is a deliberate act, never a side effect of choosing a value; renaming or removing a language people are already recorded against stays an administrator decision.

Tenant lists built by hand held the same languages twice, under different spellings and casings, once the seeded list arrived beside them. Those duplicates are merged, not deleted: everything pointing at a duplicate is moved onto the single surviving row first, so no employee’s recorded language is lost. A row that cannot be removed because something still points at it is deactivated instead and simply leaves the dropdown.

Form-1 now carries the ESI Corporation seal at its head and Form-2 the EPFO seal, as the sheets filed with the branch office do.

The seal identifies the form, not the employer, so it is shipped with the system rather than being tenant configuration — neither form identifies the employer by letterhead in any case (Form-1 does it by code and address, Form-2 by establishment code). The company logo remains only as a fallback, and if the emblem cannot be read the head prints without a seal rather than the document failing.

The employment application and the job request are bilingual forms, and the second language now follows the applicant’s mother tongue rather than being fixed. A Hindi mother tongue prints the title, every label and the declaration in Hindi; a Tamil one prints the form exactly as it printed before.

Both forms read from one shared catalogue of labels, because they are the same seventeen sections and must not end up saying different things about the same line. A translation is a lookup and never a transliteration: a mother tongue with no translated set prints in the language the form was drawn in, and a line with no translation prints in English alone rather than mixing two scripts on one page. The mother tongue itself now prints in both scripts — “TAMIL / தமிழ்” — taken from the language master, never invented.

The second lines can still be switched off outright when a plain English sheet is wanted.

Administrators: each language needs its font installed on the print server. Without one the second line simply drops out and the English label carries the meaning.

ESI Declaration Form-1 and PF Nomination Form-2 now print from the employee record, in the statutory layout, ready to be signed and filed with the branch office.

They are printed from the employee profile, with a preview before the paper. Both are locked layouts: their wording is prescribed, so unlike the tenant’s own forms they cannot be redesigned in the print designer.

Behind them is a proper nominee register. A nomination is not a family member: it is recorded per scheme — the ESI nominee and the PF nominee may be different people — with a share, and it is ended by being revoked rather than deleted, so the record of who was nominated when survives. Form-2 keeps the two apart as the statute does: the family table is the family, the nomination box is the nomination.

What the record does not say, the form does not invent. Shares are reported as recorded and never quietly adjusted to add up — a set that does not total 100% is flagged for HR to correct in the record, not corrected on the paper. An unanswered question prints blank rather than ticking a box, and the establishment code is taken from the statutory filing details in force today, with none on file printing blank.

The employee list filtered on one of the two flags that record whether somebody still works here, so an employee marked inactive could still appear. The two are kept in step now — approving or revoking a separation moves both — and the default list scope excludes inactive employees, while asking for a status explicitly still returns them.

A payroll run for one employee was not actually running as a single unit of work on the tenant’s own database connection, so a failure part way through left a partial result committed. It is now bound to the right connection and either completes or leaves nothing.

Two related corrections: the run number is allocated under a real lock, so two runs started at the same moment can no longer claim the same number; and generating payroll periods from the command line now requires the user and tenant it records, refusing by name instead of writing an empty tenant.

The working-day denominator was extrapolated from weeks × days per week, which gives 26.57 days for August 2026 on a six-day week against an actual 26 — the denominator of gross pay, wrong by half a day, every month, in both directions. The rest-day pattern is now counted for the period, with dated holidays from the production calendar taken off as an overlay.

The proration method is also configurable per payroll area instead of being fixed in the engine. It defaults to calendar days, so an existing payroll area keeps exactly the behaviour it has today.

Proration counted the denominator over the whole period but the numerator as “all working days less unpaid days”, never consulting the employment start date. Someone who joined on the 20th came out at a full month’s factor and was paid a full month. Both sides are now counted the same way, and an unpaid day falling on a rest day is no longer deducted from a working-day denominator.

Loss-of-pay days were silently always zero. The engine looked for unpaid leave by matching the word “unpaid” in a field that does not exist, the resulting failure was swallowed, and every unpaid day was paid in full.

Unpaid is now read from the leave type’s explicit paid / unpaid flag rather than guessed from its name, and a failure is reported loudly instead of being absorbed — this direction of error overpays.

The proration factor was rounded to four decimals before being multiplied, so 22/31 became 0.7097 and overpaid a few paise a month on a mid-range basic — an error that scales with salary and headcount and never reconciles. The factor is now carried at full precision through the arithmetic, with the four-decimal value kept for display on the payslip.

An employee’s application form can now be printed as a PDF from the employee record, with a preview before it goes to the printer.

It is a reprint of the master, not a second form to fill in: the print takes no field from the screen, so a blank on the form is a blank on the record — and the record grew the fields the form actually asks for, family particulars among them, rather than the form inventing them.

• A default is not an answer. An unrecorded blood group, an age of zero and an absent wage all print blank rather than printing a value nobody supplied
• The photograph is embedded in the document itself, so it is there on paper and in the PDF you email
• The layout is a print format like any other, so it can be tailored per tenant — and printing never depends on that: the shipped layout is always there behind it

The first half of the hiring paperwork is filled in before anybody is an employee, so the Job Request form prints from the recruitment candidate rather than from the employee master.

• The candidate record now holds the particulars the form asks for — previous experience, salary drawn and expected, and the declarations — captured on the candidate screen and previewed before printing
• The office-use block on the form is ruled space: it is there to be written on, and nothing is read back off it
• Anonymising a candidate purges the particulars this form added, along with everything else held about them

An identity card can be printed for an employee from the employee record, or for a selection of employees from the employee list, on a page of its own with a preview first.

• The card is laid out at the standard 91 × 56 mm, two to an A4 sheet, so a batch comes off an ordinary office printer ready to be cut
• Photograph, identifiers and a scannable code come from the employee master, so the card says what the record says
• The layout is a print format like any other and can be tailored per tenant, with the shipped layout always behind it so a card can always be printed

The staged change presented to the approver rendered raw internal identifiers — which is exactly the screen on which knowing which material is being added matters. Each side of the change now carries its label alongside the underlying value, never in place of it, since the drift check and the release both read the value.

The bill-of-materials lint run during change-order impact analysis failed on every change order. The guard around it caught the failure and reported the analysis unavailable, so nothing was ever wrong — but no approver had ever seen a lint finding. The findings are read correctly now.

The change-order form could only modify or remove component lines that already existed. Adding one now has a panel of its own — material, quantity, unit, scrap, sequence, component and supply type, unit cost, currency and notes — with the material, unit and currency searchable rather than a dropdown nobody can scroll at master-data scale.

An addition is now checked when it is staged, not when it is released:

• A component needs a material, a quantity and a unit. A missing one used to surface as a database error inside the release, long after the person who could supply it had left the screen
• Only component lines can be added. Staging an addition against an operation component or a variant rule was accepted, approved, and then quietly did nothing
• A new line carries no currency across from an old row, so it inherits the structure’s currency at release — and where the structure has none either, staging refuses and names the way out

Opening a project’s WBS tab showed a “built using a trial version” banner, while every other grid in the application was fine. One grid component was pinned to a different release line from the rest and ended up loading a second, private copy of the shared library — the copy that never saw the licence being registered at startup. The licence itself was never the problem. All components now share one library and the banner is gone.

Saving a leave application from Employee Self-Service failed with CSRF Failed: CSRF token missing. The screen was calling the server directly instead of through the shared client that attaches the security token, so the page loaded perfectly and only the save broke.

A sweep of the whole application found the same defect on eight more modules with live saves — data access and user management, the organisation chart, expeditor letters, the MBA dashboard, sub-contracting, numbering sequences and web push notifications. All of them now go through the shared client, as do seven further read-only screens, so the fault cannot come back the moment a save is added to one of them.

The leave type dropdown on Employee Self-Service was empty, so no employee could raise a leave request at all. Leave types are tenant configuration and the screen correctly invents nothing — but that left a tenant that had never configured them with no way through the screen.

A starting catalogue is now seeded — Earned, Casual, Sick, Maternity, Paternity, Bereavement, Compensatory Off and Loss of Pay — modelled on a common Indian private-sector policy. It is a starting point for your HR team to confirm, not a policy: seeding is idempotent by leave-type code, so an edit made by an administrator survives a re-run, and a leave type already in use is never removed.

Seeding a type grants nobody any leave. An entitlement is a quota recorded against an employee, with a number and a validity period, and that stays an HR decision: until quotas exist the balance panel reads zero and a quota-bearing type refuses the request.

Administrators: a tenant with no users yet is skipped by the deploy-time seed rather than having an author invented for it — run seed_leave_types for that tenant afterwards.

Add Element switched itself off after the first WBS element on a project that was still a draft, and the status transition buttons never appeared at all. Neither was a screen fault: the project status was simply not being sent with the project, so every project read as though it were already past draft.

The same omission left the Status column blank on the project grid and on the portfolio board.

The status is now served with the project — for reading only. A status change still goes through the transition action, so the rules that govern which move is allowed cannot be sidestepped by writing the field directly. The actual start and end dates, stamped by those same transitions, are served beside it and the “Actual start” field on the detail screen is no longer permanently blank.

The daily, weekly and quarterly overtime caps in Overtime Management now read from the roster compliance rules for the plant, so one place governs the limits.

Where no rule has been configured the existing limits continue to apply exactly as before — removing a warning that fires today would itself be the change nobody asked for.

A Sales Order line can now carry an output tax code from the tax master, and the code drives the line’s tax percentage instead of the rate being typed in by hand.

The tax code carries across when a quotation is converted into a sales order, so the rate the customer was quoted is the rate the order is raised at.

The time and attendance records were all in place, but nothing answered the question underneath them: which employee is on which shift on which date. That plan now exists — shifts, breaks, rotation patterns, crews and a generated roster per period.

• A rest day is a recorded off day, never a missing row. A gap in a rotation pattern silently understates absence and overstates overtime, so a pattern that does not cover its whole cycle cannot be activated and the builder shows the undefined day in red
• Generating and publishing are separate acts. A draft roster that breaches a limit is useful — it shows the manning problem — but publishing one is refused, naming each breach, because publishing a statutory breach is the breach
• Re-generating a roster replaces only the days the pattern produced, and reports how many human decisions it left alone
• Moving an employee between crews is recorded as history with effective dates, so past rosters that payroll was already computed against are not rewritten
• A locked period is a fact: correct it with a new period, never by editing the old one
• Night-shift eligibility is checked against what is on file — no exemption recorded means not permitted

Administrators: re-seed roles after this upgrade, and seed the roster configuration for each plant.

The General Ledger Journal Entries screen can reverse a posted journal, generating the opposite entry and linking the two.

It reverses manual journals only. A journal raised automatically by a document — an invoice, a receipt, a depreciation run — is one leg of that document and is reversed from the document itself, so the rest of what the document did is unwound with it.

Attendance terminals can post punches directly, and each day is evaluated against the published roster to produce worked hours, lateness, early leaving and proposed overtime.

• A missing punch is reported as a missing punch, never as zero hours — zero pays nothing for a day somebody worked, and a full shift pays for a day nobody can evidence
• A device that has gone quiet is flagged as silent. A whole shift with no data looks exactly like a whole shift absent on every report downstream
• Overtime is proposed, never posted. A supervisor accepts it into the existing overtime request process, where the existing caps apply unchanged
• Which shift-day a night punch belongs to is decided once and stored, so payroll, overtime and the shop-floor rollups all count the same night the same way

A posted vendor invoice can now be reversed. A reversal cancels a posting — it does not erase the document, which stays visible with its reversal recorded against it.

• Everything the posting did is unwound together, not just the journal: the stock revaluation, the reverse-charge accrual, any vendor advances the invoice consumed, and the vendor sub-ledger entry
• Reversing releases the goods receipt again, so the receipt can be re-invoiced instead of being held shut for ever by a cancelled invoice, and the withholding-tax threshold no longer counts the reversed amount
• An invoice that has been paid is refused by name, rather than being reversed out from under the payment
• A reason is required, and the reversal posts into an open period