SE71 — SAPscript Form Painter
SE71 is the maintenance transaction for SAPscript forms, used to lay out and edit the pages, windows, paragraph formats and text content behind classic print output such as invoices, delivery notes and purchase orders. The critical structural fact is that a form's layout and its per-language text content are separate objects, which is why edits often appear in one language and not another.
This page covers the SE71 SAPscript form painter transaction, its structural split between layout and per-language text, and the recurring reasons a form change does not show up on a printed output. It also covers the tables the save actually touches and how to confirm in the data whether the form or the calling print program is the real fault.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,212 words
Purpose
SE71 is the editor for SAPscript layout sets (forms). A form defines pages, the windows placed on those pages, and the paragraph and character formats applied inside them, and is used to render printed business documents - invoices, delivery notes, purchase orders, dunning letters. The structural fact that explains most confusion: a form is really two linked objects under one name. The layout structure (pages, windows, format definitions) is largely language-independent, while the actual text sitting inside a window is stored per language as a separate text object. Editing the German version of a window's content does nothing to the English version, and vice versa, even though both live under the same form name in SE71. Most 'I fixed it and it still prints wrong' tickets trace back to this split.
When it is used
SE71 is reached for when a classic print output - a document driven by SAPscript rather than Smart Forms or Adobe Forms - shows a wrong label, missing field, misaligned box, or blank window on the printed layout. Output determination (via the NAST-driven condition record on the business document) points to a form name and a print program; SE71 is where the form side of that pair is inspected and changed. It is not reached for when the form is a Smart Form or Adobe Form - those use different editors entirely, and SE71 will simply not open them. It also is not the place to fix wrong data on the printout if the data was never passed by the print program; that fix belongs on the ABAP side, not in the layout.
How to use it in practice
- Call SE71, enter the form name and the language variant to check or edit, then display or change.
- Confirm which version is active versus the one being edited before assuming a saved change is live.
- Navigate to the relevant page and window - multi-page forms often repeat the same field on a different window that also needs editing.
- Use the Format menu to inspect or change paragraph and character formats rather than free-typing formatting into the window text.
- Check the linked print program (source code / calling program reference) to see which fields the ABAP side actually passes into the window symbols.
- Preview or test print the form before activating, then activate and transport the change as a text object.
Key data objects
- STXH - the SAPscript text object header, keyed by object type FORM, form name, text ID and language, holding line count, active/inactive status and last change information.
- STXL - the actual layout and text lines referenced from STXH: window content, paragraph tags, and embedded formatting commands.
- TTXOB and TTXID - configuration tables registering FORM as a valid text object type and defining the text IDs (windows) a form can carry.
- NAST - not written by SE71, but the runtime record that stores which form name and print program were actually resolved for a given business document and output type; the object to check on the calling side.
How to prove it in the data
Query STXH filtered on object type FORM, form name, and language, and compare the active-flag and change-timestamp fields against what SE71 displays for that same form and language - a saved-but-inactive version explains why nothing changed on print. Read STXL for the matching key to see the actual stored window content rather than trusting the editor screen alone. Separately, pull the NAST entries for the failing document by output type and date to confirm which form name and print program were resolved at runtime, since a mismatch there means the wrong form was never the one printed at all.
ECC vs S/4HANA
SAPscript and SE71 continue to work on S/4HANA for forms that have not been migrated; SAP's direction for new form development is Adobe Forms, maintained through different transactions, not SE71. There is no Fiori app equivalent to SE71 and no functional change to the transaction itself on S/4HANA. It remains a legacy-maintenance tool, used specifically when an existing SAPscript-based output has not yet been converted.
Common pitfalls and how to diagnose them
- Language split: a fix made in one language's text object does not propagate to any other language. Check STXH for the specific TDSPRAS in question before assuming the fix is global.
- Not activated: the edited layout was saved but never activated, so the print program keeps calling the previous active version. Compare the active flag and timestamp between the working and edited versions before touching anything else.
- Transport gap: the form is a separate transportable text object from the ABAP print program that calls it. A developer transports the print program logic and forgets the form itself, or the reverse, leaving dev and QA out of sync.
- Print program mismatch: the window in SE71 looks correct but the field is blank because the calling ABAP program never populated that symbol via its WRITE_FORM or equivalent call. This is not fixable inside SE71 at all and needs the print program checked.
- Buffer lag: forms are buffered on the application server; a change activated in the system may not appear on the next print job until the buffer is refreshed or the work process is restarted, which looks identical to 'the change didn't save'.
- Wrong window edited: multi-page forms repeat similar-looking windows across pages (main window versus a constant header/footer window), and a fix applied to the wrong one leaves the visible symptom unchanged.
- Cross-client visibility: SAPscript forms are cross-client objects inside a system. A change made and activated in one client is visible in every client of that same system immediately, which surprises anyone expecting client-specific isolation and can also mean a change made 'for testing' in a shared system affects users in other clients right away.
Whose problem this is
Functional consultants identify what is wrong on the printed output and which document, output type and language reproduce it. ABAP or development owns the SAPscript layout edit and the print program logic behind it. A clean handover states the form name, language, output type, the NAST record for the failing document, and a screenshot or printout showing exactly what field or layout is wrong.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/se71ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.