Lord en

Enhancement Options for the Lean Order Interface
Introduction..................................................................................................................................2
Fictitious Example Object.............................................................................................................2

2.1
Dynpro ...................................................................................................................................2
2.2
Flow Logic..............................................................................................................................2
2.3
Event PBO .............................................................................................................................3
2.3.1
Data Preparation............................................................................................................3
2.3.2
Visibility and Ready-for-Input Status...............................................................................4
2.4
3
Event PAI ...............................................................................................................................4
Mapping in the Lean Order Framework ........................................................................................5

3.1
Communication Structures......................................................................................................5
3.2
Mapping Tables......................................................................................................................6
3.3
Events PBO and PAI ..............................................................................................................6
Enhancement Options..................................................................................................................8
4.1
New Fields in the Communication Structure............................................................................9
4.2
New Entries in the Mapping Table ........................................................................................10
4.3
Enhancement of the PBO Logic............................................................................................10
4.4
Providing Ready-for-Input Status ..........................................................................................12
4.5
Enhancement of the PAI Logic..............................................................................................12
Enhanceable Lean Order Objects...............................................................................................14
Prerequisites, Constraints, and Recommendations.....................................................................19

6.1
Decoupling ...........................................................................................................................19
6.2
Reusing Module Logic ..........................................................................................................20
6.3
Using System Fields.............................................................................................................20
6.4
Identifying the LORD Mode...................................................................................................20
6.5
Function Code Processing....................................................................................................20
Introduction
The Lean Order framework provides access to the sales document processing business logic. The procedure of
reading and changing object data largely follows the logic implemented in the processing transactions VA01,
VA02, VA21, and so on (VA transactions).
Unlike these transactions, however, the business logic available in Lean Order (LORD) is decoupled from SAP
GUI for Windows, since the interface itself does not provide any UI elements and theoretically can / should
deliver the data for any UI.
Reusing the business logic implemented in a VA transaction depends greatly on the extent to which the corresponding routines are decoupled. If this prerequisite is not fulfilled, modifications need to be made to integrate
formatting routines and processing routines into the Lean Order framework.
Using the LORD interface, the business logic fields to be read and changed can be addressed via object-specific
communication structures and tables.
The communication structures make up a kind of field catalog that provides a comprehensive yet restricted selection of fields for specific objects in sales document processing. However, not all of the fields that are available
and visible in the classic VA transaction are automatically provided by the interface. In a standard system, this
applies mostly to customer-specific fields and sometimes to industry-specific fields. It is therefore necessary to
be able to access these fields using an enhancement concept.
The first section of this documentation contains a fictitious example of how to map a standard object in the Lean
Order environment. You then get detailed information about the enhancement options.
Fictitious Example Object
In this simple example, the subobject DATA of the business logic illustrates how the business logic in the standard VA transaction is abstracted using the Lean Order interface. Since decoupling is an essential prerequisite
here, the example is presented under ideal conditions, where all the prerequisites for integration into the Lean
Order framework are already fulfilled.
2.1
Dynpro
This example is a form embedded in the VA transaction as a detail screen (dynpro 1111). The UI elements on
this screen are three input fields and their corresponding description texts. The fields on the dynpro are the component fields of structure GS_DATA (DDIC type TDS_DATA).
Dynpro 1111
2.2
Flow Logic
The following illustrates the flow logic for dynpro 1111:
Flow Logic of Dynpro 1111 in Program SAPMV45A (fictitious example)

