New endpoint allowing cancellation of a claim. If the claim is in an ERP status, a cancellation request is raised instead of an immediate cancellation.
▸PUT api/v{version}/claims/cancel-claim/{tecComId}/{culture}
Request body (CancelClaimRequestDto):
▸ClaimId
▸Message
Response (CancelActionResult):
▸Status — the resulting claim status after cancellation (e.g. Canceled or CancellationRequested).
New endpoint allowing rejection of a pending cancellation request. The claim status is restored to the previous ERP status.
▸PUT api/v{version}/claims/reject-cancellation/{tecComId}/{culture}
Request body (RejectCancellationRequestDto):
▸ClaimId
▸Reason
▸CancellationRequested — claim has a pending cancellation request awaiting receiver action.
▸Canceled — claim has been cancelled.
To prevent conflicting claim status updates, concurrent requests targeting the same claim are now rejected.
When two requests for the same claim are processed simultaneously, one is accepted and the other returns an error.
Affected endpoints include (non-exhaustive):
▸POST api/v{version}/disputes/{tecComId} (create dispute)
▸PUT api/v1/disputes/{tecComId}/take-into-work/{claimId}
▸PUT api/v1/disputes/{tecComId}/reject/{claimId}
▸POST api/v{version}/claims/{claimId}/comments/{tecComId} (create comment)
▸POST api/v{version}/attachments/{tecComId} (create attachment)
▸PUT api/v{version}/claims/update-decision/{tecComId}/{culture}
▸PUT api/v{version}/claims/submit-decision/{tecComId}/{culture}
▸PUT api/v{version}/claims/{claimId}/status/{status}/{tecComId}
▸Callers should be prepared to retry a request that fails due to a concurrent-update conflict.
The dispute resolution workflow has been significantly updated:
Previous Flow:
▸Sender creates dispute
▸Receiver could directly update decision while claim is disputed
▸Receiver resolves dispute (accept/reject) with optional comments
▸Single-step resolution process
Current Flow:
▸Sender creates dispute
▸Receiver must first choose an action:
▸Take Into Work: Puts claim and dispute into "in work" status, allowing preparation of new decision
▸Reject: Immediately resolves dispute and returns claim to "Decided" status
▸If taken into work, receiver submits new decision to resolve dispute
▸Two-step resolution process for accepted disputes
Replaced Endpoints:
▸PUT api/v2/disputes/{TecComId}/resolve (Removed)
New Endpoints:
▸PUT api/v1/disputes/{tecComId}/take-into-work/{claimId} - Accepts dispute for processing
▸PUT api/v1/disputes/{tecComId}/reject/{claimId} - Rejects dispute immediately
Updated Endpoints:
▸POST api/v1/disputes/{tecComId} - Create dispute (updated from v2)
▸PUT api/v1/claims/submit-decision/{tecComId}/{culture} - Now resolves disputes when in "in work" status
▸disputeComment field added to DecisionRequestDto (optional)
▸Used when submitting decision to resolve a dispute that was taken into work
▸Allows receiver to provide context when resolving dispute
▸PickupInitiated status (value = 7) - Introduced for claim parts
▸PartsReceived status (value = 5) - Updated status handling
▸Validation added on agreementId when creating a claim.
▸Agreement confirmation extended for claim senders (accept goods-return conditions during creation).
▸The disputeComment field in submit-decision is optional but recommended for dispute resolution
▸Cannot set decision to "None" during dispute processing
▸Dispute resolution now requires explicit receiver action (take-into-work or reject)
▸Auto-generates chat messages and notifications at each step
▸Dispute level increases with each new dispute until maximum level reached
▸Added a new endpoint allowing the claim receiver to reopen a claim and update the claim decision.
▸A message is required when reopening a claim.
▸The message is visible to the sender in the claim history.
The method GetReceiverShippingLabelSettings have been extended to support
pick-up service functionality with the following new properties:
▸IsUsePickupService
▸IsPickupLocationRequired
Important Rule: When IsUsePickupService = true and IsPickupLocationRequired = true, the system enforces that every newly created claim must provide a valid
PickupLocation; otherwise, the claim is rejected as invalid.
The Claim model has been extended with a new field:
▸ClaimPickupLocation
The Claim model (V2) and part-level models were extended with Nota Fiscal fields:
▸NotaFiscalNo
▸NotaFiscalDate
▸NotaFiscalLineNo (part level)
New endpoint allowing the claim receiver to initiate the pick-up process for parts:
▸PUT api/v{version}/claim/parts/pick-up/{id}/{tecComId}
Request body (InitiatePickupProcessDto):
▸TransporterName (string, max 500)
▸TrackingId (string, max 100)
▸TrackingLink (string, max 500)
New OData endpoint returning the V2 claim shape:
▸GET api/odata/v2/claims
The V2 response additionally contains PickupLocation, Agreements, NotaFiscalNo, and NotaFiscalDate.
The existing GET api/odata/v1/claims remains unchanged.
New endpoint to retrieve the agreements a receiver requires when a claim is created:
▸GET api/v{version}/settings/agreements/{tecComId}/{receiverTecComId}
Response (AgreementSettingResponseDto):
▸Id
▸Name
▸IsMandatory
▸Text
Related model changes:
▸The Claim model (V2) now exposes an Agreements collection (ClaimAgreement).
▸Claim creation accepts agreement confirmations via ClaimAgreementRequestDto (AgreementId, IsAccepted).
▸ClaimAgreement.AgreementId is now nullable.
▸Introduction of API Version 2 to support improved structure and breaking changes.
▸Added missing localization fields to enhance multilingual support.
▸Prevented unintended updates to Sender fields from the receiver side.
Sender is now allowed to update the following fields:
▸Subject
▸ReturnInvoiceNo
▸DeliveryNoteNumber
▸Modified request structure: it now returns options per flow type instead of per claim category.
▸Added culture information to provide more concise responses with translated descriptions.
Both endpoints accept an optional customerNumber query parameter to filter partners:
▸GET api/v{version}/settings/receiver-list/{tecComId}?customerNumber={customerNumber}
▸GET api/v{version}/settings/sender-list/{tecComId}?customerNumber={customerNumber}
When omitted, all registered partners are returned as before.
▸Corrected issue where problem packing conditions were not updating correctly.
▸Updated garage salutation type from string to int, using enum values.
▸SenderInternalNotes → SenderInternalNote
▸PackagingCondition → PackagingConditions