CONFIDENTIAL DOCUMENT/RECORD

This document/record is electronically controlled; printed copies are considered uncontrolled.

System of Record: Medtronic Records Control System (MRCS)

Identifier Version Author

30002009 3.0 Sacha, De Zylva ; Ito, Azusa
Title:
SAP(NA) Functional Specification

APPROVALS

Signed by Date/Time (GMT) Meaning of Signature

Hoeve, Victor 05-Dec-2014 07:09:35 Business Sponsor Approval

al
ov
pr
Ap
In-
centerpiece program Enhancement Functional Specification
Medtronic

Functional Specification – Enhancement

al
Enhancement ID: EDD1351_v2.2.doc
ov
Enhancement Name: Global IP FI (Non-PO) Invoice Workflow
pr
Ap
In-

30002009.doc page 1
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

Purpose
The purpose of this document is to capture the business and functional requirements for a Centerpiece
enhancement. Because multiple individuals will rely on this document throughout the interface lifecycle, all sections
must be completed and agreed upon by Medtronic and IBM before the development phase can begin. Assume that
the reader is unfamiliar with your application and processes, and is learning about them for the first time by reading
this document.

1 Document Control
Version Numbering
A brand new development object should start with version 1.0. Any version changes that occur after IBM has
accepted the 1.0 version for development and it has been uploaded into Documentum should increment the minor
version number by 1 (e.g., 1.0 -> 1.1, or 1.9 -> 1.10) with a brief description of the change in the table below. Each
version change will initiate the approval process again, so use versioning judiciously.

al
If you are leveraging an existing RDD, LDD, IDD, or EDD based on one from a previous CRD then leave the previous
version history intact and increment your major version number by 1 (e.g., 1.3 -> 2.0) and capture the CRD number
and brief description of the change in the table below.

ov
The primary author for the CRD should manage the version control for the document.

1.1 Document History

pr
Version Author Process CRD # Revision Description Date
Team

1.0 Matt PTP 103237 Original Version April 18, 2014

Ap

Fjeldsted
2.0 Sacha De PTP 104803 Adding functionality in reference to July 07, 2014
Zylva ECR 104803
2.1 Azusa Ito PTP 104803 Additional functions and updates to Sep 17, 2014
In-

Executive approvals. (Green) Also

reference for updated Payment
Request workflow from ECR103234
2.2 Azusa Ito PTP 104803 Minor changes Dec 05, 2014

30002009.doc page 2
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

2 Enhancement definition

Basic Information
Program type: User exit
Triggered: User exit

3 Functional Requirements
3.1 Description/Business Justification
Please provide a detailed description/ purpose of the enhancement request.
Corporate finance policies outline approval requirements for non-inventory purchases. These policies
require specified paybands for various dollar ranges of cash outlay (expense, capital, service, etc.).

al
Exceptions by specified categories for identified employees on an individual basis are authorized by the
Corporate Controller’s office. When invoices are matched against purchase orders, these finance policies
are satisfied by approvals applied to the purchasing process. For non-purchase order invoices, these

ov
policies must by satisfied by directly approving the invoice. This customization provides the mechanisms
necessary to accomplish such corporate policy-driven non-inventory invoice approvals.

Version 2.0
This change would make approval workflows directed to Medtronic Executives to be redirected to a pre-
pr
validation step (most often to a controller) before the final approval. The rerouting would give more
validation and control in the processing of high value invoices.
Ap

3.2 Desired Functionality

Please provide a description of the desired functionality (what the enhancement will add)
In-

OVERVIEW

An approval workflow will be applied to non-purchase order invoices as part of the Global IP project
using ReadSoft standard and custom functionality. This approval flow will hereafter be called “FI
Workflow” where “FI” stands for “Finance” as these are SAP Finance Module, non-purchase order
invoices rather than SAP Materials Management purchase order-match invoices.

TYPES OF FI INVOICES

