Martina Knoedler Solution Management Service Industries SAP AG SAP Collections Management for Utilities

AgendaIntroductionDetermination and Execution of Collection ActivitiesDetermination of Collection StepResponsible DeterminationWorkload BalancingManaging Collection Work ListsProcess Collection WorkitemsEnhancements in Financial Customer Service ProcessesCollection Fact SheetCollection HistoryPromise to PayCustomizable BalancesOutgoing Payment Request5. Dispute Management

Where to find the Financial Customer Service Processes in a Utilities ProfileFunctionalities of Standard IC WebClientUtilities Specific Functionalities in IC WebClientFinancial Customer Service Processes in IC WebClient

Collections Management in IC Web Client

Collections Overview

Set up / Adjust Business Rules Manage CollectionsWork Lists

Process Workitems Submit Receivables toCollection Agencies

Create and Process Collection Work itemsDetermine Next ActivitiesExecute ActivitiesAnalyze/Measure Success Set up dunning procedures or collection strategies Maintain responsibilities Maintain rules for collection agency determination Etc. Dunning run identifies overdue accounts and determines next activities based on predefined rules

Business Process Areas in Collections ManagementMass activityCollection Strategies Manage CollectionsWork Lists

Process CollectionsWorkitems

TodayFI-CA classical dunning based on dunning procedures

New (ERP6.0 EhP2)Dunning by collection strategy; dunning strategy and ranking rules are modeled in Business Rules Framework (BRF); Evaluation of P2PsEvaluation of collection success (per master data entity and collection step)

New (ERP6.0 EhP2)Maintenance of rules for automatic assignment of Workitems to teams/ agentsWorklist managementRelease of dunning activities

TodayIC Web Client for processing incoming/ outgoing calls

New (ERP6.0 EhP2, CRM 2006s)IC Web Client for Collection Agents provides all data and functions for collectorsFull view of customer and accountsCreate/ change promise-to-paysCollection fact sheet Extended collection historyMeasure Success

TodayA variety of BI content available

New (ERP6.0 EhP2)Additional BI content comingCollection Success per master data entity and collection strategy/stepEfficiency of collectorsPromise-to-pay analysisERPERPIC WebClientERP

AgendaIntroductionDetermination and Execution of Collection ActivitiesDetermination of Collection StepResponsible DeterminationWorkload BalancingManaging Collection Work ListsProcessing Collection WorkitemsEnhancements in Financial Customer Service ProcessesCollection Fact SheetCollection HistoryPromise to PayCustomizable BalancesOutgoing Payment RequestDispute Management

Collections Activities Create correspondence: Letter, Fax, Email Work list entry for internal collection agent Generate Request for security deposit Trigger service order, e.g. disconnection/reconnection Release to external collection agencies Automatic write off Creation and posting of charges and/or interest De-activate instalment plan Update payment behaviour / creditworthiness

Characteristics of Business Rules Framework Flexible, dynamic evaluation of different parameters Linear as well as decision-tree based collection strategies possible Logic is transparent to the business Configurable by a key business user Reduces previous programming efforts Possibility of integrating manual and automatic activities

Change of ApproachDunning by Dunning ProcedureDunning level dunning activitiesDunning procedure of contract account determines number and sequence of dunning levelsDunning by Collection StrategyCollection step dunning activitiesRules engine determines next collection step according to collection strategy for group of contract accounts

Dunning history(last collection step)

Dunning dataCredit ratingCollection step 2Amount Days

Dunning level 2Dunning level 1Amount Days

Business Rules Framework

Collection Strategy

Overview Rules DefinitionRules for Determination of Collection Step, Ranking,

The expression type of the decision tree is used for the derivation of the collection step and the evaluation numberAll data requested can be used in the other expression types (Ranges, Formulas, Truth Table etc.) to define a conditional step within the decision tree. The result of each step is either false or trueAs target you define within the decision tree the collection step

Collections Management BRF IntegrationActionsActionActionActionBRF EventRegelRegelRegelRuleExpressionExpressionExpressionActionExpressionIFTHENActionsoptionalApplication ClassFI-CA: Collections Management (Event 315) Input: Current dunning group Items in group Etc.

BRF ContextReturn parameters: Next collection step Valuation number Rank Messages

Dynamic Activity Determination - ExampleDynamic evaluation of any parameter Linear as well as decision-tree based evaluationsLogic is transparent to the business Configurable by the business userNo programming requiredTight integration of manual and automatic activities is possible

Next Treatment: L2Previous treatment L1?Previous treatment L2?L1 Early reminderTreatementso far?High Risk?Medium Risk?ELSE?Send to legalcollectionsBroken promises?Send to externalcollectionsCall customer (L3A)Final contract?...Send to legalcollectionsYNNNYYNYYY

Role of Collection StepRe-use of features from dunning:Link to dunning activitiesSettings for Charges and Interest

New features:Interval (instead of dunning rhythm)Closing of item group Capacity balancing settingsPerform success evaluation (note: feature also available on dunning levels)

Dunning by Collection StrategyDunning Proposal1. Business Rules Framework business rules evaluation for a contract account or group of contract accounts2. Collection Step definition of dunning activity, activity priority, dunning interval, charges & interest, alternative collection step 3. Organizational Management responsibility determination4. Capacity Planning & Workload Balancing definition of max. no. of dunning notices in a dunning activity

Dunning Activity Run

Collections Embedded in Organizational StructureMultiple independent collection organizations can be set upTeams or individuals can be determined based on business rulesTaking into account absence of agentsAutomatic determination and manual intervention by collection managerPrerequisite for workload balancing

