How to upload VK11 pricing conditions from Excel
VK11 is the SAP transaction that creates pricing condition records. PostNow.ai uploads them from Excel by replaying a VK11 recording, one condition record per row, under your own SAP login, with SAP's message per row in the Run Log. Record once per condition type and key combination, such as PR00 on Customer/Material (A305); SAP does not release BAPI_PRICES_CONDITIONS for this.
- Overlaps change the old record. A new record for the same key shortens, splits or deletes the existing one instead of being refused.
- One template per key combination. The key combination dialog is part of the recording.
- No document number comes back. You prove the load in VK13 and in the condition analysis on a test order.
The key combination and the validity dates decide whether a VK11 load works far more than the amounts do, so most of this page is about those two. For choosing a method across all SAP objects, see SAP mass upload from Excel.
How PostNow.ai uploads VK11 condition records from Excel
PostNow.ai treats a VK11 upload as a recorded transaction: a designer records VK11 once, and every Excel row replays that recording through CALL TRANSACTION, so SAP runs the same screen checks it runs when a pricing clerk types the record by hand.
1. Record VK11 for one key combination
Press Record on the PostNow.ai ribbon and create one real record in VK11 in a test client: the condition type on the first screen (field RV13A-KSCHL), the key combination in the Key Combination dialog, then one line on the fast-entry screen with sales organisation, distribution channel, material, rate, unit and the two validity dates, and save. The recording runs through SHDB, so afterwards you see every screen, field and OK-code it captured.
SAPMV13A 0100), the key combination selection and the fast-entry screen of the table you meant to fill.2. Map the columns and fix what should not vary
In the Mapping Designer each recorded field gets an Excel column, a fixed value, or a system value such as SAP_DATE. Make the condition type a fixed value (PR00) and give sales organisation and distribution channel defaults, so the file carries only what changes per row: material or customer, rate, unit and dates, each date column with its own format.
3. Restrict what can be typed
Give the unit and sales organisation columns a value list and switch on Restrict: the list becomes a hard allow-list at Validate, which keeps a rate unit nobody uses, or another team's sales organisation, out of a pricing file.
4. Validate, then Simulate
Validate checks formats and allowed values before SAP sees the file, and Pre-Validation asks SAP whether the customers and materials exist. Simulate then plays the screens without saving: for VK11, PostNow.ai strips the save, checks the screens, and says so. The validity adjustment described below happens at save, so watch it in Debug in a quality client.
5. Debug five rows, then run the file
Debug replays rows in the foreground in SAP GUI, either every screen or only the screens with errors. Watch the key combination dialog and the save on five rows before you send three hundred. Run then posts every row under your own SAP login, writes SAP's message to that row's Run Log, and Retry Failed re-posts only the rows whose Run Log starts with ERROR. Stop cancels the rows not yet sent; records already saved stay in SAP.
SAPMV13A 0100, then the key combination (access) screen. Each recorded field gets an Excel column or a fixed value.A ready-made sheet is the free VK11 pricing conditions template (field guide and recording mapping), listed on the master data templates page. How to record so that a recording replays reliably is covered in the BDC recording guide. If this is your first upload of any kind, how to upload data into SAP from Excel walks through one file end to end.
VK11 recording vs BAPI_PRICES_CONDITIONS: which route to use
PostNow.ai posts condition records through the VK11 recording. The table shows where the other routes you will read about fit.
| Route | How it posts | Use it when | Watch out for |
|---|---|---|---|
| PostNow.ai: VK11 recording from Excel | CALL TRANSACTION on your recording, one record per row, SAP's message per row | Prices arrive as spreadsheets and you load them repeatedly, on ECC or S/4HANA, with validation, approvals and a per-row result | One template per condition type and key combination; a changed screen layout means re-recording |
| Manage Prices – Sales (Fiori app F4111) | Spreadsheet import into the app, template per condition type and key combination | S/4HANA, pricing specialists who work in Fiori | S/4HANA only; SAP knowledge base articles describe import errors and records split by changed validity dates |
IDoc COND_A | ALE inbound processing of condition records | System-to-system transfers that IT sets up and runs | Needs ALE configuration and IDoc monitoring; not a tool for a pricing analyst |
BAPI_PRICES_CONDITIONS | Function module with control, header and item tables and a packed variable key | We would not use it for new work | SAP Note 1135984 says it is not released and can cause inconsistencies |
Why PostNow.ai posts VK11 through a recording. Three reasons. SAP's own note points away from it and toward batch input or IDocs. Its variable key (VARKEY) is one flat field into which the whole key of the condition table has to be packed in that table's field order and lengths, so a one-character slip puts the price against a different key. And in PostNow.ai's BAPI mode, the Run Log reads SAP's verdict from a parameter named RETURN; this function module reports in TO_BAPIRET2 instead. The recording returns SAP's own screen message for every row, so all three issues fall away. The general trade-off between the two methods is in BAPI vs BDC in SAP.
Condition type, key combination and access sequence: get the table right first
In PostNow.ai the key combination is fixed by the recording, so choosing it is a design decision you make once per template, not a value someone types per row. Get it wrong and every row saves cleanly into a table pricing never reaches.
- A key combination is a condition table. In a standard system, Customer/material is
A305(sales organisation, distribution channel, customer, material) and Material isA004(sales organisation, distribution channel, material). The condition table row carries the key, the validity dates and the condition record numberKNUMH; the record itself sits inKONH(header) andKONP(rate, unit, pricing unit). - The access sequence decides which table is read first. Pricing works through the condition tables in the order of the access steps. With the Exclusive indicator set, it stops at the first valid record. So a new material price in
A004is never used for a customer who has a validA305record for the same material on that date. Nothing is wrong with either record; the A305 one simply wins. - Look before you build. Take one customer and material from the file, create a test order for the date the new prices start, and open the condition analysis on the item. It lists the accesses SAP tried and the one that found a record. That tells you which table your new prices have to go into.
- Keep the condition type fixed per template. The Key Combination dialog is a list, and the recording stores which line you chose. A condition type with a different access sequence shows a different list, so the same line can mean a different table. A
PR00template and aK007template are two recordings.
VK11 validity periods: what SAP does when dates overlap
Each row is a normal VK11 save, so SAP's overlap rules apply exactly as they do in dialog. Those rules do not reject the new record. They change the old one, which is useful once you know it and expensive when you don't.
| Situation (same condition type and key) | What SAP does | What it means for your file |
|---|---|---|
| Old record 01.01.2026–31.12.9999, new record from 01.01.2027 to 31.12.9999 | Sets the old valid-to to 31.12.2026, with no message | A price change is one create row. You do not need a separate run to end the old price. |
| New record falls inside the old one (01.02.2027–31.03.2027 inside an open-ended price) | Splits the old record into a part before and a part after the new one | The old price comes back on 01.04.2027 by itself. The two outer parts share one record number, so a later VK12 change to one changes the other. |
| New record covers the whole of an existing one | Warns at save that the old record will be deleted | A recording made on the simple case never saw that warning. Test this case in Debug before you run a file that contains it. |
| The same key appears twice in your file with overlapping dates | Each row is a separate save, so the later row adjusts or replaces the earlier one | Row order matters. Sort by key and valid-from, and remove rows nobody meant to load twice. |
The end date needs a column. VK11 proposes the valid-to date from the condition type's settings, often 31.12.9999. That is right for a list price and wrong for a promotion, which then never ends and later splits whenever someone loads a new price for the same key. Make Valid To a required column in the template so nobody relies on the proposal.
Overlap only exists within one table. A customer price in A305 and a material price in A004 for the same dates do not overlap in SAP's sense. Both stay valid, and the access sequence decides which one an order uses.
Rate, unit, scales and percentages in the Excel file
PostNow.ai maps whatever the recorded fast-entry screen shows. On the usual sales price screens that is the key (for example KOMG-MATNR), the rate KONP-KBETR, the rate unit KONP-KONWA (a currency, or % for percentage conditions), the pricing unit KONP-KPEIN, the condition unit KONP-KMEIN, and the dates RV13A-DATAB and RV13A-DATBI.
- Rate, pricing unit and unit travel together. 310.00 USD per 1 EA and 310.00 USD per 100 EA are both valid entries, a hundred times apart. Keep pricing unit and unit as columns with allow-lists, and read three rows of different unit types in VK13 after the Debug run.
- Amounts reach the screen as text. A recording types values into the screen, so they have to match the decimal notation in the SAP user's defaults (SU3). A file with 1.234,50 sent for a user set to 1,234.50 is the classic batch input failure. Check one amount with a thousand separator in Debug.
- Scales are set up on the condition type. The scale basis (quantity, value, weight and others), the scale type and the checking rule (ascending or descending) come from the condition type in V/06. In VK11 you select the line and go to the scales screen; SAP stores quantity scales in
KONMand value scales inKONW. - A recording replays the scale lines you typed. If you recorded three tiers, the template has three tier slots. Either split the file by number of tiers, one template per shape, or record the most tiers you need and put the extra lines in conditional blocks with IS_NOT_EMPTY, so a row with two tiers skips the third. Either way, run a two-tier and a three-tier row in Debug before the file.
Worked example: a 2027 price list for sales organisation 1010
PostNow.ai handles this with two templates and one run each. Commercial sends a file for sales organisation 1010, channel 10, condition type PR00, effective 01.01.2027: 240 material list prices, 60 customer contract prices, and one promotion for customer 100045 on material TG-1004.
- See what exists. A designer builds an SAP Query on
A004joined toKONPon the record number, filtered onPR00,1010and10. Current price and valid-to for every material land in Excel next to the new price, so a 40% jump on one line is visible before anything posts. - Build two templates. "PR00 Material (A004)" and "PR00 Customer/Material (A305)", each its own recording.
PR00is fixed, sales organisation and channel default to1010and10, Valid From is 01.01.2027 and Valid To 31.12.9999. - Let SAP end the old prices. The existing
A004records run from 01.01.2026 with no end. Each new row shortens its predecessor to 31.12.2026 at save. There is no closing file. - Load the contract prices before the promotion. The promotion is an
A305row for100045andTG-1004at 412.00 USD from 01.02.2027 to 31.03.2027. Loaded after the open-ended contract price, it splits it, and the contract price returns on 01.04.2027. Loaded before it, the contract row from 01.01.2027 covers the promotion completely, which is SAP's full-overlap case: it warns, then deletes the promotion when the contract row is saved. Same rows, opposite result. - Approve and run. If an approval policy covers the template, Run stays blocked until someone other than the submitter approves, and the approval is tied to a fingerprint of the data, so an edit after approval cancels it. Then Debug five rows, Run the rest, and Retry Failed for whatever SAP rejected.
- Prove it on an order. A test order dated 01.01.2027 for customer
100045and materialTG-1001should show theA305access in the condition analysis; the same material for a customer without a contract should showA004.
Checklist before a VK11 mass upload
PostNow.ai enforces the formats and allow-lists in the template; this list covers the pricing decisions that stay with the pricing team.
- The condition analysis on a test order shows which table the new prices must go into.
- One template per condition type and key combination, with the condition type fixed.
- Valid From and Valid To are required columns; nobody relies on the 31.12.9999 proposal for a promotion.
- Rows are sorted by key and valid-from, and full overlaps are either intended or removed.
- Rate unit, pricing unit and condition unit have allow-lists, and three rows of different units have been checked by hand.
- The decimal notation in the file matches the SAP user's defaults.
- Validate is clean, including the pre-validation that customers and materials exist.
- Five rows have run in Debug in a quality client, and VK13 shows what you expected.
- If pricing changes need a second pair of eyes, the template has an approval policy.
How to check condition records after a mass upload
PostNow.ai gives you the first check per row: the Run Log holds SAP's message for every record, and the central audit records each row's transaction, template, SAP system, client, user and result. VK11 does not return a document number, so the rest of the proof comes from SAP.
- VK13 for a sample of keys: rate, unit, pricing unit and both dates.
- Condition analysis on a test order item (Conditions tab, Analysis): which accesses SAP tried and which record it used. This is the check that catches a record in the wrong table.
- Pricing reports in V/LD (defined in V/LA) for lists of records by condition table.
- The Pricing Conditions report (SD-03) in PostNow.ai's Report Library lists condition records with condition type, validity, rate, currency, pricing unit, unit, scale basis and deletion flag in Excel. Operators can run it, under their own SAP authorisations.
- A query on the condition table itself (for example
A305joined toKONPonKNUMH) shows the validity periods SAP will use after any shortening or split, because those periods live in the condition table.
What to plan for in a VK11 upload
PostNow.ai replays VK11 exactly as recorded, so SAP's own pricing rules decide every result.
- Review overlaps and the access sequence in SAP. Validate covers formats, allowed values and master data. SAP applies its overlap rules at save and the access sequence at order time, so check existing records in VK13 and prove the table on a test order.
- Fix wrong prices forward. Stop cancels the rows not yet sent; saved records stay in SAP. Corrections are a new run with corrected rows.
- Read the record number from SAP. The Run Log holds SAP's message for each row; the condition record number (
KNUMH) sits in the condition table. - Re-test after screen changes. A new key combination, a different condition type or a changed screen after an upgrade means re-recording or at least a Debug run.
- Load future prices ahead. Recording templates run when a user starts them, so a price list effective at midnight is loaded in advance with its future valid-from date.
- Keep the PostNow.ai portal reachable for approved templates. The approval check runs against the portal; if the portal cannot be reached, the check lets the run through, so pair approvals with your other controls on production pricing.
Making a template like this repeatable for a team (designers who record, operators who only run, a published template in the central library) is the subject of Excel to SAP automation.
VK11 on S/4HANA: what changes for condition uploads
PostNow.ai uses the same VK11 recording approach on ECC and S/4HANA on-premise, because the transaction and the condition technique are still there.
- Condition records are stored as before. Condition tables (
Annn) plusKONHandKONP, with scales inKONMandKONW. - Document conditions moved. The conditions of an order or invoice now sit in
PRCD_ELEMENTSinstead ofKONV(SAP Note 2267308). That matters when you read pricing results from orders, not when you upload condition records. - The material number can be 40 characters. If the extension is active, re-record on S/4HANA rather than reusing an ECC recording, and check that long material numbers fit the column.
- Fiori offers its own import (Manage Prices – Sales, in the method table above). It suits a pricing team that already works in Fiori.
Sales orders that will price against these records are covered in VA01 mass sales order creation, and the wider SD picture in SAP SD mass upload.