process before output.
module prepare_data_module.
module modify_screen_module.
process after input.
field gs_data-field1.
field gs_data-field2
module check_data_field2_module on request.
chain.
field: gs_data-field2,
gs_data-field3.
module check_data_field23_module on chain-request.
endchain.
chain.
gs_data-field2,
gs_data-field3.
module process_data_module on chain-request.
endchain.
The flow logic of the corresponding dynpro defines how the data is read and changed in the transactional dialog.
There are two different events:
Process before Output (PBO)
Process after Input (PAI)
2.3
Event PBO
Event PBO should contain all the process steps required to format the data so that it can be displayed. This event
also defines which fields should be visible or ready for input.
It is essential that these two subprocesses are clearly separated so that data preparation and determining the
ready-for-input status do not interfere with each other.
2.3.1
Data Preparation
In this example, the data is formatted in the PREPARE_DATA_MODULE. In this module, the data elements
that are linked to the UI elements of the dynpro are allocated (default) values.
Since dynpro modules cannot be called directly within the LORD framework, only form routines that have no
parameters (such as PREPARE_DATA_FORM) should be called in the module. Any number of form routines
can be called.
If this prerequisite is not fulfilled in the module, these types of form routine should be created and the program
logic called in the module should be moved to them.
We recommend differentiating between screen fields that can only be displayed and fields that can generally or
potentially be changed.
In accordance with this criterion, we also recommend storing the fields in different communication structures in
the LORD environment. This way, the fields that can only be displayed do not need to be transferred via the
LORD interface when a change is made.
In this example, the PBO module PREPARE_DATA_MODULE therefore also contains an additional, separate
routine for formatting the fields that are read-only. These fields are usually descriptions for related key fields or
Customizing information that cannot be changed at runtime.
Module PREPARE_DATA_MODULE
module prepare_data_module output.
perform prepare_data_form in program sapmv45a.
perform prepare_descr_form in program sapmv45a.
endmodule.
2.3.2
Visibility and Ready-for-Input Status
In the above example, the PBO module MODIFY_SCREEN_MODULE is intended to predefine the ready-forinput status of each field, for example.
In this module, a loop pass runs for each screen element. The SCREEN system structure should be passed on to a
form routine as a change parameter (form MODIFY_SCREEN_FORM, in this case). The business criteria and
the process-oriented criteria for defining the ready-for-input status are contained in this form routine. These
criteria are used to set the SCREEN-INPUT, SCREEN-ACTIVE, and SCREEN-INVISIBLE attributes, for example. It is important that the screen attributes are updated outside of the form routine using the command
'MODIFY SCREEN'.
Module MODIFY_SCREEN_ MODULE

module modify_screen_module output.
loop at screen.
perform modify_screen_form in program sapmv45a
changing screen.
modify screen.
endloop.
endmodule.
2.4
Event PAI
The PAI event contains not only the field transports from the corresponding FIELD commands, but also all the
process steps required to validate and process the data entered. The modules are sometimes called conditionally, which means that the 'ON REQUEST' or 'ON CHAINREQUEST' commands are completed when they are
called.
As regards decoupling, the same applies as for the modules in PBO the modules themselves should not contain
a programmed business logic. Instead, the logic should be moved to corresponding form routines that have no
parameters.
In this example, this results in the following module implementations:
Module CHECK_DATA_FIELD2_MODULE
module check_data_field2_module input.
perform check_data_field2_form in program sapmv45a.
endmodule.
Module PROCESS_DATA_MODULE
module process_data_module input.
perform process_data_form in program sapmv45a.
endmodule.
Mapping in the Lean Order Framework
As mentioned in the introduction, the Lean Order framework is based to a great extent on the formatting steps
and processing steps being called similarly to how they are called in the dynpro flow logic in the VA transaction.
This includes the mechanisms of the explicit and sequential field transport, as well as the conditional call of
validation and processing logics.
As a result, the LORD framework also defines events for the individual objects. PBO-specific and PAI-specific
routines are called in these events.
The following sections contain information about how the existing routines are integrated into the corresponding
LORD class methods.
As well as the subobject DATA, a fictitious LORD object (object ID = DATA) is used, which is represented by
the object-specific class CL_LORD_DATA.
3.1
Communication Structures
The fields visible on the screen are mapped as communication structures and divided into two groups: potentially
ready-for-input fields (COMV structure) and fields that are never ready-for-input (COMR structure).
COMV Structure:
COMR Structure:
DDIC Structure TDS_DATA_COMV

Component
Component type Description
HANDLE
GUID_32
Handle
FIELD1
FIELD1_TYPE
Field 1
FIELD2
FIELD2_TYPE
Field 2
FIELD3
FIELD3_TYPE
Field 3
DDIC Structure TDS_DATA_COMR

Component
HANDLE
GUID_32
Handle
FIELD1_T
DESCR_TYPE
Description: Field 1
FIELD2_T
DESCR_TYPE
FIELD3_T
DESCR_TYPE
In parallel to the COMV structure, a COMC structure is created in the DDIC. This structure contains components that are fields with the same name as each of the fields in the COMV structure, but have component type
CHAR1.
COMC Structure:
DDIC Structure TDS_DATA_COMC

Component
Component type
Description
HANDLE
GUID_32
Handle
FIELD1
CHAR1
Single-character indicator
FIELD2
CHAR1
FIELD3
CHAR1
This structure is used when the data is read (using GET methods) as an additional information carrier so that the
appropriate ready-for-input status is provided for each field in the COMV structure. The relevant GET methods
provide a COMI structure ('I' as in Input Mode) that is the same type as the COMC structure.
When data is changed (using SET methods), the COMC structure acts as a COMX structure (checkbox). Like the
BAPIs, the fields in the COMX structure whose values in the corresponding COMV structure fields are to be
considered as changed require an 'X'.
3.2
Mapping Tables
A mapping table is used to define the assignment of a field in the communication structure to a field in the business logic. COMV fields and COMR fields have their own distinct mapping tables.
Mapping Tables:
LORD_MAPPING
LORD_MAPPING_RO
The mapping table contains the following attributes:

OBJECT:
FIELD:
FIELD_INTERNAL:
REPID:
DYNNR:
Object ID of the object to which the field belongs

Name of the field in the LORD interface
Name of the field in the business logic
Framework program in which the field in the business
logic is defined or known
Number of the dynpro where the business logic
field can be found, presuming it is visible on a UI
of the VA transaction. This is used to determine the static screen attributes
such as visibility and ready-for-input status.
In this example, the fields of structures TDS_DATA_COMV and TDS_DATA_COMR are assigned as follows
to the fields of structure GS_DATA:
Mapping:
Entries in LORD_MAPPING for object DATA

OBJECT FIELD
FIELD_INTERNAL REPID
DYNNR
DATA
FIELD1 GS_DATA-FIELD1 SAPMV45A 1111
DATA
DATA
Entries in LORD_MAPPING_RO for object DATA

OBJECT FIELD
3.3
FIELD_INTERNAL
REPID
DATA
FIELD1_T GS_DATA-FIELD1_T SAPMV45A
DATA
DATA
Events PBO and PAI
The PBO and PAI events are mapped using corresponding methods that are called by the framework for the
requested objects.
At event PBO, the DO_PBO_SINGLE and DO_PBO_SINGLE_RO methods are called, which contain the formatting routines for the changeable and non-changeable fields (separately).
In our example, the form routines called in the methods are the same as those used in the dynpro modules. This
ensures that existing program logic is reusable, and reusability should always be a prime objective. Note that this
is only possible if there is no dynpro-like programming in the form routines.
Method DO_PBO_SINGLE
method do_pbo_single.
endmethod.
Method DO_PBO_SINGLE
method do_pbo_single_ro.
endmethod.
The ready-for-input status of the fields is determined using the GET_INPUT_MODE method, in which the
MODIFY_SCREEN_FORM form routine is also called as in the module MODIFY_SCREEN_MODULE. The
system gets the screen information from the allocation of the dynpro number in the mapping table
LORD_MAPPING. If there is no assignment, make sure that only the IS_SCREEN-NAME attribute is filled. All
of the other attributes, especially SCREEN-ACTIVE, are initial or have the value zero. With this particular data
constellation, it is necessary to set the attributes explicitly in the form routine MODIFY_SCREEN_FORM.
Method GET_INPUT_MODE
method get_input_mode.
data: ls_screen type screen.
ls_screen = is_screen.
perform modify_screen_form in program sapmv45a changing ls_screen.
es_screen = ls_screen.
endmethod.
At event PAI, the DO_PAI_SINGLE method is called, which maps the sequential field transports and the (conditional) calls of the check routines and processing routines using internal utility methods (methods SET_FIELD
and CALL_MODULE).
By using the defined mapping relationship between the interface field FIELD1 of the COMV structure and
FIELD1 of the GS_DATA structure, the business logic causes the
SET_FIELD( 'FIELD1' )
method to be called similarly to the command
FIELD GS_DATA-FIELD1
in the flow logic of the dynpro.
When the CALL_MODULE method is called, it does not call a PAI module, but the form routine that is called in
a module. The IV_ON_CHECK parameter controls that the routine is only called if fields have changed that
were transported using the SET_FIELD method.
Method DO_PAI_SINGLE
method do_pai_single.
call_module( iv_module
= 'FILL_DATA_FORM'
iv_program
do_submit( ).
= 'SAPMV45A' ).
set_field( 'FIELD1' ).
do_submit( ).
= 'CHECK_DATA_FIELD2_FORM'
iv_program = 'SAPMV45A'
iv_on_check = R ).
do_submit( ).
iv_on_check = 'R' ).
do_submit( ).
do_submit( ).
= 'PROCESS_DATA_FORM'
do_submit( ).
endmethod.
Enhancement Options
The Lean Order interface provides the option of integrating customer-specific fields and processing logics. The
relevant conditions and constraints are described below.
Generally, the enhancements planned in the LORD environment should be based on the enhancements that already exist in the VA transaction.
In this context, we can assume that the following enhancements will also be considered in the LORD environment:
Enhancements that have been implemented in existing user exits or BAdIs
Enhancements that are processed in VA transaction document processing
In the following, a modified version of our example is used to illustrate the enhancement options and explain
which BAdI implementations are required.
The figure below shows the modified dynpro 1111, which now has an additional, customer-specific input field
with a description.
Modified Dynpro 1111
This additional input field is linked to the customer field ZZMYFIELD of the enhanced structure GS_DATA.
The technical name of the description field is GS_DATA-ZZMYFIELD_T.
4.1
New Fields in the Communication Structure
To enable access to additional customer fields in the LORD interface, the corresponding communication structures must be enhanced. To do this, you define an append structure that contains the required fields. This applies to all three types of communication structure (COMV, COMR, and COMC structures).
COMV Structure:
COMV Append:
DDIC Structure TDS_DATA_COMV

