bdt training

customer

Business Data ToolsetIntroduction to BDT for SAP Business Partner

Steffen Dockhorn, SAP AGJuly 2009

customer

Agenda

1. What is BDT

2. Clarification of Terms

3. Different BDT Operating Modes

4. BDT Event Processing

5. Screen Configuration

6. Divisibility & Roles

7. Field Status Settings

8. Examples

© SAP 2008 /

customer

Agenda

1. What is BDT1.1. General Overview1.2. History & Future







8. Examples

© SAP 2008 /

customer© SAP 2008 /

What is BDT – General Overview

Business Data Toolset (BDT) is a generic tool to control maintenance of master data and simple transaction data

Data maintenance in GUI as well as in background via Direct Input is supported Offers generic services for repetitive tasks and functionality e.g.

Change documents Field status settings Archiving

Supports maintenance of different application objects at the same time (e.g. SAP Business Partner and Business Partner Relationship)

Offers functionality for customers to enhance existing standard objects as well as creation of own objects


What is BDT – History & Future

Was developed by the project “Central Business Partner” starting in Release 4.6 to fulfill a list of business requirements as well as technical ones

Extensibility Flexibility of configuration (especially for screen layout) Divisibility (offer only parts of the object based on business needs)

First application object using BDT was SAP Business Partner followed by BP Relationships and other objects in SAP industry solutions:

Banking (Bank Account, Financial Conditions) Insurance (Claims Management) Real Estate (RE Contract, Tenant Information)

No further development for the framework, only maintenance (new UI strategies) Applications will still use it but in future it will possibly be replaced as SAP GUI

technology

customer

Agenda

1. What is BDT

2. Clarification of Terms2.1. General Terms2.2. Application Types2.3. Memories






8. Examples

© SAP 2008 /


Clarification of Terms – General Terms

BDT Application Object Defines a master data or transaction object:

– BUPA Business Partner– BUPR BP Relationships– FICO Financial Conditions

Is setup in transaction BUS0 or via BUPT– Central characteristics– usage of divisibility– Authorization objects– Match codes– Direct Input Structures– Archiving– Differentiation Types– Transactions…

customer© SAP 2008 / Page 11


BDT Application groups homogenous components of an application object

– BUP Central Business Partner: Data– FS08 BP Ratings– ZBUP BP extension

Can be created as table owning or table using application Is setup in transaction BUS1 (definition and activation) Naming convention: up to 4 character Coding shall be created in one function group per application

Data Set groups data fields with same business context

– BKK001 Alias Names– BUP030 Payment Cards

Usually one data set is used per data base table Is setup in transaction BUS1



Activity Type States the activity that can be carried out for individual objects

– 01 Create– 02 Change– 03 Display– 04 Modify

Is setup in transaction BUSN

BP View Controls the Object specific screens in BP dialog Basic setting for BP roles Is setup in transaction BUSD


Clarification of Terms – Application Types

Table Owning Applications applications have been created to deal with the whole table data are allowed to access data base tables with read and write operations

– BUP Central Business Partner: Data (for BUT000, BUT0ID…)– BUA Central Bus.Partner: Addresses (for ADR*, BUT020, BUT021_FS)– ZBUP BP extension (for ZBP_BUT000, ZBP_STATUS…)

Must provide memory access function modules for extension

Table Using Applications applications have been created to append existing table owning applications are not allowed to access data base tables with read and write operations Data of owning application can be accessed via memory

– ZBUA BP Address extension (for append to BUT020)


Clarification of Terms – Application Types

BUT020

Standard Append

Application BUA

Read complete data from data

base table BUT020 on event ISDAT.

Process only standard fields

while event processing

including PAI

Save complete data of table BUT020 to

Database on event DSAVE

Application ZBUA

Read extension data from memory

using bua_bupa_but020_

get on event ISDST.

Process only extension fields

while event processing

including PAI

Return extension data of table

BUT020 to memory using

bua_bupa_but020_collect on event

DSAVE

ISDAT

DSAVE

ISDST

DSAVB

Communication between table owning and using applications


Clarification of Terms – Memories

Current Memory Contains data on the instance that is being edited at the moment. Thus there is always

only one object handled – independent from the current BDT mode. Contains old and new status of the current instance Data is filled for the first time on event ISDAT or ISDST (new = old) Current memory is change during processing (new <> old) Data is handed over to local memory on event DTAKE

Global memory in BDT Developers Manual also called local memory contains data for all instances that have been edited but have not yet been saved Contains old and new status of all handled instances Used by table owning application only Data is filled for the first time on event ISDAT (new = old) Data is updated for one instance from local memory on event DTAKE Is saved to DB on event DSAVE