CollectionsTeam 1CollectionsTeam 1Collection CenterRegion West Position:Collection ManagerSandyResponsiblefor CollectionsIn Region WestCollectionsTeam 1CollectionsTeam 2Position:Team LeadJohnResponsiblefor Private CustomersPosition:Collection AgentCathyPosition:Collection AgentFredFor customers range A-KResponsibleFor bankrupt customersResponsible

Assignments in the Organizational StructurePossible collections organizational structure to be maintained under Organizational ManagementOrg.Unit:Collections EastOrg.Unit: Coll.East NorthernOrg.Unit: Coll.Team 1Responsibility:Coll. Private Cust. Position: Collector 2aUser: Joe Black ... User: Susan SearsUser: John Sanders...Task:Coll. Unit NorthernChief Position: Coll.SupervisorOrg.Unit: Coll.Team 2 Position: Collector 2b Position: Collector 2cResponsibility:Amount < 100, all private customersResponsibility:Amt>100,priv.cust.up to 5000000000Task: Coll. SpecialistTask: FI-CA/RM-CA Coll. DpmtResponsibility: Cust. Region EastOrg.Unit: Coll.East SouthernUser: Rita EastChief Position: Collection Manager

Capacity Planning and Workload BalancingPrerequisite: determination of responsible department, optional: unit and agentUpper limit for number of activities that can be processedOption to execute an alternative activityOption to request explicit release of activities starting from a threshold

Capacity Planning and Capacity Balancing - SequenceDunning Proposal 2. Dunning Activity Run3. Dunning Notice Release 4. Dunning Activity Run5. Dunning Notice Release

Workitem Creation - Overview Collection step BDunning/ Collection runDunning/ collection activityWorkitem CATEGORY 01 Workitem CATEGORY 02 Workitem CATEGORY 03 Workitem CATEGORY 04Worklist 01Worklist 02Collection step A

Cockpit for Managing Work list

Monitoring and Adjusting a Worklist

Collections Management:Customizing in ERP System IIMG Contract Accounts Receivable and PayableBusiness TransactionsDunningDefine Charge Categories for DunningConfigure Charge Schedules for Dunning ProcedureDefine Document Types for Dunning Charges CategoriesDefine Specifications for Interest on ArrearsDefine Dunning Lock ReasonsConfigure Dunning ActivitiesDefine Time-Dependent Creditworthiness WeightingsDefine Execution Variants for Dunning Proposal Run

Collections Management:Customizing in ERP System IIIMG Contract Accounts Receivable and PayableBusiness TransactionsDunningDunning by Collection StrategyDunning by Dunning ProcedureDefine Collection StepDefine Collection StrategySettings in Business Rules Framework Define Capacity Planning for Dunning ActivitiesMaster Data GroupingWork List and WorkitemsClerk Determination

Master Data Groups for CollectionsGrouping level: contract accountBusiness PartnerContractContractContractContractContract Account Contract AccountContract AccountContractContract

Master Data - Migration Setting up (existing) contract accounts for collections management:

Report RFKK_UPDATE_MASTERDATA can make settings based on existing values on contract accountEvent 1044 used for determination of master data group and collection strategy:Posting area 0400 for default values

Event 1045 used for determination of contact person

Progress and Success of Collections There are different levels for measuringProgress of collection activities Monitoring of work lists regarding outstanding amounts and open items Evaluation of promises to pay Fulfilled vs. broken promises to pay Success of collection strategy for a specific customer Which activity resulted in the payment Partial vs. full settlementCan impact the next collection step Champion Challenger AnalysisIdentification of the most successful collection strategies

AgendaIntroductionDetermination and Execution of Collection ActivitiesDetermination of Collection StepResponsible DeterminationWorkload BalancingManaging Collection Work ListsProcessing Collection WorkitemsEnhancements in Financial Customer Service ProcessesCollection Fact SheetCollection HistoryPromise to PayCustomizable BalancesOutgoing Payment RequestDispute Management

Integrated Collections Functions for Processing WorkitemsGet update on customers payment dataAutomatic resubmission of WorkitemsLink to the appropriate functions

Giving instructions to agent

Showing overall customer status incl. collection information

For additional background informationAlerts during customer callCollection Fact SheetCustomer Detailed ViewsCapture payment commitment (promise-to-pay)Capture payment authorizationOffer installment planWork lists/ WorkitemsEnhanced collections history

360 degree view of customer Customer Interaction historyIncluding financial and non-financial (service, order-related) interactionsOutbound and inbound interactionsInteractions manually processed as well as interactions output through mass processes Customer Fact SheetsBrings together the most important data of a customer Various fact sheet levels: business partner level, account levelEasily customizable (including finance data, contract data, etc.) Detailed Financial ViewsInvoices including access to archived documentsAccount balancesDunning history including details about items, activities, documentsPayment historySearch for payments unapplied/ applied wrongly

Work list Overview

Detail View for Workitem

Workitem : Customizing in CRM SystemIMG Customer Relationship ManagementInteraction Center WebClientIndustry-Specific FunctionsEdit FI-CA ProfilesIntegration with Contract Account Receivable and Payable (FI-CA)21

AgendaIntroductionDetermination and Execution of Collection ActivitiesDetermination of Collection StepResponsible DeterminationWorkload BalancingManaging Collection Work ListsProcessing Collection WorkitemsEnhancements in Financial customer Service ProcessesCollection Fact SheetCollection HistoryPromise to PayCustomizable BalancesOutgoing Payment RequestDispute Management