Component Component type
Description
HANDLE
GUID_32
Handle
FIELD1
FIELD1_TYPE
Field 1
FIELD2
FIELD2_TYPE
Field 2
FIELD3
FIELD3_TYPE
Field 3
.APPEND
ZZAPP_DATA_COMV Append Structure
Append structure ZZAPP_DATA_COMV

Component
Component type
Description
ZZMYFIELD ZZMYFIELD_TYPE My Data Field
COMR Structure:
COMR Append:
DDIC Structure TDS_DATA_COMR

Description
HANDLE
GUID_32
Handle
FIELD1_T
DESCR_TYPE
Description: Field
FIELD2_T
DESCR_TYPE
Description: Field
FIELD3_T
DESCR_TYPE
Description: Field
.APPEND
ZZAPP_DATA_COMR Append Structure
Append Structure ZZAPP_DATA_COMR

Component
ZZMYFIELD_T DESCR_TYPE
Description: Field
COMC Structure:
COMC Append:
DDIC Structure TDS_DATA_COMC

Description
HANDLE
GUID_32
Handle
FIELD1
CHAR1
One-character indicator
FIELD2
CHAR1
FIELD3
CHAR1
.APPEND
ZZAPP_DATA_COMC Append Structure
Append-Structure ZZAPP_DATA_COMC
Component Component type Description
ZZMYFIELD CHAR1
4.2
New Entries in the Mapping Table
The new fields in the communication structures must be assigned to the corresponding fields in the business
logic. These assignments are defined in mapping tables.
Mapping:
Entry in LORD_MAPPING for object DATA

OBJECT FIELD
DATA
FIELD_INTERNAL
REPID
DYNNR
ZZMYFIELD GS_DATA-ZZMYFIELD SAPMV45A 1111
Entry in LORD_MAPPING_RO for object DATA

OBJECT FIELD
DATA
4.3
FIELD_INTERNAL
REPID
ZZMYFIELD_T GS_DATA-ZZMYFIELD_T SAPMV45A
Enhancement of the PBO Logic
If formatting for the newly added field is done in the VA transaction by calling an additional PBO module, you
can have the LORD framework use a LORD-specific BAdI to call the form routines that were called in the
module.
Modified Flow Logic at Event PBO (Dynpro 1111)

module prepare_data_module.
* >>> start of modification <<<<
module zzprepare_mydata_module
* >>>> end of modification <<<<<
module modify_screen_module.
...
Generally, it does not matter where the additional formatting routines are called. This can occur in modified form
in an existing PBO module, as in the following example.
Modified Module PREPARE_DATA_MODULE

module prepare_data_module output.
* >>> start of modification <<<<
perform zzprepare_mydescr_form in program sapmv45a.
* >>>> end of modification <<<<<
endmodule.
To integrate the additional formatting routines into the LORD framework, it is necessary to create a class for the
LORD object DATA, which is to be enhanced (for example, class ZZCL_LORD_INTF_SUPPLY_DATA). This
class implements the IF_LORD_INTF_SUPPLY interface. This interface contains the DO_PBO_SINGLE
method, for example. The calls of the additional formatting routines can now be placed in the method implementation.
Implementation of IF_LORD_INTF_SUPPLY~DO_PBO_SINGLE (Example)

method if_lord_intf_supply~do_pbo_single.
perform zzprepare_mydata_form
in program sapmv45a
if found.
perform zzprepare_mydescr_form
in program sapmv45a
if found.
endmethod.
In the FILL_SUPPLY_LIST method implementation of the IF_BADI_LORD_DO_PBO BAdI interface, the

CT_SUPPLY change parameter can be used to make the reference of the IF_LORD_INTF_SUPPLY interface
available to the LORD framework (dependent on the object ID). In this case, the LORD framework calls the
IF_LORD_INF_SUPPLY~DO_PBO_SINGLE method as well as the additional formatting routines.
Implementation of IF_BADI_LORD_DO_PBO~FILL_SUPPLY_LIST (Example)

