FAQ & Troubleshooting

Two possible causes, in this order:

1. The module is off. Settings → Manage Modules → enable Water Utility.
2. Your role has none of its permissions. The group needs at least Billing Accounts to appear at all.

That is permissions, and it is intended. Each child screen is gated on its own permission — Reading needs Reading Cycles & Capture, Billing needs Bill Runs & Bills, Collections needs Cashiering & Collections, and so on. There is no per-feature settings switch to look for; the whole module has exactly one on/off setting and everything below it is a permission decision.

You have the base permission but not its create / update child. Ask an administrator to grant it in the Roles editor — the children sit grouped under their parent permission.

Expected on a fresh install. Approve Tariff Versions is a separate permission and starts out granted to no role at all, so that appointing a checker is a deliberate act. Grant it to a supervisor role. Note that even then, the person who drafted a version cannot approve their own — that check is on top of the permission, not instead of it.

Also expected. Computing and approving/posting are separate permissions on purpose, so the month's money gets a second pair of eyes. If your district really wants one person to do both, an administrator can grant both keys — but understand what you are giving up.

Check, in order: the cycle is in the reading state (not still draft, not already closed); the account's connection is in the cycle's zone; the account is active; and there is an installed meter on the connection. A tap with no meter installation has nothing to read.

Not necessarily. An exception means "this deserves a human look", not "this is wrong". Most resolve as correct with an explanation — a tank refill, a leak since repaired, an empty house. Record the explanation in the resolution note: that note is what you show the customer when they query the bill.

Before billing: a validator can correct the value or request a re-read. The original value and the correction are both retained.

After billing: the reading is consumed and final. Correct the money instead — cancel the bill, or raise a signed adjustment against it. The next actual read then absorbs the difference naturally, because consumption is always the delta between two register values.

The close screen lists what is blocking it — typically reads still awaiting validation, or exceptions still open. Clear them; do not look for a way to close around them. An unclosed cycle cannot be billed, which is the safety this gives you.

That is handled. Pull the old meter (recording its removal reading) and install the new one (recording its installation reading). The bill computes each installation's span separately, on its own digit count and multiplier, and adds them — and it names both installations in the bill's snapshot, so the arithmetic is explainable.

The most-asked question, and it is a configuration gap rather than a fault.

The module ships the discount enabled but with no rate configured — because the statutory percentage and consumption ceiling under RA 9994 have to be verified per district against the current implementing rules, and inventing a number that prices real bills would be worse than showing none.

Open the bill's snapshot and you will see the exact refusal reason recorded against it. Put the rate and ceiling into your tariff configuration and the line appears on the next run.

The validator checks each meter size independently. The usual causes:

• Does not start at zero — the first block for that size must begin at 0. If you have a size-specific minimum, remember the fallback set for sizes with no rows of their own also needs a minimum.
• Gap — one block ends at 20 and the next starts at 25; the 5 cu.m between them would be unbilled.
• Overlap — two blocks both claim the same cubic metre.
• No open-ended top block — consumption above the last bound would have no rate.
• Open-ended block is not last, or there is more than one.
• More than one minimum for a size.

The database cannot express these rules, so this check is genuinely the only thing standing between a mis-keyed tier and a month of wrong bills. Fix the tiers rather than working around it.

No — and there is no hidden way to. Create a new version with a later effective date, which is what a board resolution does in reality. Bills already issued under the old version stay reproducible, which is the whole point.

If the wrong version has already priced bills, correct those bills with adjustments or cancellations; do not attempt to rewrite history.

Usual blockers: the cycle is not closed; some reads are still unvalidated; no approved tariff version is effective on the billing date for a customer class present in the run; or an account has no installed meter. The compute screen names the blocker.

Every posted bill freezes a snapshot at the moment it was computed. It records the tariff version and the tier set as applied, the meter size, digits and multiplier, both register values and the branch taken (normal, rollover or meter replacement), the senior-discount decision and why, the arrears composition bill by bill, the rounding rule, and the calculator version that produced it.

That is deliberately enough to re-derive the bill years later without relying on tables that have since been superseded several times.

A penalty is derived for the aging report and for notices, but it is only ever written once — as a line on the next bill. Nothing accrues it daily. That single-writer arrangement is what stops the same penalty being charged twice from two different places.

The minimum charge is a standing charge for having a connection, so a zero-consumption month still bills the minimum for that meter size. That is the LWUA shape, not a fault.

Correct — it ships in manual receipt mode, where the teller types the number from the printed booklet and the system only checks it is not already used. Switching to system mode is an administrator decision that should involve whoever answers to COA for your accountable forms.

Void it and re-issue. Voiding needs the separate Void Official Receipts permission and a mandatory reason. The voided receipt keeps its number — a number is never reissued or reused. Its allocations release, so the bills it had settled become outstanding again immediately.

Allocation is oldest bill first by design, so this is usually the system being right and the expectation being different. Check the allocation preview before posting next time. If the allocation genuinely must change, void the receipt and re-issue.

Open the batch detail and compare receipt by receipt. Look for a receipt posted to the wrong batch, or one voided after you counted. A supervisor can reopen a closed batch to correct it — and the reopening is itself recorded.

It stays as unallocated credit on the account and is applied to the next bill. The allocation preview shows the unallocated amount before you post, so you can tell the customer what will happen.

Check: is it still inside the grace period? Does it have an active promise to pay holding it? Is the account actually active (rather than already disconnected or closed)? And has the nightly servicing job run — if no cron runtime is ticking, the candidate list is stale.

Promises are broken by the nightly job once their date passes. If nothing has changed, confirm the job is scheduled and the cron runtime is running. You can also cancel the promise by hand.

The reconnection threshold setting decides this. At its shipped value the balance must be settled in full before reconnection. An administrator can allow reconnection at a residual balance instead — that is a district policy decision, not a technical one.

php erpat db:seed WaterUtilityDemo --remove, or the Remove button in Settings → Maintenance → Seeders. It soft-deletes — the rows are marked deleted, never destroyed — and only claims rows it can still identify by their WU-DEMO- code. Rows you renamed are deliberately left alone.

Yes. A second run changes nothing at all: it reports every row as already current, and a row-by-row comparison comes back identical. Running it after a removal restores the same demo rather than creating a second copy.

Strongly discouraged. It creates six customers in your real customer registry, six accounts, four bills and two receipts. It is designed for training and evaluation databases. Use --dry-run first to see exactly what it would touch.

No. Those rates are invented to demonstrate the tier shape. Create your own tariff from your board-approved schedule, with the real resolution reference, and approve that.