Enhancements for FCC - Collection Fact Sheet

Fact Sheet Customizing IIMG Customer Relationship ManagementUI FrameworkUI Framework Definition

Fact Sheet Customizing II

Fact Sheet Customizing III

New Views for a Collections Fact Sheets

Promise to Pay Promise to Pay History display FICACMP_P2P/FicaP2PFsListCollection StrategyCollection strategy history display for one dunning group. Only for dunning by collection strategy. If no Workitem is specified, the dunning history of the current master data is evaluated. If the selected master data include more than one dunning group, * will be displayed for collection strategy and current/ preceding collection step. FICACMP_DUN/FicaFSCollStraCurrent WorkitemDisplay details of the currently processed Workitem and business partner. FICACMP_WLI_2/WLISingleDetailsPartners for current WorkitemDisplay details of the currently processed WorkitemFICACMP_WLI_2/WLIFSPartnersNotes History for current WorkitemNotes display for the currently processed Workitem and contract account group.FICACMP_WLI_2/WLINotesDisplay

ViewDescriptionView name (technical)

Collections History IC WebClient View

Dunning History and Collections HistoryDunning HistoryLists dunning headers according to the selection criteria (e.g. for a specific dunning run, for a specific business partner, for a collection strategy, etc.) Shows items related to a dunning headerShows activities related to a dunning headerShows correspondence issued through dunning activitiesAllows to reverse a dunning header Collections HistorySelection criteria restricted to master data entities (business partner, contract account, contract) and optionally a range of open itemsShows items related to a dunning headerShows activities related to a dunning headerHierarchical display of a leading object (typically dunning header) and sub-ordinate objectsCan show correspondence related to a dunning headerCan show details related to activitiesCan also show installment plans, promises-to-pay, payments as they relate to the dunning header or other objects Extensible to report on further objects (e.g. disconnection orders, CRM interactions)No reversal function availableIs based on runtime evaluation of various data sources

Customizing in ERP SystemIMG Contract Accounts Receivable and PayableBusiness TransactionsDunningDunning by Collection StrategyDunning by Dunning ProcedureDefine EventsCollection HistoryDefine VariantsDefine Event CategoriesMake General Settings

Procedure of Promises to PayDunningActivity RunWorklist entry

P2P OpenOpen itemPromise-to-payValuation Run

P2P Fulfilled

P2P BrokenCorrespondenceP2P initiated If P2P is broken the original open items will be evaluated again by the collection activity runCorrespondenceUpdate Credit-worthinessExecute custom-specific activity

Architecture of Promise to Pay/ Status

Source System ERPSAP CRM (Interaction Center WebClient)RFC The Promise to Pay is an object in the ERP backend system.

Creation, Display, Replacement and Withdraw of a promises to pay can be done in IC WebClient

A Fast entry functionality for creating a Promise to Pay is provided in IC WebClient

Evaluation Run is done in the backend system by mass activity

Display of the results of the Evaluation Run again is possible in front-end system.Promise to Pay

Fulfillment rateStatusAmountReasonReasonFilled by evaluation run

Promise to Pay in IC WebClient

Customizing in ERP System: Promise to PayIMG Contract Accounts Receivable and PayableBusiness TransactionsPromise to PayDefine Reasons for CreationDefine Reasons for WithdrawalDefine Specifications for CreationDefine Specifications for Valuation of Promise to PayEdit Number Range for Promise to PayArchiving

Enhancements for FCC - Customizable BalancesBusiness partner itemsBPART Net due date Amount 03/23/ 2007 232.00

Sum up items to balancesBuild grids of balancesDisplayReceivablesCredits< = 30dReserved31d-60d61d-90d> 90dBalance DisplayBalance Group 1ReservedReceivablesPaymentsCredits< = 30d31d-60d61d-90d> 90d

Customizable Balances Balance Variant / Balance GroupBalance Variant 1Balance IntervalOpen since 30 daysOpen since 61-90 daysOpen since 31 60 days Open receivablesBalance CategoryReceivablesReceivables and CreditsItems in CollectionBalance Group 1Balance Group 2Balance Group 3Open since 90 day and longer

Customizable Balances in IC WebClient Account Balance

Customizing: Customizable BalancesIMG Contract Accounts Receivable and PayableBasic FunctionsAccount Balance DisplayBalances VariantsDefine Balances GridDefine Balances GroupsDefine Balances VariantsERP SystemIMG Customer Relationship ManagementCRM System

Steps to Enhance the Balances Variants in IC WebClientChange Customizing for Balance Variants in ERP System

Enhance Event 1299

Adopt Event 2801

Enhancements for FCC - Outgoing Payment RequestsApproval of the Request Refund of credit O.K.

Outgoing Payment Request: Process flowEntering Outgoing Payment Request in Interaction Center Web Client (incl. payment data)Creation of Payment Specification in Backend SystemDecision whether creation has to be approvedAfter approval payment is processed within the payment run

Outgoing Payment Requests in Interaction CenterItems already included in a payment specification are marked with status icon

Payments : Customizing in ERP SystemIMG Contract Accounts Receivable and PayableIntegrationCustomer Relationship ManagementBusiness Transactions in IC WebClientDefine Types of Agreement for Payment ProcessingDefine Types of Agreement for Payment Processing

