delivery / DSDillon
A clear route from brief to live system.
Agree the workflow, build around it and test the complete operating cycle. The project plan identifies who approves the records, connections and launch.
1. Review the trading and accounting workflow
We begin with sample invoices, sales, returns, supplier bills and closing reports. Identify the current applications, legal entities, currencies, users, hardware and records that need to move. The business owner and accountant agree the posting rules and required controls.
The review produces a scope with included functions, exclusions, dependencies and acceptance tests. The proposal names any local reviewer, hardware installer, payment provider or tax connection needed for the project.
2. Design the screens and record relationships
A prototype follows the work in the order it happens. We review the counter, invoice editor, receiving flow, bank review and reports with the people who will use them. Keyboard, touch and small screen operation are tested where they are part of the scope.
The data model identifies which system owns each record. A sale, payment, return and journal retain their relationships. Permissions define who can make each change and when another approval is needed.
3. Build and connect in a test environment
The software and integrations are developed using test records and approved provider test accounts. Financial posting rules are checked with hand calculated examples before larger datasets are imported.
The build handles duplicate requests, pending payments, changed source data and failed connections. Tax rules, exchange rates and external interfaces retain the version and source details needed to investigate a result.
4. Rehearse migration and opening balances
The migration plan maps products, contacts, stock, open customer and supplier accounts, and the financial opening position. Historic documents can be imported or retained in an agreed archive.
We compare the source and target counts and values, record exceptions and obtain approval for the opening balances. The cutover plan explains how transactions after the final export are captured and how to recover from a failed launch.
5. Test the complete operating cycle
Acceptance uses the workflows agreed at the beginning. It covers normal trading and the events that can create missing money, duplicated sales or incorrect stock. A demonstration is followed by checks of the resulting records.
| Test | Expected evidence |
|---|---|
| Sale and return | Receipt, invoice, payment, credit and stock movement |
| Accounting close | Balanced journal, subledger reconciliation and financial reports |
| Provider interruption | Pending state, safe retry and a reconciliation trail |
| Migration | Approved quantities, account balances and retained source files |
| Recovery | Restored application with matching records and attachments |
6. Launch with a named owner and support plan
The launch identifies who authorizes the change, the trading window and the checks completed before the new system is used. We preserve the agreed access to earlier records.
The handover includes operating instructions, configuration records, integration ownership, backup and recovery procedures, and support contacts. Source code rights, third party licences, hosting and maintenance are set out in the contract.
Who owns the finished software?
The contract specifies source code rights, custom development ownership, third party licences, hosting access and what is delivered at handover.
How long will the project take?
The schedule follows the approved scope, integrations, data condition and review requirements. We set milestones after inspecting the current systems and agreed workflows.
Your next system
Tell us what needs to work.
Bring your trading workflow, current software and the problems you need to solve. We will define the build, connections and acceptance checks.
DSDillon Business Systems
POS, accounting and connected operations.
