Complete operations
An accounting operation should be recorded as a whole. A failure partway through must not leave half of it looking finished.
SOFTWARE / ACCOUNTING
Accounting software.
Accounting records need to explain how the business got here.
This project starts with a browser prototype and works toward a system that can preserve that history through payroll, corrections, and a future migration.
Architecture in progress · no public download or signup.
What the design has to protect.
The hard part is deciding what must remain true when an operation fails halfway through, someone retries it, or an old entry needs a correction.
Retries without duplicates
Trying the same operation again after an interruption should not create another set of accounting effects.
Corrections with history
A correction needs to explain what changed and preserve the earlier record, including the version that supported a past result.
More than opening balances
The migration goal includes historical transactions and their context. A starting balance alone would not preserve the accounting story.
Recent progress is in the design.
The October 16–19 work tightened the agreements between accounting, payroll, migration, and storage. Money values, correction references, retries, and historical records now have more explicit rules.
Recovery design revised
A dead end in the proposed recovery path was addressed in the design and reviewed again. That is useful design progress; it is not a successful restore of an implemented system.
One operation, one result
Later work defined how a complete operation should finish together and how repeated requests should avoid duplicate effects.
History remains the goal
The design keeps prior accounting transactions and their versions in scope. A successful migration of real historical records has not been demonstrated.
What comes before implementation.
The current method starts with the domain model and UML diagrams, then spells out the rules and interfaces before building the new accounting system.
A prototype and reviewed plans
The executable app is still the original browser prototype. The new accounting implementation has not started. The next step is to settle the remaining access and accounting interfaces, storage capacity and recovery expectations, and review them together.
The Windows test environment remains unverified. The design reviews do not establish working accounting behavior, recovery, or historical migration. Those need evidence from the eventual implementation.
Follow what develops next.
New field notes, meaningful project changes, and corrections, when there is something useful to share.
Follow App Wizzud via RSS