Benefits Less bad / risky customers Increased Cash Flow / Lower DSO Reduction in write-offs Reduced overall financial risk Reduced operating costs Reduced collection time Transparent processes and data across different organizations and even systems Seamless integration in IS-U/FI-CA processes as well as in Call Center Full transparency / 360 degree view of customer Flexibility in collections processes to meet specific needs

AgendaIntroductionDetermination and Execution of Collection ActivitiesDetermination of Collection StepResponsible DeterminationWorkload BalancingManaging Collection Work ListsProcessing Collection WorkitemsEnhancements in Financial Customer Service ProcessesCollection Fact SheetCollection HistoryPromise to PayCustomizable BalancesOutgoing Payment RequestDispute Management

Business Process Account is calling Provider to complain about a Bill(s)Callcenter Agent identifies AccountProcess dispute dispute can be on whole Bill certain Bill Line Item(s) certain EDR(s)Callcenter Agent creates a DisputeCallcenter Agent identifies BillCallcenter Agent creates an Adjustment Request for the Dispute

Dispute Detail - Header and Items

LimitationThe solution does currently not contain:Integration with Invoice Display for Utilities Standard interface for Bill display to and integration with SAP ERP Billing and SAP ERP Convergent Invoicing Automated checks for the permitted adjustment amounts or usageCreate Disputes related to objects from the account receivables system (dunning notes, payments, fees) Integration with FI-CA block disputed amounts against dunning, automatic collection and interest calculationAutomatic update of Dispute in case of postings in FI-CA related to the disputed documents

But planned for future releases

Copyright 2007 SAP AGAll rights reservedNo part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned and associated logos displayed are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pagesWeitergabe und Vervielfltigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrckliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen knnen ohne vorherige Ankndigung gendert werden.Einige von der SAP AG und deren Vertriebspartnern vertriebene Softwareprodukte knnen Softwarekomponenten umfassen, die Eigentum anderer Softwarehersteller sind.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge und andere in diesem Dokument erwhnte SAP-Produkte und Services sowie die dazugehrigen Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und in mehreren anderen Lndern weltweit. Alle anderen in diesem Dokument erwhnten Namen von Produkten und Services sowie die damit verbundenen Firmenlogos sind Marken der jeweiligen Unternehmen. Die Angaben im Text sind unverbindlich und dienen lediglich zu Informationszwecken. Produkte knnen lnderspezifische Unterschiede aufweisen. Die in diesem Dokument enthaltenen Informationen sind Eigentum von SAP. Dieses Dokument ist eine Vorabversion und unterliegt nicht Ihrer Lizenzvereinbarung oder einer anderen Vereinbarung mit SAP. Dieses Dokument enthlt nur vorgesehene Strategien, Entwicklungen und Funktionen des SAP-Produkts und ist fr SAP nicht bindend, einen bestimmten Geschftsweg, eine Produktstrategie bzw. -entwicklung einzuschlagen. SAP bernimmt keine Verantwortung fr Fehler oder Auslassungen in diesen Materialien. SAP garantiert nicht die Richtigkeit oder Vollstndigkeit der Informationen, Texte, Grafiken, Links oder anderer in diesen Materialien enthaltenen Elemente. Diese Publikation wird ohne jegliche Gewhr, weder ausdrcklich noch stillschweigend, bereitgestellt. Dies gilt u. a., aber nicht ausschlielich, hinsichtlich der Gewhrleistung der Marktgngigkeit und der Eignung fr einen bestimmten Zweck sowie fr die Gewhrleistung der Nichtverletzung geltenden Rechts.SAP bernimmt keine Haftung fr Schden jeglicher Art, einschlielich und ohne Einschrnkung fr direkte, spezielle, indirekte oder Folgeschden im Zusammenhang mit der Verwendung dieser Unterlagen. Diese Einschrnkung gilt nicht bei Vorsatz oder grober Fahrlssigkeit.Die gesetzliche Haftung bei Personenschden oder die Produkthaftung bleibt unberhrt. Die Informationen, auf die Sie mglicherweise ber die in diesem Material enthaltenen Hotlinks zugreifen, unterliegen nicht dem Einfluss von SAP, und SAP untersttzt nicht die Nutzung von Internetseiten Dritter durch Sie und gibt keinerlei Gewhrleistungen oder Zusagen ber Internetseiten Dritter ab.Alle Rechte vorbehalten.

Collections Management with SAP for Utilities is based on the sub-ledger Revenue Management-Contract Accounting (FI-CA) which focus on the needs of high-volume business in the Utilities area. Collections Management with SAP for Utilities provides a wide range of capabilities to do collections including a variety of collection activities such as creating reminder letters, scheduling outbound calls, triggering disconnection documents and service orders, submitting open items to external collection agencies, and so on.

With ERP 6.0 Enhancement Package 2, major enhancements have been done in all of the listed areas:-> Additional mass activities are available to evaluate promises-to-pay and collections success, the dunning run provides additional flexibility to determine the most adequate collections activity-> Collection managers can monitor the work lists of their teams and agents and adjust the work distribution as necessary-> Additional views and functions are available for agents processing collections Workitems in IC Web Client (requiring CRM 5.2) -> Additional BI content is available to analyze collections success

The new features in Collections Management require the usage of FI-CA. Some areas require CRM IC Web Client in addition and/or BI.