customer

Agenda

1. What is BDT




5. Screen Setup



8. Examples

© SAP 2008 / Page 18


Different BDT Operating Modes

Save Mode SAP GUI processing of the current BDT Application Object The object can be saved directly Current memory and global memory contain only one object per LUW

Transfer Mode SAP GUI processing of another object linking to a BDT application object (e.g. BP

assigned to a Loans or Real Estate Contract) No save option, the linked object is saved when the “owning” object is saved Current memory contains one object but global memory can contain more than one object BDT event handling is different in transfer mode Example:

– 2 BPs are required to create a contract– From the contract application it is possible to create the BPs in transfer mode– BP UIs are shown and the BPs can be created/changed (no save button)– Possibility to go back to the contract application– All objects are saved at the end of contract processing


Different BDT Operating Modes

Direct Input Processing of the BDT Application Objects without using SAP GUI No interaction with user possible Replacement of Batch Input Receiver structure is defined in the settings of the BDT Application Object (e.g. BUS_DI

for SAP Business Partner) offering all fields Sender structure has to be created by the user (not all fields required) Data has to be provided externally in flat files, only character type allowed (no dates or

numeric fields) Current memory contains one object, global memory contains more than one object per

LUW (number depends on the selected block size – 100 is recommended)

customer

Agenda

1. What is BDT



4. BDT Event Processing4.1. General Events4.2. Screen Related Events4.3. Other Events4.4. Differences based on BDT mode4.5. Event configuration




8. Examples

© SAP 2008 / Page 21


BDT Event Processing

Start

ISSTA

ISDAT

ISDST

AUTH1

User Action

XCHNG

Screen


BDT Event Processing – General Events

Start

ISSTA

ISDAT

ISDST

AUTH1

ISSTA Initialization of the application

Set current processing mode (save, transfer, Direct Input) Set current activity type … Important function module to retrieve the settings is

bus_parameters_issta_get

User Action

XCHNG

Screen



Start

ISSTA

ISDAT

ISDST

AUTH1

ISDAT

Initialization of the application Read data

Read data of all assigned data base tables Set current and global memories (new = old) Only relevant for table owning applications

User Action

XCHNG

Screen



Start

ISSTA

ISDAT

ISDST

AUTH1

ISDST

Initialization of the application Read data Distribute data

Get data for all table using applications Set current and global memories (new = old) Not relevant for table owning applications

User Action

XCHNG

Screen



Start

ISSTA

ISDAT

ISDST

AUTH1

AUTH1

Initialization of the application Read data Distribute data Check authority

Check authorization for a defined list of authorization objects, e.g. B_BUPA_RLT for BP roles

User Action

XCHNG

Screen



Start

ISSTA

ISDAT

ISDST

AUTH1

Initialization of the application Read data Distribute data Check authority Processing data in screens

Entering data for several fields Read data for customized entries Triggering screen specific function codes (e.g. to delete or

sort entries of a table) & processing Perform checks on field level

User Action

XCHNG

Screen

Screen



Start

ISSTA

ISDAT

ISDST

AUTH1

Initialization of the application Read data Distribute data Check authority Processing data in screens Perform user action

Function code is triggered based on user interaction Options: Save, Back, Cancel, Exit Next event is triggered

User Action

User Action

XCHNG

Screen



Start

ISSTA

ISDAT

ISDST

AUTH1

Initialization of the application Read data Distribute data Check authority Perform user action Check current memories for changes

Processing is aborted after the first changed application was found

Based on result and user action further events are triggered:– Data was not changed (independent on User Action) process

event DLVE1– Data was changed and user action Save process event DSAVB– Data was changed and user action Back or Exit Message “Do

you want to save”… (to DSAVB or screen processing)– Data was changed and user action Cancel Message “Do you

want to save”… (to DLVE1 or screen processing)

XCNHG

User Action

XCHNG

Screen



AUTH1

DCHCK

DTAKE

DSAVC

Collect data Data of table using applications is transferred to the

assigned table owning applications Collect function modules of owning tables are used

DSAVB

DLVE2

DSAVB

DSAVE

DLVE1



AUTH1

DCHCK

DTAKE

DSAVC

Collect data Check authority

AUTH1

DLVE2

DSAVB

DSAVE

DLVE1



AUTH1

DCHCK

DTAKE

DSAVC

Collect data Check authority Validate data

Data of each table is validated Cross application validations can be called In case of errors a message is raised and the process is set

back to screen processing Messages are collected but only one message is displayed

for Business Partner

DCHCK

DLVE2

DSAVB

DSAVE