method if_badi_lord_do_pbo~fill_supply_list.
* With the parameter IV_OBJECT_ID the actual LORD-object is identified
case iv_object_id.
when 'DATA'.
*
The object DATA does need additional preparation steps:
*
Return its implementing instance (created centrally within the
*
CLASS_CONSTRUCTOR of this class)
insert gr_intf_supply_data into table ct_supply.
return.
endcase.
endmethod.
The class constructor of the implementation class of the above BADI might look as follows:
Implementation of Class Constructor (Example)

method class_constructor.
...
...
* create supply instances
create object gr_intf_supply_data type ref to zzcl_lord_intf_supply_data.
...
endmethod.
4.4
Providing Ready-for-Input Status
If the ready-for-input status of the new field has not already been provided by existing user exits or BAdIs of the
business logic (such as USEREXIT_FIELD_MODIFICATION in include MV45AFZZ), it can be defined for
each field using the BADI_LORD_GET_INPUT_MODE BAdI.
Implementation of IF_BADI_LORD_GET_INPUT_MODE~GET_INPUT_MODE (Example)

method if_badi_lord_get_input_mode~get_input_mode.
data: ls_screen type screen.
case iv_object_id.
when 'DATA'.
if iv_field eq ZZMYFIELD.
ls_screen = is_screen
...
perform zzmodify_myscreen_form in program sapmv45a
changing ls_screen.
es_screen = ls_screen.
endif.
endcase.
endmethod.
4.5
Enhancement of the PAI Logic
At event PAI, the ZZCHECK_DATA_MYFIELD_MODULE check module is called for the new field and it in
turn calls the ZZCHECK_DATA_MYFIELD_FORM form routine.
In addition, the PROCESS_DATA_MODULE processing module should be called if the content of the new field
has changed.
Modified Flow Logic at Event PAI (Dynpro 1111)

...
field gs_data-field1.
chain.
gs_data-field3.
module check_data_field23_module on chain-request.
endchain.
* >>> start of insertion (modification) <<<

field gs_data-zzmyfield
module zzcheck_data_myfield_module on request.
* >>>> end of insertion (modification) <<<<
*
*
*
*
*
chain.
gs_data-field2,
>>> start of deletion (modification) <<<<
gs_data-field3.
>>>> end of deletion (modification) <<<<<
>>> start of insertion (modification) <<<
gs_data-field3,
gs_data-zzmyfield.
>>>> end of insertion (modification) <<<<
module process_data_module on chain-request.
endchain.
The LORD framework provides BAdIs that enable these additional PAI commands to be considered.
The DO_PAI_SINGLE method is shown below. There are additional method calls (indicated by the blue comments), which contain the relevant BAdI calls for enhancing the PAI logic.
Method DO_PAI_SINGLE (including utility methods with BAdI enhancements)

do_submit( ).
iv_on_check = R ).
do_submit( ).
do_submit( ).
do_submit( ).
do_pai_single_add( ).
call of BADI_LORD_DO_PAI
set_field_add( PROCESS_DATA_FORM ). call of BADI_LORD_DO_PAI
= 'PROCESS_DATA_FORM'
do_submit( ).
endmethod.
It is possible implement additional PAI logic here using the BADI_LORD_DO_PAI BAdI.
With this BAdI, additional entries can be created for the (internal) GT_SUPPLY table containing the commands
for field transports and form routine calls. This means that customer-specific check routines can be called for
new fields. The BAdI is called before the main processing routine of the corresponding object is processed.
Implementation of IF_BADI_LORD_DO_PAI ~FILL_SUPPLY_LIST (Example)

method if_badi_lord_do_pai~fill_supply_list.
data: ls_supply type tds_field_supply.
*
*
*
*
if iv_object_id eq DATA.
field gs_data-zzmyfield
module zzcheck_data_myfield_module on request.
ls_supply-field = 'ZZMYFIELD'.
append ls_supply to ct_supply.
clear ls_supply.
ls_supply-module = ZZCHECK_DATA_MYFIELD_FORM.
ls_supply-program = SAPMV45A.
ls_supply-on_check = R.
separation for next statement block
by initial line
append initial line to ct_supply.
...
endif.
endmethod.
To call the main processing routine (PROCESS_DATA_FORM) because the new field has changed, the BAdI
interface provides the ADD_SUPPLY_LIST method for adding more fields to the list of fields of the chainendchain command.
Implementation of IF_BADI_LORD_DO_PAI ~ADD_SUPPLY_LIST (Example)

