The missing address field was not something we forgot to build

I spent the afternoon of 18 September building a field for an employee's address. That field is not in the product now. What I found out, after I had already started building it, was that the annual form defines nowhere to put an address at all.

It started with a short question from V. She is an accountant in Jakarta who has tested KAZENA Books with her own firm's real data more than 20 times. On the screen that produces the annual certificate, where do you enter an employee's address? She had looked from top to bottom, she wrote, and found no field for it. If someone who has used it more than 20 times cannot find the field, I thought, we must have forgotten to build one.

We had not forgotten. Open the definition of the annual form, the BPA1, and there is no element called Alamat, no address. It is not sitting there as an optional field either; the column itself does not exist. In the XML we assemble there was not 1 place where an address could be put.

V explained why. An address is not information the form carries. It is information the tax office holds, tied to the taxpayer's number. The address printed on the certificate is not the string we send; it is the address registered with the tax office that has jurisdiction. Changing it means correcting that registration. This was never a value the software gets to decide.

Even so, we went on building the field halfway through that afternoon. The reasoning went like this. Our user says she wants to enter an address. If the form has nowhere to put it, we can hold it ourselves and print it on the PDF certificate. Written out, it looks reasonable enough.

Here is why we stopped. Do that, and the address that gets printed is the address we hold, which is a different thing from the address registered with the tax office. The layout and the look are no different from the real certificate; the only difference is where that 1 line came from. Whoever receives it reads it as the address on record with the tax office. What makes them read it wrongly is our own construction.

This is not a value that settles into right or wrong the way an amount does. In most cases the address we hold is the correct address too. The problem is not whether it is correct, but that you can no longer tell what the paper is a copy of. A certificate carries meaning because it is a copy of a record the tax office holds. We should not have mixed 1 line that is not a copy into that copy.

What we decided is simple. We do not build the address field. Instead we made the screen say plainly that it is not there. The address is not carried by this form. What gets printed is the address registered with the tax office. Changes are made in that registration. Those 3 sentences now sit briefly on the employee screen, with the date we last confirmed the rule written beside them.

There is an older mistake behind how they are worded. We used to render items like this as a grey input box with a note saying it cannot be edited. A grey box reads as broken, or as something your permissions do not reach. V had in fact asked us once whether there were items her access level could not see. Now we put no box there at all; we replaced it with 1 line of explanation. Instead of writing that it cannot be edited, we write that it is not decided here. If we cannot write where the value is decided, there is no point showing it on the screen.

We also fixed the check screen that comes before the annual certificate is produced. It used to show everything unfilled in 1 list. Now it is split into 2 places: items KAZENA can fix, and items KAZENA cannot. For the second, we wrote 1 line each on where it does get fixed. This address is the first item in that second group.

There is something wider to take from this. A product is better for being able to state the limits of what it is responsible for. When a screen cannot say this is not ours to fix, people go on searching our screens. What V was looking for was not a field we had forgotten to build; it was a sentence we had forgotten to write. What cost her time was not the missing field but our never saying it was missing.

On 26 September the Jakarta stay that began on 30 July came to an end. I queued at counters a few times over those 2 months, and each time I felt that the substance of a procedure sits in the register, and the paper in my hand is a copy of it. What the person at the counter looks at is the record inside their screen; what I hold shows how that record stood at one moment. I think I was being taught the reason there is no address field while standing in those queues. Back home, I am opening the same screens.

One thing to be clear about. I am not a tax accountant. What the annual form contains, and where and how an address is registered, are decided on the regulatory side and they change. What I have written here is a record of our getting a screen wrong. Please confirm the actual procedure with a professional.

A request to close with. If there is an item on a KAZENA screen that cannot be changed and does not say why, please tell us. That is a place where we have not put it into words yet.