By using Business Rules Framework for the determination of the next collection step we address the following need of business and IT users:Very often the parameters offered in classical dunning are not sufficient in order to determine the right step to be taken for an overdue customer. Using BRF as a rules engine gives flexibility regarding the data that are available for evaluation. SAP ships default context data that can be enlarged as needed (without programming).The determination of the next collection step can be done in a variety of ways, e.g. through a decision tree.As the rules are modeled in the rules engine instead of hidden in ABAP code in events, they become transparent to the business user. Key business users trained in the usage of BRF may configure the rules, programming is not required. Determination of the next step can be made dependent on the result or status of a previous step and thus manual intervention and automatic carry-on can be put into effect.

In the classical dunning the dunning procedure assigned to each contract account determines the number of dunning levels and the respective dunning activity sequence. This determination of the next dunning level is mainly based on the days in arrears and the amount of debt.

Dunning by collection strategy is based on business rules that are evaluated at run-time. This allows for a flexible evaluation of a broad range of parameters. A collection strategy is assigned on master data level. Contract accounts (or contract) can be treated individually or can be grouped together for collections. The evaluation of the business rules within the strategy return the next collection step (and related activities) to be carried out. There is not necessarily a fixed sequence of steps to be carried out one after the other. It is the specific circumstance of an account that determines the next collection step. The data that can be evaluated in the rules engine include the dunning data, dunning history, credit risk data and many more (including customer-specific tables).

As part of the dunning proposal run, the responsible organizational units and/or positions are determined and based on this information. Workload balancing is carried out. Only afterwards, the dunning activity run can create the final activities. If you want to carry out workload balancing not only for collections Workitems but also for other activities, e.g. sending reminder letters, it is essential that also these activities have a responsible organizational unit (at least a collection center) assigned.

The collection manager is responsible for maintaining the system with the help of SAP Organizational Management so that collection specialists, units and/or departments can be determined automatically or with his manual intervention for the processing of all Workitems generated from the dunning run.For this determination of the responsible processor two steps are necessary:Set up the collection agent, unit and department tasksConfigure the collection agent, unit and department responsibilities

SAP Organizational Management plays an important role for Collections as it enables for example:the set up of multiple independent collection organizationsthe automatic determination of collection teams and collection agents with basis on business rulesthe manual intervention of a collection managerthe assignment of a back up collection specialist that can take over the Workitems of an absent collector, etc.Here is an example of a structure how the collection manager has organized the responsibilities in his collections organization.Prerequisite for workload balancing is the maintenance of the responsible organizational units and/or positions.Workload balancing functionality requires further settings in configuration per dunning activity. You can define the maximum number of an activity that can be carried out by an organizational entity and per dunning run without any additional intervention.The upper limit per dunning activity can be maintained per collections department, collections unit and collection specialist. At least the collection department needs to be specified.When the maximum number of dunning activities for an organizational unit is reached, the remaining activities may Be droppedBe replaced by an alternative activityRequire explicit releaseThe subsequent dunning activity run will ignore the dropped activities. In case of a release required, the activity run will only create entries for released activities. The release can only be performed by a report for execution of dunning activities.The sequence of all items of one activity determines which of them fall below or above the threshold. In order to influence to sequence, ranking needs to be done. The rank of each activity is determined via BRF.

By setting the Release From it means that beyond the value specified, there will be always a manual release of the dunning notices so that it is possible to verify the team/unit responsible workload after each dunning activity run.

The collections process is initiated by the dunning run. New collection activities can be configured that create and/or close collections Workitems based on the function modules FKK_0350_WLI_CREATE_AND_CLOSE (for creating a Workitem which entails closing a previous Workitem) and FKK_0350_WLI_CLOSE (to just close an existing Workitem). Different Workitem categories can be configured to represent different types of collections work. For each Workitem category a collection activity needs to be configured (re-using the same function module).

Each Workitem category comprises different parameters such as:Workitem processing type (where it is defined if the Workitem should be processed either by a specialist or a dialer)Workitem processing deadline (that defines which processing deadline the Workitem will have), etc...In order to prepare the system to generate Workitems, some settings have to be carried out in the ERP IMG.

The system can be configured so that Workitems are grouped into work lists automatically. Alternatively, it is possible for the collection manager to group the Workitems and create a new worklist manually.

In the ERP system there is a transaction that enables the collection manager to perform most part of his daily tasks.In the SAP menu the collection manager selects Utilities (or Telecommunications) -> Contract Accounts Receivable and Payable -> Periodic Processing -> For Contract Accounts -> Dunning Notice -> By Collection Strategy -> Manage Work lists (transaction FPWLM).

In the New Workitems tab it is possible to see all new Workitems that have been created with the dunning run within the responsibility area of the collection manager.After the items are processed by the collection specialist and the list is completed, it can be displayed under the Completed Worklists tab.

Under Current Worklists tab the collection manager will find the worklist he has just created.The Worklist has status New/not released and before it can be processed or at all seen by the collection specialist, the manager will have to release it.There are 3 different status for the worklist:Status N New/Not Released, here all Workitems have status A - New / Not released Status O Released (previously: Open), when at least one of the Workitems in the worklist is either B - New (already released), C - In process or D - For Resubmission Status C Closed, if the Workitems have status E Closed; F Closed by Dunning Activity, G Closed after Incomming Payment, H Closed Manually or I Closed by Reversal of Dunning Activity Run.The worklists created automatically by the system will also be released by it. In order to release the worklist manually, the manager will have to select the respective list and click on Maintain Worklist button.Worklist assignments can be monitored and adjusted in case one of the collection specialists is for example temporarily absent. By using Maintain Responsibilities button the collection manager can proceed with an adjustment of the responsibilities.