method if_badi_lord_do_pai~add_supply_list.
if iv_object_id eq DATA.
if iv_module eq 'PROCESS_DATA_FORM'.
ls_supply-field = 'ZZMYFIELD'.
endif.
endif.
endmethod.
Enhanceable Lean Order Objects
The enhancement concept of the LORD framework is based on an object-independent, generic approach. Nevertheless, the enhancement by additional fields is only supported for the objects HEAD and ITEM.
An essential prerequisite is that any additionally requested field is already part of the business logic, that is, the
fields are already integrated and used in the VA transaction.
The following structures in the business logic are available for referencing their components using additional
fields in the enhanced communication structure of the LORD interface:
Header Area (object HEAD)
o
VBAK
Header data of sales document
VBKD
Business data (header)
RV45A
Data fields for SAPMV45A
TVAK
Customizing order type
Item Area (object ITEM)

o
VBAP
Item data
VBAPD
Item data (dynamic part)
VBKD
Business data (item)
RV45A
Data fields for SAPMV45A
TVAP
Customizing item category
In addition to the standard fields in the structures mentioned, customer-specific fields can also be referenced if
they are part of these structures.
If the LORD interface is to be enhanced by non-changeable fields (COMR structure), it is also possible to refer
to fields that do not belong to the standard structures mentioned. In this case, it is probably necessary to use
BAdIs to provide additional formatting routines for event PBO.
In addition to the objects HEAD and ITEM, the LORD framework also provides the subobjects HDATAA and
HDATAB at header level and IDATAA and IDATAB at item level (see SAP Note 1228985 if the objects are not
available in your system).
These LORD objects do not contain any business logic. They merely provide empty object frameworks within
the LORD framework that can be supplied with business logic using the BAdIs mentioned above. This make it
possible to map header-dependent or item-dependent objects such as additional data in the LORD framework,
for example.
These object frameworks are represented by the following classes and object IDs:
Class CL_LORD_HDATAA,
Object ID = HDATAA
Class CL_LORD_HDATAB,
Object ID = HDATAB
Class CL_LORD_IDATAA,
Object ID = IDATAA
Class CL_LORD_IDATAB,
Object ID = IDATAB
The relevant communication structures only contain the HANDLE component (type GUID_32).
TDS_HDATAA_COMV, TDS_HDATAA_COMR, and TDS_HDATAA_COMC
TDS_HDATAB_COMV, TDS_HDATAB_COMR, and TDS_HDATAB_COMC
TDS_IDATAA_COMV, TDS_IDATAA_COMR, and TDS_IDATAA_COMC
TDS_IDATAB_COMV, TDS_IDATAB_COMR, and TDS_IDATAB_COMC
The next example of a fictitious customer-specific dynpro 9111 in SAPMV45A, which is similar to the previous
example, gives you a better overview of how customer-specific subobjects can be integrated into the LORD
framework. The only difference is that all the fields in this example are customer-specific and that the customer
defined the entire flow logic.
The following program lines illustrate the flow logic of dynpro 9111:
Flow Logic of Dynpro 9111 in Program SAPMV45A (fictitious customer-specific example)

module zzprepare_data_module.
module zzmodify_screen_module.
field zzgs_data-field1.
field zzgs_data-field2
module zzcheck_data_field2_module on request.
field zzgs_data-field3
module zzcheck_data_field3_module on request.
chain.
field: zzgs_data-field2,
zzgs_data-field3.
module zzcheck_data_field23_module on chain-request.
endchain.
chain.
field: zzgs_data-field1,
zzgs_data-field2,
zzgs_data-field3.
module zzprocess_data_module on chain-request.
endchain.
To enable access to these customer-specific fields via the LORD interface, the LORD object HDATAA is enhanced, for example.
This is done by enhancing the relevant communication structures using an append structure that contains the
interface fields. It is important that the component names of the fields in the append structure begin with 'ZZ' or
'YY' since the fields must later be entered in the mapping tables, which have a corresponding customer-specific
namespace.
COMV Structure:
COMV Append:
DDIC Structure TDS_HDATAA_COMV

Description
HANDLE
GUID_32
Handle
.APPEND
ZZAPP_HDATAA_COMV Append structure
Append Structure ZZAPP_HDATAA_COMV

COMR Structure:
COMR Append:
ZZFIELD1
FIELD1_TYPE
My Field 1
ZZFIELD2
FIELD2_TYPE
My Field 2
ZZFIELD3
FIELD3_TYPE
My Field 3
DDIC Structure TDS_HDATAA_COMR

Description
HANDLE
GUID_32
Handle
.APPEND
ZZAPP_HDATAA_COMR Append structure
Append Structure ZZAPP_HDATAA_COMR
COMC Structure:
COMC Append:
ZZFIELD1_T DESCR_TYPE
Description: Field
Description: Field
Description: Field
DDIC Structure TDS_HDATAA_COMC

