Iuran Warga

Context

Running the accounts for a residential neighbourhood — Rukun Tetangga — means tracking who owes what, recording what was collected, and producing a report the chairperson can hand to a community meeting. For a handful of households it is kept in a notebook. Past that, it stops working.

The specific pain is reporting. The data itself is not hard; it is the same rows of residents, dues and expenses. Turning those rows into something the treasurer can actually use is what breaks, and it is the part every spreadsheet does badly and every existing tool does expensively.

Problem

Three things stood in the way:

• Dues and expenses are related but not the same. Money owed and money spent sit in different places, and mixing them produces a number that means nothing. Reported separately, a treasurer still cannot answer whether the month balanced.
• Reports are manual. Exporting to spreadsheet meant reformatting by hand, every time, for every committee member who asked.
• Filtering needed to be trustworthy. An income figure that includes unapproved charges is worse than no figure at all, because it looks authoritative.

Solution

A Laravel application covering residents, dues, expenses and neighbourhood structure, with reporting as a first-class feature rather than an afterthought.

Every entity can be exported to Excel through Laravel Excel, and payment records render to PDF through Blade templates and DomPDF. Both were built so the treasurer could hand a usable file to someone who does not have the application open.

The dues feature carries its own filtering, and the income chart reads only approved charges — so the number on the chart and the number in the report agree.

Architecture

Laravel with Blade templates, Tailwind CSS and Vite. The domain splits along the vocabulary of the problem rather than along technical layers:

app/Models/        Warga, Tagihan, Lingkungan, Pengeluaran, RukunTetangga
app/Exports/       one Excel exporter per entity
resources/views/pdf/  one Blade template per PDF report
app/Policies/      authorisation

Keeping one exporter and one PDF template per entity means adding an export is a matter of following the pattern rather than inventing one, and a treasurer gets the same layout whichever record they are exporting.

Challenges

Reporting is the feature. It would have been easy to treat export as a nice-to-have. In practice it was the part that decided whether the application was used at all, which changed what "done" meant for every entity — a feature was not finished until it could be handed to someone as a file.

Filtering has to be consistent. The income chart and the Excel report have to agree, or the treasurer stops trusting both. Restricting the chart to approved charges, and carrying the same filter into the reports, was the whole fix.

Indonesian domain vocabulary resists generic abstractions. Warga, Tagihan, Lingkungan and Pengeluaran are not interchangeable, and mapping them onto a generic "transaction" model would have lost the meaning that makes the reports useful.

Results

Excel export for every entity — residents, dues, expenses and neighbourhood records — plus PDF output for payment records.

The dues feature, its filters and the approved-only income chart were the core of my contribution, and I authored 13 commits as one of five members on the team repository.

A reporting surface that works in Excel and PDF means the chairperson's data can leave the application and still be usable, which is the only version of this system that survives a community meeting.