Design Document

Functional Design Document

Order to Cash – Invoice Cancellation & Write-offs

Sensitivity: Internal & Restricted

Design Document

Revision & Sign-0ff Sheet

1.1. Change Record
Date Author Version Change Reference
20 May 2019 Hareesh Balagangadharan 1.0 Draft

1.2. Approvers
Name Version Approved Position Date

1.3. Document Properties

Item Details
Document Title Design Document
Authors Hareesh Balagangadharan
Creation Date 15 July 2019
Last Updated 17.07.2019
Wireframe
L5 Document

EY 2

Sensitivity: Internal & Restricted

Design Document

Preface
The purpose of this design document is to describe the customizations identified during the analysis phase which are mentioned in the Functional Requirement Document. The
design document is prepared based on the discussions with the process owners and core team members.

The design document explains the approach towards customizations to meet up the gaps identified. It also elaborates on the objects that will be modified in course of
customization. The document contains description of the table structure and interfaces that have been identified during the analysis phase. It will be further updated with more
specific technical details during the development phase.

EY 3

Sensitivity: Internal & Restricted

Order to Cash

Contents
REVISION & SIGN-0FF SHEET....................................................................................................................................................................................................................................... 2
1.1. CHANGE RECORD.........................................................................................................................................................................................................................................................................2
1.2. APPROVERS............................................................................................................................................................................................................................................................................. 2
1.3. DOCUMENT PROPERTIES........................................................................................................................................................................................................................................................ 2
PREFACE.......................................................................................................................................................................................................................................................................... 4
1. LEAD IDENTIFICATION............................................................................................................................................................................................................................................... 6
1.1. DOCUMENT SCOPE.................................................................................................................................................................................................................................................................. 6
1.2. REQUIREMENT DESCRIPTION.................................................................................................................................................................................................................................................. 6
FOR DETAILED REQUIREMENTS PLEASE REFER BELOW DOCUMENT:............................................................................................................................................................................................. 8

Draft
O2C_Backlog_Consloidated Invoicing_SAP Solution_V2.2.xlsx
........................................................................................................................................................................................................................................................................... 8
1.3. USE CASE DIAGRAM(S)........................................................................................................................................................................................................................................................... 8
1.4. INFORMATION FLOW DIAGRAM................................................................................................................................................................................................................................................. 9
1.5. END USER JOURNEY............................................................................................................................................................................................................................................................. 10
1.6. PERSONAS............................................................................................................................................................................................................................................................................. 10
1.7. DEVELOPMENT JUSTIFICATION.............................................................................................................................................................................................................................................. 10
1.8. FUNCTIONAL DESIGN – MOBILE APP.................................................................................................................................................................................................................................... 11
1.9. INTEGRATION REQUIREMENTS.............................................................................................................................................................................................................................................. 96
1.10. FUNCTIONAL DESIGN – WEB APPLICATION........................................................................................................................................................................................................................ 96
1.11. INTEGRATION REQUIREMENTS.......................................................................................................................................................................................................................................... 196
1.12. SECURITY DESIGN............................................................................................................................................................................................................................................................. 196
1.13. TEST CASES...................................................................................................................................................................................................................................................................... 198
1.14. OPEN POINTS.................................................................................................................................................................................................................................................................... 201
1. Lead Identification
1.4. Document Scope
In Scope:

The O2C invoice cancellation process deals primarily with the reversals of invoices generated in system based on the billing process. The request for various types of
reversals will be initiated by Delivery team which will be further approved by O2C Lead in case of cancellation and by respective approvers in case of Credit note /Debit
notes. The cancellations are required when there is a incorrect billing for the customer or there is a scenario of any Disputes with the customer for payment.

Pre-requisite for invoicing a project in T&M Model.

 Existing invoice generated in system for which the reversal is to be performed in system.

Invoice cancellation :

 First level Request creation will be performed by Project Manager / PMO / Delivery manager.

 Second level approval by Invoice coordinator part of FIFIDUS team.

 Roles Involved in Invoice cancellation process are Project manager / Delivery manager / PMO , Invoice coordinator.

Credit notes :

 First level request creation for credit note will be performed by Project manager / Delivery Manager / PMO.

 Further approvals will be done by Next levels of approvers (BFM , Senior BFM , Vertical head, O2C lead..etc) as applicable in the approval matrix maintained.

 Roles involved in Credit note process involve Project manager , Delivery manager , Vertical head , BFM , Senior BFM , FIFIDUS head , O2C lead ..etc
Order to Cash

Invoice cancellation Process :

1.Role Name: Project manager / PMO / Delivery manager:

 Project manager / PMO/ Delivery manager will perform the request creation for invoice cancellation process / Credit note process.

 Further the request would be approved by next levels of approvals as per the approval matrix maintained.