At Medtronic, FI invoices will be of two general types: (1) invoices interfaced into ReadSoft’s Process
Director within SAP ECC from various sources such as Kofax and eCATS and (2) invoices created by
virtue of ReadSoft’s internal user portal. Much of the functionality in this customization will apply to
both types of invoices, but some will apply to one or the other. When not explicitly stated, any
functionality described hereafter will apply to both types of invoices.

TYPES OF WORKFLOW

 The payband approval-driven FI Workflow process applies to the standard payment request
workflow, Recurring Document workflow, and Document Upload workflow

30002009.doc page 3
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

 The payband approval-driven FI Workflow process does not apply to down-payment requests.

CREDIT MEMOS

 Credit memos will not be subject to the FI workflow approval process.

FIRST APPROVER

Inbound Interface Invoices

 When the FI Workflow is set up with automatic recipient determination for FI invoices from the
inbound invoice interface, the FI Workflow will be sent to the Contact as the first recipient
automatically.
 The Contact can be determined by standard ReadSoft configuration
 The Contact can be an SAP ECC user or a WUM (WebCycle User) user

al
 When the Contact cannot be determined automatically, a Process Director user can initiate the
FI workflow, chose any user as the Contact and send it manually from Process Director.

Payment Request Invoices


ov
The first approver for payment requests is the Requestor (the person who initiates the
payment request)
pr
SECOND APPROVER
Ap

 For FI invoices in FI workflow, a user's manager is determined by the custom user data table
 In FI workflow, when the total value of the invoice exceeds the value corresponding to the
user's payband, another step is added to the workflow and the current user's manager is
proposed
 The first approver (whether Contact or Requestor) and every consecutive approver can
In-

override the manager determination and forward the workflow to a person other than his/her
manager
 The second approver is automatically determined as the manager of the first approver whether
a Contact, Requestor, or manually assigned first user.

APPROVAL AUTHORIZATION

 For workflow purposes, a user's payband is determined by the custom user data table
 In the FI workflow, a user's approval authority is determined by his/her payband in the user
data table and the corresponding value in the payband-value mapping table
 In the FI Workflow the Contact or Requester acts as the first approver.

INVOICE DETAILS
 For multi-line payment requests, different accounting values can be used on different lines
 The Contact or Requestor can overwrite default accounting values Moved down

Inbound Interface Invoices

30002009.doc page 4
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

 General ledger account and cost center will default from configuration by vendor when such
data has been maintained, the Contact or Requestor can overwrite default accounting
 When the general ledger account and cost center defaults are not maintained, the Contact will
be required to enter them


Payment Request Invoices

 Company code and cost center are obtained from the custom user data table, The Contact or
Requestor can overwrite default accounting
 If the company code and cost center are not obtained from the custom user data table, the
Requestor will be required to enter them.
 The Requestor cannot submit the payment request until a valid cost assignment and general
ledger account are properly entered.

EXCEPTIONS TO PAYBAND LEVELS

al
 Exceptions granted by the Corporate Controller's office to the standard payband approval
levels are maintained globally by category in the invoice exception category custom table



ov
Individual exceptions granted by the Corporate Controller's office to the standard payband
approval levels can be maintained by user by category as a global exception or as a company
code level exception
In FI Workflow, when there is an exception defined for the current approver and the current
pr
document invoice category, the value of the authorized exception will overwrite the regular
payband value
 Invoice categories can be created for invoices not subject to exceptions granted by the
Corporate Controller's office.
Ap

Inbound Interface Invoices

 For FI invoices from the inbound invoice interface, the Contact is not required to select the
invoice category. If no selection, no category will be applied
In-

Payment Request Invoices

 For FI invoices from payment requests, the Requestor is not required to select the invoice
category for the Payment Request, Recurring Payment, and Document Upload payment
request types. If no selection, no category will be applied

Version 2.1/Version 2.2

 To avoid workflows for invoices with a value above 1 milj. USD going directly to Medtronic
