Skip to Content
Technical Articles
Author's profile photo Ian Salveson

S/4 Hana Enforcement Actions and Debt Set Relationships


The purpose of this article is to explore the relationship that exists between a DCM Debt Set and an enforcement action. These new entities within S/4 Hana essentially act as an adapter or bridge between the worlds of CRM and PSCD. The new capabilities of the Debt Set and Enforcement actions means that complex transactional processing can be managed by one order object entities with the added benefit of linkages to financial processing where appropriate.

Debt Set

A Debt Set entity has been introduced which essentially acts as a container to group like fica items for a specific debtor together. A debt set may also be categorised by utilising the concept of a debt set type.

Debt Set Configuration

If a debt set object is to be utilised in the S/4Hana landscape there is a certain amount of configuration that is required, namely, defining a debt set type and a number range to be utilised by the debt set type.

Debt Set Number Range Configuration
IMG Path Contract Accounts Receivable and Payable > Business Transactions > Dunning > Dunning by Collection Strategy > Debt Collection Management > Define Number range for Debt Set Type
Purpose In this Customizing activity, you define the number range intervals for debt set types.


Debt Set Type
IMG Path Contract Accounts Receivable and Payable > Business Transactions > Dunning > Dunning by Collection Strategy > Debt Collection Management > Define Debt Set Type
Purpose In this Customizing activity, you define debt set types. Debt sets group liabilities to handle them together in the context of debt collection management.


Debt Set Persistent tables
  • DFKK_DCM_DS_H     – Debt Set Header
  • DFKK_DCM_DS_I       – Debt Set Items     
  • DFKK_DCM_DS_CLS – Debt Set Classifications

The details of the debt set header and Items are shown below in diagram 1.

