Orders

Yes, in the “Statuses and locations” drawer. The school sets the name, the tone and the order; the system only insists that the set holds at least one status in progress, one bought and one rejected. A school that never opens it gets five ready-made ones on first use. A status dropped from the list while an order still sits in it is archived; an unused one simply goes.

Two columns and two different people: the methodologist reports and runs it, a teacher only reports, the owner pays. The reporter comes from the SESSION - there is no such field in the request at all, because noticing a shortage is a fact rather than something to type. After someone leaves the team both columns keep the name as a snapshot, so the purchase history is not left without an author.

Behind a link, because this module has no file storage. The rest of the invoice is DATA you can query: number, issuer, net, gross, issue date and due date - and it is that, not the scan, which answers what is still unpaid. The only correction allowed is marking it paid or unpaid; deleting an invoice leaves a trace in the history. One order sometimes carries several.

Once the module is granted, yes: they create the row, add the quantity and the place, and move it through the statuses. Without the grant they tell someone who has the module, because the screen carries the amounts, invoices and suppliers of the whole school. Deleting a row stays with management either way. A narrow “report a shortage” entry without sight of the amounts does not exist today.

So that “East Branch”, “east branch” and “EB” are one entry you can count money against - the stats strip has a chart just for that. The catalog belongs to the SCHOOL, not to this module: the rental module reads the same locations, and lately so do Groups, the Journal and the Schedule. A location typed into the cell is searched for first and only then created.

Five tiles (in progress, bought this month, spent this month against the previous one, overdue, unpaid invoices), a breakdown by status, twelve weeks of spending and the locations. The database counts it and recounts after every save. Next to a status stands the BEST KNOWN amount - spent, or the estimate before the purchase - so that two numbers about one purchase never sit side by side unexplained.

Neither. Orders know what was bought and for how much; they do not know how much is left or who is holding it - that is the rental module. An invoice here is a COST invoice for one particular thing; tuition and student payments are Finance. This module does not place orders either: the supplier and the link are a note on where to buy, and a person does the buying.