Computed Fields in APES: Numbers That Update Themselves
Most business systems have a quiet weak point. Somewhere there is a total that someone has to add up, a count that someone has to check, or a summary field that someone has to remember to refresh. It works fine for a week. Then someone forgets, and the number on the dashboard stops matching reality. Nobody notices until a decision gets made on bad information.
APES avoids this problem with a feature called computed fields. A computed field is a field that calculates its own value instead of waiting for a person to type one in. Once it is set up, it stays correct automatically, every time the data it depends on changes.
There are three kinds of computed fields in APES, and each one solves a different problem.
Rollups: summarizing a group of related records
A rollup looks at a group of related records and produces one summary value from them. If a category has ten items in it, a rollup field on that category can show the count of ten without anyone typing a number in. If a customer has five open orders, a rollup can show the total value of those orders on the customer record itself.
The key property of a rollup is that it recalculates the moment the underlying records change. Add an eleventh item to the category, and the count becomes eleven right away. Delete one of the customer's orders, and the total drops to match. Nobody has to remember to update anything, because the field is not storing a number, it is recomputing one.
This is the same mechanism behind the dashboard stat cards you see on a module's home page. A fleet size number, an open order count, a pending approval count, these are all rollups doing their job quietly in the background.
Lookups: pulling a value across a relation
A lookup is simpler than a rollup. Instead of summarizing many records, it reaches across a single relation and copies one value from the related record. If a rental line is linked to an equipment item, a lookup field can show that equipment's category right there on the rental line, without duplicating the category as separate typed text.
This matters more than it sounds like it should. Without a lookup, someone would need to type the category manually on every rental line, and that typed value could drift out of sync the moment the equipment's real category changes. With a lookup, there is only one source of truth, the equipment record, and every place that displays its category is always reading the current value.
Formulas: calculating from a record's own fields
A formula calculates a new value from fields that already exist on the same record. If a record has a day rate and a number of rental days, a formula field can multiply the two and show the total cost, updated instantly if either input changes. If a record has a due date, a formula can compare it against today's date and flag whether the item is overdue.
Formulas can also reference rollups and lookups, which means the three types of computed fields are not separate tools working alone, they build on each other. A formula might take a rollup's total and divide it by a lookup's unit count to produce a per unit cost, all without a single manual entry.
Why this matters more than it first appears
The real value of computed fields is not the convenience of not typing numbers in by hand, although that helps. The real value is trust. When a manager looks at a dashboard and sees a number, they need to know that number reflects what is actually in the system right now, not what it happened to be the last time someone remembered to update it.
Computed fields remove the gap between the data and the display of the data. There is no second copy to fall out of sync, because there is no second copy at all. The field is always looking directly at the current state of the records it depends on.
This also protects the system when things change in ways nobody planned for. A record gets deleted, a relation gets reassigned, a status flips from one value to another. A hand maintained number would need someone to notice and fix it. A computed field simply reflects the new reality the next time anyone looks at it, because that is what it was already designed to do.
How this shows up in a real module
Picture a simple equipment rental system. A dashboard shows how many pieces of equipment exist in total, how many are currently checked out, and how many are under repair. Every one of those numbers is a rollup, reading directly from the equipment records and their current status.
A rental agreement shows the total cost owed, calculated from a formula that multiplies the day rate by the number of days booked. Change the day rate on the rate card, and any agreement still referencing that card recalculates without anyone touching it.
A rental line shows which category its equipment belongs to, pulled in through a lookup from the equipment record it is linked to. If the equipment later gets reassigned to a different category, the rental line shows the new category immediately, because it was never storing its own separate copy in the first place.
None of this requires custom code or a background job someone has to maintain. It is built into how the field is defined, and it runs the same way every time.
Closing thought
A system that requires people to keep numbers updated by hand is a system that will eventually show someone the wrong number. Computed fields close that gap by design. Rollups summarize, lookups connect, and formulas calculate, and all three stay correct on their own, for as long as the module exists.