Generic notes – Invoice cancellation:

 For the invoice cancellation request to be performed, User should provide the invoice number as the input which needs to be cancelled.

 User will have the option to enter either a single invoice number or a consolidated invoice number, In the later case user will have to additionally choose the
individual invoice inside that consolidated invoice to go with the cancellation request.

 Only current month invoices are allowed to be processed through invoice cancellation route.

 User will have to mandatorily select the reason for going into invoice cancellation through the dropdown.

 Once the request is created , The intimation mail is triggered to the respective invoice coordinator who is responsible for the invoice cancellation approval.

 The summary information regarding the invoice being requested for cancellation will be shown to the user in the approval screen includes the following.

o Type of invoice (T&M , FPP..etc)

o Invoice number

o Invoice date

o Value
Order to Cash

o Currency

o Company code

o Created on

o Customer code

2. Role : Invoice coordinator

 Invoice coordinator is responsible for the approval / Rejection of Invoice cancellation request .

 Once the request is approved in system , the original invoice is flagged for cancellation in SAP and scheduler runs to cancel the invoice.

Credit note process :

Generic notes – Credit note with reference:

 Credit notes are performed for doing invoice reversals pertaining to previous months for which revenue has already been taken in previous months.

 Credit note with reference can be done against a FPP invoice or T&M invoice or a periodic invoice.

 The reference invoice which is given should be a valid invoice number in SAP and shouldn’t belong to the current billing period and should have been already
posted and not cancelled.

 In Credit note with reference to invoice , User has to further select the following :
Order to Cash

o Re-raise Full option (Credit note + Debit note)

 In this case the Credit note will be generated for the original value of the invoice and Inputs will be taken from Screen for raising the debit note.

 The content in the reference invoice will be auto populated in approval screen.

o Only Credit note( Partial CN route).

 Based on the user input , Only the credit note will get generated in system.

 The content in the reference invoice will be auto populated in approval screen.

 While raising credit note , user should select the reason for creating the credit note , The list of reasons for credit note option would be readily available in
approval screen along with the selection of billing date.

Generic notes – Credit note without reference :

 Credit notes are performed for doing invoice reversals pertaining to previous months for which revenue has already been taken in previous months.

 In Credit note without reference , The user will select the Order , Line item and date range for which credit note without reference has to be raised.

 User will have to manually enter the content which will be considered for creating the credit note in system.

People Cost section :

 Following are the fields which will be proposed for approval with the identification of editable / Non editable fields.
Order to Cash

 People cost section would reflect / add with the employee related efforts billing.

Credit note Volume discount

without reference editable fields
Fields Credit note with reference editable fields editable fields Source
Employee id N Y N H2R
Employee name N N N H2R
Employee type N N N H2R
Role N Y Y H2R
Material code for Y Y
reimbrusements Y Cost module.
Country N Y Y Timesheet
Time bucket N Y Y Timesheet
Billing period N N N RRB
Approved efforts N N N Timesheet
Billing efforts Y Y Y Manual
Rate N Y Y RLS
Amount N Y Y Calculated
Group id Y Y Y Manual
PO Y Y Y Manual
Kind attention Y Y Y Manual
Customer project Y Y Y Manual
Customer cost Y Y
center Y Manual
Remarks Y Y Y Manual

Non People cost

Order to Cash

 Non people cost involves the derivation following billable cost booked against the project.

o Reimbursement cost line items like Travel , Equipment reimbursements , Bot Cost , .

o Unbilled Reimbursement cost line items from previous billing period.

o Line items which have been postponed from the previous invoicing cycles.

Following are the fields which will be proposed to the project manager for approval:

Credit note without

Credit note with reference reference editable
Fields editable fields fields Source
Cost type N Y Cost module
Payment date N N Cost module
Start date N N Cost module
End date N N Cost module
Actual cost N N Cost module
Currency N N Cost module
Total Cost N N Cost module
Billing value Y Y Manual
Start date N Y Cost module
end date N Y Cost module
Status Y N Manual
Rejection reason Y Y Manual
Group id Y Y Manual
Kind attention Y Y Manual
PO Y Y Manual
Customer project name Y Y Manual
Cost center Y Y Manual
Remarks Y Y Manual
Order to Cash

 User should have the option to perform the following:

o Perform invoice split across the line items as per the customer invoicing requirement.

o Customer approval supporting document upload.

o Download the data for pre-invoicing approval with the customer as per the customer requirement.

2. Role : Delivery Manager :

 The Delivery manager approval would be performed by person mapped as Delivery manager at project level.

 Delivery manager will also have the option to directly perform approvals if the Project manager / Delivery manager is the same for the project.

 Email notifications will be triggered to the next levels of approver based on approval matrix.