Description
HANDLE
GUID_32
Handle
.APPEND
ZZAPP_HDATAA_COMC Append Structure
Append Structure ZZAPP_HDATAA_COMC

ZZFIELD1
CHAR1
ZZFIELD2
CHAR1
ZZFIELD3
CHAR1
The fields of structures TDS_HDATAA_COMV and TDS_HDATAA_COMR are assigned to the fields of the
ZZGS_DATA structure, which are used in this example. The customer namespace of the key fields of the mapping tables must be taken into account here.
Mapping:
New entries in LORD_MAPPING for object HDATAA

OBJECT FIELD
FIELD_INTERNAL
REPID
DYNNR
HDATAA ZZFIELD1 ZZGS_DATA-FIELD1 SAPMV45A 9111

New entries in LORD_MAPPING_RO for object HDATAA

OBJECT FIELD
FIELD_INTERNAL
REPID
HDATAA ZZFIELD1_T ZZGS_DATA-FIELD1_T SAPMV45A

For event PBO, the formatting routines and the definition of the ready-for-input status should be implemented
using BAdIs as described above.
For the standard PAI logic, the following LORD-specific implementation for the enhanced HDATAA object
would be used:
Method DO_PAI_SINGLE (for the enhanced object HDATA, expected)
set_field( 'ZZFIELD1' ).
do_submit( ).
= 'ZZCHECK_DATA_FIELD2_FORM'
iv_on_check = R ).
do_submit( ).
do_submit( ).
do_submit( ).
= 'ZZPROCESS_DATA_FORM'
do_submit( ).
endmethod.
However, the real implementation of method DO_PAI_SINGLE for the object HDATAA would look like this:
Method DO_PAI_SINGLE (for object HDATA, given)
endmethod.
Only a utility method is called here, which in turn contains a BAdI call. Since the entire flow logic is defined by
the customer, it must be implemented using the BADI_LORD_DO_PAI BAdI by filling the supply table.
Implementation of IF_BADI_LORD_DO_PAI ~FILL_SUPPLY_LIST (example for enhanced object

HDATAA)
method if_badi_lord_do_pai~fill_supply_list.
if iv_object_id eq HDATAA.
clear ls_supply.
ls_supply-field = 'ZZFIELD1'.
*

clear ls_supply.
clear ls_supply.
ls_supply-module = ZZCHECK_DATA_FIELD2_FORM.
*

clear ls_supply.
clear ls_supply.

clear ls_supply.
clear ls_supply.
clear ls_supply.

clear ls_supply.
clear ls_supply.
clear ls_supply.
clear ls_supply.
ls_supply-module = ZZPROCESS_DATA_FORM.
endif.
endmethod.
Prerequisites, Constraints, and Recommendations
6.1
Decoupling
The prerequisite for integrating processing logic that is processed in the VA transaction into the LORD framework is that the business logic is decoupled from SAP GUI for Windows.
None of the commands used to map dialogs in SAP GUI for Windows (such as CALL SCREEN) are
supported by the LORD interface and can lead to problems or errors.
If the Lean Order interface is called or used, the corresponding business logic is executed in a dialogfree session, similar to a BAPI.
It is not possible to call screens or popups. Yes/No decisions or selection dialogs should not be used or
should be avoided by using default decisions.
6.2
Reusing Module Logic
In the LORD framework, it is not possible to call modules of dynpro flow logics directly. In the example above,
the prerequisite was that the logic was mapped in the module solely by form routines without parameters. These
form routines can be called by the LORD framework, and we recommend that you configure your customerspecific modules in the same way.
6.3
Using System Fields
In many routines (standard and customer-specific), system fields such as SY-TCODE, SY-CPROG, SY-REPID
or SY-DYNNR are used to control or restrict the program logic.
When using the Lean Order interface, the processing logic is called in a different environment than in the VA
transactions. This is reflected especially in system fields that may contain changed or initial values that are not
expected or cannot be evaluated.
For example, the SY-TCODE field does not contain values such as 'VA01' or 'VA22' in LORD mode, even if the
user is creating a sales order or changing a quotation. We also advise against querying the SY-DYNNR field
since there is no reference to a UI in the LORD mode and therefore no dynpro numbers are known.
For the transaction code, we recommend replacing queries on SY-TCODE by queries on T180-TCODE in
routines that are processed during sales document processing (program SAPMV45A and others).
6.4
Identifying the LORD Mode
To find out if the program logic is run via the LORD interface or via the VA transaction, there are specific parameters that can be queried. This makes it possible to provide alternative process logics based on these parameters, or to bypass certain process steps if they cannot be supported in the LORD mode.
If sales document processing is processed via the Lean Order interface, the following parameters are set:
CALL_FUNCTION
This parameter has the value 'X' in the LORD mode. The value is also set in BAPI mode. However, the
BAPI indicator CALL_BAPI is not set in LORD mode. The CALL_FUNCTION parameter is declared
in the MV45ACOM include and thus available in all programs that access this declaration.
CALL_ACTIVITY
This parameter has the value 'LORD' in the LORD mode. This parameter is declared in the
MV45ACOM include and thus available in all programs that access this declaration.
It is generally possible to call the DIALOG_GET_STATUS function module to find out if the business logic is
processed without any dialogs, which is the case in LORD mode.
6.5
Function Code Processing
Function code processing (FCODE) is not supported in the same way as it is in the VA transaction.
The LORD interface is designed to read and change data. Some activities can also be carried out for the object
data (such as deletion, pricing, ATP check). In these cases, however, program logic is processed that only contains commands for the activity to be executed.
Program logic for formatting, checking, and processing data should be independent and separate from any activities or function codes. In this context, note that next screen processing is not used in the LORD environment.