In the IMG, under Contract Accounts Receivable and Payable -> Business Transactions -> Dunning you will find all the customizing steps necessary that are valid for both dunning with the dunning procedure and dunning with a collection strategy.Under Contract Accounts Receivable and Payable -> Business Transactions -> Dunning -> Dunning by Collection Strategy all settings can be done for Dunning with Collection Strategy (e.g. configuration of the collection steps, definition of Collection Strategies, settings for capacity planning per dunning activity,) With the new collections management the dunning grouping indicator on contract account level is not used. Instead, an explicit grouping of contract accounts and/or contracts is available. Grouping can take on two levels: on contract account level or on contract level. With this concept you can dun all contract accounts of a business partner together (i.e. dunning on business partner level) or you can define any groups you need. If a contract account shall be treated on its own, you dont have to assign it to a group.Per master data group you have to define the collection strategy and the contact personThe transaction code to maintain the groups is FPCG. A direct access from contract account maintenance transactions (CAA2, CAA3) is provided. Direct access from contract account creation (CAA1) is planned for a later release.

The report RFKK_UPDATE_MASTERDATA makes the initial entries for the master data group, strategy, and the contact persons for the contract account or contract.Firstly, all contract accounts for the selected business partner are determined. If company codes that group at contract level are involved, event 1040 is processed to determine the contracts of a business partner.The required values for the fields above are determined via events 1044 and 1045. The data is then stored in the corresponding master data objects.

In posting area 0400 you define default values for the collection strategy and collection unit.You can use the following contract account attributes to determine the default values:Company code groupStandard company codeContract account categoryDunning procedureDunning groupingUsing the dunning procedure attribute, you can control whether the default values are to be used for a migration of existing contract accounts (with a defined dunning procedure) or as initial values for new contract accounts to be created (dunning procedure is blank).For the migration you should run the report RFKK_UPDATE_MASTERDATA. However, you can also do the migration step by step using the Maintenance of Master Data Groups of Business Partners transaction in the SAP menu under Master Data -> Business Partner -> Data for Collections Management -> Maintain Master Data Groups or the dunning run.This posting area 0400 is used exclusively in event 1044. Collection Success: The result of this calculation is stored on the dunning header table as a percentage value. Therefore the dunning header table has been extended to store the collections success (percentage value)Subsequent to the dunning run, the success of each dunning step and/or level with regards to a particular customer can be evaluated with a new mass activity. If the success of the dunning has not been valuated yet, the field contains the earliest possible date for this success valuation. It is set by the dunning proposal run. Default value is: 7 days after payment target date if available, else 14 days after date of issue.If the success of the dunning has already been valuated, the field contains the date of the valuationThe full dunning history including the collections success value is available for analysis in BI.

In the IMG, under Customer Relationship Management -> Interaction Center WebClient -> Industry-Specific Functions -> Integration with Contract Accounts Receivable and Payable the settings for the respective profile (FCC) can be customized by enabling the collection mode and setting the ERP Release for at least 602 ERP ECC 6.02.Other settings have to be carried out regarding the Workitem. These are done in the backend system.Configuration IMG: Customer Relationship Management -> UI Framework -> UI Framework Definition -> Maintain Fact Sheets In the Fact Sheet area the fact sheet components / views are defined You can create own fact sheets and add own views to existing fact sheets. Standard layout Types: The following standard layout types will be available for pages with tiles:2x3 layouts, that is, two columns and three rows2x2 layout, that is two columns and two rowsT-shape

Configuration:You can define the layout that is relevant for pages with tiles.You need to define the name of the new tile layout , and the number of columns and rows. Then you define the tiles and their position and span in the grid.For the grid definition, you need to make entries in the following fields: tile ID: The tile ID is a unique identifier for a tile in a certain tile layout. it does not define the order of the rile Column: the number defines the column position of the upper left corner of a tile in a layout Row: The number defines the row position of the upper left corner of a tile in a layout Cols pan: the number defines the number of columns many columns in the grid that a tile expands to the right Rows pan: The number defines the number of rows in the grid that a tile expands downward

When you define the grid, be careful that the tiles do not overlap or exceed the grid size. the order in a grid is from left to right, from to bottom, and starts with '1'.

Configuration:In assign which view maintained in the customizing before should be displayed in which tile Therefore go to the BSP WD Workbench (Transaction BSP_WD_CMPWB), enter Component BSP_DLC_FS go to the Configuration of View BSP_DLC_FS/factsheet. You have to enter then the ID of the fact sheet you want to configure.Additionally some view configuration can be done dependent on the Fact Sheet. In addition to the dunning header you will see the objects related to the dunning. The possible object types need to be configured in the IMG as event categories. Example: the event category promise-to-pay is assigned to the context event dunning. You can drill down further from a promise-to-pay into a payment if configured accordingly. The assembly of the collections history is done based on so-called reporters and some configuration. The reporters make sure that data are associated correctly (e.g. a payment can only be related to a dunning header if the payment has a data equal or higher than the dunning date).By drilling down into the dunning header you will get details about the dunning run, the items involved and the activities that were triggered. For the Workitems it is also possible to drill into its full details through the hyperlink available in the text. This feature is not available in the backend.Details about each line can be found (only when the line is marked and when details are available) in the details section in the lower part of the screen.Please find here the comparison of the history in the conventional dunning and the new collections processing.Events and event categories determine what type of information will be displayed in the collections history. Unless you want to extend the collections history with specific information currently not available in standard, the default configuration should be sufficient. The following event categories are delivered:0001Dunning Notice0002Correspondence0003Workitems0004Payments0005Promise to Pay0006Installment Plans