Volume discount :

 Project manager , Delivery manager, or PMO will have the access for initiating the volume discount for the project.

 User will have to give the declaration of volume discount amount that is applicable for the selected WBS and date range.

 Once the approval is performed , the request will go into next level of approvers and once the O2C lead approves it final credit note gets generated in system.
Order to Cash

Out of Scope :

 System based auto determination of volume discount value applicable for the period.

1.5. Requirement Description

Process ID Requirement Description Gap Description
O2C 1.1 Invoice Generation Invoice generation process enabling PM / PMO / DM with a view
of billable cost against the project in case of T&M project. For FPP
the view to be provided with the milestones for invoicing. For
Element based invoicing the list of Elements relevant for invoicing
along with the corresponding rate cards to be proposed for
invoicing.
For detailed requirements please refer below document:

L5_Draft_Lead
Identification Generation_05 Dec Nov 2018.xlsx

1.6. Use Case Diagram(s)

Order to Cash

1.7. Information flow diagram

1.8. End User Journey

The below L5 process depicts the complete end to end flow of the user journey through Web app for Invoice generation for T&M.

Draft L5 Process
Flow - O2C.03.04.01_Consolidated Invoicing_V2.0 (1).pdf

1.9. Personas

As per the L5 process, the below personas will perform the activities defined in this specification.

 Request creation will be done by Project Manager / PMO / Delivery Manager

 Approved by O2C for cancellation, and BFM ,Senior BFM ,Vertical head, Revenue team, FIFIDUS head, O2C Lead..etc

1.10. Development Justification

1.10.1. SAP
Objects will be developed in SAP as standard SAP Objects wont be taking of functionality expectation in Wipro.
Order to Cash

1.10.2. Purpose of Modification

The requirements provided cannot be achieved by the standard features of SAP. Therefore, the standard features will need modifications to
accommodate the requirements.

1.10.3. Considerations & Assumptions

The UI design and the digital features and functionalities provided in requirement will be developed by respective teams.

1.11. Functional Design – Web App

1.11.1. UI Design – Invoice cancellation request Page :
Order to Cash

1.11.2. UI Design – Selection of cancellation invoice.

Order to Cash

1.8.4 : UI Design – Cancellation summary screen :

Order to Cash

1.8.5 : UI Design – Credit note with reference screen :

Order to Cash

1.8.6 : UI Design – Credit note with reference approval main screen where it shows the line items from
reference invoice for approvals.
Order to Cash

1.8.7 : UI Design – Credit note without reference project selection screen :

Order to Cash

1.8.8 : UI Design – Credit note without approval screen with the line items added :
Order to Cash

1.8.9: UI Design – Credit note without reference , Add line item option screen
Order to Cash

1.8.9 : UI Design – Credit note Volume discount selection option.

Order to Cash

1.8.10 : UI Design – Credit note Volume discount approval main screen :

Order to Cash
Business Requirement
Credit note with reference
validation
Credit note with reference
validation
Credit note with reference
validation
Credit note with reference
validation
Credit note with reference
validation
Credit note with reference
Partial credit note
Credit note
Credit note without reference
Volume discount
Business Rule/Validation Validation Handled by –
UI/SAP
Invoice should be valid as UI+SAP
per SAP
Invoice should pertain to a UI+SAP
project which is under
corresponding PM or DM.
Invoice should not pertain to UI+SAP
current billing period.
Credit note with reference to UI+SAP
existing invoice is allowed if
there is no other credit note
against same invoice, if it
exist credit note should be
restricted to the existing
overall value of original
invoice.
Reason selection and Billing UI
date is mandatory while
creating credit note , Billing
date should pertain to
current open billing period.
Credit note value should be UI + SAP
within the original invoice
value
Line item value shouldmatch UI
with the overall value.
Reason and billing date UI
selection is mandatory.
Volume discount value UI
should be within the allowed
limit based on contract
Order to Cash

User Actions
Action Expected Result
Click on Notification icon All notifications for the logged in user to be displayed. UI to Call API to fetch notification
data from CRM table
Click on Sort button All the conversations in the Conversation list should be sorted. UI to Call API to fetch the
sorted list of Conversations from respective Activity table in CRM
Order to Cash

1.12. Security Design

1.12.1. Security Requirements
Security Role/Persona Entity Create Read Write
Order to Cash

1.13. Test Cases

Sl No Test Scenario Test cases Test Steps Expecte Actual Test Remarks
d Result Result Status

       

       

       

       

1.14. Open Points

Sl. Particulars Functionality Impacted Owner
No.
1. Employee line item split during billing approval Billing approval Shekar
2 Types of reimbursement costs Non People cost approval Shekar.
Order to Cash

Additional Documents
User Actions and Related API Details

User Actions and

API.xlsx