Executives we need to redirect workflows to a designated approver. For this purpose a custom
table has to be created which will have a Tcode & table denoted as ZPTP_GIP_EXEC_AP
ZPTP_GIP_PB_EXEC which will map the executives (1. CFO, 2. COO 3. CEO 4. BOD) by
using the network ID and their approval authority as well as the designated approver. When a
workflow is directed towards an Executive that is maintained in this table, the system will look
for the designated approver and reroute the approval task towards their designated approver.
The designated approver rejects or approves. Approval by the designated approver results in
automatically assigning it to the first executive. Each executive’s approval will be validated
against their approval authority from the table. If not within the approver‘s authorization, the
next executive will be assigned automatically.

30002009.doc page 5
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

 Regardless of which executive is triggered, the executive workflow always starts with the
designated approver, (generally the controller), followed by the CFO.
 An executive FI workflow item moves through the table coming to a C-level role without an
associated network ID, that C-level approval will be skipped and the workflow will proceed
to the next approver in the table

3.3 Business Requirements

Please complete the excel template of the business requirements/testing statements and insert here.

See separate document posted in same folder in Documentum

3.4 Business Process Flow – As Is (optional but recommended)

Please insert a Visio or picture of current business process

AS IS documentation will not be detailed in this document. At a very high level, these AS IS activities are

al
performed as follows:
 In Prodagio (Americas)
 In Basware (Europe)
 No system solution (AsiaPac)
ov
3.5 Business Process Flow – To Be (optional but recommended)
pr
Please insert a visio or picture of proposed business process
Ap

As this is optional, these notes are provided as a simple draft for a Visio to follow.

INBOUND INVOICE INTERFACE

 Kofax
In-

 eCATS
PAYMENT REQUEST
 Standard payment request workflow
 Recurring Document workflow
 Document Upload workflow
 (The payband approval-driven FI Workflow process does not apply to the IDCM workflow)

NO CREDIT MEMOS
|
|
V
(Table for maintaining contact)
|
|
V
FIRST APPROVER
|

30002009.doc page 6
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

|
V
CHECK PAYBAND

(Exceptions categories & users with exception assignments)

(Accounting details)
|
|
V
SUBSEQUENT APPROVER(S)
|

al
|
V
POSTED VIA REPETITOR PROGRAM

Version 2.0/Version 2.2

ov
pr
FI Work Flow is triggered towards a Medtronic Executive
Ap

Program checks the ZPTP_GIP_PB_EXEC table to confirm a designated approver has been maintained
for the Executive in question. If yes, the approval task is redirected to his designated approver
In-

Designated approver receives the rerouted task. Approval by the designated approver results in
automatically assigning it to the first executive. Each executive’s approval will be validated against their
approval authority from the table. If not within the approver‘s authorization, the next executive will be
assigned automatically. Designated approver receives the task only once.

4 Processing Logic
Step 1
Step 2
Step 3
Please describe how the selection screen inputs are processed and how the data retrieval and
computations take place.

30002009.doc page 7
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

5 Custom tables

Two custom tables will be created with this enhancement. “Log Data Changes” should be
activated in the technical settings for these two tables).

A custom table will be created to maintain exception categories for the standard approval
values. The category will be selected in most FI documents. The category will be required for all
inbound invoice interface invoices and by payment request type as explained earlier in this
document for payment requests. A separate table will be created to assign users and exception
values by category.

al
Basic Information
Table name: ZPTP_GIP_PB_EX_C

Table type: Configuration / Application ov

GIP Payband Exception Categories
pr
Field Key Data el. / format Comment
Exception Yes
Category
Code
Ap

Exception Yes Length = 40 (Toby, I did not run this by the business. Let me
Category characters know if you think this should be adjusted.)
Description
Created on (To be created by MDT/IBM)
In-

Created by (To be created by MDT/IBM)

Changed (To be created by MDT/IBM)
on
Changed (To be created by MDT/IBM)
by

