Vendor credits, receipts, and amendments
Vendor credits rebuilt as GL-posting credit memos, a receipt on every payment that you can open and send, one property and project picker, and single-step contract amendments.
When the books became a general ledger, three everyday objects were left behind: vendor credits that never posted, receipts that were a label rather than a document, and contract amendments that took several clicks to assemble. All three now behave the way the ledger expects.
Vendor credits post double-entry GL
A vendor credit used to be a note on a balance. It’s a credit memo now. It writes double-entry GL entries when issued, carries a property and project on the header, scopes its GL picker to the accounts that apply, and applies against open bills. Customer credit memos run on the same record, so a credit posts the same way whichever direction the money is going.
Every payment has a receipt you can open and send
A receipt is the document you hand someone to prove a payment landed. Each payment now has one. It references the payment it came from, it’s generated the same way everywhere, and the same component renders it in every module. A tech in the field, a tenant paying rent, and a buyer making a draw payment all get the same document.
One property and project picker
A handful of one-off property and project selectors were replaced with a single PropertyPickerPopover. Tagging a credit memo, a transaction, or a contract line uses the same search, the same scoping, and the same keyboard behavior.
Amendments in one step
Adding a fee-schedule amendment to a contract used to be a multi-stage affair. It’s a single form: name the amendment, add its line items, and it posts as one change to the contract’s value. This is the first piece of a larger reworking of how contracts handle change orders.
All of this is live for every organization on the Books module. Walkthrough on request: [email protected].