Work sample / Demo ERP
An integration starts with a documented decision.
This report shows what to clarify before building a connector: what is known about the source, what still needs evidence and who decides the next step.
Information that arrives ready to use.
- Source
- Agreement
- Destination
By Kenea · Editorial review: .
The example’s decision: proceed to a limited trial.
Not ready for production. The assumption makes an integration worth investigating because the vendor might be able to intervene at the point of invoice issuance. Before quoting for the complete connector, we need to demonstrate that and agree who maintains each component.
- Assumed source
- Demo ERP, fictional version 0.1; one invoicing business, two workstations and one example numbering series.
- Need
- Preserve existing operations and make the relationship between invoice, record and response traceable.
- Out of scope
- Validating a company’s tax situation, migrating real data, operating production or guaranteeing compatibility with other ERP systems.
The map that needs checking
- Source. Identify the act of issuance and the data fixed at that point.
- Integration. Link the event to its record and retain necessary evidence.
- Response. Associate each result with its record, including delayed responses.
- Review. Resolve uncertainty without automatically turning it into a new issuance.
This is an architecture proposal, not a diagram of a live installation.
Requirements and unknowns
| Question | Evidence needed | Proposed owner |
|---|---|---|
| Where is the invoice issued? | Trace confirmation, numbering and persistence; inspect interruption behaviour. | ERP maintainer |
| Is the data sufficient? | A field map with fictional examples, intended invoice types and open decisions. | Business and maintainer, with their adviser for tax interpretation |
| What happens with two workstations? | Reproduce concurrency and repeated events; check that no extra operations appear. | Integration team |
| Who submits and queries? | Define identity, permissions and representation where relevant, without sharing secrets in the report. | Taxpayer and relevant provider |
| Who maintains the whole system? | Version inventory, contractual boundaries and a change and incident procedure. | Producer and providers, with client acceptance |
Retry without losing operation identity
We propose a stable internal reference per operation and a history of attempts. The reference identifies repetitions; it is not presented as an official field or a provider idempotency guarantee. If the same reference arrives with different content, the design must stop that discrepancy and request review.
If a response is lost, the example would retain the operation as pending reconciliation. The procedure must establish how to check the result and when to retry under the protocol used. Scheduling “send again” when a timer expires is not enough. The guide to states and decisions develops these scenarios.
What to demonstrate before approval
- A test run links source, content, record, attempts and response without losing traceability.
- A restart, two concurrent processes and a repeated event leave an explainable result.
- A lost response, rejection and warning follow different paths.
- Recovery preserves evidence and has an owner; deleting records to “start again” is not proposed.
- The responsible people review tests, limits, version changes and operating tasks before authorising production.
These are proposed acceptance conditions for the example. All remain pending; no test result has been approved and no implementation date committed. Human review controls production approval and exceptions; it does not mean manually approving every ordinary submission.
Technical documentation and responsibility
Article 13 of Royal Decree 1007/2023 assigns certification through a declaration of responsibility to the producer. This illustrative report neither replaces that document nor determines who is the producer of a particular system.
Legislative source consulted on 8 September 2026: the consolidated BOE text, showing its latest update as 3 December 2025. The rest of the report is Kenea’s editorial proposal. See the VeriFactu context and KeneaFactu’s current status.
Discuss an assessment of my software Understand states and retries
To begin, share the application, version and problem. Do not attach certificates, passwords or third parties’ invoices.