A custom table will be created to maintain payband approval exceptions by category and user
by company. When an FI invoice is routed for approval to a user with a record in this table with
the same category as that identified in the FI invoice, the exception value in this table will be
used for approval purposes instead of the standard payband value.

Basic Information
Table name: ZPTP_GIP_PB_EX_U
GIP Payband Exceptions by User
Table type: Configuration / Application

30002009.doc page 8
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

Field Key Data el. / format Comment

Exception Yes
Category
Code
Exception Yes Length = 40 (Toby, I did not run this by the business. Let me
Category characters know if you think this should be adjusted.)
Description
User ID
Amount
Currency WEARS
Created on (To be created by MDT/IBM)
Created by (To be created by MDT/IBM)
Changed (To be created by MDT/IBM)

al
on
Changed (To be created by MDT/IBM)
by
ov
Version 2.0/Version 2.2
pr
A custom table will be created to maintain the Executive and their designated approvers.

Basic Information
Ap

Table name: ZPTP_GIP_PB_EXEC

GIP Executive Approver Designation
Table type: Configuration / Application
In-

Field Key Data el. / format Comment

Sequence YES 2 digit number 01, 02, 03, etc. for sequencing executive roles
Executive YES 10 char alpha- CFO, COO, CEO, BOD (Board of Directors)
Role numeric
Approval No CURR-11-2
Amount
Approval No CUKY-5 WAERS
Currency
Executive No
User ID
Designated No
approver
User ID
Created on No (To be created by MDT/IBM)
Created by No (To be created by MDT/IBM)
Changed No (To be created by MDT/IBM)
on
Changed No (To be created by MDT/IBM)
30002009.doc page 9
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

Field Key Data el. / format Comment

by

6 Selection screen

Not applicable

Select options Comment

Parameters Comment

al
7 Transaction screens

Not applicable
ov
pr
7.1 Screen flow logic
Screen flow logic
Ap

7.2 Header
In-

Field M/O Comment

7.3 Line item

Field M/O Comment

30002009.doc page 10
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

8 Test Requirements and Test Data Attributes

Please complete the excel template of test scenarios and test data attributes and insert here.

See separate document posted in same folder in Documentum

al
ov
pr
Ap
In-

Approval flow version 2.2

9 Security / Authorization Requirements

Add the following two new t-codes to the following role with display access only
 T-codes:
o ZPTP_GIP_PB_EX_C
o ZPTP_GIP_PB_EX_U
o ZPTP_GIP_EXEC_AP
 Role:
o ZS:PTP_AP_GIP_ADMIN_DISPLAY

30002009.doc page 11
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

Add the following two new t-codes to the following role with create/change access:
 T-codes:
o ZPTP_GIP_PB_EX_C
o ZPTP_GIP_PB_EX_U
 Role:
o ZS:PTP_AP_GIP_ADMIN_MAINT_FI_WF

Version 2.0/Version2.2

Add the following new t-code to the following role with create/change access:
 T-codes:
o ZPTP_GIP_PB_EXEC

al
 Roles:
o ZS:PTP_AP_GIP_ADMIN_FI_WF

10 Error Handling
ov
pr
Please describe any error handling requirements

If a workflow fails, then the document will stay in Process Director until the issue is resolved.
Ap

11 Dependencies
Please provide any Configuration dependencies.(This would also help determine the transport sequence)

The following two tables will be created as part of ECR103201-EDD1262 and are prerequisites to
In-

completing this enhancement:

 ZPTP_GIP_WF_USER (GIP User Data for Workflow)
 ZPTP_GIP_PB_MAP (GIP Payband Value Mapping)

12 Assumptions and Issues

12.1 Assumptions
1. The design and development for bringing user data into the custom user data table will be
handled separately in an inbound user ID and user data interface.

12.2 Issues
Please list any Issues here
No Issue / Resolution Description Name Date

30002009.doc page 12
12/5/2014
centerpiece program Enhancement Functional Specification
Medtronic

al
ov
pr
Ap
In-

30002009.doc page 13
12/5/2014