Skatteudvalget 2014-15 (2. samling)
SAU Alm.del Bilag 48
Offentligt
1549093_0001.png
Functional Analysis
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0002.png
DATE: 24.09.2015
Table of Content
1
Executive Summary ...................................................................................................... 4
1.1
1.2
Scope of work ......................................................................................................... 4
Methodology for Functional Analysis ...................................................................... 5
Process Review ............................................................................................... 5
Functional Overview ......................................................................................... 5
Functional Capability Assessment ................................................................... 5
1.2.1
1.2.2
1.2.3
1.3
1.4
1.5
2
3
2.1
3.1
3.2
3.3
4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
5
5.1
5.2
5.3
5.4
5.5
Findings (As-Is Picture) .......................................................................................... 6
Consequences ........................................................................................................ 7
Recommendations .................................................................................................. 7
Limitations ............................................................................................................ 10
Process Review .................................................................................................... 11
Functional Overview ............................................................................................. 11
Functional Capability Assessment ........................................................................ 11
Purpose ................................................................................................................ 13
Approach .............................................................................................................. 13
PRO014 Receive Claim Process Review ............................................................. 13
PRO021 Add Claim to a Treatment Process Review............................................ 14
PRO008 Customer Selection Process Review ..................................................... 14
PRO009 and PRO013 Payment Plan Process Review ........................................ 15
PRO017 and PRO020 Salary Deduction Process Review ................................... 15
PRO003 Asset Repossession Process Review .................................................... 16
PRO011 Insolvency Processes Review ................................................................ 16
Purpose ................................................................................................................ 18
Approach .............................................................................................................. 18
Functional Area Overview with Large Gaps Highlighted ....................................... 18
Functional System Distribution ............................................................................. 19
Core Functions ..................................................................................................... 19
Claim Management ........................................................................................ 19
Account Management .................................................................................... 23
1|Page
Scope of Work .............................................................................................................. 9
Methodology ............................................................................................................... 11
Process Review .......................................................................................................... 13
Functional Capability Assessment .............................................................................. 18
5.5.1
5.5.2
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0003.png
DATE: 24.09.2015
5.5.3
5.5.4
5.5.5
5.6
5.6.1
5.6.2
5.6.3
5.6.4
5.7
5.7.1
5.7.2
5.7.3
5.7.4
5.7.5
5.7.6
5.7.7
5.7.8
5.7.9
5.7.10
5.7.11
5.8
5.8.1
5.8.2
5.8.3
5.8.4
6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
7
7.1
7.2
Disbursement Management ........................................................................... 28
Reconciliation ................................................................................................. 29
Compliance and Treatments .......................................................................... 30
Business Reconstruction ................................................................................ 36
Insolvency and Litigation ................................................................................ 36
Forced Dissolution ......................................................................................... 36
Court Interactions, Reporting & Registrations ................................................ 36
Case Management ......................................................................................... 36
Operational Effectiveness .............................................................................. 37
Work Management (Resource Manager) ....................................................... 38
Dispute Management ..................................................................................... 39
Debtor Analytics (Risk Rating) ....................................................................... 39
Business Rule Management .......................................................................... 40
Document Management ................................................................................. 41
Operational and Governmental Analytics and Reporting ............................... 42
Client Meetings .............................................................................................. 45
Debt Relief/Subsidy .................................................................................... 45
Audit and Discovery .................................................................................... 45
Contact Management ..................................................................................... 45
Debtor Management ...................................................................................... 45
Claimant Management ................................................................................... 46
Correspondence ............................................................................................. 47
Other Functions .................................................................................................... 36
Support Functions................................................................................................. 36
Customer Functions.............................................................................................. 45
Other Findings ............................................................................................................ 48
Functional Architecture Overview ......................................................................... 48
Event Driven ......................................................................................................... 48
Insufficient Monitoring ........................................................................................... 49
Poor Performance due to Functional Architecture ................................................ 49
Insufficient Transaction Audit & History ................................................................ 49
Poor Exceptions/ Error handling and Transaction Roll-Back ................................ 49
Flexibility ............................................................................................................... 50
Process Overview Diagram .................................................................................. 51
Process List .......................................................................................................... 51
2|Page
Appendix - Process Diagram and List......................................................................... 51
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0004.png
DATE: 24.09.2015
8
9
Appendix – List of Defined Terms ............................................................................... 53
Documentation Listing with Review ............................................................................ 57
10.1
10.2
10.3
10.4
Claim Management Functional Review and Service Mapping ........................... 70
Account Management Functional Review and Service Mapping ....................... 72
Compliance and Treatment Functional Review and Service Mapping .............. 74
Insolvency Functional Review and Service Mapping ......................................... 80
10 Appendix - Service Mapping and Review ................................................................... 70
10.5
Court Interactions, Reporting & Registrations Functional Review and Service
Mapping ......................................................................................................................... 80
10.6
Case Management Functional Review and Service Mapping ........................... 80
10.7
Work Management (Resource Manager) Functional Review and Service
Mapping ......................................................................................................................... 81
10.8
10.9
Business Rule Functional Review and Service Mapping ................................... 85
Document Management Functional Review and Service Mapping ................... 85
10.10 Operational and Governmental Reporting Functional Review and Service
Mapping ......................................................................................................................... 86
10.11
10.12
10.13
10.14
Contact Management Functional Review and Service Mapping ....................... 86
Debtor Management Functional Review and Service Mapping ......................... 87
Claimant Management Functional Review and Service Mapping ...................... 89
Correspondence Functional Review and Mapping ............................................ 89
3|Page
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0005.png
DATE: 24.09.2015
1 Executive Summary
This document is divided into six sections; Executive Summary, Scope of Work,
Methodology, Process Review, Functional Capability Assessment (with key findings) and
Other findings. Although Accenture has performed an in-depth analysis on some EFI
functional areas, an overall assessment has not been performed on all of SKAT`s
functionality within other systems including DMI, Remedy, Captia etc. also on interfaces to
these systems nor on the data warehouse. The functional capability assessment has also
focused on core functionality as Accenture has defined it and we have excluded DMI
specific and other system functionality such as Remedy (used for case management).
Where possible, Accenture has listed these areas for functional completeness and
attempted to describe the capabilities in these areas from what we have learnt through our
process reviews and functional capability assessment.
1.1 Scope of work
The scope of the functional analysis was to provide an overview of the functional areas
that are supported within the System (EFI + DMI) and to then assess selected critical
areas of the EFI System to understand whether there are functional issues within these
areas. The review covered critical areas such as; claim management, treatments,
compliance including payment plans, salary deduction and acknowledgement of debt. In
this report, functional areas are used to describe the grouping of functionality or activities
within the processes on the basis of the functions that they perform.
Given the divergence between the original use cases and the current functionality,
Accenture focused on understanding the as-is functionality to determine critical areas and
whether or not Accenture could find any issues and gaps in these areas based on what
Accenture would expect for debt collection and management functionality. Refer to
Accenture’s technical report for the to-be analysis.
Specifically, as part functional analysis, Accenture has:
Performed a review of the core business processes
Created a functional overview and defined the as-is functional areas to the depth
possible given the documentation at hand, the timeline and the agreed with SKAT
effort put into this overview
Assessed the overall functional areas to identify missing functionality and potential
issues
Compared the functional capabilities against the debt collection process
management model to identify gaps or deficiencies
Accenture did not:
Perform a review of the functionality from a legal perspective
Create a detailed listing of all functionality under each functional area
Perform a complete review of the functionality within EFI, DMI and other systems
4|Page
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0006.png
DATE: 24.09.2015
Assess or trace workflows through the functionality
Review the business rule matrices or document the business rules and how they
are applied
Perform a detailed review of DMI functional designs or any DMI code
Review the to-be requirements based on the original system specification
Defined a to-be functional overview from the perspective of what was originally
expected
1.2 Methodology for Functional Analysis
Under the limitations given in section 2.1 Limitations, Accenture’s approach to the
functional architecture was:
1) Review the processes
2) Create functional overview
3) Assess the functional capability for selected areas on the basis of best practice,
using experience from other revenue agencies and based on our own revenue
functional model.
1.2.1 Process Review
This step involved reviewing the as-is processes with the process owners. Our review
focused on understanding what actions the caseworkers are performing and determining
whether these actions are in a system or not.
The processes only cover what happens today, they do not cover what should be
happening or what is expected to happen.
1.2.2 Functional Overview
The functional area overview was created by identifying the functional areas from the
process models and then categorising these areas into core, customer, other and
supporting groups. The group classification was based on discussions with SKAT process
owners and past revenue debt collection experience. This grouping or overview was then
used to determine where the analysis should focus.
1.2.3 Functional Capability Assessment
The first step was to determine which functional capability is currently supported by EFI
and other selected parts such as DMI. Then from the overview Accenture selected and
reviewed a selection of the functional areas to determine if there are capability gaps
between what is needed for SKAT debt collection processes and what exists. The purpose
was to try to understand which areas are not functioning as expected and which are not
complete. The areas were selected based on their importance in the business processes
and how often they are used. In addition to this, Accenture compared the selected areas
against our experience with comparable revenue debt collection and management
systems and our revenue functional model.
5|Page
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0007.png
DATE: 24.09.2015
Our approach for this task was to:
Gather a listing of services from the service registry
Map functional components to the systems, services & classes
Select functional areas for review (based on criticality for processes)
Review EFI functional and technical designs (ODSB`s & DDSB`s) for selected
functional areas
Review EFI services related to selected functional areas (including creating maps of
the module flows)
Compare selected functionality to what Accenture would expect based on functional
knowledge of other revenue agencies and comparable systems.
Document selected areas and potential functional issues and gaps.
The functional review covered the following: claim management, treatments, compliance
including payment plans, salary deduction and acknowledgement of debt. Accenture also
covered parts of other functional areas within the context of our reviews of these areas
such as account management, work management and business rule management.
1.3 Findings (As-Is Picture)
Our findings show that there are gaps and functional limitations, which are time-
consuming, risky and technically challenging to fix. These gaps and limitations are
impacting SKAT`s ability to manage debtors effectively, perform their collection processes,
collect debts before they expire and improve efficiency (e.g., through automation). The
functionality also makes it difficult to manage debtors and cases in an integrated uniform
manner.
Following is a summary of our key findings:
There are a large number of claim types in the System that increases the
complexity of the System and the treatments.
The System is not build to handle expired claims that has not been written-off,
which has the effect that the System will apply treatments and credits to expired
claims.
There are significant issues with the management of claims including the handling
of claims on treatments and with the rules that govern claims. Additionally, the 490
claim types lack grouping and categorisation, which is important for consistent
handling and re-use.
The functionality is complex and there is very little re-usability in areas such as
treatments
The quality of the data is compromised by the functionality.
It is difficult to implement most changes including critical ones that are urgently
required due to the functional architecture and system functional distribution.
6|Page
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0008.png
DATE: 24.09.2015
Limits with the functional architecture and design make it difficult to fix functionality
in EFI such as adding new claims to treatments, applying debtor level actions
(including tagging), handling of claims and sub-claims, performing updates to
treatments and complete transaction roll-back.
EFI does not support the following business process requirements; case and work
management, auditing, mail, asset repossession, insolvency and tagging of debtors.
There is insufficient reconciliation to prevent data quality issues, ensure accounting
consistency and maintain integrity between systems.
History and logging is insufficient to track actions already taken.
Auditing is challenging and the functionality does not support comprehensive
traceability.
There is little to no validation on data such as claims and sub-claims, missing
business rules and issues with the management and handling of claims including
the calculation of expiration dates.
There is currently no understanding of a fraud detection mechanism in the System.
1.4 Consequences
Although Accenture has drawn some conclusions, our understanding of the consequences
of these conclusions is limited and it is difficult to define the overall impacts from a
business perspective, simply due to a lack of documentation and from the information that
is currently available.
However, it is still our opinion that there exists fundamental functional flaws, which are
risky, difficult and time-consuming to fix. Specifically these are:
Manage debt cases with complex or shared liabilities with the existing functionality
Implement adequate debtor and claimant tagging
Add new claims to an existing treatment,
Understand the business rules and their usage from the matrices
Enable full automation including write-offs and the automatic creation and
management of treatments such as payment plans or salary deductions.
1.5 Recommendations
Our recommendation is that SKAT take the following steps in order to start addressing
some of the major concerns Accenture found during the functional analysis.
Implement a CRM system for management of debtors (instead of EFI which
provides only parts of this)
Provide a work management capability for treatment selection and work
management (not currently in EFI or DMI)
Implement work packages (changes) to EFI/DMI to fix functional flaws such as:
7|Page
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0009.png
DATE: 24.09.2015
o
Validation
o
Tagging of claims, sub-claims and debtors
o
Filtering that prevents actions, credit or payments being applied against
expired claims
o
Updates to treatments such as salary deduction
o
Updates to business rules for claim types, treatments & payment ability
o
Ensuring decision and deducted percentage are aligned for Salary deduction
o
Stop and restarting of payment plans
o
Stop and restarting of other treatments
o
Payment ability calculations
o
Monitoring of salary deductions
Implement reconciliation processes and reports at a data, transaction and system
level
Manually manage non-standard debt cases and shared liability scenarios.
The functional architecture of the System (EFI + DMI) is dependent upon and therefore
limited by the technical architecture. Consequently, when a single functional area is
implemented over two systems this technical division limits the capabilities and changes
that can be made to any one area (refer to the functional distribution diagram). Based on
this and other technical findings (refer to technical report) and in addition to the functional
findings, the conclusion is that there are some fundamental functional flaws or limitations
that are difficult, risky and time-consuming to fix in the System (EFI + DMI). Some of these
include adding claims to an existing treatment, enabling full automation including the
automatic creation and management of treatments such as payment plans or salary
deductions.
Therefore, Accenture’s recommendation is that in the short term SKAT should avoid using
some functional areas until they are repaired and then over the longer term they should
consider a complete replacement of the System (EFI + DMI). This, longer-term plan should
be combined with a simplification of some applicable legislations and a review of the
enterprise architectural landscape (See technical report for further background).
8|Page
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0010.png
DATE: 24.09.2015
2 Scope of Work
The scope of the functional analysis was to provide an overview of the functional areas
that are supported within the System (EFI + DMI) and to then assess selected critical
areas of the System to understand whether there are functional issues within these areas.
The review covered critical areas such as; claim management and treatments and
compliance including payment plans, salary deduction and acknowledgement of debt. In
this report functional areas are used to describe the grouping of functionality or activities
within the processes on the basis of the functions that they perform.
Originally, Accenture agreed that we would perform a documentation review to understand
SKAT’s to-be requirements and system functionality; specifically, identify gaps by mapping
the to-be functionality against as-is to and compare the functional capabilities against the
debt process management model. However, given the divergence between the original
use cases and the current functionality Accenture realised that this would not be possible
and instead Accenture focused on understanding the as-is functionality to determine
critical areas and whether or not Accenture could find any issues and gaps in these areas
based on what Accenture would expect for debt collection and management functionality.
For the to-be analysis, please refer to Accenture’s technical report.
Specifically, as part functional analysis Accenture has:
Performed a review of the core business processes
Created a functional overview and defined the as-is functional areas
Assessed the functional areas to identify missing functionality and potential issues
Compared the functional capabilities against the debt collection process
management model to identify gaps or deficiencies
Accenture did not:
Perform a review of the functionality from a legal perspective
Create a detailed listing of all functionality under each functional area
Perform a complete review of the functionality within EFI, DMI and other systems
Assess or trace workflows through the functionality
Review the business rule matrices and document the business rules and how they
are applied
Perform a detailed review of DMI functional designs nor any DMI code
Reviewed the to-Be requirements based on the original system specification
Defined a to-be functional overview from the perspective of what was originally
expected
Following is a summarised overview of the items provided to Accenture, which describe
the System (EFI + DMI) as it is today. The overview also summaries the items that
Accenture has reviewed as part of the functional analysis.
9|Page
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0011.png
DATE: 24.09.2015
Description of Item
26 Process Diagrams in power point from
Valcon
38 EFI Functional Design Documents
Description of Review
Reviewed all 26 diagrams
Reviewed 13 EFI designs, which included
receive claims, acknowledgement of debt,
payment plan and salary deduction.
Reviewed 6 EFI Technical Documents
Reviewed 52 java programs, which included
the selected functional areas and event
handling for these.
20 EFI Technical Design Documents
402 Java programs and code
Table 1 Overview over Items Reviewed
2.1 Limitations
The process review and functional capability assessment was conducted based on our
understanding of the processes and functionality. The process reviews were conducted
with the process owners (SKAT experts who work within the various competency areas of
the debt collection and management operations), whereas the functional assessment has
been undertaken by us independently with minimal involvement from SKAT employees.
Accenture realises that design and other decisions may have been taken to address some
of the issues or gaps in other systems (not EFI or DMI) and that some gaps are being
covered through a manual workaround process.
This report does not give a full picture of the current state of EFI and DMI, the reasons that
have led to the current state of the Applications (EFI and DMI) or if the current state of the
applications are consistent with the original contractual requirements as described in the
EFI and DMI contracts. It is also important to note that the missing functionality listed in
this report is based on a mapping of processes (which is a part of the analysis) and it is not
based on an assessment as to whether or not the contractual requirements have been
fulfilled. Hence, this report cannot be used to conclude whether or to what extend any of
the parties involved in the project execution can be held legally responsible for their
involvement in the project. Note that SKAT has had limited opportunity to validate
Accenture’s findings.
Additionally, the findings, issues and gaps identified in our capability assessment are
purely based on our experience with other government revenue agencies and represent
the functionality that Accenture would typically expect to see for debt collection and
management. Accenture also realises that a lot of work is being undertaken to repair EFI
and DMI and that some of the issues Accenture discovered may already be in the process
of being repaired at the time of writing this report.
10 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0012.png
DATE: 24.09.2015
3 Methodology
Our three-step approach to the functional architecture analysis was:
1) Review the processes
2) Create functional overview
3) Assess functional capability for selected areas on the basis of best practice, using
experience from other revenue agencies and based on our own revenue functional
model.
3.1 Process Review
This step involved reviewing the as-Is processes with the process owners. Our review
focused on understanding what actions the caseworkers are performing and determining
whether these actions are in a system or not.
Our review covered 26 processes and included the following:
PRO001 - Acknowledgement of Debt
PRO014 - Receive Claim
PRO021 - Add Claim (to treatments)
PRO008 - Customer Selection
PRO009 - Payment Plan, Individuals (CPR)
PRO010 - Handling of payments
PRO012 - Offsetting
PRO013 - Payment Plan, Businesses (CVR)
PRO015 - Resource Planning
PRO016 - Risk Scoring
PRO017 - Salary Deduction
PRO018 - Two year High Priority Claims
PRO019 – Write-offs
PRO020 - Special Salary Deduction
PRO022 – Dunning
The processes only cover what happens today, they do not cover what should be
happening or what is expected to happen.
3.2 Functional Overview
The functional area overview was created by identifying the functional areas from the
process models and then categorising these areas into core, customer, other and
supporting groups. The group classification was based on discussions with SKAT process
owners and past revenue debt collection experience. This grouping or overview was then
used to determine where the analysis should focus.
3.3 Functional Capability Assessment
The first step was to determine which functional capability is currently supported by EFI
and other selected parts such as DMI. Then from the overview, Accenture selected and
reviewed a selection of the functional areas to determine if there are capability gaps
11 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0013.png
DATE: 24.09.2015
between what is needed for SKAT debt collection processes and what exists. The purpose
of this was to try to understand which areas are not functioning as expected and which are
not complete. The areas were selected based on their importance in the business
processes and how often they are used. In addition to this, Accenture compared the
selected areas against our experience with comparable revenue debt collection and
management systems and our revenue functional model.
Our approach for this task was to:
Gather a listing of services from the service registry
Map functional components to systems, services & classes
Select functional areas for review (based on criticality for processes)
Review EFI functional and technical designs (ODSB`s & DDSB`s) for selected
functional areas
Review EFI services related to selected functional areas (including creating maps
of the module flows)
Compared selected functionality to what Accenture would expect based on
functional knowledge of other revenue agencies and comparable systems
Document selected areas and potential functional issues and gaps
The functional review covered the following; claim management, treatment selection
including salary deduction and payment plans. Accenture also covered parts of other
functional areas within the context of our reviews of these areas such as account
management, work management and business rule management.
12 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0014.png
DATE: 24.09.2015
4 Process Review
4.1 Purpose
The purpose of the process review was to gain an understanding of how the core
processes and system functionality is used at SKAT today.
4.2 Approach
Our approach was to perform a review of the 26 main processes to try to determine what
functionality is supported by which systems today. During the review Accenture also tried
to determine the connections between the processes, the sequence of the processes and
to understand which parts of the processes are performed manually verses which are
supported by a system. Accenture also looked at the pre and post conditions of the
processes and what happens or is expected to happen within these processes when they
succeed or fail (For a full listing of the process please refer to the appendix).
4.3 PRO014 Receive Claim Process Review
The Receive Claim Process covers SKAT receiving a claim from a claim owner up until the
claim is either partially or fully paid or it has expired. The process also covers what
happens when a new claim owner contacts SKAT to register as a claim owner and the
creation of new claim types for collection.
The claims that SKAT manage are received through the portal or via the system-to-system
interface. However, a SKAT employee also has the ability to enter a claim manually into
the System through the portal and DMI is able to create sub-claims using a web service.
Once registered, the portal allows a claim owner to enter claim information through a web
form, which includes validations to ensure that the information they have filled-out is
correct. If the claim information does not meet the validation rules, it is not possible to
submit the entered claim into the System. When files are submitted with multiple claims
using the system-to-system interface, a web service handles the processing and creation
of the claims within the System. This web service has a minimal level of validation and
only checks the claim type, claimant and taxpayer.
At the time of creating the EFI and DMI, the information strategy stipulated that claim
information SKAT receives from a claim owner should not be altered or adjusted.
However, this does create some complications. For example when data submitted from
the claim owners is missing essential details required for a collectible claim. These
incomplete or incorrect claims require significant manual follow-up by SKAT with the
claimant to correct the information and sometimes this can result in RIM having to write off
the claim as being uncollectable. Our opinion is that there should be tougher requirements
for data including claims that enter the System (EFI + DMI). SKAT should also update the
agreements with claimants so that they can reject or return claims to a claimant if they do
not meet these new requirements.
Claims may be single instances or be bundles of claims where there is a main claim
(parent) with sub-claims (children), such as fees or interests that have been added to the
original claim. Consequently, it is possible that after a claim has been sent to RIM the
claim owner needs to later apply fees and/or interests, which then need to be added onto
13 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0015.png
DATE: 24.09.2015
the original claim as sub-claims and stored. In EFI, these bundles of claims are handled as
separate claims connected via the original claim through the claim ID. To create these in
EFI the claims need to be entered one by one and all sub-claims must refer to the original
claim. There are currently no limitations on how many claims can refer to an existing claim
in EFI, that only one parent claim can exist and there are no checks on the parent claim to
ensure that it has not expired or been paid-out when a sub-claim is added. This can result
in a sub-claim being submitted against an original claim that has already been paid or is
expired, which means it should not be collected on.
In some cases where information has not been provided for a claim, EFI will attempt to
calculate this value based on the provided information and populate it. For example, when
the expiration date of a claim is not provided, EFI will calculate this information using the
date when the claim is received and the claim type and then set the date accordingly.
Other fields, which are populated by the System typically come from the taxpayer and
company registry (CPR and CVR) information.
4.4 PRO021 Add Claim to a Treatment Process Review
The Add Claim process covers adding a new claim into a treatment that is already active
for a debtor. At the moment this process is not in use as the System does not support this
functionality. This means that all active treatments ignore new main claims and only treat
the claims that were included in the treatment when it was started. Sub-claims are in
general treated correctly except for scenarios where the main claim has a balance of zero.
In that case the main claim will not be added to the treatment again.
4.5 PRO008 Customer Selection Process Review
This process is executed outside of the System (EFI + DMI) and it is the start of all
treatment processes for new and existing claims. Other than the data warehouse
extraction, the majority of the process is manual and is used instead of the automated
treatment selection process in EFI, which is currently disabled as it could start treatments
on claims and debtors that may potentially cause an incorrect action or include claims that
are not able to be collected on.
The process commences when the production group is ready to start a production run and
ends with the debtors being sent for debt collection via a treatment such as a payment
plan.
To start this process the production group will select a target group, define the parameters
for this target group and then send this information to Affecto. Once received, Affecto will
retrieve a list of the debtors and their claims from the data warehouse. The process
concludes once Affecto has executed this request and sent the information to the
production group for allocation to the various caseworker groups.
After the information has been received, each debtor and their claims are investigated and
a decision is then taken as to whether or not the debtor should be executed on and if so,
which claims should be include in that execution. The extracted list is always checked
against the healthy customer list and Affecto assists by rating the customers. The list is
then compared against the deviation and other lists to ensure that only expected
treatments are started and that no action is taken on debtors that should not be. Debtors
14 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0016.png
DATE: 24.09.2015
that are excluded at any of these points are currently not handled through the processes
that are listed in the overview (See section 6 of this document).
4.6 PRO009 and PRO013 Payment Plan Process Review
For Payment Plan there are two processes. One for individuals (CPR) and another for
businesses/companies (CVR). A Payment plan is a treatment or strategy that is designed
to collect debt from the debtor by offering them fixed instalments of payment over a period
of time.
Both the CPR and CVR processes start by offering the debtor a payment plan and end
when the debtor has either fulfilled the payment plan or mistreated it – mistreating leading
to other actions. Based on the payment ability of an individual debtor EFI will suggest the
rates or amount for a proposed payment plan. The payment ability is based on information,
which SKAT receives through their normal operations, such as eIndkomst. Once a
decision has been made to put a debtor onto a payment plan, this decision and the
payment plan information is sent to the debtor with additional information about how to
submit a complaint regarding the decision.
There are two types of payment plans; one which is forced (automatically applied) and the
other which is voluntary and can be requested by a debtor. Debtors are able to submit a
budget to RIM to recalculate the payment ability and to decide on a new payment plan or
to be moved out of the payment plan due to lack of payment ability. RIM also offers a
voluntary payment plan to businesses and companies as a gesture to collect the debt from
the debtor over time.
The payment plan process covers all of the above, in addition to what happens when a
debtor mistreats a payment plan. One of the main issues with payment plan process is that
the length of the payment plan is limited to 1 or 3 years. This can cause an issue when the
payment plan is a voluntary one or associated with an insolvency case (Payment plans are
controlled through business rules which can be updated to accommodate this, however,
there are some other functional limitations due to the EFI/DMI distribution which currently
are not able to be resolved).
4.7 PRO017 and PRO020 Salary Deduction Process Review
Salary deduction is a treatment RIM applies to deduct salary from an individual by
increasing the tax percentage that is withheld (withholding tax) to collect payment of a
debtor’s debt. The process starts when the debtor is placed onto a salary deduction
treatment and ends when the debt has been collected or by failure of the debt collection
such as mistreatment or debt expiration.
Once a debtor is on a salary deduction treatment the debtor can contact SKAT to request
a lower deduction percentage for various reasons. If SKAT agrees, they will set the debtor
to show as “bero” which means that the percentage deducted by SKAT is lower than the
original percentage. It is also possible to set the deduction percentage to zero for a period
of time to provide a grace period for debtors. If the deduction percentage is zero, it will
result in no collection on the debt for the time period the “bero” has been applied.
15 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0017.png
DATE: 24.09.2015
4.8 PRO003 Asset Repossession Process Review
The Asset Repossession process is mostly manual and only a few of the activities are
performed in EFI. The process commences with debtors being selected for asset
repossession and it ends with the repossession of assets, failure to acquire assets or a
decision to let the debtor pay through a payment plan.
The asset repossession process includes all activities related to the work of the
caseworkers such as the booking of meetings, communicating with the debtors, reserving
of cars and securing of assets through registers such as houses and cars. The
caseworkers are booked manually in EFI, as is the information related to the activities they
need to perform such as the registration of documents related to the client meetings. The
documentation that is registered in EFI is in some cases are also created in Captia.
Although this part of the process is handled manually today, it was originally intended that
this would be completely automated in EFI. Additionally, the part that EFI does support
does not work in a usable way and often books time inefficiently or incorrectly (as the
System limits the manual capabilities or adjustments that are possible).
Although the majority of activities are performed manually in EFI, EFI is able to
automatically secure cars and houses through the registers, but currently this only works in
90% of the cases. EFI does this by sending a message to the property registers to request
that these assets are assigned to RIM for coverage of a debt held by the debtor. However,
EFI does not record whether this registering of assets was successful.
4.9 PRO011 Insolvency Processes Review
The insolvency process at SKAT consists of many smaller processes that are associated
with insolvency or deceased estates. It also includes processes for supporting insolvent
debtors. These processes are:
Creditor arrangement for CVR and CPR clients
Submission of bankruptcy
Bankruptcy or insolvent proceedings
Enforced dissolutions
Business Reconstruction
Administration of deceased estates
Debt relief for CPR clients
Remission for CPR clients
The majority of these processes are manually handled today by a small set of workers.
One of the main issues they have in relation to these processes is that suspension
currently does not work in EFI. They also face issues when creating payment plans as EFI
only allows them to create a one or three year payment plan and waiting times for
receiving a payment or settlement from an insolvent estate can be much longer than this.
At the moment the way they enable this in the System is to use a workaround. The
workaround involves setting the date to 9999 to suspend the case, which then creates a
16 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0018.png
DATE: 24.09.2015
three year extension on the expiration date via a payment plan (but it actually should
extend it longer). Additionally, there are no notifications in EFI to warn them when an
insolvency payment plan is about to expire and so they manually create reminders of their
own to manage these cases.
17 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0019.png
DATE: 24.09.2015
5 Functional Capability Assessment
5.1 Purpose
To create an overview of the functional areas across the System (EFI + DMI) and to
assess the functional capabilities within selected EFI functional areas to understand what
capabilities are supported and to determine whether or not there are major capability
issues and or problems within the areas.
5.2 Approach
The functional capability assessment approach was to take the functional areas identified
during the process review, identify the functionality within these areas and then work out
what capabilities are currently supported. To do this Accenture identified all of the services
in use today, mapped these to the functional areas and then performed a detailed review
of the selected functionality, which included reviewing the ODSB`s and code to determine
exactly what the System was doing in each of these areas. Please refer to the above
description of activities related to the processes and appendix for exact items that were
part of our review.
5.3 Functional Area Overview with Large Gaps Highlighted
Following is the functional area overview that was created as part of our assessment work.
It outlines the main functional areas used at SKAT in their debt collection and
management processes. This diagram below has been updated to highlight the areas
where Accenture has found the largest gaps in terms of functional capabilities.
Figure 1 Functional Area Overview highlighting large functional gaps
However, note that our review did not cover all of the areas listed, including write-offs and
penalties that not were analysed in-depth, and that Accenture has found other functional
18 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0020.png
DATE: 24.09.2015
issues that apply to a number of the areas which are not shown on this diagram.
Therefore, this diagram only represents the areas with significant problems and does not
provide an overview of the issues across all areas or the issues within areas outside of our
reviews.
5.4 Functional System Distribution
The functional system distribution overview diagram maps EFI and DMI to the functional
areas. Although Accenture has continued to refine this mapping during our capability
assessment, it is important to note that:
The diagram only distinguishes between EFI and DMI, whereas all other systems
are grouped under “other”
The diagram does not show areas, which are currently being performed manually
due to one of the systems having a gap or capability deficiency
The mapping only gives a rough overview of how the EFI and DMI Applications are
currently used within the SKAT System architecture for debt collection and
management
Applications are not strictly mapped to one certain functional area, but can be used
to perform tasks across several functional areas
5.5 Core Functions
Figure 2 Functional System Overview with EFI and DMI System Distribution
5.5.1 Claim Management
The claim management functional area covers the entire lifecycle of a claim from receiving
a claim through to creation of the claim in the System. It also covers the capture of all
19 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0021.png
DATE: 24.09.2015
information associated with claims and events or actions that are taken in relation to
claims.
The key capabilities the System provides in this area are:
Create, validate and update of claims and sub-claims, including their expiration date
and limited values
Search and view claims and sub-claims
Automatic processing of claims and creation in DMI
Monitoring of claims, and updating information based on this monitoring
Creation and updating of claim types and liability information
Performing of identity matching for debtors and location of ID`s in the registers
Recording of changes made to claims (history) and viewing of these changes
5.5.1.1 Claim Management Key Findings
Following are the key findings from our review of the claim management functionality:
F.1 EFI only validates claim type, claimant and debtor information, it does not validate claim
and sub-claims data (conclusion is based on our review of EFI functional designs and
code). This lack of validation causes issues for caseworkers and prevents complete
automation from being enabled in the System
F.2 There are a large number of claim types in the System, which causes complexity in the EFI
and DMI Systems. Whilst some of the rules and laws relating to these claims and the
management of them has been defined and implemented in the System, this is still
incomplete for a number of the claim types
F.3 There is insufficient validation on created or received claims to prevent incorrect information
being entered into the System. There is also insufficient validation in relation to actions
taken against claims to prevent claim data from being corrupted or invalidated
F.4 The claim management functionality is not able to handle all activity associated with the
normal lifecycle of a claim such as changing of information or the deletion of claims
F.5 There are numerous issues related to missing business rules and the management of sub-
claims and the System does not have any rules, which ensure that any actions taken
against a main claim are also applied to the sub-claim
F.6 It is not easy to trace the history of a claim nor to identify values or actions that have been
taken in relation to a claim. This includes not being able to see an original debt amount nor
the original debt amount in a foreign currency. Based on our experience, this is highly
unusual for a system of this type and Accenture has never seen this in a revenue system
F.7 There are issues and missing business rules for the calculation and management of claim
expiration dates such as for complex liability situations (where debtors have varying
percentage obligations against the debts such as for Interessentskab debtors) or when the
System tries to work out a claim expiration date based on an action taken in the System
F.8 Expired claims are not handled well and there is no monitoring to ensure that when a claim
expires all of its sub-claims are also expired. There are also no business rules in the
System that prevent expired claims from being included into a treatment or to prevent
credits or payments being offset against an expired claim
20 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0022.png
DATE: 24.09.2015
F.9 The claims have no real status or values that can be set which easily allow the System or a
worker to understand when a claim has been deleted or flagged for another purpose such
as when it has been sent to an oversees debt collector or should not be included in
treatments
5.5.1.2 Claim Management Functional Assessment
Following is the detailed information on the issues that Accenture found during the
capability assessment.
Creation, Updating and Validation
The claim management functionality is quite complex. When a claim enters SKAT it
is created in multiple spots, which creates additional complexity and means that
when a change is made it must be made to all of these locations
Almost no validation is provided in the receive claim functionality, this results in
invalid data being accepted such as expired claims, orphaned claims (where the
sub-claims do not have a parent) etc. SKAT operations currently do not pursue
claims with sub-claims that are less than 100 Danish Kroner, as it costs them more
to recover the debt than it is worth. However, since there is not validation to prevent
such claims from entering into the System, there are significant amounts of debt
that are not able to be pursued and consequently end up expiring and needing to be
written off
Claims with a status of Modregning can be changed to a status of Inddrivelse. The
System is not able to handle this change for a claim even when there is only one
debtor. In more complex cases such as where there are two or more debtors liable
for a claim, this becomes even more of an issue. One example of this issue is
related to treatments, which are unable to respond to this change – meaning that
the treatment associated with the claim does not reflect the new status. The other
concerns updating of expiration dates and management of due dates for claims with
more than one debtor
If a claim needs to be removed from the System it is not possible to logically delete
the claim. Consequently, several workarounds have been implemented but the
usage of these workarounds is at the discretion of the caseworkers. For example
one way a caseworker can do this is to write-off the claim and the other is to delete
a claim by setting the outstanding balance to zero. Another issue with this
workaround is that when a parent claim is set to zero, the System does not check to
ensure that all of the child claims have also been set to zero (or deleted) which
results in inconsistent data in the System
There is no way to track changes made to a claim over time through the user
interface. Tracking changes over time requires manual intervention at the database
level. Changes are not saved in a timeline, nor do they contain all the information
on the before and after changes have been made. This creates problems when they
need to roll back changes or pinpoint and action
The System is able to receive claims in a foreign currency. However, it does not
save the amount received in the foreign currency; instead it immediately exchanges
the amount to Danish kroner and saves that value. It has been decided by SKAT
21 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0023.png
DATE: 24.09.2015
business indirectly, as this is how SKAT operated in prior systems. The System is
unable to track how much the original debt was, and hence the claimant may pay
too little or too much depending on how the exchange rate fluctuates.
The System is able to show the amount of debt that is currently against a claim, but
is unable to show how much the original debt was when it was entered into EFI
Claim Types
The System has a lot of different claim types and there is no grouping or
categorisation that enables re-use of these categories. Instead, every time a
claimant has a new type of claim it is added as a brand new type into the System
which means all the rules etc. need to be redefined each and every time
There is no detailed mapping or documentation from claim type to what law(s)
govern that specific type and how these should then be applied in the System. It is
not always clear what the legal basis is for the claims within EFI
Expiration Dates
The System does not provide functionality that ensures when a parent claim expires
that all of the sub or child claims also expire. Consequently, when a main claim
expires, there is no update to set the sub-claims (children) to also show that they
are now expired
When creating a claim and no expiration date is set, the System tries to calculate
this based on available information and the date that the claim was received (refer
to claim type issues mentioned above). The actual expiration date calculation rules
are much more complex than that but the System has not been designed to cope
with this and consequently, it is not able to apply all of the necessary expiration date
rules (the calculation from this functionality is often ignored, as it is known that it
incorrectly calculates dates)
There are issues when the expiration date is adjusted based on an action such as
one that is taken through a treatment. Essentially, the expiration date calculation
does not always happen when expected and when the System does calculate the
date it sometimes calculates the date incorrectly (refer to compliance and treatment
section)
When a claim is received and the expiration date is not provided, the expiry date is
calculated by taking the date the claim was received and adding the number of
years in which the claim type would normally expire. Unfortunately, this rule does
not always yield the correct expiration date, as events or actions taken on a claim
prior to entering the System and after entering the System also affect the expiration
date. For example if a dunning letter has been sent or if a debt has been
acknowledged this can also adjust the expiration date
Another issue we found was due to a limitation in the System where claims are
unable to be tagged based on actions such as when there has been a complaint
regarding the claim or a negotiation has commenced, the worker will set the expiry
date of claims to 31/12-9999. This means that when the System tries to update the
22 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0024.png
DATE: 24.09.2015
expiration date it is unable to determine what the original date was or understand
what actions have been taken and it can incorrectly calculate the expiration date
Interruption of aging on a claim that belongs to a partnership does not interrupt the
aging for the liabilities
When a debtor does not receive their decision letter and this letter is returned to
SKAT, the System changes the expiration date of the claims that the letter covered
back to their original date. However, the System only does this for the main claim
expiration date and it does not do this for the sub-claims that are connected to the
main claims. Thus there is a risk that the System will cover these expired sub
claims, resulting in the debtor paying for a debt that has legally expired
Claim States and Status
The claims have no status or way to tag them that allows caseworkers or services
and other systems to see when a claim has been deleted, is being contested by a
debtor, has an issue or should not be included into a treatment.
When a claim is sent to another country for debt collection this should interrupt the
expiration date and the claim should not be placed on a treatment; currently this is
not supported and the caseworkers use claim notes to detail when this has
occurred. If automation is turned on, Accenture has no way to identify these claims
in the system, as they are not on a special treatment and debtor or claim status
tagging is not provided, which would enable this to occur.
5.5.2 Account Management
Account management functional area contains all of the functionality related to the
management of customer (debtor) accounts including their account balance, debts,
credits, interests, write-offs, offsets, refunds and payments.
The key functionality that the System provides in this area are:
Create and update financial transaction postings such payments, refunds etc.
Initiate credit & debit offsetting
Create and update adjustments, transfers & reversals
Create and update penalties & interest calculations
Create and update fines and reminder fees
Create and remove a penalty & interest suppression
Create and remove an insolvency or bankruptcy lock
Manage unallocated/unmatched amounts
Issue balance statements
Clear debtor account
Reversal of financial postings
23 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0025.png
DATE: 24.09.2015
Search and view customer account balances and transactions
Calculate and apply exchange rates
Calculate and apply depreciation rates
Payments
o
Park or suspend pay-outs
o
Issue receipts for payments
o
Record missing payments
o
Find, list and view payments
o
Create and update automatic and manually entered payments
o
Cancel payments
o
Allocate payments to debt
o
Calculate Instalment Payments
o
Suspended Payments
o
Handle Dishonoured Payments
o
Receives dividends
o
Receive payment from an estate.
Credit Offsetting
o
Perform simulation of coverage
o
Create and update offsetting
o
Receive and post offsetting amount
o
Receive receipt from sender
o
Perform open offsetting
o
Create offset notice to the customer
o
Create pay-out letter to customer
Write-offs
o
Search and select claims to be written off
o
Select effective date of write-offs
o
Create and update initial write-off
o
Approve write off
o
Reject write off
o
Create and update percentages of write off
o
Execute write offs
o
Create and update a partial write off
24 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0026.png
DATE: 24.09.2015
o
Create and update reason for write off
o
Send letter to debtor
o
Send letter to claim owner
5.5.2.1 Account Management Key Findings
This area was not part of our review. However, Accenture has some key findings for this
areas that we discovered through our other reviews.
F.10
There is no way to tag or filter main and sub-claims to prevent them from being included in
accounting processes There is no way to correct financial deviations on debtor’s accounts
such as when a credit is offset and an interest has been calculated prior to a debt amount
being adjusted
The System refunds money to nemKonto, if the debtor does not have a nemKonto the
refunds will be transferred back to DMI. From there, a manual process enables RIM to
refund money to the debtor - if the debtor supplies a new nemKonto or bank account. After
this, some refunds will still end up as open records in the system, even though they have
been attempted allocated manually. AKR customers are prone to this as they might not
have CPR/CVR numbers, which is required by nemKonto.
For salary deductions, there is no system check or reconciliation performed to ensure that
the amount notified to debtors is the amount that is deducted. Consequently, sometimes
the amount deducted is not what was notified
Across the account management area there are no reconciliations or system checks to
ensure that actions are not repeated, this includes that SKAT have not received two salary
deductions or payments and that SKAT have not issued two refunds to debtors
The account management functional area lacks the ability to apply suppressions or mark
debtors and their financial transactions to prevent write-off`s, deduction of payments,
issuing of refunds etc.
Reversal or cancellation of complex transactions such as those that prevent the calculation
of interest is not possible
The order of coverage that is used by DMI to determine the claims, which will be covered
by a credit or payment does not check the expiration date of claims; it is therefore possible
to use credits or payments to cover an expired claim
In complex liability scenarios such as where several debtors are responsible for individual
sub-claims under a main one, the System is not able to distinguish which debtors are
responsible for a specific sub-claim and it can use debtor’s credits or payment to pay a sub-
claim that they are not responsible for
Due to the functional distribution of the systems, there is an issue with links between
treatments and claims. Currently, if all claims on a treatment are reversed or recalled the
System will not cancel the treatment fee, which remains as a liability for the debtor
Automatic write-off of debt is not able to be enabled, as the System cannot handle future
effective cases (ones with a future due date) and ensure that it does not write-off debt that
is not yet due
There are issues with automatically handling debtor requested deviations such as a
different payment or credit allocations for debts.
Credit offsetting notification to a debtor occurs after the offsetting has occurred. The actual
notification should happen prior to the offsetting. It should also be able to be prevented
based on a request from a debtor.
F.11
F.12
F.13
F.14
F.15
F.16
F.17
F.18
F.19
F.20
F.21
25 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0027.png
DATE: 24.09.2015
5.5.2.2 Account Management Functional Assessment
The majority of account management is handled in DMI and Accenture did not review the
code, however Accenture has looked at some of the DMI design documents and
Accenture were also involved in workshops which discussed this area. This has enabled
us to perform a limited assessment of the functionality. As a result of this assessment,
Accenture has found the following capability concerns:
Insolvency and Bankruptcy
The System has a treatment that supports this functionality but the process and all
communication is done manually outside the system. This information must then be
manually entered into the System. There are no locks in the System to prevent
refunds going to the customer when they are under this treatment. This is an
important functionality and points to a larger gap in the System in terms of stopping
actions when required (refer to technical analysis report which also covers this point
in detail)
Reversal of Payments
The System is not able to correctly handle the reversal of payments and
consequently, when a payment is reversed the corresponding interest calculations
and balance are not correct
Handling of Debtor Requested Payment Allocation
The System is not able to handle debtor requested payment allocations to claims
automatically. At the moment, these are only able to be actioned manually by a
worker
Refunds that are not through NemKonto
The System can only issue refunds to debtors through nemKonto, and if nemKonto
cannot find the debtor, the amount is returned to the System. If a caseworker has
worked on a case, it would be possible to refund money to a bank account
manually. Consequently, there are a number of refunds that cannot be issued and
hence remain in the DMI System. The DMI System should be able to handle
debtors who do not have a nemKonto, by handling the returned refunds from
nemKonto, by issuing letters to the debtors.
PEF Customers with Uneven Debt on SE and CPR Tracks
When a debt correction has not yet been entered into the System, it is possible that
the payment allocation or credit offsetting functionality can accidently cover the
debt. This coverage means that the debtor is now missing a credit amount and that
any correction of this deviation must take into account a calculation of the interest to
be subsidised. Unfortunately, the System is not able to handle this and
consequently, there are a number of customers who have incorrect debt amounts
due to the deviations not being handled
26 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0028.png
DATE: 24.09.2015
Salary Deduction
The System sends out a decision letter conveying the amount that shall be
deducted from a debtors payments. However, as the System is not checking the
amount deducted against the amount notified in the decision letter, there are issues
that sometimes the amount deducted is different in the e-tax card than the decision
letter that had been sent
There are no checks in the System to ensure that a salary deduction payment has
not accidently been taken twice. Today all salary deduction payments are manually
checked and then the credits are either applied into the System or sent back to the
debtor
The System is not able to correctly handle interest and balance calculations when
an employer does not withhold tax correctly for a debtor or pays late
Cancel Interest Exception after it has Expired
It is not possible to edit an interest exemption where the end date is exceeded. For
instance, the customer has received an interest exemption for a period where you
later find evidence that invalidates the interest exemption and hence the exemption
should be reversed, so the customer has to pay the full rate
Coverage of Aged (expired) Claims
If the System receives a payment, it will use the coverage order to cover the claim
and presumes that the claim has not expired. Thus it is possible that expired claims
are covered by payments if they still exist in the system
Claims that Belong to Another Claimant are Covered
If a main claim has several debtors and contains several sub-claims where one or
more of the sub claims is assigned to one debtor. The System can use payments or
credits to cover the sub-claims, even though the paying debtor has no liability for
those sub claims
There is no notification in the System to alert caseworkers when they need to check
payment coverage, to ensure that debtors are not covering debt that they are not
liable for
Recalled or Cancelled Claims
If a claim has been received and then recalled (i.e. the debtor should not owe the
debt) the System can cover a claim with incoming payments. This creates a
situation where SKAT is at risk of collecting more money than the debtor owes
Reversal of Fees on Treatments
If a treatment is created together with a fee, and the claim(s) are cancelled and/or
recalled or in some other way removed, then the fee for the treatment should also
be removed. However, due to the functional distribution and the links within the
27 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0029.png
DATE: 24.09.2015
System, the claims are not connected to the fee for the treatment and this means
that when they are all cancelled or recalled, the System is not aware that the fee
should also be reversed and this debt remains for the debtor.
Write-offs
The automatic write-off functionality cannot be enabled. If it is enabled the System
will start to write-off all debt that appears to be expired, even if the dates have not
been checked and it is not confirmed that the expiration date is correct
It is possible to write off a claim with a future effective date. This should not be
allowed, for debt with future effective dates, the write-off process should be manual
5.5.3 Disbursement Management
The disbursement functional area covers all of the functionality related to the act of
disbursing money from RIM such as the paying out of money to claimants or other
governmental bodies and groups. This area does not cover the issuing of money to
debtors, as this is covered under account management.
The key functionality in this area is:
Creation and updating of a disbursement
Search, list and viewing of a disbursement
Grouping of amounts to be disbursed
Approval of a disbursement
Controlled disbursement
Reconciliation of disbursements
Issuing of credit to claimants and other government agencies
5.5.3.1 Disbursement Management Key Findings
Accenture did not review this area and we have no key findings in relation to it.
5.5.3.2 Disbursement Management Functional Assessment
Accenture has not performed an analysis of the capability in this area and we did not come
across any gaps during our process reviews.
5.5.3.3 Collections Management
The collections management functional area includes all of the functionality related to the
management on collections at SKAT such as their strategies for maximising debt collection
and minimising write-offs due to unrecovered debt.
5.5.3.4 Collections Management Key Findings
Accenture did not review this area, however, based on reviews in other areas we have one
key finding.
28 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0030.png
DATE: 24.09.2015
F.22
The System is not able to handle uncollectable debt that needs to be returned to claimants
such as when it was raised in error or was already expired upon being received
Collections Management Capability Assessment
The major issue that Accenture found is that there is no way for SKAT to return
non-collectable debt to agencies upon receipt of these claims, such as when it is
not economically viable to collect or when the debt was already expires. They are
also unable to return debt to agencies before it is about to expire, which results in
large amount of write-off`s (refer to write-off capability assessment) Penalties,
Interests Fines.
5.5.4 Reconciliation
The reconciliation functional area covers all of the functionality related to the comparing of
various different types of data in order to determine whether or not there are
inconsistencies between systems, values, numbers on lists etc. One example of a
reconciliation is where different systems are compared to see if there are any
discrepancies in the systems such as different debts.
5.5.4.1 Reconciliation Key Findings
Accenture did not review this area, however, based on our reviews in other areas we have
one key finding.
F.23
There is a significant lack of reconciliation between EFI and DMI, specifically; there is no
comparison of the data such as claims in EFI and DMI and on the interactions or events
sent between these systems; there is also no reconciliation related to work management
such as ensuring work tasks have been completed. This lack of reconciliation causes
significant data quality issues and means that the business is unable to detect and resolve
problems
5.5.4.2 Reconciliation Functional Assessment
Reconciliation is very important for ensuring system integrity and for various auditing
processes. During our investigations of EFI, Accenture did not find any documents, reports
or code that were specifically used to perform reconciliations. Based on this investigation,
our conclusion is that EFI has very little reconciliation between other systems. Given that
EFI is highly integrated with DMI and there are numerous services that duplicate data
between the two systems, it is our opinion that there should be a number of different types
of reconciliation on the data and between the EFI and DMI Systems.
Although Accenture has not performed an extensive review, our initial investigations could
not find any services or reports that are specifically focused on reconciling information
between these systems. However, from discussions Accenture understand that some
bailiffs and caseworkers do themselves perform manual reconciliations as it relates to their
work but this is not extensively practiced and it is a relatively manual process.
In terms of reconciliation, Accenture has specifically found:
29 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0031.png
DATE: 24.09.2015
There are no permanent automated reconciliations between DMI and creditors
including SKAT's own claimant systems (KOBRA, SAP38 and DMO). Although,
some manual analysis has been performed in order to identify the amount and size
of the differences and to then identify specific cases that can be cleaned up
There are no reconciliations between the amount that is advised to users and the
actual amount that is deducted and registered in eIndkomst
The System does not check that when payments are issued to debtors that the
payment was actually issued by the payment centred. There should be an interface
to check that payments were actually successful
It is our opinion that the lack of reconciliation is a symptom of an overall problem
with the system design; in that it only ever looks at a perfect path for processes and
actions and never considers that data might be wrong or that exceptions can occur.
Based on our experience, the opposite assumption is normally taken with fully
automated systems. Accenture also believes that a thorough analysis of
reconciliation is likely to show many problems, but this will be better than continuing
as is, as problems can then be resolved
5.5.5 Compliance and Treatments
The compliance and treatments functionality covers the debt collection and compliance
strategies that are applied in order to collect outstanding debt from debtors. This functional
area is critical for ensuring that debtors meet their obligations and for collecting on the
maximum amount of debt possible
The compliance and treatment functional area provides capability to create, update, list,
view, search and calculate payment abilities for the following treatments;
Dunning
Payment plan
Asset repossession
Salary deductions
Acknowledgement of debt
5.5.5.1 Compliance and Treatment Key Findings
Following are the key findings from our review of the compliance and treatment
functionality;
F.24
F.25
F.26
F.27
F.28
Creation of new treatments or the alteration of existing treatments to cater for changes in
law or business operational requirements is difficult and time-consuming
Claims are not able to be added to a treatment once it has been commenced
When a treatment is created, expired and tagged claims are not able to be excluded
Management of claims at a sub-claim level is not possible in EFI. Consequently, you can
only exclude or include parent claims in treatments
There are several issues with the handling of sub-claims when a parent claim is on a
treatment. For example expiration dates will not be updated for sub-claims even when a
30 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0032.png
DATE: 24.09.2015
payment is received and sub-claims can be included in a treatment even though they were
not included in the decisions sent to the debtor
F.29
Treatments do not respond to changes that are made to claims. This means that when a
worker or claimant alters the claim information, the treatment is not updated to reflect this
change
The applying and removing of grace periods does not handle expiration dates
There are numerous issues with the manual and automatic calculation of payment ability for
treatments which causes debtors payments to be too high or too low. These issues are
significant and result in an increased workload for workers
When a treatment is created and a decision letter is sent but the debtor is not located, the
expiration date is not handled correctly
The System does not provide monitoring for treatments and actions are only initiated when
an event is triggered. Consequently actions such as a mistreatment of a salary deduction
need to be manually detected by workers
There are issues with the rules defined for the creation and ending of salary deductions.
There are a number of issues with editing and ending payment plan treatments. For
example, it is possible to update a payment plan amount when it is in progress even though
this has not been notified to the debtor
There are no payment plans that meet the requirements for insolvency cases
The System does not provide all of the required functionality for asset repossession.
Consequently, a majority of this process is manual
F.30
F.31
F.32
F.33
F.34
F.35
F.36
F.37
5.5.5.2 Compliance and Treatment Functional Assessment
Although EFI uses an event management set-up that allows for the handling of system
events in a flexible way, it seems that the actual design of the System does not easily
facilitate the creation of new or alteration of existing treatments.
Generally functionality should be designed with reuse in mind, which means that business
logic is defined in a way to allow configurability and reuse that accommodates future
needs. At SKAT most treatments follow a predictable pattern of creation, updating, issuing
of correspondence, payments, calculation of ability to pay, monitoring, ending, applying
and releasing a grace period and manual intervention of a treatment.
However, the current design rather than create a generic treatments with configurable
steps, has separate services for each treatment in the system. Consequently, these
services are specialised for individual treatments and little to no reuse is possible.
Additionally, their design means that whenever a change is required a new treatment
design and service has to be created and that each individual design within the System
needs to be reviewed to determine adjustments. It is also often difficult to fully anticipate
the impact a new treatment will have and to adjust the System accordingly. Meaning that
such changes are complex and difficult to implement.
Additionally, our review of the functionality and processes has found the following gaps
and issues.
Automatic selection of debt treatments is too reactive, it often creates a treatment
without considering that more information may be in transit. Also, the treatments do
not have any mechanism to filter on a claim-by-claim or sub-claim basis, which
31 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0033.png
DATE: 24.09.2015
means there is no way to tell the System to ignore certain claims or not action them
other than based on their claim type
Treatments in EFI are created and managed at the parent claim level; this means
that currently sub-claim (child) level or claim wise treatment is not possible
It is not possible to add claims to an existing treatment. This means any new claims
received are not immediately added into a treatment
No treatment is available to handle or treat claims that are sent overseas for debt
collection. When the System identifies that a compliance or intervention is required,
it creates a manual handling treatment, which results in a lot of these tasks being
created in the System for operational staff to intervene. Some of these manual
takes could have been actioned or fixed via other means for example: looking up
peoples addresses through other registers, internet etc.
When a claim is corrected or altered, if it is on a treatment the treatment is not
updated to reflect this alteration and can have incorrect information. Given that
claimants are able to update or delete claims by sending in an altered file, it is
possible that they change an expiration date or delete a claim where Accenture has
already been collecting credits against
Treatments do not react to correspondence from debtors. If correspondence is
received from a debtor in regards to a notification on salary deduction, the System
does not check this before making a decision on salary deduction. Once a
caseworker has commenced looking at the correspondence it is up to the
caseworker to take action
Payment Ability Calculation
Calculation of the ability to pay is complex, especially when a debtor has more than
one active treatment. Currently the System is only able to calculate the ability to pay
by looking at one treatment, it is not able to take other treatments into consideration
when performing this calculation, which results in an incorrect amount being
determined and the payments, withholding tax etc. being wrong
The payment ability calculation on existing customers takes approximately 48 hours
and there is no automatic validation that ensures that the payment ability
calculations are done correctly. Thus, each month a worker must manually check
that the payment ability calculation basis is valid for all debtors (i.e. that all annual
income reports and pay checks used as basis for the calculations are valid)
There is a risk that treatments are manually initiated before the calculations are
done and before a worker has validated the calculations. Because of this risk, the
event which triggers active treatments when the payment ability for a debtor
changes, has been disabled. Thus, treatments are not changed based on whether
payment ability for a debtor goes up or down, unless the debtor on their own
initiative contacts SKAT to inform about the changes. In such a case, SKAT will
send the debtor a budget form to be filled out. If this is done, a new payment ability
calculation will be made based on the budget
32 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0034.png
DATE: 24.09.2015
EFI does not update debtor-types automatically. Consequently when a debtor
changes from being a PEF-customer to having a normal job/salary income,
situations may arise where the payment ability calculation is calculated on outdated
information and this can result in the an incorrect treatment being initiated
When allocating a debtor to salary deduction, the amount which is taken through
salary deduction is not reserved in the debtor’s payment ability
If the debtor submits a budget due to a notification on start of salary deduction, the
System does not react that this is received. If a budget is received from the debtor
which needs to change the salary deduction a caseworker must open the case and
manually do the necessary changes to the treatment, regardless if the salary
deduction has started or not
Budget Calculation (Manually calculated payment ability)
The functionality for when a debtor requests the manual calculation of a payment
ability or budget, is not being used. Instead:
o
If the new payment ability is the same or higher than the payment ability
noticed or used in the current treatment, the current treatment will continue
without any changes
o
If the new payment ability is lower than the payment ability noticed or used in
the current treatment, the current treatment will be stopped and replaced with
a voluntary payment plan
o
If the new payment ability is zero, the treatment will be stopped and the
debtor will be granted a grace period
Claim Expiration
If a sub-claim is received after a treatment has been started the interruption of aging
as a result of actions or credit collected will not occur to the sub-claim. Even if a
sub-claim has been covered by a payment through salary deduction. The
interruption can only be handled when the treatment has stopped
The System cannot roll back the expiration date for sub claims when a decision
letter is returned to SKAT
Creation and Ending of a Salary Deduction
If a sub-claim is received after the notification of salary deduction is sent the sub
claim is automatically included into the salary deduction treatment. Results are that
the sub claims are a part of the decision although it has not been notified to the
debtor. Consequently, this can result in credits being offset or tax withheld from
salary deduction being applied against the sub-claim which the debtor has not
notified about. (Ref Funktionelle krav til LØN)
There are no restrictions to start salary deduction if the debtor is an individual but
owns a personal business (enkeltmandsvirksomhed).
33 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0035.png
DATE: 24.09.2015
When the decision notification letter is returned, as it has not been possible to
deliver it, the System does not stop the decision making or interrupt the aging of the
claim, as stated in the law
There are no rules applied when starting a salary deduction to ensure that only
allowed debtor segments are included. Consequently, it is possible that companies
could be on a treatment until the manual monitoring detects and then closes down
the treatment
If salary deduction fails to collect from a debtor, the treatment will not automatically
end and change track for the debtor. Instead, they need to be manually removed
from the treatment by a case worker
Monitoring a Salary Deduction
Today the System does not automatically end a special salary deduction (S-Løn)
even after the debt has been paid. The only way to end this is to manually stop the
special salary deduction.
There is no system based monitoring of the salary deduction to detect
mistreatments (such as when a payment is not made). Presently the detection of
such an event is handled manually by case workers.
Grace Period (Bero)
If a treatment has been stopped due to a grace period being applied, the expiration
date of claims should remain as they are and no updates should be made to the
dates until the grace period is ended. Currently this is not enforced in the System
and other actions taken on the claims are able to update the expiration dates of the
claims.
The rules in terms of handling paused and restarted claims has not been defined in
the system. Consequently, the expiration dates of claims that were suspended and
then restarted are handled incorrectly.
Change of Tax Reporting from Employer
Today there are some issues if the employer changes the tax reporting to Skat. For
example if the employer withdraws the previous amount of tax paid to Skat and
submits a new tax reporting. The system does not see that the deducted salary on
the debtor is actually claimed back to the employer. If then the new tax reporting is
done, it actually looks like the debtor has paid twice instead of once. This could
result in a debtor paying too little of his debt and actually gets reimbursed money
which was never paid by the debtor.
Change in Deduction Percentage
At certain times, it should not be possible for caseworkers to increase and reduce
the deduction percentage manually via the caseworker portal. For example, when a
notification letter has been sent out to a debtor and the System shows that it is still
34 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0036.png
DATE: 24.09.2015
waiting for a response. However, this is currently possible.
Payment Plan
The System allows caseworkers to configure and update data, business rules and
actions when it should not be allowed. For example, you can update the payment
plan rate after a payment pan has already been paid-out or stopped
There are no rules applied when starting a payment plan to ensure that debtor
segments are treated as required. For example, PEF customers need to be treated
in a manner that is different from individuals or companies, today this functionality
does not exist in the System and consequently means that they are treated as
individuals
Payment plan timeframes are restricted to 12 months, however the documentation
states that there should be no such limitations in the systems for a caseworker and
that you should be able to change the following; frequency and number of
instalments
It is possible to change the payment amount in the payment plan while the payment
plan is active. Currently the automation of this functionality has been disabled due
to the consequences of activation
It is not possible to add new claims to a payment plan
When a payment plan has ended (after the EFI set period) and the last payment
does not cover the remaining debt (due to an interest), the payment plan is unable
to close. This is an issue as no new instalments (expected payments are created)
and the debtor is not notified that they still have remaining debt
A payment plan can only be created for 12 or 36 months, and if the payment plan is
unable to cover the debt in the set time period caseworkers need to create a new
plan or extend the existing one. This creates overhead work due to that RIM need
to monitor the payment plan that fulfil this criteria
If a payment that have been made to a payment plan is rolled back, the expiration
date for the covered claims should be rolled back. This however, is a manual
process and if not done it creates a risk that claims that should have been expired
are covered. In some cases the caseworkers have tried to subtract the expired
claims, but in the choice of track the aged requirements is included anyway
Asset Repossession
Asset Repossession is mainly a manual process, where the activities are done either
completely manually or manually within EFI. Even the selection of debtors for this
treatment is performed manual as part of the treatment selection process. However, our
assessment found the following concerns:
When a repossession is cancelled it is possible that the cancelation is not always
registered and there is no verification that the repossession have been cancelled
When an asset repossession is in a waiting state, e.g. “Pending police search” or
“Awaiting business outlay” and all the claims are removed from the treatment. The
35 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0037.png
DATE: 24.09.2015
treatment shall stop, which it does not
5.6 Other Functions
5.6.1 Business Reconstruction
There is no business reconstruction specific functionality in the EFI and DMI Systems. The
process is mainly manual and the actions are registered in EFI in the document section.
Related documents are also uploaded to the case. In other words using supportive
functions to register the steps and history of the case manually and using work
management to set up appointments and schedule meetings.
5.6.2 Insolvency and Litigation
There are no insolvency specific functionality in the System. The process is mainly manual
and the actions are registered in EFI notes section. Related documents are also uploaded
into the case management tools. In other words using supportive functions to register the
steps and history of the case manually and using work management to set up
appointments and schedule meetings.
5.6.3 Forced Dissolution
Forced dissolution is a functionality area that covers the management of forced dissolution
cases. Today the process for this is manual and involves court interactions. The actions
and documentation of the process are handled by registering documents and actions in
EFI under the document section. However, SKAT does use some supportive functionalities
such as document handling to;
Register the forced dissolution
Create and manage the forced dissolution case
5.6.4 Court Interactions, Reporting & Registrations
Court interactions, reporting and registration is functionality related to obligation in terms of
managing debt cases through the courts. This work is completely manual and no
functionality is provided in the system. Some specific actions taken in this area are:
Send insolvency to the court
Send information to court
Attend a court hearing
5.7 Support Functions
5.7.1 Case Management
The case management functional area covers all of the functionality related to the
management of different types of debtor cases such as bankruptcy, audit and dispute
cases.
36 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0038.png
DATE: 24.09.2015
Key Capabilities:
Create and update a case and associated information
Search, list and view debtors and cases
Create case work load lists including prioritisation and target case groups
View historical information on cases related to debtors
5.7.1.1 Case Management Key Findings
This area was not part of our review. However, Accenture has some key findings for this
area that Accenture discovered through our other reviews.
F.38
Case management is handled outside of EFI and there is no integration with this system to
EFI or DMI. This makes it extremely difficult for caseworkers to manage debt cases and to
ensure that no actions are taken in EFI or DMI that are contrary to what is required based
on their cases
It is difficult to obtain a consolidated picture of debtors their active cases and history
F.39
5.7.1.2 Case Management Functional Assessment
Currently, case work is not supported within EFI. Therefore, the entire lifecycle of case
management is handled within another system that has minimal links to EFI being the
case identifier and caseworker information. This is a major gap in the functional capability
within EFI, which was originally supposed to support casework. Although, the case
management tool that is used does provide sufficient functionality for case management.
The major gaps that Accenture sees are:
Caseworkers do not have a single connected view of a debtor from the case
management tool and EFI
There is insufficient information for caseworkers in EFI to quickly assess a debtor
and they must actively look for the case link and to then navigate to the case
management tool to find out what the case is and whether or not it is active
Unable to prioritise debtors using case information; currently is not possible to do
this and the prioritisation has to be done manually by extracting lists that containing
the focus groups
5.7.2 Operational Effectiveness
Operation effectiveness covers everything related to operations from the implementation of
strategies to the effective management of workers and the measuring of efficiency using
KPI`s. This includes the creation of KPI`s to track the effectiveness of operations in terms
of work load management, time spend on direct contact with the debtors or claimant and
the most effective management of cases to determine how you can better manage your
operations.
This area was not reviewed by us and there are no specific reports on the reporting list
that Accenture could identify that belong to this functional area. Accenture would need to
37 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0039.png
DATE: 24.09.2015
look into this more in order to understand the gaps here.
5.7.3 Work Management (Resource Manager)
The work management functional area contains the functionality for the management of
resources, activities and workflows for debt collection at RIM today. Currently, there are
three ways that SKAT is performing work management;
Through the Resource System in EFI called (RS – only Bailiff booking is in use);
By managing individual debtor cases in the case management tools Remedy and
Captia; and,
Through custom spreadsheets placed on the SKAT SharePoint for work allocation
Work Management Key Findings
This area was not part of our review. However, Accenture has some key findings for this
areas that Accenture discovered through our other reviews.
F.40
The case work is completely handled outside of EFI and DMI. This means that there is no
integration between the case system and EFI/DMI. This functionality is important for
ensuring workers are able to manage cases in one place and important for continuity
RS was planned to be used for automated management of all workers. However, due to
missing functionality it is only being used for management of bailiffs such as scheduling
their meetings or asset repossession tasks and booking cars. Even then, as used, it does
not provided the necessary flexibility required
Case workers need to constantly set manual reminders for tasks such as insolvency etc. as
there is no reminder for these items in the System
It is difficult to obtain a work list backlog, manage work tasks and to accurately plan work
There is no way to gain a meaningful picture of task completion
There is a lack of understanding on what resource manager can and cannot do and this
causes frustrations. The result of this frustration is that more and more work is managed
outside of EFI and these processes are not all handled in a consistent manner. Additionally,
security is hard to manage and errors are easier to introduce
Workflow and tasks are currently being managed in spreadsheets and not in the RS
System
F.41
F.42
F.43
F.44
F.45
F.46
5.7.3.1 Work Management (Resource Manager) Functional Assessment
In terms of work management, the main gaps that Accenture has observed are as follows:
EFI generates tasks for workers to action such as when it needs a worker to
manually intervene in a treatment. Unfortunately, the System does not provide an
efficient way for workers to sort and action these tasks which makes this
functionality difficult to use for workers
Configuration needs to be done in RS for each case-worker in order for correct
tasks to be automatically assigned by EFI
Tasks are managed outside of EFI in spreadsheets. Consequently, there is no way
to close or update these tasks in the resource system and a lot of tasks that may
have been completed remain open
38 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0040.png
DATE: 24.09.2015
Having work tasks in different places means that it is impossible to get an accurate
and timely picture on how much is executed and when it is executed. To get a good
picture of the work delivered you need to know that the caseworker is both working
in the spreadsheet and on an RS task and you would then need to combine this
information
Asset repossession caseworkers use the calendar feature to manager their cases,
however they have found that this feature does not work as they would expect and
that it is difficult to accurately manage their client site visits
5.7.4 Dispute Management
The functionality within dispute management is;
Allocate & handle disputes
Create a dispute case
Process a dispute case
Monitor disputes
Contact customer and advise of dispute outcomes
Perform appropriate dispute actions and record
5.7.4.1 Dispute Management Key Findings
Dispute management was not part of our reviews, however a key finding from our other
reviews was;
F.47
There is no way to tag debtors and adequately manage dispute cases in a centralised
consistent and repeatable manner
5.7.4.2 Dispute Management Functional Assessment
Dispute management is a manual process, the only system interaction that is sometimes
used in these cases relates to the notes functionality. In terms of gaps, the main gap is
that there is no ability to tag claims, treatments etc. to indicate that they are currently under
dispute (refer to claim management and treatment gaps.)
However, it has been stated by Kammeradvokaten that SKAT is entitled to try and collect
on all disputed debts etc. (a positive collection result being an acknowledgement of the
debt) therefore, it would be more for information purposes that this tagging would be
useful.
5.7.5 Debtor Analytics (Risk Rating)
Debtor Analytics contains the functionality for determining the risk of debtors, their
likelihood to pay and for identify cases that require immediate action. This also covers
analytics for the debt collection strategies, which are focused on determining actions which
will maximise debt returns. The functionality in this area is used to understand debtor
behaviours and gain information about types of debtors. Specific functionality is:
39 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0041.png
DATE: 24.09.2015
Determine high risk taxpayers
Detect and analyse fraud
Model fraud and risk
Research and develop fraud and risk models
Improve collections
Analyse payment behaviours
5.7.5.1 Debtor Analytics (Risk Rating) Key Findings
This area was not part of our review, however based on our other work our key findings
are:
F.48
The system only provides basic functionality in this area and this functionality is insufficient
to even determine a simple risk profile for RIM. Consequently, this functionality is not being
used and all risk profiling is being calculated manually
There are significant gaps in terms of what the System is providing and there are no debt or
fraud models that RIM can use to maximise debt collection
F.49
5.7.5.2 Debtor Analytics (Risk Rating) Functional Assessment
Currently the only debtor analytics functionality active in EFI is the risk rating. This risk
rating is a very small component located in the data warehouse that is used to score the
risk rating of debtors. This functionality is not well developed and is not actually used in the
high risk rating process, which is performed manually out of the system.
Additionally, treatments and other decisions which should use these risk analytics as the
basis for choosing which treatments the debtor should be placed based on and other
factors such as propensity to pay, most effective outcome based on similar debtor profiles
etc. are not being used. Today risk rating is handled by a manual process and it is only
done at a very basic level.
We did not perform an extensive investigation, but the gaps Accenture noticed are:
Scoring of high risk debtors to determine treatment strategy
There is no refund risk profiling available (to mitigate refund risks)
Determining the best debt collection strategy based on propensity to pay, debtor
profiles etc.
Detection and analysis of fraud or compliance issues
Not having information in order to focus on collection improvement
5.7.6 Business Rule Management
EFI contains a large number of Business Rules, which are configurable by the
administrator of the system. The business rule management functional area covers the
creating, updating, viewing and listing of the rules that govern many of the Systems
decisions.
40 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0042.png
DATE: 24.09.2015
Business rules are used in many areas and determine the rules for things such as: types
of claims that can be added to a treatment, expiry date of a claim, which claims can be
placed on which treatments, the tracks debtors can be placed one, the amount of payment
or salary deduction that a debtor has to pay based on their ability to pay etc.
Key capabilities include:
Create and update business rule
Get or search business rule
Add legal rule
Accenture did not perform a specific review of the matrices or all the business rules in
each program, however, Accenture has reviewed business rules that were contained in
each of the areas that Accenture reviewed.
5.7.6.1 Business Rule Functional Assessment
In EFI Business Rules are implemented through matrices; these matrices make it possible
to generate a large number of rules and to then have these rules used in many ways and
places. Unfortunately, there seems to be a large number of matrixes with repeated
information, which make it hard to understand which rules apply when and makes the
System more complex. As rules are developed for each module, meaning that the rules
are maintained on many places.
Additionally, the creation and management of these business rules have very little
restrictions applied to them and it is possible to generate almost any rule desired. This
makes the System difficult to maintain and update correctly in all environments the System
is installed.
In other systems, the rules that are defined in matrixes clearly defined and well
documented as is the usage restrictions to be applied to the matrixes. In EFI there is a
distinct lack of documentation concerning the rules implemented by the matrixes and how
these matrixes should be used or read (this point is covered in our technical report in more
detail).
5.7.7 Document Management
Document management involves the creation, searching and maintenance of documents
that are created for either issuing to debtors, communication with claimants or for internal
processes. The majority of document management is not part of the core EFI/DMI system.
Following are the key capabilities for this functional area:
Create and update document
Search document
View and list documents
41 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0043.png
DATE: 24.09.2015
5.7.7.1 Document Management Functional Assessment
Most of the document management capability was not part of our review. However, one
problem that Accenture did notice is that the System does not use Meta tagging when
documents are created as part of workflows within the system. This is an industry standard
and critical for the ability to search and assess documents quickly.
As a consequence of this, it is very difficult for caseworkers etc. to search out specific
documents and to find the ones that they are looking for. Additionally, this means that it is
not possible to include documents as part of KPI`s, analytics or understanding and
investigating debtors.
5.7.8 Operational and Governmental Analytics and Reporting
The operational and governmental reporting functional area includes all activities related to
reporting and analytics that are required for operational, strategic, reconciliation and other
SKAT tasks - specifically;
Analytics for parliamentary queries
Reporting to the Skatteministeriet
Revenue accounting and write-off reporting
Client accounting reports such a debt overviews
Audit reporting
Traceability
Activity log
Analytic capabilities to support operations, accounting etc.
Create reports related to case management
Create reports related to work allocation
Create reports on the effectiveness of treatments based on revenue collected
This area was not part of our review. However, below is a list of reports, which provide an
overview of the reports in use today and where possible Accenture has described what
they are used for.
Report Name DK
Den samlede
Forvaltningsstrategi
Report Name EN
The overall
management strategy
State
Contents/Comments
Action plan to "Rigsrevision"
and "Intern Revision (114-
560). EFI/DMI in relation to
audit and quarterly follow-up
reports.
DMI up against SAP38,
Kobra and DMO. Report is
coming against eIndkomst
and SLUT is in process. Also
in progress to report towards
claim owners and
Kontrolmiljø
Control environment
42 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0044.png
DATE: 24.09.2015
Aktiv Monitorering
Active Monitoring
administration agreement
with State Administration.
Monitoring report from
system owners to monitor
EFI/DMI. Implemented but
moving over to IT-operations.
Might be extended when
critical connections on
EFI/DMI is executed.
Expected to deliver a
reporting routine for
leadership towards risk
based deviations.
Daily information on number
of EFI tasks, produced and
accessed tasks. Including
queue changes.
Weekly summary of
production and access of EFI
tasks.
Monthly summary of
production and access to EFI
tasks
In use
In use
Afgivelseshåndtering
Deviation
management
Liggetidsrapport
Daily (task) report
Produktionsrapport
Production report
Månedsrapport
Monthly report
L1-Totalrestancen-
antal(valgt kunde)
L1a-
Aktuelt_inddrivelige_resta
ncer_spec_detalje
L1a-Totalrestancen-
antal(valgt kunde)-inddr
L1b-
Aktuelt_ikke_inddrivelige_r
estancer_spec_detalje
L1b-Totalrestancen-
antal(valgt kunde)-ikke
inddr
L1b-Aktuelt ikke
inddrivelige restancer
specifikation
L2_Igangværende
virksomheder
L2b_Igangv_afmeldte_virk
somheder_ikke_inddrivelig
e
L2a_Igangv_afmeldte_virks
omheder_inddrivelige
L11-InddrivelsesPct
L11-InddrivelsesPct-ikke
inddr
L11-InddrivelsesPct-inddr
L11A-IndbetalingsPct
L11A-IndbetalingsPct-ikke
inddr
L11A-IndbetalingsPct-inddr
Total debt - number
(selected customer)
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
43 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0045.png
DATE: 24.09.2015
L12afgang
L12afgang-ikke inddr
L12afgang inddr
L12tilgang
L12tilgang fra DMO
L12tilgang-ikke-indr
L12tilgang-indr
L12tilgang SIMRENTE
L12tilgang SIMRENTE-ikke-
inddr
L12tilgang SIMRENTE-
inddr
L12Aafgang
L12Aafgang-ikke inddr
L12Aafgang-inddr
L15-Kommunestatistik-til
kommuner_md_201409_20
1410
L15 kommunestatistik-
oversigt
L16_Intervaller_og_under_
100000
Ovrige_Total
Ovrige_Ikke_Inddrivelig
Ovrige_Inddrivelig
Kommunerapport_Total
Kommunerapport_Ikke_Ind
drivelig
Kommunerapport_Inddrive
lig
Personrestancer
Aktuelt inddrivelige
restancer
Aktuelt ikke inddrivelige
restancer
Restancer Udland
Indsatsstatistik
Bobehandling
Indsatsundertyper
Restancealder
Restantalder
Geografisk opdelt (postnr)
Forældelse
Afskrivningsprognoser §16
Opgørelse over
afskrivninger
Municipality report
total
Municipality report not
collectable
Municipality report
collectable
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In use
In development
In development
In development
Debt international
In development
In development
In development
In development
In development
In development
In development
In development
In development
Table 2 Reports
44 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0046.png
DATE: 24.09.2015
5.7.9 Client Meetings
The client meetings functionality handles client meetings some supportive functions are
used, such as work management, debtor management and correspondence.
This area was not reviewed as part of our work and Accenture has no key findings in
relation to it.
5.7.10 Debt Relief/Subsidy
The debt relief/subsidy functionality covers the creation and application of reliefs by
debtors. This is a manual debtor initiated process today.
This area was not reviewed as part of our work and Accenture has no key findings in
relation to it.
5.7.11 Audit and Discovery
The client audit and discovery functionality covers everything related to auditing of work
related to debt collection and management and discovery work related to determining
compliance and other issues.
This area was not reviewed as part of our work. However there seems to be an issue with
collecting and providing information that is required for auditing such as actions taken due
to the inability to find information or adequately report on items within the system.
The key findings are:
F.50
There is no functionality that has been designed or provided in the System to support
SKAT`s auditing obligations or discovery requirements
5.8 Customer Functions
5.8.1 Contact Management
Functionality within this area includes the ability to effectively and efficiently manage
contact with debtors and claimants.
We did not review this area and have no key findings.
5.8.2 Debtor Management
Debtor management concerns the functionality that allows the System to store and use
information about the debtors connected to claims and their treatments. This include the
information around identification, address, and other vital information that may be needed
in the collection process. Key functionality include:
Creation, search and update of debtor types
Creation of debtors and information related to debtors
Viewing of history related to debtors
Changing or adding of a new debtor type for debtors
Setting of debtors to active, inactive or deceased in the System
45 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0047.png
DATE: 24.09.2015
5.8.2.1 Debtor Management Key Findings
We have not reviewed this area however; Accenture has the following findings from our
other review work;
F.51
The System is only able to manage CPR and CVR debtors, this means PEF and other
debtor types are currently not supported in the System and therefore not able to be
managed.
The System does not support all of RIM`s requirements for debtor management.
Specifically, the System does not provide the ability to tag a debtor to show that they are a
debtor of interest or to indicate that a debtor has been handed over to a foreign agency for
debt collection.
There is no consolidated view of a debtor, which shows their status with RIM, their active
cases, treatments and history. This makes it difficult for RIM to manage debtors and
means caseworkers have to look in numerous places for this information.
The System does not handle a change in a debtor’s obligations such as when then change
from self-employed to being an employee
F.52
F.53
F.54
5.8.2.2 Debtor Management Capability Assessment
Following are the capability concerns that Accenture discovered for this area.
The System cannot handle anything related to PEF debtors and their specific
requirements. There is no way to manage the specific conditions and apply rules
specifically for this type of debtor
Not able to tag debtors such as when they are unable to be located, debts are sent
overseas or if they are a debtor of interest such as when they are high risk
The System should be able to create notes for persons and companies which do
not have claims within the systems
It is possible to register an AKR number together with a fax number but the data
field is not viewable within the System
EFI does not update customer-type automatically. This means that when a debtor
changes from being a PEF-customer to having a normal job/salary income the
System does not automatically respond. Consequently SKAT must verify and
update customer types manually
The System is not able to handle debtors that are involved in housing co-operations
correctly
5.8.3 Claimant Management
Claimant management contains the functionality for management of claimants including
the creation and maintenance of claim owner agreements, which are required for claim
management. Key functionality includes create, update and search of claim owner
agreements.
We did not review this area and have no key findings.
46 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0048.png
DATE: 24.09.2015
5.8.4 Correspondence
Correspondence functional area includes the following functionality:
Template Management
Inbound Mail
Outbound Mail
Other Channels
Send letter to customer
Receive transport proposal from creditor
Send confirmation to claim owner
Create correspondence from customer
Send decision to customer
Handling returned mail
5.8.4.1
Correspondence Key Findings
We have not reviewed this area however; Accenture has one key finding from our other
review work:
F.55
The System is not able to receive information related to returned mail and update the
System based on this information. This is a significant problem and means that the System
is not able to respond to these events such as by interrupting the aging of claims
47 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0049.png
DATE: 24.09.2015
6 Other Findings
The purpose of this section is to cover our other functional key findings, which do not
specifically belong to one functional area.
6.1
Functional Architecture Overview
The distribution of the functionality does not utilise strengths within each technology. For
example, one of DMI’s main strengths is its core accounting and data locking capabilities.
However, this standard functionality has not been used in DMI. Instead, a lot of custom
code has been developed and business rules have been created in EFI to provide this
functionality. As a consequence of this missing functionality, manual workarounds are
being used which introduce risks into the process and can impact data quality.
Service Oriented Architecture - SOA is an application or system made up of smaller
components (services). Services are normally self-contained, semi-independent units of
functionality. However, it seems that at SKAT functionality is partly in EFI and partly in
DMI, rather than having a single service containing all functionality in a single area. The
division of functional responsibilities among services in EFI and DMI has resulted in a high
complexity. In many cases, a designer, developer or tester has to understand many
components in order to understand a single function.
SOA is powerful in its ability to provide re-usable functionality that is simple and modular.
However, looking at the functional design of EFI this principle has not been used. Instead
workflows in the System have no reusability. For example, each treatment has programs
or services that are responsible for creating and maintaining that are specific only to them.
If you want to create a new treatment, you must create all of the new programs and make
several adjustments to existing ones in order to allow for the new treatment. Typically, in
other systems, treatments are viewed as a series of configurable activities. This is
important and means that the time to implement or change the configuration is rapid.
Another problem is the custom build resource management part of EFI. Essentially, this
part is designed to deliver some but not all of what Accenture would typically use a CRM
system to provide; so debtor relationship, caseworker and work management.
Consequently, the usage of this component today is minimal, as it only partially covers the
processes and it is not flexible enough to provide the functionality that the workers need in
order to perform their activities (refer to process review list in the appendix).
6.2 Event Driven
A lot of functionality is event driven which means that an event such as receiving a new
claim on a customer with ongoing treatment gets interrupted. The events can create
special circumstance which then initiate processes which seem to be uncontrolled.
Handling of these types of circumstances is difficult as there are complex legal
requirements related to the handling of treatments.
Additionally, it is our assessment the event driven functionality is insufficient in an
automated system and that a certain level of system monitoring and assessment needs to
48 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0050.png
DATE: 24.09.2015
happen independently of an event being triggered in the system. It is our observations that
EFI and DMI are missing monitoring in core areas such as salary deductions.
6.3 Insufficient Monitoring
Generally, in fully automated systems monitoring of conditions and data is critical to
ensure that nothing is missed in terms of events and that events are reacted to in the
System. This is especially true for an event driven system such as EFI where monitoring is
important to highlight the cases where events have not occurred or have blocked further
processing. Our assessment did not find any services that monitors important values for
RIM such as claims, customers, liabilities and treatments. This is a significant problem in
the System and means that numerous issues can be happening that are not being noticed
by the people who need to take action once these issue occur. For example, the amount of
money being debited by salary deduction (eInk) should be the same in both EFI and DMI,
however, as there is not monitoring there is no check to ensure that EFI and DMI are
100% aligned on the number and state of claims.
6.4 Poor Performance due to Functional Architecture
The distribution of the functionality means that a vast majority of the accounting and other
financial related or treatment detailed actions occurs in DMI (refer to system distribution
diagram). Consequently, whenever EFI creates a treatment or an action is taken on a
treatment, EFI needs to retrieve information from DMI and it will send numerous action
requests to DMI. Normally we design the System to handle this in real-time. However, in
this case it seems that EFI has been given a traffic light system, which enables users to
see that the process in still waiting to be complete and the information requests etc. have
been placed on a queue and handled as asynchronously.
It is our opinion that this traffic light system is not a good design as it gives the impression
that the System is running very slowly and means that the users or workers often have to
wait a long time before they can continue with their work. Moreover, sometimes their work
is delayed when a request fails, as they are not informed of this failure and when they do
find out they need to try to fix it. Based on our experience, it seems to us that this entire
approach is actually a workaround for architectural issues and actually increases users’
workloads by introducing delays.
6.5 Insufficient Transaction Audit & History
There is some logging in EFI, but the logging in DMI is not turned on. Currently EFI logs
things such as usage of the System by users and error code.
In EFI there is some recording of history but not at the level Accenture would expect for
functionality. This often causes difficulty when trying to understand actions that have been
taken and to tracing things in the System such as alterations to the treatments.
6.6 Poor Exceptions/ Error handling and Transaction Roll-Back
The System is not able to do a full roll back of transactions and its children, this means
that it is possible that when a transaction fails during its commit - that SKAT can be left
49 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0051.png
DATE: 24.09.2015
with an incomplete transaction in the systems. For example, when a claim is received it is
entered in the receive claim part of EFI and then it creates the claims in DMI. If creation of
the claim in DMI fails this is not able to be detected by the original program in EFI and
consequently ends up with a claim in EFI but only half created in DMI. At the moment,
there is no check to notify users when this has happened, and then when they become
aware of this failure due to other investigations, they need to manual fix the transactions in
the System.
Normally, transactional integrity is validated through technical testing. Although Accenture
did not review the test conditions, given the issues Accenture found in our review our
opinion is that this should be put in place, and that the lack of this is a major issue that will
gradually corrupt business records over time.
6.7 Flexibility
Based on our review, it is our opinion that the use of the System is too broad and that few
limitations are place on the actions and changes that workers are able to do. This means
that workers are able to change critical areas that they should not have access too.
Normally when Accenture designs an automated system, Accenture would not allow an
average caseworker to change information that governs decisions taken by the System, as
these changes impact numerous parts of the System.
50 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0052.png
DATE: 24.09.2015
7 Appendix - Process Diagram and List
7.1 Process Overview Diagram
Below is the high-level overview of all the processes that Accenture created in System
Architect.
PRO014 -
Receive Cl aim s
+
PRO018 - Two
year High
Priority Claim s
PRO020 -
Special Salary
Deduction
PRO008-
Customer
Selec tion
+
PRO021 - Add
Cl aim s
-
PRO010 -
Handling of
paym ents
+
+
PRO028 - Work
Management
(Resource
Manager)
+
PRO009
Payment Pl an,
CPR
+
PRO022 -
Dunning
PRO013 -
Payment Pl an,
CVR
PRO012 -
Offsetting
+
+
+
PRO003 -
Asset
Repossession
-
PRO017 -
Salary
Deduction
PRO024 -
Assistance
Request
+
PRO001 -
Ack nowledgement of
Debt
+
+
PRO019 - Write
offs
+
Supportive processes
PRO016 - R isk
Scoring
PRO007 -
Customer
Management
PRO006 -
Complaint
Proceedure
PRO005 -
Cl ient Meetings
PRO002 - A ging
PRO004 - C ivil
Law Suit
+
PRO027 -
Correspondence
management
PRO026 -
Telephone
management
PRO025 -
Cl aim owner
contacting Skat
PRO023 -
Telephone
Col lection
PRO011 -
Insolvency and
Legislative
Functions
PRO015 -
Resourc e
Pl anning
+
Figure 3 Process Overview Diagram
7.2 Process List
Following is a list of the key as-is processes in use at SKAT today; the list only contains
the ones that Accenture is aware of but there may be other critical processes that are not
listed on this list. For each of the business process Accenture has listed the functional
areas, whether or not it was reviewed as part of our work and whether or not Accenture
has created it in System Architect. The purpose of this section is to provide traceability in
terms of what Accenture were provided with and what Accenture actually reviewed.
Process
PRO001 - Acknowledgement
of Debt
Functional Area
Claim Management
Debtor Management
Compliance & Treatments
Correspondence
Document management
Reviewed and Entered in SA
Yes
51 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0053.png
DATE: 24.09.2015
PRO014 - Receive Claim
PRO021 - Add Claim (to
treatments)
Manual Handling
PRO002 - Aging
PRO003 - Asset Repossession
Acknowledgement of Debt
Claim Management
Document Management
Correspondence
Claimant Management
Claim Management
Claim Management
Claim Management
Compliance & Treatments
Asset repossession
Forced Dissolution
Bank Garnishee
Work management
Governmental reporting
Court Interactions
Debtor management
Debtor management2
Debtor management
Debtor management
Claim management
Claim management
Debtor management
Payment plan
Compliance & Treatments
Correspondence
Document management
Payment processing
Account management
Claim Management??
Insolvency and Litigation
Forced Dissolution
Bank Garnishee
Business Reconstruction
Claim management
Offsetting
Debtor management
Claim management
Debtor management
Payment plan
Compliance & Treatments
Correspondence
Document management
Work Management (Resource
Manager)
Debtor Analytics (Risk Rating)
Claim management
Compliance & Treatments
Salary Deduction
Correspondence
Document management
Claim management
Compliance & Treatments
Yes
Yes – but diagram is incomplete as
this is not working in EFI
No
No
Yes
PRO004 - Civil Law Suit
PRO005 - Client Meeting
PRO006 - Complaint
Procedure
PRO007 - Customer
Management
PRO008 - Customer Selection
PRO009 - Payment Plan,
Individuals (CPR)
Yes
Yes
Yes
Yes
Yes
Yes
PRO010 - Handling of
payments
PRO011 – Insolvency
Processes
Yes
Yes
PRO012 - Offsetting
Yes
PRO013 - Payment Plan,
Businesses (CVR)
Yes
PRO015 - Resource Planning
PRO016 - Risk Scoring
PRO017 - Salary Deduction
Yes but only covers resource part
of the work management and not
case handling.
No, diagram not available or
created
Yes
PRO018 - Two year High
Priority Claims
Yes
52 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0054.png
DATE: 24.09.2015
PRO019 - Write offs
PRO020 - Special Salary
Deduction
PRO022 - Dunning
PRO023 - Telephone
collection
PRO024 - Assistance Request
PRO025 - Claim Owner
Contacting Skat
PRO026 - Telephone
management
PRO027 - Correspondence
management
Analytics and Reporting
Debtor Analytics (Risk Rating)
Claim management
Compliance & Treatments
Debtor management
Correspondence
Document management
Claim management
Compliance & Treatments
Salary deduction
Correspondence
Document management
Claim management
Debtor management
Document management
Correspondence
Debtor Management
Collections & Treatments
Governmental Reporting
Claimant Management
Debtor Management
Claimant Management
Correspondence
Document handling
Operational and Governmental
Reporting
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No, as these processes have not
been mapped and no diagram was
available
Table 3 Process List
8 Appendix – List of Defined Terms
Term
ACID
ADM
Definition
Atomic, Consistent, Isolated and Durable. These are the fundamental guarantees
a database provides when using transactions to ensure data integrity.
ADM is a development methodology that supports business process analysis,
application requirements and use case analysis, application design, technical
architecture development, testing, and the deployment of a system.
An application is an executable software program that performs a function or
group of functions. It is typically composed of a single technology, and may be
integrated with other applications.
The term “application” is used to describe EFI and DMI. EFI and DMI are
technically separate and are built on different technologies in separate projects.
Is used to describe that an anticipated event has occurred or that something is
how it was thought or believed to be.
Is the set of functions or capabilities that the software or system is currently
providing for a user. A function or capability is a defined objective or characteristic
action that a system or component is providing.
Automation is the practice of using applications and other IT to perform tasks that
would otherwise be performed manually, i.e. by people.
A typical example is the issue of reminder letters to debtors.
A Business Process (or Business Process Model) is a formal description of how a
business function is performed from beginning to end. The description should
Application
As expected
As-is functionality
Automation
Business Process
53 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0055.png
DATE: 24.09.2015
Code / Source
Code
Configuration
COTS
CRM
Database
Debt collection
process
management model
Design
indicate the activities performed by users and applications, and the interfaces
between each.
The “code” or “source code” refers to the human readable instructions that are
either compiled and/or interpreted to form object code that can be executed by a
computer system.
Configuration refers to any data that is used to control the behaviour of a system.
Configuration data may be held in files, databases or elsewhere.
An example could be a fee amount held in a database. This allows the fee to be
changed, without requiring changes to source code. Changes to configuration data
should be tested as these can completely change the behaviour of a system.
Commercial Off The Shelf [software]. COTS refers to the use of software
applications (packages) to implement a business solution. Complex business
solutions will require the COTS software to be customised, often to a significant
extent.
Customer Relationship Management.
A database is a platform application that enables data to be stored and retrieved.
Additionally, a database can be used to guarantee the integrity of the data stored
within certain constraints, using ACID transactions and Relational Integrity.
Is an illustration of the main processes or activities that are performed by entities
which specialise in the management of debt collection, i.e. pursues of payments
for debts owed by individuals or businesses.
[1]
Design is the process of converting requirements or a higher level design into a
more detailed design. Designs are typically decomposed over multiple levels from
a Solution Blueprint through high level design to low level design.
“Debitormotor Inddrivelse”
“Et Fælles Inddrivelsessystem”
The programme of work (a number of related projects) to deliver a new debt
collection system for SKAT.
The EFI Programme included the EFI project, DMI project and a number of other
smaller projects or packages of work to integrate EFI and DMI with other systems
within SKAT.
End to end (e2e) refers to a complete process and/or the supporting IT system.
For example:
The end to end process of handling a Claim includes initial receipt,
performing collections treatment(s) and finally closing the Claim.
The corresponding IT system(s) to enable this process includes all the IT
systems and applications that integrate to perform the overall function.
DMI
EFI
EFI Programme
End to end
Flexibility
Fuctional Design
Documents
Simple path
Interface
IT
KISS principle
Flexibility refers to the programme principle to implement a system that enables
future business requirements to be accommodated primarily by configuration of
the System, rather than source code changes.
A functional design or specification (also, functional spec, specs, functional
specifications document (FSD), functional requirements specification, or Program
specification) in systems engineering and software development is the
documentation that describes the requested behaviour of an engineering system.
In a software system, the simple path is the default path through the System, with
no exceptions.
E.g. case processing of a single, simplistic claim with low complexity and no errors
along the way.
An interface is the point where an application connects to something external to
the application. Interfaces may be implemented with a wide variety of technologies
including files, database tables, web services and more.
Information Technology
Keep It Short and Simple – principle suggesting focus on simple solutions that
meet the requirements
54 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0056.png
DATE: 24.09.2015
Maintainability
Need
Package Software
Process Diagram
Requirement
Requirements
Traceability Matrix
(RTM)
Maintainability is a non-functional characteristic of a system. It refers to the ability
to make changes to an application over its lifetime to accommodate changing
requirements.
As used in this document, the Needs are the detailed documented requirements
established through requirements gathering workshops for the selected sample
areas.
The Needs were gathered on the basis that they described what the users
originally expected or required the System to do.
Package Software: see COTS
The
Process diagram provides a visual representation of the steps in a process.
Flow charts are also referred to as process maps or flow diagrams. Constructing a
process diagram is the first activity of a process improvement effort and it is critical
when trying to understand the core activities of a business.
A requirement is a formal statement of what a system must do, in order to be
working correctly. Typically, the scope of a business application is defined by a
number of requirements. Large systems often comprise 3,000 – 10,000
requirements.
An example could be “The decision letter to debtor must in all cases contain size,
period, type, and due date of all claims covered by the decision.”
A Requirements Traceability Matrix (RTM) is
a) A list of all the requirements comprising the system
b) An audit for each requirement of where the requirement was satisfied in
design, build and test.
Danish acronym that is short for “restanceinddrivelsesmyndighed” which in English
should be understood as “claim collection authority” which is handled by SKAT.
SAP is package software for performing many common business functions.
Software Development Life Cycle. SDLC is used to describe the process of
creating a software system.
A Service (or web service) is a self-contained unit of functionality and data that
performs some useful function.
An example Service could be a service that allows users or other applications to
check the registration number (CVR, CPR or AKR) for a customer.
Service Oriented Architecture (SOA) is the concept of creating systems based on
integrating Services that provide self-contained functionality.
See Design.
A System is one or more applications that perform an overall business function.
An example system is an email system that performs all receiving, storing and
sending email (although this may be comprised of a number of discrete
applications).
The term “system” is used to describe the integrated combination of EFI and DMI,
which provides the overall debt collection IT function for SKAT.
In software a technical document or specification refers to any type of
documentation that describes handling, functionality and architecture of a
technical product or a product under development or use within a system.
A Test is a documented procedure that can be performed to validate compliance
with a requirement.
As an example, with reference to the definition of Requirement above, the
corresponding test would validate that in all cases the decision letter contained the
necessary details and that these were correct.
In any large system, some testing will have dependencies on external
components, where the “remote side” of the interface is required to perform the
test.
It is usual to perform some testing where the “remote side” of the interface is
performed with a fake system that returns sufficiently real responses to enable
testing.
These fake remote systems are termed “Test Stubs”.
RIM
SAP
SDLC
Service
SOA
Specification
System
Technical Design
Document
Test
Test Stub
55 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0057.png
DATE: 24.09.2015
To-be analysis
To-be functionality
As-is functional
areas
To-be
Requirements
Use Case
V Model
Web Service
WSDL
YAGNI
Refers to the tasks that go into determining the needs or conditions that have to
be meet for a new or altered product or project, taking account of the possibly
conflicting requirements of the various stakeholders, analysing, documenting,
validating and managing software or systems.
Is the set of functions or capabilities that the software or system must provide for a
user. A function or capability is a defined objective or characteristic action that a
system or component needs to provide.
This is the grouping of current activities or processes that are performed within a
system on the basis of their need in accomplishing one or more tasks.
Are the documented physical and functional needs that a particular design,
product or process must be able to perform. There are several types of
requirements; architectural, business, user (stakeholder), quality of service (non-
functional), implementation (transition) and functional (solution).
A Use Case is a description of the steps that a number of users (actors) must
perform in order to complete a business scenario.
Use Case descriptions can be used, together with other designs, to provide a
design for a system or application.
Use Cases typically describe the “simple path” and any number of alternate paths
through the system.
Separate sets of use cases were used to describe the functionality for the EFI and
DMI applications.
The “V Model” is a widely used model for defining the verification and validation
processes for an IT system, in which each design and build output is validated via
a matching testing (validation) step.
A Web Service is a Service that provides a machine to machine interface. The
interface technologies used were originally HTTP, SOAP and WSDL, but are now
commonly considered to include REST.
Web Services Description Language
You Aren’t Going to Need It – principle to avoid “Rolls Royce” solutions when you
need a “Ford”
Table 4 List of Defined Terms
56 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0058.png
DATE: 24.09.2015
9 Documentation Listing with Review
Following is a listing of all the documentation made available to us that represents the
current situation or as-is of the system. Accenture has not included a listing of any
documentation that describes the original to-Be for the EFI and DMI. The purpose of this
section is to provide traceability in terms of what Accenture were provided with and what
Accenture actually reviewed.
Type
System Design
(OSB)
Document Name
Overordnet
forretningsmæssig
beskrivelse_EFI_OP_00 -
Addendum for Modtag
fordring
Overordnet
forretningsmæssig
beskrivelse_EFI_OP_00
Overordnet
systembeskrivelse for den
samlede
inddrivelsesløsning_EFI_O
P_00 - Addendum for
Modtag fordring
Overordnet
systembeskrivelse for den
samlede
inddrivelsesløsning_EFI_O
P_00
SAD - Software
Architecture Document for
EFI-IPO
Overordnet
Delsystembeskrivelse for
indsatstypen
Lønindeholdelse
Overordnet
Delsystembeskrivelse for
EFI ESDH og AandD
Integration
Overordnet
Delsystembeskrivelse for
Administrationsportalen
Overordnet
Delsystembeskrivelse for
Betalingevneberegning og
Budget
Overordnet
Delsystembeskrivelse for
indsatsen betalingsordning
EFI_OP_00
Overordnet
Delsystembeskrivelse for
indsatsen Bobehandling
EFI_OP_00
System
EFI
Pages
36
Requirements
5
Change
Requests
Reviewed
No
EFI
136
25
No
EFI
43
10
No
EFI
128
28
No
System
Architecture
Documentation
(SAD)
Functional
Design
Document EFI
(ODSB)
EFI
128
5
No
EFI
169
4
9
Yes
EFI
51
10
14
No
EFI
30
2
2
Yes
EFI
101
6
13
No
EFI
94
2
9
Yes
EFI
151
4
8
No
57 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0059.png
DATE: 24.09.2015
Overordnet
Delsystembeskrivelse for
indsatsen
Bødeforvandlingsstraf
EFI_OP_00
Overordnet
Delsystembeskrivelse for
EFI ESDH og AD
Integration
Overordnet
Delsystembeskrivelse for
Eksport af data fra EFI til
DW EFI_OP_00
Overordnet
Delsystembeskrivelse for
indsatsen Erkend fordring
(WEB) EFI_OP_00
20110715 - ODSB for
SKAT ETL
Overordnet
Delsystembeskrivelse for
indsatsen Henstand
EFI_OP_00
Overordnet
Delsystembeskrivelse for
hændelseshåndtering i EFI
Overordnet
Delsystembeskrivelse for
Inddrivelsesmotor
Overordnet
Delsystembeskrivelse for
indsatser EFI_OP_00
Overordnet
Delsystembeskrivelse for
IPO sikkerhed -
kommenteret v2
Overordnet
Delsystembeskrivelse for
indsatsen
Kreditoplysningsbureau
EFI_OP_00 OLD
Overordnet
Delsystembeskrivelse for
Kundefordringsfacade
Overordnet
Delsystembeskrivelse for
indsatsen kundemøde
EFI_OP_00
Overordnet
Delsystembeskrivelse for
indsatsen Lønindeholdelse
EFI_OP_00
Overordnet
Delsystembeskrivelse for
indsatsen Manuel
Sagsbehandling
EFI_OP_00
EFI
92
5
3
No
EFI
57
9
17
No
EFI
26
0
3
No
EFI
52
2
3
Yes
EFI
EFI
31
5
0
7
0
3
No
No
EFI
43
0
4
Yes
EFI
47
8
Yes
EFI
67
0
Yes
EFI
22
2
No
EFI
78
7
No
EFI
108
45
Yes
EFI
41
2
No
EFI
168
13
Yes
EFI
62
9
No
58 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0060.png
DATE: 24.09.2015
Modtag Fordring ODSB 1
External system interface
and MF Component
Modtag Fordring ODSB 2
Receive Debts Dialogues
OLD
Modtag Fordring ODSB 3
Claimants and agreements
OLD
Modtag Fordring ODSB 4
DMI Dialogues
Modtag Fordring ODSB 5
Alternative Liabilities
Overordnet
Delsystembeskrivelse for
overvågning af udlagte
aktivers forældelse
EFI_OP_00 OLD
Overordnet
Delsystembeskrivelse for
Regelmotor
Overordnet
Delsystembeskrivelse for
Ressourcestyring i EFI 2.3
Overordnet
Delsystembeskrivelse for
rykker EFI_OP_00
Overordnet
Delsystembeskrivelse for
Sagsbehandlerportalen
Overordnet
Delsystembeskrivelse for
Stop Automatisk Sporskifte
EFI_OP_00 OLD
Overordnet
Delsystembeskrivelse for
Indsatsen Udlæg
EFI_OP_00
Overordnet
Delsystembeskrivelse for
Udsøg fordringer til
automatisk afskrivning
ODSB 3 0 for EFI data
warehouse v 4 4
ODSB_for_Hændelsesfabri
kken_v_3 5 2
dnet Delsystembeskrivelse
for indsatsen Bobehandling
EFI_OP_00 BILAG
ODSB 3.0 for EFI data
warehouse v 4.4
DW_(ODSB 2.0) v.4.0
ODSB for
Hændelsesfabrikken v 2 0
ODSB 3.0 for EFI data
warehouse v 4.4
EFI
79
24
Yes
EFI
178
8
No
EFI
47
8
No
EFI
EFI
EFI
76
33
24
9
0
0
No
No
No
EFI
18
8
Yes
EFI
1268
124
Yes
EFI
41
7
No
EFI
191
26
Yes
EFI
13
7
No
EFI
193
19
No
EFI
32
6
No
EFI
EFI
EFI
27
25
170
16
0
0
No
No
No
EFI
EFI DW
EFI DW
EFI DW
27
30
23
27
0
0
0
6
No
No
No
No
59 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0061.png
DATE: 24.09.2015
Detailed
Technical
Design EFI
(DDSB)
ODSB for
Hændelsesfabrikken v 3.4
Modtag Fordring (MF)
Detaljeret Design System
Beskrivelse (DDSB) for MF
komponenten
SKAT EFI DDSB - Logning
SKAT EFI DDSB -
Kundefordringsfacade (KFI)
Detaljeret
Delsystembeskrivelse for
EFI IPO sikkerhed
DDSB for Analyse Base
Tabel (ABT)_v95
DDSB_for_Hændelsesfabri
kken_1.5.3
DDSB_for_upscoringskomp
onent_v1.3.5
DDSB-EFI_DW_v2.2_JB
SKAT EFI DDSB -
Automatiserede
teststrategier
SKAT EFI DDSB - B2B
gateway
SKAT EFI DDSB - Batch
Jobs
SKAT EFI DDSB -
Betalingsevneberegning og
Budget (BEBB)
SKAT EFI DDSB - EFI
Database
SKAT EFI DDSB - EFI
ESDH og AandD
Integration (DP)
SKAT EFI DDSB - EFI
portaler
SKAT EFI DDSB - EFIs
anvendelse af DAP
SKAT EFI DDSB -
Fejlhåndtering
SKAT EFI DDSB -
Indsatser
SKAT EFI DDSB -
Management API -
Overvågning og teknisk
administration
SKAT EFI DDSB - Teknisk
Arkitektur
Systemdokumentation for
ABT(Analyse Base
Tabel)_v02
DDSB-EFI_DW_v1.91
DDSB_for_hændelsesfabri
kken v 1 2 - SA LWH sa
DDSB_for_upscoringskomp
onent_v1.3.0
EFI DW
EFI
25
57
0
0
0
No
Yes
EFI
EFI
EFI
22
46
26
0
0
0
0
0
0
No
No
No
EFI
EFI
EFI
EFI
EFI
34
31
112
40
9
0
0
0
0
0
No
No
No
No
No
EFI
EFI
EFI
16
75
37
0
0
0
Yes
No
No
EFI
EFI
25
32
0
0
No
No
EFI
EFI
EFI
EFI
EFI
58
22
7
27
40
0
0
0
0
0
No
No
Yes
Yes
No
EFI
EFI DW
38
13
0
0
No
No
EFI DW
EFI DW
EFI DW
30
38
86
0
0
0
No
No
No
60 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0062.png
DATE: 24.09.2015
Functional
Designs DMI
(ADD)
ADD - Administration
(ZADMI)
ADD - Afregn
Fordringhaver (ZCLAM)
ADD - Betalingsordning
(ZINST)
ADD -
Dækningsrækkefølge
(ZCOVE)
ADD - Fordring (ZRECE)
ADD - Fordring Afskriv
(ZRECE_WROF)
ADD - Fordring Nedskriv
(ZRECE_DEPR)
ADD - Fordring Opskriv
(ZRECE_REVA)
ADD - Fordring Returner
(ZRECE_RETU)
ADD - Fordring Tilbagekald
(ZRECE_WITH)
ADD - Hæftelse (ZCLIA)
ADD - Indbetaling (ZIPAY)
ADD - Kontooplysning
(ZACCO)
ADD - Modregning
(ZOFFS)
ADD - Ompostering
(ZREPO)
ADD - Regnskab (ZFICO)
ADD - Rente (ZINTE)
ADD -
RenteKontrolOrdningen
(ZINTE_RKO)
ADD - Stamdata (ZMAST)
ADD - Udbetaling (ZOPAY)
DMI
DMI
DMI
DMI
46
106
80
30
0
0
0
0
No
No
No
No
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
213
11
11
11
11
11
88
89
46
138
14
58
44
44
0
0
0
0
0
0
0
0
0
0
0
0
0
0
No
No
No
No
No
No
No
No
No
No
No
No
No
No
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
39
131
10
11
10
9
15
13
0
0
0
0
0
0
0
0
No
No
No
No
No
No
No
No
Technical
Design DMI
(IDD)
DMDMIIDD.000.02
DPDokumentOpret
DMDMIIDD.000.03
DPMeddelelseSendAkter
DMDMIIDD.000.04
RSOpgaveAsynkronBook
DMDMIIDD.000.05
DMIDWInformationOpret
DMDMIIDD.000.10
StyretFiloverførsel_Inbound
DMDMIIDD.000.11
StyretFiloverførsel_Outbou
nd
DMDMIIDD.110.01
VirksomhedStamOplysning
SamlingHent
DMDMIIDD.110.02
DMIFordringHaverAftaleOpl
ysningerÆndr
DMI
10
0
No
DMI
13
0
No
61 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0063.png
DATE: 24.09.2015
DMDMIIDD.110.03
DMIKundeArkiver
DMDMIIDD.110.04
AlternativKontaktSamlingH
ent
DMDMIIDD.110.05
PersonStamoplysningerMul
tiHent
DMDMIIDD.120.01
DMIFordringList
DMDMIIDD.120.03
DMIKontoSpecifikationHent
DMDMIIDD.120.04
DMIKontoÆndr
DMDMIIDD.120.06
DMIKundeList
DMDMIIDD.120.08
BetalingsaftalerTrækListeM
odtag
DMDMIIDD.200.02
EFIFordringSaldoAEndret
DMDMIIDD.200.03
DMIFordringHent
DMDMIIDD.200.05
DMIFordringÆndr
DMDMIIDD.210.01
DMIFordringSynkronOpret
DMDMIIDD.210.02
DMIFordringAsynkronOpret
DMDMIIDD.210.03
MFFordringAsynkronOprett
et
DMDMIIDD.210.04
EFIFordringOprettet
DMDMIIDD.220.01
DMIFordringNedskriv
DMDMIIDD.230.01
DMIFordringTilbagekald
DMDMIIDD.240.01
DMIFordringOpskriv
DMDMIIDD.250.01
DMIFordringAfskriv
DMDMIIDD.250.02
MFFordringAfskrivUnderret
DMDMIIDD.260.01
DMIFordringReturner
DMDMIIDD.270.01
MFUdligningAfregningUnde
rret
DMDMIIDD.270.05
MFRenteTilskrivningUnderr
et
DMDMIIDD.280.01
DMIRenteGodtgørelseBere
gn
DMI
DMI
12
10
0
0
No
No
DMI
10
0
No
DMI
DMI
DMI
DMI
DMI
13
13
13
13
13
0
0
0
0
0
No
No
No
No
No
DMI
DMI
DMI
DMI
DMI
DMI
10
13
12
13
13
10
0
0
0
0
0
0
No
No
No
No
No
No
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
10
13
13
13
13
10
13
10
0
0
0
0
0
0
0
0
No
No
No
No
No
No
No
No
DMI
10
0
No
DMI
13
0
No
62 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0064.png
DATE: 24.09.2015
DMDMIIDD.280.02
DMIRenteGodtgørelseTilsk
riv
DMDMIIDD.280.03
RentekontrolOrdningFradra
gIndberet
DMDMIIDD.300.01
DMIFordringForespørgBes
var
DMDMIIDD.300.02
DMIFordringForespørgAsy
nkronBesvar
DMDMIIDD.300.03
DMINemKontoModregningI
ndbetalingModtag
DMDMIIDD.300.04
NemKontoModregningIndb
etalingModtagSvar
DMDMIIDD.300.05
MFModregningKundemedd
elelseUnderret
DMDMIIDD.300.07
EFIBetalingEvneHent
DMDMIIDD.300.08
EFIBetalingEvneAsynkronH
ent
DMDMIIDD.300.09
DMIBetalingEvneHentet
DMDMIIDD.300.10
DMINemKontoUdbetalingLi
steSend
DMDMIIDD.300.11
DMINemKontoUdbetalingLi
steSendSvar
DMDMIIDD.300.12
EFIBetalingEvneÆndr
DMDMIIDD.300.13
NemKontoModregningKund
eListeSend
DMDMIIDD.300.14
DMINemKontoModregning
KundeListeSendSvar
DMDMIIDD.300.15
DMIFERVModregningFordr
ingList
DMDMIIDD.300.16
DMIFERVModregningModt
ag
DMDMIIDD.400.02
DMIHæftelsesforholdList
DMDMIIDD.400.03.DMIHæ
ftelsesforholdTilAfskrivning
Modtag
DMDMIIDD.400.04
DMIHæftelsesforholdÆndr
DMI
13
0
No
DMI
9
0
No
DMI
13
0
No
DMI
10
0
No
DMI
12
0
No
DMI
10
0
No
DMI
10
0
No
DMI
DMI
10
10
0
0
No
No
DMI
DMI
13
12
0
0
No
No
DMI
12
0
No
DMI
DMI
11
9
0
0
No
No
DMI
13
0
No
DMI
13
0
No
DMI
12
0
No
DMI
DMI
13
13
0
0
No
No
DMI
13
0
No
63 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0065.png
DATE: 24.09.2015
DMDMIIDD.400.05
DMIHæftelseForældelseLis
t
DMDMIIDD.400.06
DMIHæftelseForældelseÆ
ndr
DMDMIIDD.400.07
EFIHæftelseForældelseMo
dtag
DMDMIIDD.500.01
DMIKontoIndbetalingFordel
ingBeregn
DMDMIIDD.500.02
DMIKontoIndbetalingFordel
ingÆndr
DMDMIIDD.600.01
DMIBetalingOrdningOpret
DMDMIIDD.600.02
DMIBetalingOrdningForslag
Beregn
DMDMIIDD.600.03
DMIBetalingOrdningHent
DMDMIIDD.600.04
DMIBetalingOrdningList
DMDMIIDD.600.05
EFIBetalingOrdningMisligh
oldt
DMDMIIDD.600.07
DMIBetalingOrdningÆndr
DMDMIIDD.600.08
DMIForventetIndbetalingOp
ret
DMDMIIDD.600.09
DMIForventetIndbetalingLis
t
DMDMIIDD.600.10
DMIForventetIndbetalingÆ
ndr
DMDMIIDD.600.11
DMIForventetIndbetalingAn
nuller
DMDMIIDD.810.08
DMIValutaKursBeregn
DMDMIIDD.810.09
DMIValutaKurserOverfør
DMDMIIDD.810.20
FinansKontoBilagOpret
DMDMIIDD.820.01
DMIKontoIndbetalingSynkr
onOpret
DMDMIIDD.820.02
DMIKontoIndbetalingListeO
pret
DMDMIIDD.820.03
DMIIndbetalingList
DMI
13
0
No
DMI
13
0
No
DMI
11
0
No
DMI
13
0
No
DMI
13
0
No
DMI
DMI
13
13
0
0
No
No
DMI
DMI
DMI
13
12
10
0
0
0
No
No
No
DMI
DMI
12
13
0
0
No
No
DMI
12
0
No
DMI
13
0
No
DMI
13
0
No
DMI
DMI
DMI
DMI
13
10
10
13
0
0
0
0
No
No
No
No
DMI
13
0
No
DMI
13
0
No
64 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0066.png
DATE: 24.09.2015
Database data
Model
DMDMIIDD.820.04
DMIIndbetalingOplysningLi
steModtag
DMDMIIDD.820.05
DMIKontoudtogOplysningLi
steModtag
DMDMIIDD.820.06
EFIIndbetalingModtaget
DMDMIIDD.820.07
DMIIndbetalingskortStatus
Modtag
DMDMIIDD.830 01
DMIKontoUdbetalingOpret
DMDMIIDD.830 02
DMIKontoUdbetalingAfgør
DMDMIIDD.830.03
DMIUdbetalingList
DMDMIIDD.830.04
DMIBetalingsanmodninger
TrækListeSend
DMDMIIDD.830.05
DMIBetalingsoplysningerTr
ækListeModtag
DMDMIIDD.830.06
DMICheckUdbetalingIkkeIn
dløstListeModtag
DMDMIIDD.830.07
DMICheckUdbetalingStatus
ListeModtag
DMDMIIDD.830.08
DMICheckUdbetalingListeS
end
DMDMIIDD.830.09
DMIUdbetalingOplysningLis
teModtag
DMDMIIDD.830.10
DMIBetalingTilAfmeldinger
TrækListeSend
DMIDD.000.12
DMProcesMonitor
Database Schema for EFI-
projektet_ EFI_OP_00
EFI core database DDL
ER diagram og Database
model for EFI Core
DB_OP_00
DM AI Platform LDM
Integration
DM AI Platform LDM
Logning
DM AI Platform LDM
Monitorering
DM AI Platform LDM SAP
ERP
DM AI Platform LDM SAP
PI
DMI
12
0
No
DMI
13
0
No
DMI
DMI
10
10
0
0
No
No
DMI
DMI
DMI
DMI
13
13
13
18
0
0
0
0
No
No
No
No
DMI
12
0
No
DMI
10
0
No
DMI
12
0
No
DMI
13
0
No
DMI
12
0
No
DMI
9
0
No
DMI
EFI
EFI
EFI
10
5
0
5
0
0
0
0
No
No
No
No
Data Model
(DM)
DMI
DMI
DMI
DMI
DMI
17
45
19
80
44
0
0
0
0
0
No
No
No
No
No
65 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0067.png
DATE: 24.09.2015
DM AI Platform LDM
Servicemønstre
DM AI Platform LDM
Sikkerhed
DM AI Platform LDM Use
case mønstre
DM AI Platform Overordnet
Systembeskrivelse
DM ARK - Kvalitetssikring
DM ARK Overordnet
Systembeskrivelse
DM ARK
Systemdokumentationsstru
ktur
DM DMI
Funktionalitetsgruppering
Rente 08 OKT 2012_v1.00
DM
DMI_FGD_Overfør_Regns
kabsdata_ til_SAP38_08
OKT 2012_v1
DM INFR PTM
DM IP v1.00
DM Logning v1.00
DM Monitorering v1.00
DM SAP and Database
Logging v1.0
DM SAP ERP
Configuration Guidelines
v1.10
DM SAP ERP Development
Guidelines v1.20
DM SAP ERP v1.20
DM SAP PI Development
Guidelines v1.10
DM SAP PI
Skemavalidering
Guidelines v.1.00
DM SAP PI v1.00
DM Sikkerhed v1.00
DM XpoLog
Logningsrapporter v1.0
DM_DMI_FGD_500.T01_Q
C10071_25.01.2015_v.1.20
DM_DMI_FGD_Tillæg_Te
mplate
DM_DMI_Funktionalitetsgr
uppering_Administration 08
OKT 2012_v1.0
DM_DMI_Funktionalitetsgr
uppering_Afregn_Fordrings
haver_ 08 OKT 2
DMI
DMI
DMI
DMI
DMI
DMI
DMI
105
69
28
19
12
34
31
0
0
0
0
0
0
0
No
No
No
No
No
No
No
DMI
28
0
No
DMI
18
0
No
DMI
DMI
DMI
DMI
DMI
DMI
58
15
35
23
23
13
0
0
0
0
0
0
No
No
No
No
No
No
DMI
DMI
DMI
DMI
40
26
44
10
0
0
0
0
No
No
No
No
DMI
DMI
DMI
DMI
DMI
DMI
14
31
30
9
7
33
0
0
0
0
0
0
No
No
No
No
No
No
DMI
20
0
No
66 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0068.png
DATE: 24.09.2015
DM_DMI_Funktionalitetsgr
uppering_Betalingsordning
_ 08 OKT 2012_v
DM_DMI_Funktionalitetsgr
uppering_Dækningsrækkef
ølge_08 OKT 2012
DM_DMI_Funktionalitetsgr
uppering_Fordringer_ 08
OKT 2012_v1.00.d
DM_DMI_Funktionalitetsgr
uppering_Fordringer_Afskri
v_ 08 OKT 2012
DM_DMI_Funktionalitetsgr
uppering_Fordringer_Neds
kriv_ 08 OKT 201
DM_DMI_Funktionalitetsgr
uppering_Fordringer_Opskr
iv_ 08 OKT 2012
DM_DMI_Funktionalitetsgr
uppering_Fordringer_Retur
ner_ 08 OKT 201
DM_DMI_Funktionalitetsgr
uppering_Fordringer_Tilbag
ekald_ 08 OKT
DM_DMI_Funktionalitetsgr
uppering_Hæftelse_ 08
OKT 2012_v1.0
DM_DMI_Funktionalitetsgr
uppering_Hæftelse_Foræld
else_08 OKT 2012
DM_DMI_Funktionalitetsgr
uppering_Indbetalinger_ 08
OKT 2012_v1.0
DM_DMI_Funktionalitetsgr
uppering_Modregning_ 08
OKT 2012_v1.00.d
DM_DMI_Funktionalitetsgr
uppering_Modregning_ 08
OKT 2012_v1.00
DM_DMI_Funktionalitetsgr
uppering_Omposteringer_
08 OKT 2012_v1.0
DM_DMI_Funktionalitetsgr
uppering_Processer _08
OKT 2012_ v1.00.d
DM_DMI_Funktionalitetsgr
uppering_Regnskab_13JU
N12_v1.00
DM_DMI_Funktionalitetsgr
uppering_Stamdata_ 08
OKT 2012_v1.00
DM_DMI_Funktionalitetsgr
uppering_Transporter_08
OKT 2012_v1.00.d
DM_DMI_Notifications_Des
ign describtion
DMI
31
0
Yes
DMI
83
0
No
DMI
21
0
No
DMI
20
0
No
DMI
19
0
No
DMI
16
0
No
DMI
16
0
No
DMI
18
0
No
DMI
30
0
No
DMI
34
0
No
DMI
28
0
Yes
DMI
36
0
No
DMI
36
0
No
DMI
24
0
No
DMI
45
0
No
DMI
49
0
No
DMI
25
0
No
DMI
18
0
No
DMI
5
0
No
67 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0069.png
DATE: 24.09.2015
Datamodel
(ER)
DM_DMI_Overordnet_syst
embeskrivelse_v1_1
DM_DMI_Processdocumen
t_Notifications
DMDMI - Overordnet
datamodel på
begrebsniveau v1.30
DMDMI - Plan - DMI
documentation test v1 1
BEBB
DP
EFI
EFITXT
ETIL
IA
IM
IP
KFI
MF
AA
Bilag 2 Beregningsregelsæt
v2.1
Automatisk afskrivning af
fordringer V1.0
Copy from
DM_DMI_FGD_Tillæg_Te
mplate
DBM CMA Repositories
Debitormotor Configuration
Management responsible
v1.1_05032014
Documentation Update
Filstruktur i SAP ERP
Interface overblik - DMI
v100
Java Mapping General
Documentation
Processér udgående
betaling V1.0
SAP Stnd_Payment Run
Claimants V1.0
SAP Stnd_Payment Run
V1.0
Servicekald af
MFFordringAfskrivUnderret
V1.0
Sizing af DMI Services
EFI Data Warehouse
Systemdokumentation_v1.0
Systemdokumentation for
Pilotspor v1.0
DMI
DMI
DMI
75
5
755
0
0
0
No
No
No
DMI
EFI
EFI
EFI
EFI
EFI
EFI
EFI
EFI
EFI
EFI
EFI
EFI
DMI
DMI
0
0
0
0
0
0
0
0
0
0
0
0
3
7
0
0
0
0
0
0
0
0
0
0
0
0
0
0
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Other
DMI
DMI
13
1
0
0
No
No
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
8
3
3
3
3
0
0
0
0
0
2
0
No
No
No
No
No
No
No
No
DMI
EFI DW
EFI DW
49
9
0
0
No
No
No
68 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0070.png
DATE: 24.09.2015
Systemdokumentation for
Upscoringskomponenten
EFI Hændelse abonnent
EFI Hændelser producent
EFI Udstillede webservices
med dialoger og
komponenter der kalder
dem
Eksterne services med
dialoger og komponenter
der kalder dem
EFI DW
EFI
EFI
EFI
31
0
0
0
0
0
0
0
No
No
No
No
EFI
0
0
No
Table 5 Documentation Listing
69 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0071.png
DATE: 24.09.2015
10 Appendix - Service Mapping and Review
The following section provides tables, which list the functionality and EFI services that
Accenture has found within each functional area. The tables also indicates which services
have been reviewed, which ones Accenture found issues in and for some of these
Accenture has also provided high-level review comments. As mentioned in the
methodology section of this document, the gaps highlight the areas where Accenture
found issues or capability gaps based on our assessment of the functionality.
The purpose of this section is to provide traceability in terms of what Accenture were
provided with and what Accenture actually reviewed.
10.1 Claim Management Functional Review and Service Mapping
Functionality
FCT061 - Return
claim
FCT062 - Recall
claim
FCT068 -
Correction of claim
FCT078 - Get claim
type
FCT080 - Create
claim
Service
SVC045 - DMIFordringReturner
SVC246 – MFFordringReturner
SVC046 - DMIFordringTilbagekald
SVC247 – MFFordringTilbagekald
SVC209 - KFIFordringMultiÆndr
SVC098 - MFFordringTypeHent
Reviewed
Yes
Gap
Yes
Comments
Refer to handling of sub
claims if main claims are
returned.
Refer to handling of sub
claims if main claims are
returned.
Treatments do not react to
changes
Lots of claims with no
categorisation or grouping
that enables re-use.
Yes
Yes
Yes
Yes
Yes
Yes
FCT120 - Update
expiration date
SVC019 - DMIFordringAsynkronOpret
SVC027 - DMIFordringSynkronOpret
SVC208 - KFIFordringMultiOpret
SVC244 - MFFordringOpret
SVC354 - FordringOpretService
SVC358 -
FordringAsynkronOpretCallbackServiceI
mpl
SVC359 -
FordringAsynkronOpretService
SVC361 - KFIFordringMultiOpretService
SVC368 -
FordringAsynkronOpretCallbackXmlServ
iceImpl
SVC369 -
DMIFordringAsynkronOpretXmlService
SVC370 -
KFIFordringMultiOpretXmlService
SVC034 - DMIHæftelseForældelseÆndr
Yes
None
Yes
None
FCT161 - Validate
claim
FCT172 – Get
(view) claims
SVC355 - FordringValiderService
Yes
Yes
SVC356 - DMIFordringHentService
SVC366 - DMIFordringHentXmlService
SVC042 - DMIFordringHent
SVC207 - KFIFordringHent
Yes
None
Traceability for change in
expiration date and
reasoning? Available in
DMI.
Very little validation
applied to claims that are
received or altered.
Claim is accessed through
multiple entry points.
70 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0072.png
DATE: 24.09.2015
SVC375 - HentFordringer
FCT206 - Get claim
list
FCT219 - Write
down claim
SVC026 - DMIFordringList
SVC043 - DMIFordringNedskriv
SVC240 - MFFordringNedskriv
Yes
Yes
None
Yes
Complex, multiple
services to perform
updates to claims
instead of one.
Treatments do not
react to changes to
claims.
Complex, multiple
services to perform
updates to claims
instead of one.
Treatments do not
react to changes to
claims.
Complex, multiple
services to perform
updates to claims
instead of one source.
Treatments do not
react to changes to
claims.
FCT220 - Write up
claim
SVC044 - DMIFordringOpskriv
SVC245 - MFFordringOpskriv
Yes
Yes
FCT221 - Change
claim
SVC047 - DMIFordringÆndr
SVC209 - KFIFordringMultiÆndr
SVC249 - MFFordringÆndr
Yes
Yes
FCT223 - Get
liabilities expiring
claim list
FCT259 - Claim
created
FCT260 - Claim
amount changed
FCT266 - Get claim
notification
collection
FCT267 - Get claim
receipt
FCT352 - Order
claim overview
FCT360 - List
customer claims
FCT362 - List
customers claim
types
FCT373 -
Regulated claim
FCT374 - Receive
claim
SVC049 - DMIHæftelseForældelseList
No
SVC090 - EFIFordringOprettet
SVC096 - MFFordringAsynkronOprettet
SVC091 – EFIFordringSaldoÆndret
SVC099 - MFUnderretSamlingHent
SVC100 – MFKvitteringHent
SVC210 -
KFIFordringRestanceOverblikBestil
SVC219 - KFIKundeFordringList
SVC221 -
KFIKundeIndsatsTypeFordringList
SVC237 -
MFFordringAsynkronReguleret
SVC239 - MFFordringModtag
No
No
No
No
No
No
No
No
Yes
Yes
Error handling - if a claim
has been received but
fails to create in DMI there
is no information sent
back to EFI and no
reconciliation or checks
regarding this.
Error handling - if a claim
is received but fails to be
submitted in DMI there is
no information sent back
to EFI and no
FCT467 - Submit
claim
SVC097 - MFFordringIndberet
SVC350 - FordringIndberetXmlService
SVC351 - FordringIndberetService
Yes
Yes
71 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0073.png
DATE: 24.09.2015
reconciliation or checks
regarding this.
Table 6 Claim Management Functional Review and Service Mapping
10.2 Account Management Functional Review and Service Mapping
Sub Area
N/A
Functionality
FCT196 - Get pay-out
(BFY)
FCT207 - Create
expected payment
FCT208 - Cancel
expected payment
FCT209 - Get payment
list
FCT212 - Get account
specification
FCT213 - Create
payment list
FCT214 - Create
payment
FCT217 - Change
account
FCT222 - Get
expected payment list
FCT229 - Calculate
currency exchange
Service
SVC010 - BFYUdbetalingHent
Review
ed
No
Gap
Comment
s
No
SVC028 - DMIForventetIndbetalingOpret
SVC114 - DOForventetIndbetalingOpret
SVC029 –
No
DMIForventetIndbetalingAnnuller
SVC030 – DMIIndbetalingList
No
SVC033 -
DMIKontoSpecifikationHent
SVC035 -
DMIKontoIndbetalingListeOpret
SVC036 -
DMIKontoIndbetalingSynkronOpret
SVC039 - DMIKontoÆndr
SVC048 -
DMIForventetIndbetalingList
SVC055 – DMIValutaKursBeregn
No
No
No
No
No
No
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI
DMI, only
supports
DKK
currency.
FCT277 - Change
account payment
allocation
FCT279 - Change
account stop
Receive Salary
Deduction
SVC116 –
DOKontoIndbetalingFordelingÆndr
SVC117 – DOKontoStopÆndr
No
No
No
Yes
Currently
salary
deduction
amounts
are
checked
manually
and then
released
into the
system,
as there
are no
duplicate
checks to
prevent
double
deduction
72 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0074.png
DATE: 24.09.2015
Payment
Processing
FCT227 - Calculate
interest tax deduction
FCT228 - Give tax
deduction of interest
FCT215 - Decide pay-
out
FCT216 - Create pay-
out
FCT218 - Get pay-out
list
FCT270 - Report
compensation
settlement
FCT280 - Decide
account for pay-out
FCT281 - Create
account for pay-out
FCT281 - Create
account for pay-out
FCT210 - Calculate
payment allocation
FCT211 - Change
payment allocation
FCT303 - Get card
payment receipt
FCT304 - Create card
payment
FCT205 - Write off
claim
SVC053 –
No
DMIRentegodtgørelseBeregn
No
SVC054 - DMIRenteGodtgørelseTilskriv
SVC120 - DORenteGodtgørelseTilskriv
SVC037 – DMIKontoUdbetalingAfgør No
SVC038 – DMIKontoUdbetalingOpret
SVC040 – DMIUdbetalingList
SVC103 -
MFUdligningAfregningUnderret
SVC118 – DOKontoUdbetalingAfgør
SVC119 – DOKontoUdbetalingOpret
SVC119 – DOKontoUdbetalingOpret
SVC031 -
DMIKontoIndbetalingFordelingBereg
n
SVC032 -
DMIKontoIndbetalingFordelingÆndr
SVC151 - EFIKortBetalingKvittering
SVC152 – EFIKortBetalingOpret
SVC025 - DMIFordringAfskriv
SVC234 - MFFordringAfskriv
No
No
No
s being
applied.
DMI
DMI
No
No
No
No
DMI
No
No
No
No
Yes
DMI
Offsetting
Known
defect -
not
handling
sub
claims.
FCT225 - Get liabilities
to write off
FCT286 - Receive
liability relation for
write off
FCT332 - Write off on
treatment
påskravskrivelse?
SVC051 –
DMIHæftelsesforholdTilAfskrivningM
odtag
SVC128 -
DWHæftelsesforholdTilAfskrivningMu
ltiModtag
SVC182 –
IAIndsatsPåkravsSkrivelseAkterAfskr
iv
No
DMI
No
No
Table 7 Account Management Functional Review and Service Mapping
73 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0075.png
DATE: 24.09.2015
10.3 Compliance and Treatment Functional Review and Service Mapping
Sub Area
N/A
Functionality
FCT038 - Start
treatment Payment
Plan
Service
SVC184 – IAIndsatsStart
Reviewed
Yes
Gap
None
Comments
Manually started
by a list being
entered in
system, then
treatments are
created. If this
was automated
again it would be
unable to check
or understand
claims it should
skip or not add to
treatments.
FCT346 - Perform
activity
FCT039 - Start
treatment Salary
Deduction
SVC201 – IAAktivitetUdfør
SVC184 – IAIndsatsStart
Yes
Yes
None
Manually started
by a list being
entered in
system, then
treatments are
created. If this
was automated
again it would be
unable to check
or understand
claims it should
skip or not add to
treatments.
Only occurs
when the last
deduction is
received by
DMI. If no last
deduction is
received and
the payment is
not zero, the
salary
deduction is
not ended.
Salary
deduction
checks are
only triggered
when a
deduction is
received by
DMI – when a
deduction is
not received
no notification
is created to
tell a
caseworker to
FCT042 - End
treatment Salary
Deduction
SVC190 –
IMHændelseModtag
Yes
Yes
74 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0076.png
DATE: 24.09.2015
FCT043 - Start
treatment Asset
Repossession
SVC184 - IAIndsatsStart
Yes
None
look at missed
deductions.
Manually started
by a list being
entered in the
system, then
treatments are
created. If this
was automated
again it would be
unable to check
or understand
claims it should
skip or not add to
treatments.
FCT057 - Get payment
ability
FCT102 - Update
payment ability
FCT149 - Start
treatment
FCT175 - Start
treatment parameter
SVC041 - DMIBetalingEvneHentet
No
SVC081 - EFIBetalingEvneAsynkronHent
SVC085 - EFIBetalingEvneHent
SVC087 –
None
EFIBetalingEvneÆndr
SVC184 – IAIndsatsStart
Yes
None
SVC380 –
createIndsatsParametreP
aaIndsatsId
All treatments are
manually started
by a list being
entered in
system, then
treatments are
created. If this
was automated
again it would be
unable to check
or understand
claims it should
skip or not add to
treatments.
FCT180 - Delete event
FCT181 - Create
future event
FCT183 - Create audit
trail
FCT184 - Audit trail
budget
correspondence
FCT185 - Receive
event
SVC191 - IMHændelseSlet Yes
SVC377 - SletHaendelse
SVC378 - OpretFremtidigHaendelse
Yes
SVC391 - HHFremtidigHaendelseOpret
None
None
SVC381 –
Yes
Yes
genererAkteringNote
SVC080 - DPMeddelelseSendAkter
Not
Reviewed
SVC382 - ekspressMeddelelseSendAkter
SVC105 - IMMultiHændelseModtag
Yes
SVC190 - IMHændelseModtag
SVC388 - HaendelseModtag
Yes
Events are used
to perform actions
in the system,
currently a
number of them
are turned-off to
prevent them
behaving in an
unexpected
manner and to
introduce errors
into the data and
mistreat debtors.
75 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0077.png
DATE: 24.09.2015
FCT230 - Get
eSkattekort
FCT231 - Get income
information
FCT246 - Get net
income calculation
FCT253 - Receive
payment ability BFY
FCT254 - Receive
payment ability
property/residence
FCT255 - Recalculate
payment ability parent
dependent
(forsørgerpligt)
FCT256 - Receive
payment ability vehicle
FCT257 - Receive
change in net income
FCT289 - Get payment
ability from budget
FCT290 - Send
payment ability from
budget
FCT291 - Change
payment ability from
budget
FCT292 - Simulate
salary from payment
ability
FCT293 - List payment
ability for net income
SVC056 –
eSkattekortHent
SVC057 -
IndkomstOplysningKlassis
kAbonnentHent
SVC072 –
NIBNettoIndkomstBeregni
ngHent
SVC082 –
EFIBetalingEvneBFYModt
ag
SVC083 –
EFIBetalingEvneEjendom
Modtag
SVC084 –
EFIBetalingEvneForsørge
rpligtGenberegn
SVC086 –
EFIBetalingEvneKøretøjM
odtag
SVC088 -
EFINettoIndkomstÆndring
HændelseModtag
SVC132 –
EFIBetalingEvneBudgetH
ent
SVC133 –
EFIBetalingEvneBudgetS
end
SVC134 -
EFIBetalingEvneBudgetÆ
ndr
SVC138 –
EFIBetalingEvneLønSimul
er
SVC139 -
EFIBetalingEvneNettoIndk
omstList
SVC140 –
EFIBetalingEvneNettoIndk
omstÆndr
SVC165 –
IAIndsatsBetalingOrdning
Hent
SVC167 –
IAIndsatsBobehandlingHe
nt
SVC172 –
IAIndsatsHenstandHent
SVC173 –
IAIndsatsKreditOplysnings
BureauHent
SVC174 –
IAIndsatsKundeMødeHent
No
No
No
Not
Reviewed
Not
Reviewed
Not
Reviewed
Not
Reviewed
Not
Reviewed
Not
Reviewed
Not
Reviewed
Not
Reviewed
Not
Reviewed
Not
Reviewed
Assumption Gap?
FCT294 - Change
payment ability for net
income
FCT315 - Get
treatment payment
plan
FCT317 - Get
treatment insolvency
FCT322 - Get
treatment grace
FCT323 - Get
treatment credit
bureau information
FCT324 - Get
treatment customer
meeting
Not
Reviewed
Yes
None
Not
Reviewed
Not
Reviewed
No
Yes
Functionality does
not work.
Does not work in
resource manager
No
Yes
76 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0078.png
DATE: 24.09.2015
FCT325 - Get
treatment salary
deduction
FCT326 - Get
treatment manual case
work
FCT327 - Get
treatment parameters
FCT328 - Save
treatment parameter
on treatment
FCT329 - Get
treatment parameter
on treatment
FCT330 - Save
treatment parameter
on treatment type on
track type
FCT331 - Get
treatment parameter
on treatment type on
track type
FCT333 - Get
treatment
påkravskrivelse
FCT334 - List
treatment type
FCT335 - Get
treatment type
FCT336 - Get
treatment asset
repossession
FCT338 - Get track
overview
FCT340 - Save track
SVC175 –
IAIndsatsLønindeholdelse
Hent
SVC176 –
IAIndsatsManuelSagsbeh
andlingHent
SVC177 -
IAIndsatsParametreHent
SVC178 –
IAIndsatsParametrePåInd
satsGem
SVC179 –
IAIndsatsParametrePåInd
satsHent
SVC180 -
IAIndsatsParametrePåInd
satsTypePåSporTypeGem
SVC181 -
IAIndsatsParametrePåInd
satsTypePåSporTypeHent
SVC183 -
IAIndsatsPåkravsSkrivels
eHent
SVC185 –
IAIndsatsTypeList
SVC186 –
IAIndsatsTypeMultiHent
SVC187 –
IAIndsatsUdlægHent
SVC189 –
IASporOverblikHent
SVC195 – IMSporGem
Yes
None
No
No
No
No
No
No
No
Yes
Yes
No
None
None
Yes
Yes
None
Yes
Complex and too
many variations.
No duplicate
handling.
Complex and too
many variations.
No duplicate
handling.
FCT341 - Get track
FCT342 - Save track
template
SVC196 – IMSporHent
SVC197 –
IMSporSkabelonGem
Yes
Yes
None
Yes
FCT343 - Get track
template
FCT344 - List track
template
FCT345 - Delete track
template
FCT347 - List asset
(aktiv)
FCT348 - Create asset
(aktiv)
FCT349 - Delete asset
(aktiv)
SVC198 -
IMSporSkabelonHent
SVC199 –
IMSporSkabelonList
SVC200 –
IMSporSkabelonSlet
SVC202 – KFIAktivList
SVC203 – KFIAktivOpret
SVC204 – KFIAktivSlet
Yes
None
Yes
No
No
No
No
None
77 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0079.png
DATE: 24.09.2015
FCT350 - Change
asset (aktiv)
FCT351 - Change
automatic track
change
FCT353 - Remove
treatment asset (aktiv)
FCT354 - Add
treatment asset (aktiv)
FCT355 - Remove
claim on treatment
FCT356 - Add claim to
treatment
SVC205 – KFIAktivÆndr
SVC206 –
KFIAutomatiskSporskifte
Ændr
SVC211 –
KFIIndsatsAktivFjern
SVC212 -
KFIIndsatsAktivTilføj
SVC213 -
KFIIndsatsFordringFjern
SVC214 -
KFIIndsatsFordringTilføj
No
No
No
No
No
Yes
Yes
Not possible to
add claim to
treatment, without
restarting the
treatment or
manual
intervention.
FCT357 - List
treatment
FCT358 - Get
treatment state
FCT361 - List
customers treatment
FCT368 - List track
treatments
FCT471 - Create event
SVC215 – KFIIndsatsList
SVC216 –
KFIIndsatsTilstandHent
SVC220 –
KFIKundeIndsatsFordring
List
SVC228 -
KFISporIndsatsTypeList
SVC383 –
OpretHaendelse
Yes
Yes
Yes
None
None
None
Yes
Yes
None
Yes
System is
generating a lot of
events.
FCT472 - Change
future event
FCT473 - Delete future
event
FCT474 - Event
FCT475 - Publish
current event
FCT046 – Get
payment ability from
external systems
Acknowledge
ment of Debt
FCT316 - Get
treatment payment
dunning
FCT037 - Start
treatment
Acknowledgement of
Debt
FCT168 - Create
acknowledgement of
debt letter
FCT170 - Send
acknowledgement of
debt letter
SVC385 - EFIFremtidigHaendelseAendr
No
SVC390 - HHFremtidigHaendelseAendr
SVC386 - EFIFremtidigHaendelseSlet
No
SVC392 - HHFremtidigHaendelseSlet
SVC387 – Haendelse
No
SVC389 –
No
HHAktuelHaendelsePublic
er
SVC 057 –
No
IndkomstOplysningKlassis
kAbonnementHent
SVC 056 –
eSkattekortHent
SVC166 -
No
IAIndsatsBetalingsRykker
Hent
SVC184 – IAIndsatsStart
Yes
None
No
SVC011 - DokumentMultiOpret
SVC079 - DPDokumentOpret
No
SVC002 - MeddelelseMultiSend
SVC004 - MeddelelseMultiSendEkspres
78 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0080.png
DATE: 24.09.2015
FCT321 - Get
treatment
acknowledgement of
debt
FCT296 -
Acknowledge debt
Salary
Deduction
FCT092 - Create
salary deduction
notification
FCT097 - Decrease
deduction percentage
FCT098 - Increase
deduction percentage
FCT099 - Create
salary deduction
decision letter
FCT103 - Register
salary deduction
interruption of aging
FCT232 - Update
salary deduction
information
FCT173 - Create
payment plan
SVC171 –
IAIndsatsErkendFordringH
ent
Yes
None
SVC143 –
Yes
EFIErkendFordringerKund
e
No
SVC079 - DPDokumentOpret
SVC011 – DokumentMultiOpret
SVC087 -
No
EFIBetalingEvneÆndr
SVC087 -
No
EFIBetalingEvneÆndr
No
SVC079 - DPDokumentOpret
SVC011 - DokumentMultiOpret
SVC034 -
DMIHæftelseForældelse
Ændr
SVC058 -
LønIndeholdelseAjourfør
SVC023 -
DMIBetalingOrdningOpret
SVC141 -
EFIBetalingordningOpretK
unde
SVC022 –
DMIBetalingOrdningHent
SVC021 -
DMIBetalingOrdningForsla
gBeregn
SVC374 -
DMIBetalingOrdningForsla
gTilBetalingsOrdningBere
gn
SVC089 –
EFIBetalingOrdningMislig
holdt
No
Yes
Expiry date is
changed
manually.
No
Payment Plan
Yes
None
FCT176 - Get payment
plan
FCT177 - Calculate
proposed payment
plan
Yes
Yes
None
FCT258 - Payment
plan mistreated
Yes
Yes
Internal service to
be called when
the payment plan
treatment has to
detect that it is
mistreated. It
raises an internal
event to stop the
payment plan if
no payments
have been
received within a
given timeframe.
FCT272 - Get payment
plan list
Change payment plan
SVC110 –
DMIBetalingOrdningList
Yes
Yes
None
Yes
It is possible to
change the
payment amount
in the payment
plan while the
79 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0081.png
DATE: 24.09.2015
payment plan is
active. Currently
the automation of
this functionality
has been disabled
due to the
consequences of
activation.
Table 8 Compliance and Treatment Functional Review and Service Mapping
10.4 Insolvency Functional Review and Service Mapping
Functionality
FCT318 - Create insolvency
treatment contact
FCT319 - Delete insolvency
treatment contact
FCT337 - Calculate court fee
Service
SVC168 –
IAIndsatsBobehandlingKontakt
Opret
SVC169 –
IAIndsatsBobehandlingKontakt
Slet
SVC188 - IARetsafgiftBeregn
Reviewed
No
Gap
Comments
No
No
Table 9 12.4 Insolvency Functional Review and Service Mapping
10.5 Court Interactions, Reporting & Registrations Functional Review and
Service Mapping
Functionality
FCT244 - Create credit
bureau information on
debtor
FCT245 - Delete credit
bureau information on
debtor
FCT269 - Report interests
credit (tilskrivning)
Service
SVC070 –
KreditoplysningBureauDebitor
Opret
SVC071 –
KreditoplysningBureauDebitor
Slet
SVC102 –
MFRenteTilskrivningUnderret
Reviewed
No
Gap
Comments
No
No
Table 10 Court Interactions, Reporting & Registrations Functional Review and Service Mapping
10.6 Case Management Functional Review and Service Mapping
Functionality
FCT179 - Case worker
receive event
FCT198 - Create case
Service
SVC193 -
IMSagsbehandlerHændelseMo
dtag
SVC013 – SagOpret
Reviewed
No
Gap
Comments
No
Table 11 Case Management Functional Review and Service Mapping
80 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0082.png
DATE: 24.09.2015
10.7 Work Management (Resource Manager) Functional Review and Service
Mapping
Functionality
FCT186 - Delete task
Service
SVC306 - RSOpgaveSlet
SVC384 - sletOpgaver
Reviewed
No
Gap
Comments
Deletes a specific
task in RS. This
functionality is often
used for error
handling in
treatments to
reverse bookings or
remove bookings in
the future as that
booking is not used
anymore.
Books a task as
FCT271.
Books a specific
task in the future in
RS. This
functionality is often
used when booking
a caseworker to
handle tasks
around treatments.
FCT187 - Book resource
FCT271 - Book task
SVC264 – RSEFIOpgaveBook
SVC104 –
RSOpgaveAsynkronBook
No
No
FCT310 - Receive event
create task
FCT339 - Sub process
caseworker event
FCT375 - Close claim task
FCT376 - Get claim task
FCT379 - Save receiver
alarm
FCT380 - List receiver alarm
FCT381 - Search receiver
alarm
FCT382 - Search alarm
types
FCT383 - Save equipment
booking
FCT384 - Find available
resources
FCT385 - Book progress
FCT386 - Create task
SVC160 –
EFIOpgaveOpretHændelseMo
dtag
SVC194 –
IMSagsbehandlerHændelseUn
derproces
SVC242 –
MFFordringOpgaveAfslut
SVC243 –
MFFordringOpgaveHent
SVC257 –
RSAlarmModtagerGem
SVC258 –
RSAlarmModtagerList
SVC259 –
RSAlarmModtagerSøg
SVC260 – RSAlarmTypeSøg
SVC261 – RSBookUdstyrGem
SVC262 -
RSEFIFindLedigeRessourcer
SVC263 - RSEFIForløbBook
SVC265 - RSEFIOpgaveOpret
No
No
No
No
No
No
No
No
No
No
No
No
No EFI integration
detected.
No EFI integration
detected.
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
This functionality is
used to book tasks
for a caseworker in
EFI.
This functionality is
used to change the
information for the
FCT387 - Change task
SVC266 - RSEFIOpgaveÆndr
SVC313 - RSOpgaveÆndr
No
81 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0083.png
DATE: 24.09.2015
FCT388 - Find booking for
rebooking
(FindAftalerTilOmbooking)
FCT389 - Save deselected
zip code
FCT390 - List deselected zip
code
FCT391 - Create absence
FCT392 - Search absence
FCT393 - Change absence
FCT394 - Save calendar day
FCT395 - Search calendrer
day
FCT396 - Get calendar day
FCT397 - Save calendar
preferences task type
)KalenderPræfernceOppgav
etypeSave
FCT398 - Change calendar
FCT399 - Save municipal
number zip code
FCT400 - Search municipal
number zip code
FCT401 - Save
transportation time
FCT402 - Save colleague
work location
FCT403 - List colleague
work location
FCT404 - Save colleague
skill set
FCT405 - List colleague skill
set
FCT406 - List colleague
organization unit and work
location
FCT407 - Get colleague
profile
FCT408 - Change colleague
profile
FCT409 - Change meeting
time lunch time
SVC267 -
RSFindAftalerTilOmbooking
SVC268 -
RSFravalgtPostnummerGem
SVC269 –
RSFravalgtPostnummerList
SVC270 - RSFraværOpret
SVC272 - RSFraværSøg
SVC273 - RSFraværÆndr
SVC274 –
RSKalenderDagGem
SVC275 - RSKalenderDagSøg
SVC276 - RSKalenderHent
SVC277 –
RSKalenderPræferenceOpgav
etypeGem
SVC278 - RSKalenderÆndr
SVC279 –
RSKommuneNummerPostNu
mmerGem
SVC280 –
RSKommuneNummerPostNu
mmerSøg
SVC281 - RSKørselstidGem
SVC282 –
RSMedarbejderArbejdsstedGe
m
SVC283 –
RSMedarbejderArbejdsstedLis
t
SVC284 –
RSMedarbejderKompetenceG
em
SVC285 –
RSMedarbejderKompetenceLi
st
SVC286 –
RSMedarbejderOrgEnhedArbe
jdsstedList
SVC287 -
RSMedarbejderprofilHent
SVC288 -
RSMedarbejderprofilÆndr
SVC289 -
RSMødetidFrokosttidÆndr
No
booked task for a
caseworker in EFI.
No EFI integration
detected.
No EFI integration
detected.
No EFI integration
detected.
No EFI integration
detected.
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No
No
No
No
No
No
No
No
No
No
No
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No
No
No
No
No
No
No
No
No
No
82 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0084.png
DATE: 24.09.2015
FCT410 - Reject task
FCT411 - Rebook task
FCT412 - Get task
SVC290 - RSOpgaveAfvis
SVC292 - RSOpgaveGenbook
SVC293 – RSOpgaveHent
No
No
No
FCT413 - Save task queue
alarm type
FCT414 - Save task queue
booking rule
FCT415 - Get task queue
details
FCT416 - Get task queue
FCT417 - Save task queue
skill set
FCT418 - Save task queue
task type
FCT419 - Create task queue
FCT420 - Save task queue
production leader
FCT421 - Delete task queue
FCT422 - Search task queue
FCT423 - Change task
queue
FCT424 - List tasks
FCT425 - Search task
FCT426 - Get task type
FCT427 - Create task type
FCT428 - Delete task type
FCT429 - Search task type
FCT430 - Change task type
FCT431 - Save configuration
FCT432 - Get configuration
FCT433 - Save organization
unit alarm type
FCT434 - Get organization
unit
FCT435 - Save organization
unit task queue
SVC294 -
RSOpgavekøAlarmtypeGem
SVC295 –
RSOpgavekøBookingRegelGe
m
SVC296 –
RSOpgavekøDetaljerHent
SVC297 - RSOpgavekøHent
SVC298 -
RSOpgavekøKompetenceGem
SVC299 -
RSOpgavekøOpgavetypeGem
SVC300 - RSOpgavekøOpret
SVC301 -
RSOpgavekøProdLederGem
SVC302 - RSOpgavekøSlet
SVC303 - RSOpgavekøSøg
SVC304 - RSOpgavekøÆndr
SVC305 - RSOpgaveList
SVC307 – RSOpgaveSøg
SVC308 - RSOpgavetypeHent
SVC309 –
RSOpgavetypeOpret
SVC310 - RSOpgavetypeSlet
SVC311 - RSOpgavetypeSøg
SVC312 –
RSOpgavetypeÆndr
SVC314 - RSOpsætningGem
SVC315 - RSOpsætningHent
SVC316 –
RSOrganisatoriskEnhedAlarmt
ypeGem
SVC317 -
RSOrganisatoriskEnhedHent
SVC318 –
RSOrganisatoriskEnhedOpgav
ekøGem
No
No
No EFI integration
detected
No EFI integration
detected
At different points in
the execution of a
treatment the task
is received.
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected.
No EFI integration
detected.
No EFI integration
detected.
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
83 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0085.png
DATE: 24.09.2015
FCT436 - Create
organization unit
FCT437 - Save organization
unit production lead
FCT438 - Save organization
unit resource
FCT439 - Delete
organization unit
FCT440 - Change
organization unit
FCT441 - Get point usage
(Anvendelse)
FCT442 - Save preference
FCT443 - Save geography
preference slot
FCT444 - Get resource
group
FCT445 - Create resource
group
FCT446 - Delete resource
group
FCT447 - Search resource
group
FCT448 - Change resource
group
FCT449 - Get resource
FCT450 - Save resource
requirement
FCT451 - Get resource with
available time
FCT452 - Search
organization unit
FCT453 - Create resource
FCT454 - Delete resource
FCT455 - Search resource
FCT456 - Change resource
FCT457 - Save slot
FCT458 - List slot
FCT459 - Save chosen task
type
FCT460 - Validate plucking
SVC319 -
RSOrganisatoriskEnhedOpret
SVC320 –
RSOrganisatoriskEnhedProdL
ederGem
SVC321 –
RSOrganisatoriskEnhedResso
urceGem
SVC322 -
RSOrganisatoriskEnhedSlet
SVC324 -
RSOrganisatoriskEnhedÆndr
SVC325 -
RSPointAnvendelseHent
SVC326 - RSPræferenceGem
SVC327 -
RSPræferenceslotGeografiGe
m
SVC328 –
RSRessourcegruppeHent
SVC329 -
RSRessourcegruppeOpret
SVC330 -
RSRessourcegruppeSlet
SVC331 -
RSRessourcegruppeSøg
SVC332 -
RSRessourcegruppeÆndr No
SVC333 – RSRessourceHent
SVC334 -
RSRessourcekravGem
SVC335 -
RSRessourceLedigTidHent
SVC323 -
RSOrganisatoriskEnhedSøg
SVC336 - RSRessourceOpret
SVC337 - RSRessourceSlet
SVC338 - RSRessourceSøg
SVC339 - RSRessourceÆndr
SVC340 - RSSlotGem
SVC341 - RSSlotList
SVC342 -
RSValgtOpgavetypeGem
SVC343 - RSValiderPlukning
No
No
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected.
No EFI integration
detected.
No EFI integration
detected
No EFI in.tegration
detected.
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No EFI integration
detected
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Table 12 Work Management (Resource Manager) Functional Review and Service Mapping
84 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0086.png
DATE: 24.09.2015
10.8 Business Rule Functional Review and Service Mapping
Functionality
FCT126 - Create
business rule
Service
SVC154 – EFIMatriceGem
Reviewed
Yes
Gap
Yes
Comments
Possible to create
and manage
business rules
without restrictions.
Excessive use of
configuration in
system. One service
for all types of rules
with little traceability
on why rules are set.
Possible to create
and manage legal
rules without
restrictions.
Excessive use of
configuration in
system. One service
for all types of rules
with little traceability
on why rules are set.
Possible to create
and manage legal
rules without
restrictions.
Excessive use of
configuration in
system. One service
for all types of rules
with little traceability
on why rules are set.
FCT129 - Create legal
rule
SVC154 – EFIMatriceGem
Yes
Yes
FCT131 - Create
administration rule
SVC154 – EFIMatriceGem
Yes
Yes
FCT306 - Get matrix
FCT307 - List matrix
FCT308 - Lookup matrix
FCT311 - Save parameter
table
FCT312 - Get parameter
table
SVC155 - EFIMatriceHent
SVC156 - EFIMatriceList
SVC157 - EFIMatriceOpslag
SVC161 - EFIParamTabelGem
SVC162 - EFIParamTabelHent
No
No
No
No
No
Table 13 Business Rule Functional Review and Service Mapping
10.9 Document Management Functional Review and Service Mapping
Functionality
FCT178 - Create
document
FCT197 - Update
document
FCT199 - Get document
FCT282 - Search
document
Service
SVC011 - DokumentMultiOpret
SVC079 - DPDokumentOpret
SVC012 - DokumentOpdater
SVC124 - DPDokumentÆndr
SVC014 - DokumentHent
SVC121 - DPDokumentHent
SVC123 – DPDokumentSøg
Reviewed
No
No
No
No
Gap
Comments
85 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0087.png
DATE: 24.09.2015
FCT284 - Get document
journal number
FCT285 - Create
temporary document
FCT288 - Collect
container of notes
(AkterinNoteSamlingCont
ainer)
FCT295 - Receive
document metadata
SVC125 – DPJournalNummerHent
No
No
SVC127 - DPTemporærtDokumentMultiOpret
SVC367 - DPTemporaertDokumentMultiOpretXmlService
SVC373 - DPTemporaertDokumentMultiOpret
SVC130 –
No
EFIAkteringNoteSamlingContainer
SVC142 –
EFIDokumentMetadataModtag
No
Table 14 Document Management Functional Review and Service Mapping
10.10
Operational and Governmental Reporting Functional Review and
Service Mapping
Functionality
FCT239 - Report
Andelsbog (to police
authority)
FCT240 - Get report
status (from police
authority)
FCT241 - Report car book
(bilbog, to police
authority)
FCT242 - Send Electronic
Act (to authority)
FCT243 - Report Tingbog
(to authorithy)
FCT249 - Request
correspondence Danish
Official Gazette
FCT250 - Reply report
andelsbog
FCT251 - Reply report
FCT252 - Reply report
bilbog
Service
SVC065 - AndelsbogAnmeld
SVC066 – Anmeldelsesstatus
SVC067 – BilbogAnmeld
SVC068 – ElektroniskAkt
SVC069 – TingbogAnmeld
SVC075 –
SEMStatstidendeMeddelelseAnmod
SVC076 –
ETILAndelsbogAnmeldelsesSvar
SVC077 - ETILAnmeldelsesSvar
SVC078 –
ETILBilbogAnmeldelsesSvar
Reviewed
No
Gap
Comments
No
No
No
No
No
No
No
No
Table 15 Operational and Governmental Reporting Functional Review and Service Mapping
10.11
Contact Management Functional Review and Service Mapping
Service
SVC005 – AlternativKontaktOpret
SVC006 -
AlternativKontaktSamlingHent
SVC007 – AlternativKontaktSøg
Reviewed
No
No
No
Gap
Comments
Functionality
FCT191 - Create
alternative address
FCT192 - Get alternative
address
FCT193 - Search
alternative address
86 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0088.png
DATE: 24.09.2015
FCT194 - Update
alternative address
FCT195 - Search
collaboration partner
FCT200 - Get persons at
persons residence
FCT201 - Get persons
master data
FCT202 - Search person
FCT203 - Get persons
address history
FCT236 - Get company
contact information
FCT237 - Get company
master data
FCT273 - Reply claim
enquiry
FCT359 - Get contact
information
SVC008 - AlternativKontaktOpdater
SVC009 – SamarbejdPartSøg
No
No
SVC015 –
No
PersonBopælsamlingHent
No
SVC016 - PersonStamoplysningerMultiHent
SVC223 - KFIKundeStamoplysningerHent
SVC017 – PersonSøg
No
SVC018 -
No
PersonAdresseHistorikSamlingHent
SVC062 -
VirksomhedKontaktOplysningSamli
ngHent
SVC063 -
VirksomhedStamOplysningSamling
Hent
SVC111 –
DMIFordringForespørgBesvar
SVC217 -
KFIKontaktOplysningerHent
SVC345 – VirksomhedAdresseHent
SVC347 –
KanalAdresseSamlingHent
No
No
No
No
DMI
Alternative addresses
are not verified
against a high data
quality source.
FCT462 - Get company
address
FCT464 - Get channel
address collection?
No
No
Table 16 Contact Management Functional Review and Service Mapping
10.12
Debtor Management Functional Review and Service Mapping
Service
Reviewed
SVC050 –
No
DMIHæftelsesforholdList
SVC052 –
No
DMIHæftelsesforholdÆndr
No
SVC059 - EjerVirksomhedRelationHent
SVC229 - KFIVirksomhedEjerforholdHent
SVC060 -
VirksomhedAlleEjerLederRelati
onSamlingHent
SVC061 -
VirksomhedBrancheForholdKla
ssifikationHent
SVC064 - VirksomhedSøg
SVC073 -
VirksomhedKontrolOplysningHe
nt
SVC074 –
PersonKontrolOplysningHent
No
Gap
Comments
DMI
DMI
Functionality
FCT224 - Get
liabilities list
FCT226 - Change
liabilities
FCT233 - Get
company relation
information
FCT234 - Get
company owners and
leaders relation
FCT235 - Get
company
industry/branch
relation classification
FCT238 - Search
company
FCT247 - Get control
information on
business
FCT248 - Get control
information on
person
No
No
No
No
87 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0089.png
DATE: 24.09.2015
FCT261 - Receive
expired liability
FCT262 - Get
customer list
FCT274 - Archive
customer
FCT275 - List
customer
FCT276 - Change
liability stop
FCT287 - Receive
inactive customer
flag
FCT297 - Get liability
share
FCT298 - Search
liability share?
FCT299 - Get car
liabilities
FCT300 - Get
property liabilities
FCT301 - Search
property liabilities No
FCT313 - Receive
event company
change
FCT363 - Transfer
customer
FCT364 - List
collaboration part?
FCT365 - List
customer master data
FCT366 - Change
customer master data
FCT367 - Get
personal company
FCT377 - Report
customer change
FCT461 - Get CVR -
SE number relation
FCT463 - Get
company
industry/branch
relation
FCT466 - Get person
event collection
FCT469 - Get
customer master data
FCT470 - Validate and
enrich liability
relation
SVC092 –
EFIHæftelseForældelseModtag
SVC093 – EFIKundeList
SVC112 - DMIKundeArkiver
SVC218 - KFIKundeArkiver
SVC113 - DMIKundeList
SVC115 –
DOHæftelseStopÆndr
SVC129 –
DWKundeInaktivMarkeringModt
ag
SVC144 –
EFIETILAndelHæftelserHent
SVC145 – EFIETILAndelSøg
SVC146 –
EFIETILBilHæftelserHent
SVC147 -
EFIETILEjendomHæftelserHent
SVC148 - EFIETILEjendomSøg
SVC163 -
EFIVirksomhedÆndringHændel
seModtag
SVC222 - KFIKundeOverfør
No
No
No
No
No
No
DMI
No
No
No
No
No
No
No
SVC227 -
No
KFISamarbejdPartList
SVC224 -
No
KFIKundeStamoplysningerList
SVC225 -
No
KFIKundeStamoplysningerÆnd
r
No
SVC226 - KFIPersonVirksomhedHent
SVC364 - PersonVirksomhedHentService
SVC372 - PersonVirksomhedHentXmlService
SVC250 –
No
MFKundeÆndringUnderret
SVC344 -
No
CVRNummerSENummerRelatio
nHent
SVC346 -
No
VirksomhedBrancheForholdHen
t
SVC349 -
No
PersonHændelseSamlingHent
No
SVC357 - DPTemporaertDokumentMultiOpretService
SVC363 - KundeStamoplysningerHentService
SVC371 - KundeStamoplysningerHentXmlService
SVC365 -
No
ValiderOgBerigHaeftelsesforhol
dService
Table 17 Debtor Management Functional Review and Service Mapping
88 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0090.png
DATE: 24.09.2015
10.13
Claimant Management Functional Review and Service Mapping
Service
SVC231 – MFAftaleHent
SVC352 – AftaleService
SVC020 –
DMIFordringHaverAftaleOplysni
ngerÆndr
SVC232 - MFAftaleSøg
SVC233 - MFAftaleÆndr
Reviewed
No
No
Gap
Comments
Functionality
FCT073 - Get claim
owner agreement
FCT074 - Create
claim owner
agreement
FCT077 - Change
claim owner
agreement
FCT118 - Search
claim agreements
FCT076 – Add claim
type to claim owner
No
No
No
Table 18 Debtor Management Functional Review and Service Mapping
10.14
Correspondence Functional Review and Mapping
Service
SVC011 - DokumentMultiOpret
SVC079 - DPDokumentOpret
Reviewed
No
Gap
Comments
Functionality
FCT052 - Create
letter about ongoing
case work
FCT053 - Send letter
about ongoing case
work
FCT093 - Send
salary deduction
notification letter
FCT100 - Send
salary deduction
decision
FCT165 - Send reject
claim owner letter
FCT182 - Get budget
correspondence
FCT188 - Get
correspondence
content
FCT189 - Send
correspondence
FCT190 - Get
correspondence
status
FCT263 - Receive
National Gazette
correspondence
FCT264 - Create
notification that
claim is written off
FCT268 - Report
offset to customer
SVC002 - MeddelelseMultiSend No
SVC004 - MeddelelseMultiSendEkspres
SVC002 - MeddelelseMultiSend No
SVC004 - MeddelelseMultiSendEkspres
SVC002 - MeddelelseMultiSend No
SVC004 - MeddelelseMultiSendEkspres
SVC002 - MeddelelseMultiSend No
SVC004 - MeddelelseMultiSendEkspres
SVC379 -
No
budgetMeddelelseHent
SVC001 -
No
FormateretMeddelelseIndholdM
ultiHent
SVC002 - MeddelelseMultiSend No
SVC004 - MeddelelseMultiSendEkspres
SVC003 –
No
MeddelelseStatusMultiHent
SVC094 -
EFIStatstidendeMeddelelseModt
ag
SVC095 -
MFFordringAfskrivUnderret
SVC101 –
MFModregningKundemeddelels
eUnderret
No
No
No
89 |
P a g e
 SAU, Alm.del - 2014-15 (2. samling) - Bilag 48: Samlet fremadrettet plan for SKAT, samt materiale vedrørende Et Fælles Inddrivelsessystem (EFI) og refusion af udbytteskat
1549093_0091.png
DATE: 24.09.2015
FCT309 - Get
collection of
correspondence
SVC158 -
EFIMeddelelseSamlingContaine
r
No
Table 19 Correspondence Functional Review and Mapping
90 |
P a g e