Lord en

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Lord en

Загружено:

Авторское право:

Доступные форматы

Enhancement Options for the Lean Order Interface

Fictitious Example Object.............................................................................................................2

Event PBO .............................................................................................................................3

Visibility and Ready-for-Input Status...............................................................................4

Event PAI ...............................................................................................................................4

Mapping in the Lean Order Framework ........................................................................................5

Events PBO and PAI ..............................................................................................................6

New Fields in the Communication Structure............................................................................9

New Entries in the Mapping Table ........................................................................................10

Enhancement of the PBO Logic............................................................................................10

Providing Ready-for-Input Status ..........................................................................................12

Enhancement of the PAI Logic..............................................................................................12

Enhanceable Lean Order Objects...............................................................................................14

Prerequisites, Constraints, and Recommendations.....................................................................19

Reusing Module Logic ..........................................................................................................20

Using System Fields.............................................................................................................20

Identifying the LORD Mode...................................................................................................20

Function Code Processing....................................................................................................20

Fictitious Example Object

The following illustrates the flow logic for dynpro 1111:

Flow Logic of Dynpro 1111 in Program SAPMV45A (fictitious example)

Visibility and Ready-for-Input Status

Module MODIFY_SCREEN_ MODULE

Mapping in the Lean Order Framework

DDIC Structure TDS_DATA_COMV

Component type Description

DDIC Structure TDS_DATA_COMR

Component type Description

DDIC Structure TDS_DATA_COMC

The mapping table contains the following attributes:

Object ID of the object to which the field belongs

Entries in LORD_MAPPING for object DATA

FIELD1 GS_DATA-FIELD1 SAPMV45A 1111

FIELD2 GS_DATA-FIELD2 SAPMV45A 1111

FIELD3 GS_DATA-FIELD3 SAPMV45A 1111

Entries in LORD_MAPPING_RO for object DATA

FIELD1_T GS_DATA-FIELD1_T SAPMV45A

FIELD2_T GS_DATA-FIELD2_T SAPMV45A

FIELD3_T GS_DATA-FIELD3_T SAPMV45A

Events PBO and PAI

New Fields in the Communication Structure

DDIC Structure TDS_DATA_COMV

ZZAPP_DATA_COMV Append Structure

Append structure ZZAPP_DATA_COMV

ZZMYFIELD ZZMYFIELD_TYPE My Data Field

DDIC Structure TDS_DATA_COMR

ZZAPP_DATA_COMR Append Structure

Append Structure ZZAPP_DATA_COMR

Component type Description

DDIC Structure TDS_DATA_COMC

ZZAPP_DATA_COMC Append Structure

New Entries in the Mapping Table

Entry in LORD_MAPPING for object DATA

ZZMYFIELD GS_DATA-ZZMYFIELD SAPMV45A 1111

Entry in LORD_MAPPING_RO for object DATA

ZZMYFIELD_T GS_DATA-ZZMYFIELD_T SAPMV45A

Enhancement of the PBO Logic

Modified Flow Logic at Event PBO (Dynpro 1111)

Modified Module PREPARE_DATA_MODULE

Implementation of IF_LORD_INTF_SUPPLY~DO_PBO_SINGLE (Example)

In the FILL_SUPPLY_LIST method implementation of the IF_BADI_LORD_DO_PBO BAdI interface, the

Implementation of IF_BADI_LORD_DO_PBO~FILL_SUPPLY_LIST (Example)

Implementation of Class Constructor (Example)