VA42 — Change Sales Contract

VA42 changes an existing sales contract document - quantity contract, value contract, master contract, or service and maintenance contract - after VA41 has created it. It opens the same header and item screens as create and display, but only fields still open for change are editable; once a release order has consumed the contract, some fields such as item deletion, material, or reducing target quantity below what has already been drawn become locked. The single fact that explains most confusion: the contract itself never generates deliveries or billing documents. It is a target agreement referenced by separate release order sales documents. Changing validity dates, target quantity, or target value on the contract in VA42 does not touch release orders already created against the old values - those documents keep whatever was copied into them at their own creation time.

VA42 is reached whenever a contract needs adjusting after creation: extending or shortening the validity period, raising or lowering the target quantity or value, changing the cancellation procedure, adding or rejecting an item, updating header partners, or re-running pricing on the contract itself. It sits in the outline agreement layer of order-to-cash, upstream of the release orders that actually trigger delivery and billing. A consultant reaches for VA42 specifically when the complaint is about the contract's own target figures or validity - not when a release order fails to create a delivery, which is a release order or delivery problem, not a contract problem. On S/4HANA the same task can be done from a Fiori contract management app, but VA42 remains the transaction most consultants still use for detailed field-level changes.

The transaction opens directly on the contract screen sequence; there is no separate initial screen split from VA41 beyond replacing create with change.

Start in VEDA on the contract number to read the cumulative quantity and cumulative value already consumed against the target figures held in VBAP. Then read VBFA with the contract as preceding document to list every release order drawn against it, sum the quantities or values on those lines, and compare the total to VEDA's cumulative fields. A mismatch after a VA42 change usually means release orders were created or changed outside the period the comparison covers, or that the update to VEDA failed silently on one of them.

The transaction itself is unchanged on S/4HANA; VA42 still opens the same header and item structure and writes to the same VBAK, VBAP, VEDA and VBFA tables. A Fiori contract management app exists for sales contracts and presents the same fields through a worklist and object page rather than the classic screen sequence; it is aimed at business users doing routine extensions, while VA42 remains the tool for detailed or exception changes. No table or field structure was replaced.

Functional SD, specifically whoever owns contract and outline agreement management within order-to-cash. A basis or ABAP escalation is only needed if a change fails with a dump or an update termination rather than a business message. A good handover states the contract number and item, the field changed, the expected versus actual cumulative or validity figures from VEDA, and the list of release orders from VBFA.

VA41 and VA43 cover create and display for the same contract document and share its screen layout, so a change confusion is usually resolved by comparing what VA43 shows against what VA42 allows to be edited. VOV8 holds the document type configuration - completion rule default, cancellation procedure default - that determines what VA42 will let a consultant change. VK12 is where the pricing conditions referenced by contract items actually get changed, since VA42 itself only triggers redetermination. VA22 is worth reviewing as the equivalent change transaction one document category up, for contrast.