Purchase Document A_PurchaseContractItemConditionValidity PATCH Method not updating End Date.

[MuralitharanC]

I am trying to update the validity End Date (ConditionValidityEndDate) for an existing purchase contract item condition using a PATCH call.  However, the End Date is not getting updated in the backend

SAP S/4HANA API: not working
API: A_PurchaseContractItemConditionValidity
Unable to identify the Operation: PATCH?

Working with Header Level is updating the ValidityEndDate but not succeed in the Condition Validity level, Kindly help me to whether anyone have successfully updated dates using this API with Full or Partial Payload? Please throw some lights on same.

[ElenaPuica]

Hello!

The ConditionValidityEndDate field is part of the composite key of the condition validity entity, alongside PurchaseContract, PurchaseContractItem, ConditionRecord, and ConditionSequentialNumber. In OData, key fields are used to identify a record, not update it. This means can’t change the end date by PATCHing it, the system either tells the record is not found  or silently does nothing. This is also why the PATCH returns HTTP 200 or 204 with no actual backend change.

This behavior is confirmed by SAP KBA 3338491, which states that PATCH is not supported for item conditions in API_PURCHASECONTRACT_PROCESS_SRV. This is a known platform-level limitation, not something specific to system configuration or implementation. This also explains why updating the header-level ValidityEndDate works fine  at the header entity, that field is a regular editable property, not a key field, so PATCH behaves as expected.

Recommended Solution: DELETE and POST.  SAP-compliant approach available is to treat the validity end date change as a key rotation, delete the existing record and create a new one with the corrected date.

The process from.NET integration would work as follows:

First, perform a GET to retrieve the current condition validity record and capture all key field values including the existing ConditionValidityEndDate and ConditionRecord number,  never hardcode these, always read them new before any write operation.

Second, fetch a fresh CSRF token from the API, as tokens expire and must be fetched before each write session.

Third, issue a DELETE against the existing condition validity record using the full composite key.

Fourth, issue a POST to create a new condition validity record using the same ConditionRecord and ConditionSequentialNumber, but with desired new ConditionValidityEndDate and all other required fields from the original record.

One important implementation note: since DELETE and POST are two separate API calls, wrap them in.NET code with a compensating POST. Meaning if the POST fails after a successful DELETE, error handling should automatically re-create the original record to avoid leaving the contract in an incomplete state.