In Define Events you define the events of the collection history Each event is linked to a reporter, i.e. a small program that makes the respective data available.In the collections history variant you define how the data will be arranged in display. In the default variant, the dunning header is the leading object. Other objects are grouped below.

A Promise to Pay can be created from a Worklist item. Worklist items describe the receivables due from a business partner. They are created during the Dunning activity run. Since a Promise to Pay usually is a result of a customer contact the functionality will be provided in the IC WebClient. When creating a Promise to Pay in the IC WebClient, this will create an object in the ERP backend system.It is possible to send correspondence to the business partner via the print workbench when a Promise to Pay is created. The correspondence type for printing a Promise to Pay is 0045 (Promise to Pay).A valuation takes place once the Promise to Pay is closed. The valuation determines a level of fulfillment for the promise to pay, and, using the level of fulfillment, a status. The valuation might lead e.g. to one of the following statuses: -> Promise fulfilled -> Promise fulfilled with accepted variances -> Promise not fulfilled or Promise Broken The information whether a Promise to Pay has been broken or not can be stored in the header of the Promise to Pay object and can e.g. be used for the decision whether to accept again a Promise to Pay from this particular customer or which kind of Promise to Pay should be accepted in future.A broken Promise to Pay has an effect on the creditworthiness of a business partner. If a Promise to Pay is broken the original open items will be evaluated again by the collection run activity, before that, correspondence can be triggered to the business partner has well.The Promise to Pay is an object in the ERP system.Its possible to create, withdraw, change and display promises to pay in the front-end system using the SAP CRM Interaction Center WebClient. Nevertheless, the Promise to Pay object itself his stored in the ERP backend system.A fast entry functionality is provided in the IC WebClient to create a Promise to Pay with only a view clicks. A valuation process runs in the backend system as a mass activity for all Promises to Pay with status Open. This valuation process will determine the level of fulfillment of the Promise to Pay. The level of fulfillment will then determine the status of the Promise to Pay. The Fulfillment rate and the status, which are determined in the Evaluation are stored in the Promise to Pay object and can then be displayed in the Interaction Center WebClient. Its possible to have multiple Promise to Pay items with different due dates and amounts. It is allowed to manually change these parameters in the IC WebClient for all the items in the Promise to Pay or to change the items individually. There can be multiple payment options, also in combination within one promise to pay. So different Promise to Pay items can have different payment methods.A charge for capturing a Promise to Pay can be included in the open amount of the promise. In case of a charge, the customer should be informed by the agent.

Under the activity step Define Categories, you define the categories for the promises to pay. A category determines the rules used for setting up the installments (due dates and amounts) and specifies if charges and interest apply. Under Define Reasons for Creation, you define the reasons a clerk can specify for creating a Promise to Pay. In the Activity Define Reasons for Withdrawal, you define: The reasons a clerk can specify for withdrawing a Promise to Pay. You also define for each withdrawal reasons, the specifications for dealing with interest and charges and the update of the creditworthiness of a business partner in the case of a broken Promise to Pay.In the activity step Define Specifications for Creation you define the specifications for the standard entry and the fast entry in the CRM IC WebClient of Promises to Pay.Under Define Specifications for Valuation of a Promise to Pay you define:The number of tolerance days that you want to grant before a payment is deemed to be too late and is to have an effect on the level of fulfillment.The influence each day of delay is to have on the level of fulfillment.And which level of fulfillment must be reached as a minimum for a Promise to Pay to be deemed fulfilled or fulfilled with variances.You can also define a Number Range interval for the Promise to Pay.

Its also possible to define archiving settings in case you choose to archive Promises to Pay. In this case you can define how many days a Promise to Pay must be in the system before it can be archived. You also need to activate the Archive Information Structure for Promises to Pay.

In addition to the existing totals in the account balance display, you can configure balances variants in Customizing. The individual balances are summarized to balances groups and displayed as tables. This means that a balance category (row) such as receivables is subdivided further by a balances grid (column) such as open due, or due since 30 days, due since 60 days, due longer than 90 days.A balances variant covers balances whose type of calculation is defined in Customizing. Therefore the system groups the individual balances categories of a balances variants in balances groups (for example, payments) and displays them as a row in a table. For each column of the display, the balances categories are subdivided by balances intervals (for example, open, due since 30 days). A balance is therefore the combination of a balances category and a balances interval. SAP supplies a standard variant. The system only calculates balances automatically for the combinations of balances categories and balances intervals delivered in this standard variant. If you define your own balances variants with balances different to the combinations contained in the standard variant, you have to implement the calculation of these balances in FI-CA Event 1299.For the Account Balance Display in IC WebClient a fixed balance variant is used, the agent cannot change the balance variant like in the ERP Backend System. This balance variant can be set in FI-CA Event 2801, the standard delivery balance variant STD.With the Filter Filter by Balance Group different Balance Groups according to the balance variant can be displayed.In case of not being 0,00 a link on the amount navigates to a list of all items that have been taken into account to calculate the selected balance amountERP System: For each balances variant, you can also define which balances, that is, which cells in the table, are not to be calculated and displayed.Under Contract Accounts Receivable and Payable -> Basic Functions -> Account Balance Display -> Balances Variants you can define the balance categories that you need subsequently for the definition of balance groups as well as the balance grid that you require later of for the definition of balance groupsSettings under Define of Balance Groups control the representation of items in the account balance display.In this activity individual balances are grouped into balance groups. For each balances group it has to be defined which balances categories are to be used in the rows for the table display and which balances grid is to be used in the columns. You summarize the balances groups into balances variants in the activity Define Balance Variants.

