A register of disputed deliveries should track each claim from a specific delivery line to a confirmed outcome. The minimum record links the line, reason, attachments, case owner and agreed outcome. A decision alone does not close the case: closure requires evidence that the agreed action was completed. If a financial document is needed, it is created in the official system by an authorised user.
A delivery claim often starts outside the ERP: in a customer message, a warehouse call, a photo of damage or an internal finding. Without a shared record, the connection between the claim, the actual delivery, the agreement with the customer and a later financial action can be lost.
A mini register does not need to replace the ERP. Its role is to keep the operational context of a claim in one place and show clearly who owns the next action.
A sound minimum process answers five questions:
This record is not the same as approval for posting, approval for a return or issuing a document. Those actions belong in the official system and with a user holding the relevant authority.
Each case benefits from a unique identifier linked to the delivery. Where a delivery contains multiple lines, the record should also identify the specific line, quantity or another available line identifier. A delivery note number alone can remain ambiguous when the claim concerns only part of the delivery.
Recommended inputs include:
A controlled list of reasons can support later review, but it should not hide an important case description. For example, the label "damage" does not itself show whether the damage was visible on receipt, found during use or documented later. Free text and attachments often carry essential context.
The input owner, such as customer service or the person receiving the claim, opens the case and links it to the delivery and line. If the link is unavailable, the case can receive an exception status such as "awaiting delivery identification". This prevents the case from appearing ready for a decision.
The handling owner checks whether the reason, description, required attachment and delivery link are sufficient for assessment. Missing evidence is not necessarily a reason to reject a claim, but it should remain visible as an open question. Input completeness and the validity of a claim are separate decisions.
The operational owner collects findings from the relevant function, such as warehouse, quality, sales or production. An authorised person or role then records the decision. The role entering a finding does not need to be the role approving the outcome.
It is useful to distinguish at least these outcomes:
The agreed outcome should be operationally clear. Rather than a broad label such as "resolved", the record can state a replacement delivery, goods return, service correction, rejection with rationale or another agreed action.
Hypothetical scenario: a customer reports damage to one line on a delivery note and attaches a photo. The case owner links the claim to that line, the warehouse enters its finding, an authorised role approves a replacement delivery, and the case remains open until the responsible person confirms completion of the agreed action. If the outcome requires a financial document, its reference is recorded after the document is created in the official system.
A decision is not evidence of completion. A case is ready for closure only after confirmation that the agreed action was completed or that the reason it will not be completed has been recorded. Confirmation can include the person completing the action, date, a brief note and a link to a relevant official record.
This is where evidence of claim resolution is created: a traceable sequence from the claim and attachments, through the decision, to confirmed action. The evidence does not need to be a single document, but it needs to support review of the sequence without relying on verbal recollection.
A mini application can operate independently, without ERP or Orkasta. This is a proposed process, not an announcement of a ready-made product. System boundaries should nevertheless be defined before implementation.
The operational register can hold the claim, communication context, attachments, responsibilities and status. The ERP remains the place for official transactions, including a financial document when an authorised user needs to create one. The register can store a reference to that document, but it should not present document creation as an automatic consequence of the claim without defined approval and authority.
In the ORKA approach, Orkasta can support everyday collaboration, ERP can hold official transactions, and Trueforce can provide specialised engineering work. Clear allocation is more useful than overlapping responsibilities: define in advance which system holds each data item, who changes it and what constitutes the official trace for each action.
Data constraints can support basic record quality. For example, they can check identifier uniqueness, required fields and relationships between records. The PostgreSQL Constraints documentation describes these categories of constraints.
A data constraint does not replace a business rule. A rule such as "a damage claim requires a photo" or "a particular outcome requires additional approval" needs separate definition: who decides, when the rule applies, whether exceptions exist and where an exception is explained.
It is also important to avoid an overly rigid form. A mandatory attachment can block a legitimate claim with no photo. At the same time, fully unrestricted entry makes work queues and later review more difficult. A practical balance is to mark a missing input visibly, assign an owner for completion and specify who may accept the exception.
Before building a form or integration, agree on the following.
Inputs and their owners
Exceptions that must remain visible
The process is ready for use when every closed case allows review of the delivery link or a recorded exception, reason, available attachments, handling owner, authorised decision, agreed outcome and completion confirmation. Where a financial document has been created, its official reference should be available. This criterion is verifiable without assuming a baseline or target value.
If data ownership, the boundary between ERP and the operational register, or exception rules remain unclear, a Business process screening can provide a structured next step before a solution is built.