Invoice Print Type - IDOC vs Form (Fragmented Forms)

[AskeH]

Hello Gurus,

I'm looking for some inspiration and war stories from you talented people.
Are we the only ones struggeling with the Print Type settings in the pricing procedure when controlling output in the our Adobe Forms as well as INVOIC IDOC?

Background: In our pricing procedure we're using Print Type to control both line item pricing display on the form as well as determine value in IDOC Segment E1EDP26 (INVOIC02). Business wants these two outpu to differ in certain countries - E.g. Form to show a set of pricing, while IDOC typically containing more.

We have tried: Changing the content of the form directly, supressing values from the Print Type setting, leaving a mismatch between Print Type and actual print. However, using the same form across multiple countries, following method significantly increases complexity.

Have any of you successfully managed to separate the Print Type setting for the form content from IDOC content? Any advice on how to implement the split?

Appreciate you time,
Best regards,
Aske

SAP S/4HANA SD (Sales and Distribution) 

[Ryan-Crosby]

We are using print type to control the behavior of line items across three pricing procedures in the print form without any problems. Difficult to know what advice to provide without knowing what problem(s) you are facing, however.

[Lakshmipathi]

Yes, the “Z-Fields in Pricing Procedure” refer to custom fields added to the pricing communication structure—typically KOMK (header) or KOMP (item)—not directly to table KOMV. These fields are then used in routines to drive logic for form and IDOC separation. Take into consideration, do not enhance KOMV directly—it’s a result table and not intended for custom fields.

To separate pricing logic for Adobe Forms vs. IDOC (INVOIC02), especially across countries, you can introduce custom Z-fields that act as flags or filters. Follow the below steps to implement

Add fields like ZPRINT_FORM → controls display in Adobe Form and ZPRINT_IDOC → controls inclusion in E1EDP26 segment for KOMK & KOMP structures. Use requirement routines in V/08 (pricing procedure config) to populate the fields and to check country and condition type. Also, the logic should ensure that the condition is shown on the form but excluded from the IDOC.

In your Adobe Form (via SmartForms or Adobe LiveCycle), filter condition types using ZPRINT_FORM. This avoids relying solely on Print Type and keeps the form logic modular.

Control IDOC Output via User Exits like EXIT_SAPLVEDF_002 → for header-level filtering & EXIT_SAPLVEDF_004 → for item-level filtering

If ZPRINT_* fields are blank, fall back to standard Print Type behavior. This ensures backward compatibility and avoids breaking legacy flows.

[AskeH]

Hi Lakshmipathi,

No – we must not enhance the result structure KOMV; it’s transient – It would take us interesting places 😅

Thank you for the elaboration! – Once again, appreciate your time and contributions to this forum!

[Lakshmipathi]

The following table summarizes the strengths, limitations, and suitability of each strategy for your use case

Given your need to separate form and IDOC logic across countries, here's a layered approach:

Introduce Custom Z-Fields in Pricing Procedure by adding two new fields: ZPRINT_FORM and ZPRINT_IDOC. Populate them via routines based on country, document type, or other business rules.

Use ZPRINT_FORM to filter which condition types are displayed. This keeps the form logic clean and avoids relying on the overloaded Print Type.

Use ZPRINT_IDOC in user exits like EXIT_SAPLVEDF_002 or EXIT_SAPLVEDF_004 to control which conditions populate E1EDP26.

Fallback Logic - If Z-fields are not populated, fall back to standard Print Type behavior to ensure backward compatibility.

[AskeH]

Thank you for taking the time Lakshmipathi

[AskeH]

Thank you for taking the time, Lakshmipathi - much appreciated!

Could I ask you to elaborate a bit on the “Z-Fields in Pricing Procedure” part of your solution?
I’m a bit unsure whether you’re referring to custom fields added to KOMV, or if you had something else in mind entirely?

Best regards,
Aske