CRM System: For the customizing settings in the CRM System the ERP Release of the backend system has to be set for the FI-CA Profile you are using (e.g. FCC). This can be done under Customer Relationship Management -> Interaction Center WebClient -> Industry-Specific Functions -> Integration with Contract Accounts Receivable and Payable -> Edit FI-CA Profiles -> Settings -> General Settings.The entered Balance Version under Account Balance in the same Customizing Transaction allows you to control which FI-CA module should be used to create the balances. If you are using SAP ERP ECC 6.00 and lower you can only use the Classic balances. With SAP ERP ECC 6.0 Enhancement Package 2 you can use the new flexible customizable balances or the Balance Variants.

The settings under Customer Relationship Management -> Interaction Center WebClient -> Industry-Specific Functions -> Integration with Contract Accounts Receivable and Payable -> Define Filters for Balance Overview are only relevant in case you are using the Classic Balances. They are not needed for the Balance Variant.

For customer specific Enhancements of the Balances Variants first create a new Balance Variant in the Customizing settings for the Balance Variants in ERP System. Then enhance Event 1299 where the Balances are calculated. You have to add the calculation method for your new customer specific balances. In Event 2801 it is fixed which balance variant should be used for FCC Display, so you might have to do some changes there as well.

Please be aware, that the calculation of balances is not only used for the Balance Overview View. Balances have to be calculated for various views in the IC WebClient. Also the Navigation to a special group of items (e.g. all payable receivables) is provided by the same logic that is used for grouping items to summarize them to a particular balance.

By creating an outgoing payment request in IC WebClient you can summarize several items of a business partner with one outgoing payment using a specific payment method and specific payment data. All the items selected for an outgoing payment are handled as one outgoing payment through the process of approval. The payment run refunds the sum of the items as a one outgoing payment as well.After entering the outgoing payment request in Interaction Center WebClient a payment specification is created in the ERP Backend system. With a payment specification you can group items and at this level, define a payment method and payment data. The following payment types are provided: Bank Transfer, Credit Card and outgoing check.When you create or change a payment specification, the workflow for check and approval in accordance with the dual control principle can be run. You decide whether the creation must be approved in the FI-CA event module 5514. You cannot change a payment specification with the status to be approved until it has been approved or rejected. The payment run includes only complete payment specifications that do not have status to be approved as well.The payment run in the backend system treats the payment method, bank details, card details, and all details as if they had been entered on document item level.

In the Document or Item Display of the IC WebClient after choosing outgoing Payment Request items that should be included in the outgoing payment request can be selected. The payment data such as payment type and bank details or credit card can be entered. The entry in the Text field and in the Reason filed are transferred into the approval workflow text and are therefore available during the approval process. In case of not using the approval workflow the entry in field reason will get lost.

Under Contract Accounts Receivable and Payable -> Integration -> Customer Relationship Management -> business Transactions in IC WebClient -> Define Types of Agreement for Payment Processing settings can be done in order to handle Agreements for Payment Processing in Interaction Center.In Customizing Transaction Define Types of Agreement for Payment Processing for each type of agreement in particular for the payment specification in FCC the allowed payment types have to be set up. There it also can be fixed in which order the payment types are to be offered for selection and which payment method for the payment should be used in the back end. Since payment methods are country-specific, you make the definition per country.The following payment types are provided: Bank Transfer, Credit Card and outgoing check

The use case is a call from the customer to the call centre. The call centre agent identifies the customer as an account. The customer wants to complain about his bill. The call centre agent searches for the bill of the account.The list of found bills is displayedStarting from the list of bills navigation to the following information is possible, depending on the object of customers complaint:Details of one billList of line items of one billDetails of one bill line itemList of EDRs (Event Detail Records) of one bill or one bill line ItemDetails of one EDRList of adjustment requests related to one bill, bill line item or EDRAfter identifying the object of the complaint, the call centre agent can create an dispute for one or more of these objects.Existing Disputes can be changed.Additional objects can be linked to the dispute for information purposesThe dispute can be dispatched to other processors Outbound correspondence can be created and linked to the dispute. Adjustment Requests can be created to the dispute.There are several attributes in a Dispute header The Reason why a dispute has been created. It can be freely defined in Customizing and might include information about incorrect invoice, goods or delivery date.The Status specifies the current processing status of a dispute case. Also the status can be defined in Customizing. Possible statuses may include open, in process, clarified, closed.The escalation reason can be set (automatically) depending on duration of the processing, the amount or priorityThe Disputed Gross amount which is the sum of all disputed gross amounts of the items. In case of different currencies in the dispute items the amounts are converted to the dispute currency in the header. The default dispute currency is determined from the business partner but can be overwritten.The Dispute allows to trigger CRM actions manually as well as automatically controlled by schedule conditions . Therefore based on these actions it is possible to create automatic correspondences (e.g. by a particular status change), or to include case-specific notes in a pre-defined form. Besides the correspondence creation other actions are feasible, e.g. the creation of a credit memo request for particular dispute items or the approval of all Dispute items. The dispute is based on the One Order Object Complaint. The Dispute Case in CRM 5.0 was based on the object case. The new dispute can contain several items. Every item has a reference object, the so called disputed object. The disputed object can be a bill, a bill line item or an EDR. Adjustment requests can be created in relation to each dispute item.