DLVE1



AUTH1

DCHCK

DTAKE

DSAVC

Collect data Check authority Validate data Update global memory

Global memory of each application is updated from current memory

Depending on the current mode global memory contains one BP (save mode) or multiple BPs (transfer mode, Direct Input)

DTAKE

DLVE2

DSAVB

DSAVE

DLVE1



AUTH1

DCHCK

DTAKE

DSAVC

Collect data Check authority Validate data Update global memory Complete data for saving

Temporary internal keys (e.g. ##1) are replaced by final internal keys

External keys remain unchanged

DSAVC

DLVE2

DSAVB

DSAVE

DLVE1



AUTH1

DCHCK

DTAKE

DSAVC

Collect data Check authority Validate data Update global memory Complete data for saving Save data to data base

Data is written to data base (table owning applications only) Creation of change documents

DSAVE

DLVE2

DSAVB

DSAVE

DLVE1



AUTH1

DCHCK

DTAKE

DSAVC

Collect data Check authority Validate data Update global memory Complete data for saving Save data to data base Exit Maintenance (One Account)

Clear current memories It must be ensured that all current memories are cleared

including screen texts. Otherwise old data is displayed after change of BP.

DLVE1

DLVE2

DSAVB

DSAVE

DLVE1



AUTH1

DCHCK

DTAKE

DSAVC

Collect data Check authority Validate data Update global memory Complete data for saving Save data to data base Exit Maintenance (One Account) Exit Maintenance (All Accounts)

Clear global memories It must be ensured that all global memories are cleared.

Otherwise old data is displayed after change of BP.

DLVE2

DLVE2

DSAVB

DSAVE

DLVE1


BDT Event Processing – Screen Related Events

DTITL

DCUAD

DCUAC

PBO

Process prior to screen call Usually called for step loops (not allowed anymore) or table

controls Used to:

– Display the first page of entries– Sort the sequence of entries– Deselect all entries

PBCPBC

PAI

FCODE



DTITL

DCUAD

DCUAC

PBO

Process prior to screen call Change Title

Adjust the screen title generated by BDTDTITL

PBC

PAI

FCODE



DTITL

DCUAD

DCUAC

PBO

Process prior to screen call Change Title Determine GUI Status

DCUAD

PBC

PAI

FCODE



DTITL

DCUAD

DCUAC

PBO

Process prior to screen call Change Title Determine GUI Status Change GUI Status

Can be used to activate/deactivate functions based on conditions

Functions that depend on screen settings should not be using event DCUAC but the generic GUI function settings

DCUAC

PBC

PAI

FCODE



DTITL

DCUAD

DCUAC

PBO

Process prior to screen call Change Title Determine GUI Status Change GUI Status Process prior to output

The relevant fm shall be assigned to the view to – Move data from current memory to screen– Read texts – Convert data from DB format to screen format if necessary

(numeric and date types are not allowed in BDT screens)

In screen PBO no application logic shall be called (only function module bus_pbo)

PBO

PBC

PAI

FCODE



DTITL

DCUAD

DCUAC

PBO

Process prior to screen call Change Title Determine GUI Status Change GUI Status Process prior to output Process after input

The relevant fm shall be assigned to the view to – Move data from screen to current memory – Convert data from screen format to DB format if necessary

(numeric and date types are not allowed in BDT screens)– Validate screen fields

In screen PAI no application logic shall be called (only function module bus_pai)

PAI

PBC

PAI

FCODE



DTITL

DCUAD

DCUAC

PBO

Process prior to screen call Change Title Determine GUI Status Change GUI Status Process prior to output Process after input Process function codes

Process of function codes triggered in SAP GUI Processed after every single function code Processing is stopped after on application reported

processing multiple used of the same function code is prohibited

FCODE

PBC

PAI

FCODE


BDT Event Processing – Other Events

ARCH1 – Archiving: Check data ARCH2 – Archiving: Header Data (Owner Application) ARCH3 – Archiving: Dependent Data (Participating Appl.) ARCH4 – Archiving: Delete Archived Data ARCH5 – Archiving: Check Before Reloading ARCH6 – Archiving: Reload DELE1 – Deletion Program: Check Deletability DELE2 – Deletion Program: Delete CHGD1 – Change Docs: Transfer Selection Values (SE38) CHGD2 – Change Docs: Collect Objects with Object ID CHGD3 – Change Docs: Relevant Header? CHGD4 – Change Docs: Relevant Item? DINP0 – Direct Input: Convert Appl.-Specific Header Data DINP1 – Direct Input: Fill Out Initial Fields DINP2 – Direct Input: Fill Out Data Fields


BDT Event Processing – Differences based on BDT mode

Start dialog

ISSTA

DLVE1

Transfer mode Dialog processing

Processing starts when switching to dialog of the linked object (e.g. from loan contract to BP)

Event handling starts with initialization of the application and is exactly as in save mode until DLVE1

DLVE1 and end of dialog processing is triggered by user action “Back”

Save processing Starts when the main application triggers save Data is completed, saved to DB and global memories are

cleared

...

End Dialog

Start save

DSAVC

DLVE2

End save

DSAVE


BDT Event Processing – Differences based on BDT mode

Direct Input No user interaction possible Additional events for Direct Input are processed Process including initialization (ISSTA) and clear of

current memory is repeated until the last entry of a block was processed

Data is saved for each block Whole process is executed until no block is left In case of errors in DCHCK single BPs are not saved Flow logic is simplified (no error handling and PAI

processing included)

*1 End of block or last record

Start

ISSTA

DINP1

ISDAT

ISDST

AUTH1

DINP2

DSAVB

DTAKE

DLVE1

XCHNG

DSAVE

DLVE2

*1

B

Bno

yes

Last record

no

B

B

yes

End


BDT Event Processing – Event Configuration

Standard events cannot be changed If required, the processing function modules are assigned in transaction BUS7 Order of calls is determined by position in the table Naming conventions apply for function modules as well as for positions

Function module names <application>_<application_object>_event_<event> Example: bup_bupa_event_dsave Position No. is numeric, 7 digits long XXXXYZZ

– X = SAP– Y = SAP partner– Z = Customer

Function module is assigned to an application Call is performed everytime (using *) or only if the calling application is assigned to the current

BP view (using X)

customer

Agenda

1. What is BDT




5. Screen Configuration5.1. Field Groups5.2. Views5.3. Sections & Screens5.4. Screen sequences & Subheaders5.5. Screen Generation



8. Examples

© SAP 2008 / Page 51


Screen Configuration – Field Groups

A group of fields used in dialog for Field labels, Input fields and Text fields All fields must be assigned to field groups and no multiple assignments are allowed!

Otherwise field status settings won’t work properly. The challenge while field group definition is to find a good granularity Customizing of field status is based on field group level

Required Display Optional hidden

Cannot be identified in SAP GUI (only in configuration) Key is a number between 1 and 9999, customer name space is 600 - 699 Is setup in transaction BUS2


Screen Configuration – Field Groups

Field Group


Screen Configuration – Views

A view represents a single subscreen (Dynpro) used in dialog May only contain fields of one application and data set, Key consist of max. 6 digits starting with the application, e.g. BUP520 Cannot be identified in SAP GUI (only in configuration) Additional function modules can be assigned for

Processing before call Processing before output (reading texts) Processing after input (checks on field level) additional checks per view (e.g. for individual required field checks) Naming convention <application>_<application_object>_<event>_<view>

One or more field groups can be assigned Is setup in transaction BUS3


Screen Configuration – Views

View


Screen Configuration – Sections & Screens

Section A Section is a group of Views (at least one) Can be identified in SAP GUI by a frame showing a label Key consist of max. 6 digits starting with the application Is setup in transaction BUS4

Screen A Screen combines sections including header data Is the largest single unit in screen layout Screens appear as a tab strip (standard) or as a modal window in dialog Key consist of max. 6 digits starting with the application Is setup in transaction BUS5


Screen Configuration – Sections & Screens

Screen

Section


Screen Configuration – Screen Sequence & Subheader

Screen Sequence A screen Sequence is a collection of screens (tab strips) Defines the order in which the screens appear using position numbers A main screen sequence must be defined. Usually the application starts in that

screen sequence Is setup in transaction BUS6

Sub Header A button that offers the possibility to switch

between screen sequences of the same object, e.g. Differentiation Data, Company Code, Sales & Purchasing Data (ERP only)

A button that offers the possibility to switch between screen sequences of different application objects, e.g. Business Partner and BP Relationships

Display is selected dynamically, max. 5 including General Data and Relationship


Screen Configuration – Screen Sequence & Subheader

Screen Sequence

Subheader


Screen Configuration – Overview

Screen Sequence

Subheader

Screen

Section

View

Field Group


Screen Configuration – Screen generation

Screens as a combination of Dynpros are generated by the framework (so-called carrier dynpros) after every change

In case it looks strange due to failed generation, screens can be generated manually using transaction BUSP

customer

Agenda

1. What is BDT







8. Examples

© SAP 2008 / Page 75


Divisibility & Roles

Divisibility was one of the major requirements when BDT was developed It is used to split complex objects into smaller parts

For BP it can be found in transaction BUSD for definition of BP views as a Defines screen control in BP dialog Basic setting for role customising

View definition: Define a key (6 alphanumeric digits) Define a description and a title (no longer used GUI since SAP_ABA 6.40) Assign applications relevant for that view Assign relevant data sets depending on the fields that shall be used Assign screen sequences (not required if only main screen sequence is used) Assign subheaders to enable switching to other screen sequences Assignment of views is obsolete!



A role defines a view to a BP from a business point of view, e.g. a function the business partner fulfils (Account Holder)

Basic screen control is defined by the assigned BP view but the status of the fields can be defined in customising additionally

Role configuration can be accessed via IMG Roles and BP views have been the same until SAP_ABA 6.20

A role category is defined as an attribute of a role Existence of a role category assigned to a role defines whether the role is saved in

data base table BUT100

Access in coding: Roles: not allowed Role Categories: allowed BP views: not allowed



TBZ0TBZ0TTBZ0CTBZ0STBZ0U

BDT Object PartsBP Views

TB003TB003T

BP Roles

TB003ATB003B

BP Role Categories

BDT SAP Business Partner

BUT100

Customising Master Data

BP Roles

Customising

1:1

1:1

1:0

customer

Agenda

1. What is BDT







8. Examples

© SAP 2008 / Page 79


Field Status Settings

All field groups can be configured to a certain status: Display field: data is displayed and cannot be changed Input field: entry is possible but not mandatory Mandatory field: entry is required, initial mandatory fields are not allowed Hidden field: field is not available in the current configuration Optional field: same as Input field

Configuration is always valid for all fields of the field group (except mandatory fields if excluded in the field assignment screen

Configuration is done on different levels of field status settings System client (via IMG) Activity and activity type (BUSJ, BUCH) BP category (BUSO) BP role (BUCG) BP type (via IMG)


Field Status Settings

All configuration settings can be overruled by coding in event FMOD2

Rules exist how to deal with settings for field groups on different levels, e.g. Status defined for the client cannot be changed Status on BP category for hidden fields cannot be changed in role settings Special rules apply for mandatory fields: Once a mandatory field per object always a

mandatory field – A mandatory field on BP category level is always a mandatory field on BP role level– As soon as a BP has a role with mandatory fields assigned, these fields are mandatory in other

roles too, even if not configured in that way

For correct checking of mandatory fields using generic functionality GET function modules must be assigned to tables (transaction BUSG)

Required field checks in tables do not check whether there is at least one entry

customer

Agenda

1. What is BDT







8. Examples8.1. Enhancement of BP Address Data8.2. Enhancement of FSBP Data (Close of Business)

© SAP 2008 / Page 82


Example 1 - Requirements

A new field shall be added to BP addresses to cover the Delivery Point Identifier The field is of character type and can contain up to 9 alphanumeric digits Data is free text (no configuration and value help, o validation is required The field shall be displayed close to the BP default address The field shall be displayed address detail screen The field shall not be displayed in BP address overview

A new field shall be added to addresses to cover the Delivery Point Reed Solomon Identifier

The field is of character type and can contain up to 9 alphanumeric digits Data is free text (no configuration and value help, o validation is required The field shall be displayed close to the BP default address The field shall be displayed address detail screen The field shall not be displayed in BP address overview


Example 1 – Table & Application Definition

Q: What table shall be used? Option 1: Enhancement of an existing table Option 2: Creating a new table

A: Standard table BUT020 for BP addresses will be enhanced

Q: What type of BDT Application is required? A: Table using application using name be ZBUA (extending table owning standard

application BUA)

Q: Do we need a new data set for the application? A: Yes. Fields have to be separated from standard ones to ensure the can be

handled independent. Name will be ZBUA01.


Example 1 – Technical Enhancement in DDIC

Create new data elements in DDIC for the fields ZDTE_DP_ID - Delivery Point Identifier (CHAR9)

ZDTE_DP_RS_ID - Delivery Point Reed Solomon Identifier (CHAR9)

Create a new structure in DDIC containing the new fields Name ZSTR_DP_ID - Delivery Point Identifier Field 1 ZDP_ID of type ZDTE_DP_ID Field 2 ZDP_RS_ID of Type ZDTE_DP_RS_ID

Append structure to table BUT020


Example 1 – Screen enhancement (Code)

Create new function group ZBP_BDT_ZBUA - BDT for BP address extension Create new screen

Screen number is 100 BP Address Extension Screen type is subscreen Add elements

– Label for Delivery Point Identifier– Input field for Delivery Point Identifier– Label for Delivery Point Reed Solomon Identifier– Input field for Delivery Point Reed Solomon Identifier

Call BDT PBO processing in flow logic Call BDT PAI processing in flow logic


Example 1 – Application and Data Set Creation (Customising)

Create application ZBUA Start transaction BUS1 Create Application ZBUA - BP Address Extension Activate it

Create data set ZBUA01 Start in transaction BUS23 Create new data set ZBUA01 - Delivery Point Identifiers No further settings required Simulation shows no result


Example 1 – Screen Enhancement (Customising)

Q: How many field groups are required/recommended? A: Two are possible (one for each label and entry field) but one is sufficient from a

business point of view.

Create a new field group in the given name space Start transaction BUS2 Create new field group 602 - Delivery Point Identifiers Define detail settings Assign relevant fields:

– BUT020-ZDP_ID– BUT020-ZDP_RS_ID– G_STR_BUT020_UI-ZDP_ID– G_STR_BUT020_UI-ZDP_RS_ID



Q: How many views are required/possible? A: Only one is possible (all fields are on the same subscreen).

Create a new view in the given name space Start transaction BUS3 Create new view ZBUA01 (key = application name + counter) Use title BP Address Extension Define detail settings:

– Application ZBUA– Differentiation type 0– Data set ZBUA01– Subscreen SAPLZBP_BDT_ZBUA – 100– Assign field group 602



Q: How many Sections required/possible? A: No new section is required. According to the requirement the fields shall be

added to existing standard sections.

Q: to how many/which sections shall the fields be added? A: Two standard sections:

BUA110 – Address: Standard Address BUA130 – Address: Data

Add the new view to the existing sections Start transaction BUS4 Assign view ZBUA01 to section BUA110 using position 300010 Assign view ZBUA01 to section BUA130 using position 400010



Q: Are there any changes in screens required? A: No. Existing standard screens are reused.

Q: Are there any changes in screen sequences required? A: No.

Q: Are there any changes for subheaders required? A: No.

Q: Are there any new GUI functions required? A: No.

Additional activities: Assign screen fields to data base fields (BUSB) Add the application and dataset to relevant BDT view


Example 1 – Result Check

Are the fields available in transaction BP now? Yes

Does it work? No

Why? Data is not transferred from GUI to memory and vice versa. Data is not processed (event processing) Data is not retrieved and passed to the owning application BUA


Example 1 – Screen Enhancement (Code)

Create PBO function module Naming convention:<application>_<application_object>_PBO_<view> Name: ZBUA_BUPA_PBO_ZBUA01 Read data from current memory Select entry for current address and transfer it to UI No field conversion required, no validations or required

Create PAI function module Naming convention:<application>_<application_object>_PAI_<view> Name: ZBUA_BUPA_PAI_ZBUA01 Read data from UI and update it for selected address in current memory No field conversion required, no validations or required



Assign PBO function module Open details of view ZBUA01 in transaction BUS3 Enter function module name ZBUA_BUPA_PAI_ZBUA01 into PBO field

Assign PAI function module Open details of view ZBUA01 in transaction BUS3 Enter function module name ZBUA_BUPA_PAI_ZBUA01 into PAI field

No PBC function module required


Example 1 – Event Handling

Q: Which events must be processed?

ISSTA

User Action

Screen

Start

Start

ISDAT

ISDST

AUTH1

XCHNG

DSAVB

AUTH1

DCHCK

DTAKE

DSAVC

DSAVE

DLVE1

DLVE2

DTITL

DCUAD

DCUAC

FCODE

CHGDx

ARCHx

DELEx

FMOD2



Q: Which Events must be processed? A: Only a small subset of BDT events:

ISDST - Distribute Data (to Participating Applications)

XCHNG - Check Whether Data Has Been Changed

DSAVB - Collect Data (in Owner Applications) DLVE1 - Exit Maintenance (One Account)

ISSTA

User Action

Screen

Start

Start

ISDAT

ISDST

AUTH1

XCHNG

DSAVB

AUTH1

DCHCK

DTAKE

DSAVC

DSAVE

DLVE1

DLVE2

DTITL

DCUAD

DCUAC

FCODE

CHGDx

ARCHx

DELEx

FMOD2


Example 1 – Event Handling (Code)

Create function module ZBUA_BUPA_EVENT_ISDST Read memory from application BUA using function module

BUA_BUPA_BUT020_GET Get function module can be found in TA BUSG assigned to the owning table

Create function module ZBUA_BUPA_EVENT_XCHNG Compare old and new memory of the application Return true in case of changes

Create function module ZBUA_BUPA_EVENT_DSAVB Set memory of the appended fields to application BUA using function module

BUA_BUPA_BUT020_GET Collect function module name can be found in TA BUSG assigned to the

owning table

Create function module ZBUA_BUPA_EVENT_DLVE1 Clear current memory

ISDST

XCHNG

DSAVB

DLVE1


Example 1 – Event Handling (Customising)

Assign function modules in transaction BUS7

Event Position Function Module Call Application

ISDST 1000010 ZBUA_BUPA_EVENT_ISDST X ZBUA

XCHNG 1000010 ZBUA_BUPA_EVENT_XCHNG X ZBUA

DSAVB 1000010 ZBUA_BUPA_EVENT_DSAVB X ZBUA

DLVE1 1000010 ZBUA_BUPA_EVENT_DLVE1 X ZBUA


Example 1 – Result Check

Are the fields available in transaction BP now? Yes

Does it work in SAP GUI? Yes

Does it work in Direct Input? No

Why? Fields are not connected to receiver structure BUS_DI Mapping between Direct Input fields and DB fields is not processed


Example 1 – Direct Input Enhancement (Code)

Enhance DI receiver structure Append the two fields to BUS020_DI Use names starting with Z to avoid future problems with SAP extensions

Create Direct Input mapping Function module ZBUA_BUPA_EVENT_DINP1 to fill header data is not required Create function module ZBUA_BUPA_EVENT_DINP2

– Map data fields from Direct Input fields to fields in current memory– Assignment of DI fields to data base fields can be read from customising or hard coded– Activity type must be taken into account. Valid values are create (01), change (02) and modify (04) – “No Data” flag must be taken into account


Example 1 – Direct Input Enhancement (Customizing)

Enter field assignments Start transaction BUSB_DI Assign fields appended to BUS020_DI to data base fields If fields have the same name placeholder + can be used

Enter function module for data mapping Start transaction BUS7 and open event DINP2 Assign function module ZBUA_BUPA_EVENT_DINP2


DINP2 1000010 ZBUA_BUPA_EVENT_DINP2 X ZBUA


Example 2 - Requirements

A new field shall be added to FS BP data to record whether business was closed down or not

The field is of boolean type and can only contain the values true or false The field shall be displayed close to the BP credit standing data

A new field shall be added to FS BP to cover the date when the business was closed

The field is of date type It shall not be possible to enter dates in future The field shall be displayed close BP credit standing data It shall not be possible to maintain the date if the status is not set

A new field shall be added to FS BP to cover the reason why the business was closed

The field is for free text input The field shall be displayed close BP credit standing data It shall not be possible to maintain the field if the status is not set


Example 2 – Table & Application Definition

Q: What table shall be used? Option 1: Enhancement of an existing table Option 2: Creating a new table

A: Standard table BP1010 for BP will be enhanced

Q: What type of BDT Application is required? A: Table using application using name be ZCOB

Q: Do we need a new data set for the application? A: Yes. Fields have to be separated from standard ones to ensure the can be

handled independent. Name will be ZCOB01.


Example 2 – Technical Enhancement in DDIC

Create new data elements in DDIC for the fields ZDTE_FLG_COB – Close of Business (XO_BOOLE) ZDTE_DATE_COB - Close of Business Date (DATS) ZDTE_DATE_COB_UI - Close of Business Date (CHAR10) ZDTE_DATE_COB_DI - Close of Business Date (CHAR8) ZDTE_REASON_COB - Close of Business Reason (CHAR30)

Append table BP1010 Name ZSTR_COB – Close of Business Field 1 ZCOB of type ZDTE_FLG_COB Field 2 ZCOB_DATE of Type ZDTE_DATE_COB Field 3 ZCOB_REASON of Type ZDTE_REASON_COB

Create a new structure ZSTR_COB_UI in DDIC for GUI using field PARTNER, the fields appended to the table BP1010 and field ZCOB_DATE_UI


Example 2 – Screen enhancement (Code)

Create new function group ZBDT_ZCOB - BDT for BP CoB extension Create new screen

Screen number is 100 - Close of Business Add elements

– Check box for close of business– Label for Close of Business Date– Input field for Close of Business Date

Screen number is 200 - Close of Business Reason– Label for Close of Business Reason– Input field for Close of Business Reason

Screen type for both screens is subscreen Call BDT PBO processing in flow logic Call BDT PAI processing in flow logic


Example 2 – Screen Enhancement (Code)

Create PBO function modules Naming convention:<application>_<application_object>_PBO_<view> Names: ZCOB_BUPA_PBO_ZCOB01 and ZCOB_BUPA_PBO_ZCOB02 Read data from current memory Field conversion for date field required (DATS CHAR10)

Create PAI function modules Naming convention:<application>_<application_object>_PAI_<view> Names: ZCOB_BUPA_PAI_ZCOB01 and ZCOB_BUPA_PAI_ZCOB02 Read data from UI and update current memory Field conversion required (CHAR10 DATS) Validation of date required Validation of text field required


Example 2 – Application and Data Set Creation (Customising)

Create application ZCOB Start transaction BUS1 Create Application ZCOB - Close of Business Activate it

Create data set ZCOB01 Start in transaction BUS23 Create new data set ZCOB – Close of Business No further settings required Simulation shows no result



Q: How many field groups are required/recommended? A: Three are possible and recommended to be able to control field settings of single

entry fields

Create a new field group in the given name space Start transaction BUS2 Create new field groups

– 697 – Close of Business Checkbox– 698 – Close of Business Date– 699 –Close of Business Reason

Define detail settings Assign relevant fields from Dynpro



Q: How many views are required/possible? A: Two are required (two fields are on one subscreen, one is on the second).

Create a new views Start transaction BUS3 Create new views ZCOB01 and ZCOB02 Use titles Close of Business and Close of Business Reason Define detail settings:

– Application ZCOB– Differentiation type 0– Data set ZCOB01– Subscreen SAPLZBP_BDT_ZCOB – 100 and ZSAPLBP_BDT_ZCOB – 200 – Assign PAI and PBO function modules– Assign field groups 697 and 698 to view ZCOB01– Assign field group 699 to view ZCOB02



Q: How many Sections required/possible? A: One new section is required/recommended.

Create a new section Start transaction BUS4 Create new section ZCOB01 Use description Close of Business Use title Close of Business Assign view ZCOB01 to section ZCOB01 using position 1000010 Assign view ZCOB02 to section ZCOB01 using position 1000020



Q: Are there any changes in screens required? A: Yes. Existing standard screen shall be extended.

Assign section ZCOB01 Start transaction BUS5 Mark screen FS8001 - Ratings Assign section ZCOB01 to screen FS8001 using position 2200010

Additional activities: Assign screen fields to data base fields (BUSB) Add the application and dataset to relevant BDT view



Q: Which event function modules need to be implemented?

ISSTA

User Action

Screen

Start

Start

ISDAT

ISDST

AUTH1

XCHNG

DSAVB

AUTH1

DCHCK

DTAKE

DSAVC

DSAVE

DLVE1

DLVE2

DTITL

DCUAD

DCUAC

FCODE

CHGDx

ARCHx

DELEx

FMOD2



Q: Which Events must be processed? A: Only a small subset of BDT events:

DLVE1 - Exit Maintenance (One Account) FCODE – Function Code FMOD2 – Field Status Settings

ISSTA

User Action

Screen

Start

Start

ISDAT

ISDST

AUTH1

XCHNG

DSAVB

AUTH1

DCHCK

DTAKE

DSAVC

DSAVE

DLVE1

DLVE2

DTITL

DCUAD

DCUAC

FCODE

CHGDx

ARCHx

DELEx

FMOD2


Example 2 – Event Handling (Code)

Create function module ZCOB_BUPA_EVENT_FCODE Only required in case the check box is triggering release of a function code E.g. a warning could be raised in case it is deactivated and date and reason

is removed

Create function module ZCOB_BUPA_EVENT_FMOD2 Only required in case the content of check box is used to change the field

status settings of the date and reason field E.g. the fields could be set to display mode if the check box is inactive

Create function module ZCOB_BUPA_EVENT_DLVE1 Clear current memory used for screen presentation

FCODE

FMOD2

DLVE1


Example 2 – Event Handling (Customising)

Assign function modules in transaction BUS7

Assign FMOD2 function module to field groups 698 and 699 in transaction BUS2


FCODE 100010 ZCOB_BUPA_EVENT_FCODE X ZCOB

DLVE1 100010 ZCOB_BUPA_EVENT_DLVE1 X ZBUA


Example 2 – Direct Input Enhancement (Code & Customising)

Enhance DI receiver structure Append the three fields to BP1010_DI because it is not allowed to append BPA1010_DI Use names starting with Z to avoid future problems with SAP extensions

Direct Input mapping Function modules ZCOB_BUPA_EVENT_DINP1 to fill header data and

ZCOB_BUPA_EVENT_DINP2 for data mapping are not required

Enter field assignments Start transaction BUSB_DI Assign fields appended to BPA1010_DI to data base fields If fields have the same name placeholder + can be used


Questions & Answers


Thank you!

bdt training

Documents