@EndUserText.label : 'Debt set header'
@AbapCatalog.enhancementCategory : #EXTENSIBLE_CHARACTER_NUMERIC
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table dfkk_dcm_ds_h {
  key mandt           : mandt not null;
  key debt_set_number : dcm_debt_set_number_kk not null;
  debt_set_type       : dcm_debt_set_type_kk;
  debtor              : dcm_debt_set_debtor_kk;
  description         : dcm_debt_set_description_kk;
  protection          : dcm_ds_protection_kk;
  lifecycle_status    : dcm_ds_lifecycle_status_kk;
  collection_strategy : strat_cm_kk;
  collection_step     : step_cm_kk;
  created_at          : timestamp;
  created_by          : uname;
  changed_at          : timestamp;
  changed_by          : uname;

@EndUserText.label : 'Debt set item'
@AbapCatalog.enhancementCategory : #EXTENSIBLE_CHARACTER
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table dfkk_dcm_ds_i {
  key mandt           : mandt not null;
  @AbapCatalog.foreignKey.screenCheck : false
  key debt_set_number : dcm_debt_set_number_kk not null
    with foreign key dfkk_dcm_ds_h
      where mandt = dfkk_dcm_ds_i.mandt
        and debt_set_number = dfkk_dcm_ds_i.debt_set_number;
  key opbel           : opbel_kk not null;
  key opupw           : opupw_kk not null;
  key opupk           : opupk_kk not null;
  key opupz           : opupz_kk not null;


Diagram 1

Enforcement Action

An example for an enforcement action could be say a wage garnishee which encompasses all of the customer’s outstanding receivables. In such an example all of the debtor’s existing debt sets would be assigned to the wage garnishee enforcement action. Note: It is also possible to assign a debt set to more than one enforcement action.

A new enforcement action object is available in the S/4Hana system and the existing one order framework can be utilised to process the enforcement action. A new standard transaction type of  DMEA has been delivered and the details of the standard template can be seen in diagram 2.

Note: Never modify the standard transaction type DMEA. If variations are required to the standard then copy the standard DMEA transactions to a custom transaction type and then make configuration changes. There are many CRM blogs on how to create a status profile or action profile.

Enforcement Action Configuration
IMG Path Service>Transactions>Basic Setting>Define Transactions Types
Purpose In this Customizing activity, you define transaction type



Diagram 2

Enforcement Action Persistent Table
@EndUserText.label : 'Enforcement Action Header'
@AbapCatalog.enhancementCategory : #EXTENSIBLE_CHARACTER_NUMERIC
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table crms4d_dmea_h {
  key include crms4s_key_h not null;
  include crms4s_dmea_h_orderadm_h;
  include crms4s_dmea_h_ea_h;
  include crms4s_dmea_h_partner;
  include crms4s_dmea_h_dates;
  include crms4s_dmea_h_orgman;
  include crms4s_dmea_h_status;
  include crms4s_dmea_h_incl_eew_ps;

Relationship Diagram

The diagram below(diagram 4) demonstrates the relationships between a debt set and enforcement actions. The persistent table that realises the linkages between an enforcement action and a debt set is CRMS4D_EXT_REF(diagram 3).


@EndUserText.label : 'Customer Mgmt Add-on S4: External Reference'
@AbapCatalog.enhancementCategory : #EXTENSIBLE_CHARACTER_NUMERIC
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table crms4d_ext_ref {
  key include crms4s_key_i not null;
  key counter : crms4_ext_ref_counter not null;
  include crmt_ext_ref_ext;


Diagram 3


Diagram 4


Diagram 4 articulates the following:

  1. A debtor[BUT000] can have many different debt sets[DFKK_DCM_DS_H]
  2. A debt set is associated with one debtor
  3. A debt set can have many debt set items
  4. A debt set item is linked to one fica item.
  5. A debt set can be linked to many different enforcement actions
  6. An enforcement action belongs to one debtor
  7. An enforcement action can be linked to many different debt sets

The following tables explains the physical realisation of the business object in the above model and their relationship to other business objects.

Business Role Explanation Physical Table Relationship
Debtor This debtor represents a customer under debt and collection management system. BUT000, BUT0ID A debtor can have many Enforcement Actions as well as many Debt Sets
Enforcement Action A container used to keep track of collections. CRMS4D_DMEA_H A debtor can have many enforcement actions and an enforcement action can be linked to activities via a doc flow.
Enforcement Action link to Debt Set A container which links and the DCM enforcement action to debt set. CRMS4D_EXT_REF An enforcement action can link to many different debt sets and a debt set can link to many enforcement actions.
Debt Set A container used to collate face items. DFKK_DCM_DS_H A debt set is link to one debtor, a debt set has many fica items and a debt set may link to many different enforcement actions.
Debt Set Items A container used to group fica items for a debt set DFKK_DCM_DS_I An item can only belong to one debt set.
Activity A one order container used to record activity. CRMS4D_ACTV_H An activity can be linked to an enforcement action via a doc flow.
Doc Flow A container used to store linkage between enforcement actions and activities. CRMD_BRELVONAE Represent an association between two one order (orderadm_h) objects.
FICA Document A PSCD object which hold the financial document header details. DFKKKO A PSCD header document linked to the document items.
FICA Items A PSCD object which holds the BP items associated with a financial document DFKKOP A fica Item has a 1:1 relationship with a debt set item.

CDS View Showing Data Linkages

The relationships between enforcement actions and debt sets can be represented using CDS view. In diagram 5 we can see how CDS interface views have been created and how associations have been established between relevant entities.
For example the CDS view ZI_DEBTSET can be seen to have associations _dsItem, _dsEALINK, _dsDEBTOR and the CDS view ZI_EA has the associations _eaDEBTOR and _esDSLINK.


Diagram 5


The details of the CDS are shown in Diagram 6.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Interface View of Debt Set'
@Metadata.ignorePropagatedAnnotations: true
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
define view entity ZI_DEBTSET
  as select from dfkk_dcm_ds_h

  association [1..1] to ZI_DS_DEBTOR   as _dsDEBTOR on $projection.Debtor = _dsDEBTOR.Partner

  association [0..*] to ZI_DS_ITEM as _dsITEM   on $projection.DebtSetNumber = _dsITEM.DebtSetNumber

  association [0..*] to ZI_DS_EALINK    as _dsEALINK     on $projection.DebtSetNumber = _dsEALINK.DebtSetNumber

  key debt_set_number     as DebtSetNumber,
      debt_set_type       as DebtSetType,
      debtor              as Debtor,
      description         as Description,
      protection          as Protection,
      lifecycle_status    as LifecycleStatus,
      collection_strategy as CollectionStrategy,
      collection_step     as CollectionStep,
      created_at          as CreatedAt,
      created_by          as CreatedBy,
      changed_at          as ChangedAt,
      changed_by          as ChangedBy,



@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Interface View of DebtSet Items'
@Metadata.ignorePropagatedAnnotations: true
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
define view entity ZI_DS_ITEM
  as select from dfkk_dcm_ds_i

  association [1..1] to ZI_DEBTSET as _itemDS on $projection.DebtSetNumber = _itemDS.DebtSetNumber
  key debt_set_number as DebtSetNumber,
  key opbel           as Opbel,
  key opupw           as Opupw,
  key opupk           as Opupk,
  key opupz           as Opupz,

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Debt Set to Enforcement Action'
@Metadata.ignorePropagatedAnnotations: true
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
define view entity ZI_DS_EALINK
  as select from ZI_DEBTSET     as ds
    inner join   crms4d_ext_ref as ea on ea.reference_number = ds.DebtSetNumber


  key ea.objtype_h  as ObjtypeH,
  key ea.object_id  as ObjectId,
  key ea.number_int as NumberInt,
  key ea.counter    as Counter,
  key ds.DebtSetNumber,
      /* Associations */

      ea.objtype_h      = 'BUS2000294'
  and ea.reference_type = '0011'

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Interface View of Debtor'
@Metadata.ignorePropagatedAnnotations: true
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
define view entity ZI_DS_DEBTOR
  as select from but000 as bp
    inner join   but0id as id on bp.partner = id.partner

  association [0..*] to ZI_DEBTSET as _debtorDS on $projection.Partner = _debtorDS.Debtor
  association [0..*] to ZI_EA  as _debtorEA on $projection.Partner = _debtorEA.Debtor

  key bp.partner          as Partner,
      id.idnumber         as crn,
      id.type             as idtype,
      bp.type             as Type,
      bp.bpkind           as Bpkind,
      bp.bu_group         as BuGroup,
      bp.bpext            as Bpext,
      bp.bu_sort1         as BuSort1,
      bp.bu_sort2         as BuSort2,
      bp.source           as Source,
      bp.title            as Title,
      bp.xdele            as Xdele,
      bp.xblck            as Xblck,
      bp.augrp            as Augrp,
      bp.title_let        as TitleLet,
      bp.bu_logsys        as BuLogsys,          as Contact,
      bp.not_released     as NotReleased,
      bp.not_lg_competent as NotLgCompetent,
      bp.print_mode       as PrintMode,
      bp.bp_eew_dummy     as BpEewDummy,
      bp.remitter_ref1    as RemitterRef1,
      bp.remitter_ref2    as RemitterRef2,
      bp.remitter_ref3    as RemitterRef3,
      bp.remitter_ref4    as RemitterRef4,
      bp.rate             as Rate,
      bp.name_org1        as NameOrg1,
      bp.name_org2        as NameOrg2,
      bp.name_org3        as NameOrg3,
      bp.name_org4        as NameOrg4,
      bp.legal_enty       as LegalEnty,
      bp.ind_sector       as IndSector,
      bp.legal_org        as LegalOrg,
      bp.found_dat        as FoundDat,
      bp.liquid_dat       as LiquidDat,
      bp.location_1       as Location1,
      bp.location_2       as Location2,
      bp.location_3       as Location3,
      bp.name_last        as NameLast,
      bp.name_first       as NameFirst,
      bp.name_lst2        as NameLst2,
      bp.name_last2       as NameLast2,
      bp.namemiddle       as Namemiddle,
      bp.title_aca1       as TitleAca1,
      bp.title_aca2       as TitleAca2,
      bp.title_royl       as TitleRoyl,
      bp.prefix1          as Prefix1,
      bp.prefix2          as Prefix2,
      bp.name1_text       as Name1Text,
      bp.nickname         as Nickname,
      bp.initials         as Initials,
      bp.nameformat       as Nameformat,
      bp.namcountry       as Namcountry,
      bp.langu_corr       as LanguCorr,
      bp.xsexm            as Xsexm,
      bp.xsexf            as Xsexf,
      bp.birthpl          as Birthpl,
      bp.marst            as Marst,
      bp.emplo            as Emplo,
      bp.jobgr            as Jobgr,
      bp.natio            as Natio,
      bp.cntax            as Cntax,
      bp.cndsc            as Cndsc,
      bp.persnumber       as Persnumber,
      bp.xsexu            as Xsexu,
      bp.xubname          as Xubname,
      bp.bu_langu         as BuLangu,
      bp.gender           as Gender,
      bp.birthdt          as Birthdt,
      bp.deathdt          as Deathdt,
      bp.perno            as Perno,
      bp.children         as Children,
      bp.mem_house        as MemHouse,
      bp.birthdt_status   as BirthdtStatus,
      bp.partgrptyp       as Partgrptyp,
      bp.name_grp1        as NameGrp1,
      bp.name_grp2        as NameGrp2,
      bp.mc_name1         as McName1,
      bp.mc_name2         as McName2,
      bp.crusr            as Crusr,
      bp.crdat            as Crdat,
      bp.crtim            as Crtim,
      bp.chusr            as Chusr,
      bp.chdat            as Chdat,
      bp.chtim            as Chtim,
      bp.partner_guid     as PartnerGuid,
      bp.addrcomm         as Addrcomm,
      bp.td_switch        as TdSwitch,
      bp.is_org_centre    as IsOrgCentre,
      bp.db_key           as DbKey,
      bp.valid_from       as ValidFrom,
      bp.valid_to         as ValidTo,
      bp.xpcpt            as Xpcpt,
      bp.natpers          as Natpers,
      bp.milve            as Milve,
      bp.nuc_sec          as NucSec,
      bp.par_rel          as ParRel,
      bp.bp_sort          as BpSort,
      bp.kbanks           as Kbanks,
      bp.kbankl           as Kbankl,        as Institute,
      id.entry_date       as EntryDate,
      id.valid_date_from  as ValidDateFrom,
      id.valid_date_to    as ValidDateTo,          as Country,
      id.region           as Region,
      id.idnumber_guid    as IdnumberGuid,
      id.bp_eew_but0id    as BpEewBut0id,



@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Enforcement Action'
@Metadata.ignorePropagatedAnnotations: true
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
define view entity ZI_EA
  as select from crms4d_dmea_h
    association [0..*] to ZI_DS_EALINK     as _eaDSLINK   
  on  $projection.ObjtypeH = _eaDSLINK.ObjtypeH   and $projection.ObjectId = _eaDSLINK.ObjectId
  association [0..1] to ZI_DS_DEBTOR    as _eaDEBTOR on  $projection.Debtor = _eaDEBTOR.Partner
  key objtype_h           as ObjtypeH,
  key object_id           as ObjectId,
      header_guid         as HeaderGuid,
      process_type        as ProcessType,
      posting_date        as PostingDate,
      description_h       as DescriptionH,
      descr_language      as DescrLanguage,
      template_type       as TemplateType,
      created_at_h        as CreatedAtH,
      created_by_h        as CreatedByH,
      changed_at_h        as ChangedAtH,
      changed_by_h        as ChangedByH,
      head_changed_at     as HeadChangedAt,
      btx_class           as BtxClass,
      auth_scope          as AuthScope,
      archiving_flag      as ArchivingFlag,
      object_id_ok        as ObjectIdOk,
      verify_date         as VerifyDate,
      pricing_document    as PricingDocument,
      pricing_procedure   as PricingProcedure,
      header_guid_char    as HeaderGuidChar,
      by_dunning          as ByDunning,
      by_dun_laufd        as ByDunLaufd,
      by_dun_laufi        as ByDunLaufi,
      employee_resp       as EmployeeResp,
      debtor              as Debtor,
      dmea_start_h        as DmeaStartH,
      dmea_end_h          as DmeaEndH,
      dis_channel         as DisChannel,
      division            as Division,
      service_org_ori     as ServiceOrgOri,
      service_orgr_ori    as ServiceOrgrOri,
      sales_org_ori       as SalesOrgOri,
      dis_channel_ori     as DisChannelOri,
      sales_off_ori       as SalesOffOri,
      sales_group_ori     as SalesGroupOri,
      sales_orgr_ori      as SalesOrgrOri,
      division_ori        as DivisionOri,
      sales_org           as SalesOrg,
      sales_office        as SalesOffice,
      sales_group         as SalesGroup,
      sales_org_resp      as SalesOrgResp,
      service_org         as ServiceOrg,
      service_org_resp    as ServiceOrgResp,
      sales_org_sd        as SalesOrgSd,
      sales_office_sd     as SalesOfficeSd,
      sales_group_sd      as SalesGroupSd,
      service_team_rm     as ServiceTeamRm,
      service_team_rm_ori as ServiceTeamRmOri,
      stat_lifecycle      as StatLifecycle,
      stat_open           as StatOpen,
      stat_archivable     as StatArchivable,
      stat_archived       as StatArchived,
      stat_error          as StatError,
      stat_cancelled      as StatCancelled,
      dmea_h_dummy_ps     as DmeaHDummyPs,


Diagram 6



The article has shown how the relationships exists between enforcement actions and Debt Set within the Debt Collections Management module in the S/4Hana landscape. The new entities within DCM provide a mechanism by which receivables can be managed using the CRM foundations of the one order framework.

If readers wish to explore how linkages can be created programmatically then please refer to my previous blog:


Please feel free to supply comments on thoughts on this blog. The following links may also be of benefit to readers.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.