BUG - 15620 - FSR-Enhancement-QC15608-New SO Type For Intragroup Customers Only - V3

AGORA
Functional Specification Requirement document for

WRICEFP
- THE ENHANCEMENT -
New SO Type for Mirroring process Intragroup customer only
FSR
Document Reference: New SO Type for Mirroring process Intragroup customer only
Version: V1
Document Status: <Draft/Review/Signed Off>
Author: Mamadou TOGOLA
Date Created: 15-09-2017
FSR_Template: ENHANCEMENT 06/07/2015 Page 1 / 26

FSR Document Information
Functional Domain OPE : SALES
SAP System / Module ECC
Scope of requirement: VESA

Global / Local
Document Change History
Initial / Reason for change QC number QC GRC Author Date

Change
Initial CORE - Mirroring process 15620 15-09-2017
implementation - SD customizing
Check PO number in SO - QC15604 15604 15-09-2017
(SD)
New SO Type with default pmnt term 15606 15-09-2017
Z001 - QC15606 (SD)
New SO Type for Intragroup 15608 15-09-2017
Customers only - QC15608 (SD)
New field in SO item for recording the 15611 15-09-2017
cost center - QC15611 (SD)
New SO Type for Intragroup 16025 27-11-2017
Customers only (credit note) -
QC16025 (SD) and new rule for
incompletion log.
FSR Template: Enhancement 06/07/2015 Page 2 / 26

Table of Contents
1 Business requirement.................................................................................................................................................................5
1.1 Business requirement summary.............................................................................................................................................5
1.2 Business justification and benefits.........................................................................................................................................6
2 Business process flow................................................................................................................................................................6
3 Enhancement features................................................................................................................................................................9
3.1 Enhancement description.......................................................................................................................................................9
3.1.1 CORE - Mirroring process implementation - SD customizing (QC 15620)............................9

3.1.2 Check PO number in SO - QC15604...................................................................................10
3.1.3 New SO Type with default pmnt term Z001 - QC15606.....................................................11
3.1.4 New SO Type for Intragroup Customers only - QC15608...................................................12
3.1.5 New field in SO item for recording the cost center - QC15611..........................................13
3.2 Screen design......................................................................................................................................................................14
3.3 Starting Conditions :.............................................................................................................................................................14
4 Security Requirements/ Authorization Details...........................................................................................................................15
5 Error handling...........................................................................................................................................................................15
6 Test cases................................................................................................................................................................................16
6.1 Test case New SO Type for Intragroup Customers only - QC15608....................................................................................16
6.1.1 Positive test cases..............................................................................................................16

6.1.2 Negative test cases............................................................................................................16
6.2 New SO Type with default pmnt term Z001 - QC15606.......................................................................................................18

6.3 Check PO number in SO - QC15604...................................................................................................................................19
6.3.1 Positive test cases ZMIR....................................................................................................19

6.3.2 Negative test cases ZMIR..................................................................................................19
6.3.3 Positive test cases ZMIA....................................................................................................20
6.3.4 Negative test cases ZMIA..................................................................................................20
6.4 New field in SO item for recording the cost center - QC15611.............................................................................................21

7 FSR Quality Gate (CoE consultant)..........................................................................................................................................22

Document Glossary
<In this section an author of the document needs to explain all the abbreviations or non-SAP, terms coming from
legacy systems or business terms typical to the local business>

1 Business requirement
1.1 Business requirement summary
The objective is to optimize operational intercompany processes between Agora entities, i.e. automate as much as possible all
process steps and accounting entries related to intercompany purchases and sales.
The current scope of entities concerned by this process is listed below:
CAMPUS
VESA

1.2 Business justification and benefits
<This section should be filled in with data such as saving for legal requirement covered, business, process
improvement or additional knowledge related gains etc.>
2 Business process flow

As is Process 1: the buyer purchasing order
Process step description
1 - Manual creation of a Purchase Order (PO) in the Buying company which is sent manually to the Selling company by email
2 - Manual creation of Sales Order (SO) in the selling company
3 - Generation of the customer invoice (INV) in the Selling company through the Agora Core Model process. This document is sent
by mail to the Buying company (post office)
4 - Posting of the customer invoice in the accounting of the Selling company
5 - The Buying company performs the good receipt manually
6 - The Buying company receives the invoice, scan it and post it in its accounting through SIM process. If the invoice is not received
at month-end, then the buying company post accruals using the standard closing program available in Agora (reclassification of the
GR/IR account)

As is Process 2: the buyer doesn’t raise any Purchase Order
1 - Manual creation of Sales Order (SO) in the selling company
2 - Generation of the customer invoice (INV) in the selling company through the Agora Core Model process. This document is sent
by mail to the buying company (post office)
3 - Posting of the customer invoice in the accounting of the selling company
4 - The buying company receives the invoice, scan it and post it in its accounting through SIM process
Notes :
If the invoice is not received at month-end, then the buying company post manually accruals in accounting
If the invoice is not issued at month-end, then the selling company post manually accruals in accounting
(posting schemes available in the Agora Core Model documentation Finance)

To be Process
1 - Manual creation of a Purchase Order (PO) in the Buying company. Once done, a request for creating the SO in the Selling
company is manually sent (out of system)
2 - Manual creation of a Sales Order (SO). The reference number of the created PO in the Buying company is to be mentioned in
the SO of the Selling company
3 - Manual Good Receipt in the Buying company when the service is delivered
4 - Generation of the customer invoice (INV) in the Selling company (current Agora process - no change)
5 & 6 - Posting of the customer invoice in the accounting of the Selling company and automatic generation of mirroring between
Selling and Buying companies which posts automatically in the Buying company the vendor invoice in the accounting, in reference
to the PO. The vendor invoice must not go through SIM process. It is directly posted in the accounting of the Buying company using
cost assignment from the SO
7 - The customer invoice image (pdf file) must be attached to both AP and AR postings in the partner companies
Optional adjustment flow
This optional flow will be used if the PO & SO are raised based on a quotation and if the real cost of the services provided is
different from the initial quotation.
This optional flow will mainly be used for all services related to events management provided by the Campus to the BUs.
8 - Manual creation of an “Ajdustment Sales Order” in the Selling company. The initial PO number should be stored in a dedicated
field of the SO for information only and replicated in the AR & AP invoices. Moreover, the cost assignment objects of the buyer from
the original SO is manually filled in a dedicated field in the “Adjustment SO” in order to allow the mirroring flow (i.e. be able to
automatically post the vendor invoice document on P&L cost accounts)
9 - Generation of the customer invoice (INV) in the Selling company (current Agora process - no change)
10 & 11 - Posting of the customer invoice in the accounting of the Selling company and automatic generation of mirroring between
Selling and Buying companies which posts automatically in the Buying company the vendor invoice in the accounting. The vendor
invoice is posted without reference to the PO but should hold in a dedicated field the original PO number to ease analysis.
The vendor invoice must not go through SIM process. It is directly posted in the accounting of the Buying company using cost
assignment from the SO
12 - The customer invoice image (pdf file) must be attached to both AP and AR postings in the partner companies

3 Enhancement features
3.1 Enhancement description

3.1.1 CORE - Mirroring process implementation - SD customizing (QC 15620)
3.1.1.1 Business requirement
Business requirement is to create two news sales order document type in order to isolate this new intercompany sale flows from the
existing intercompany flow.
3.1.1.2 Action required
3.1.1.2.1 Business requirement for news order type
Action required is to create two news sale order type. (Because there are 2 distinct processes, one for adjustments and one for
original SO)).
Bellow the description of the two sale order document type to create.
Sales order type Document type Document type Comment

Description in English Description in french
ZMIR “Interco Original SO” Interco Commande Ori” Don’t forget to do the translation
ZMIA “Interco Ajdust SO” “Interco Commande Adj” Don’t forget to do the translation
Attention point
These 2 news sales order type must be restricted to the current scope of entities concerned by this process listed in section “1.1
Business requirement summary”.
3.1.1.2.2 Business requirement for billing document type
The current Agora process to invoice customer in the Selling Company is kept.
No changes required
3.1.1.2.3 Business requirement for accounting document type)
To check with FI team.

3.1.2 CORE - Mirroring process implementation - SD customizing "credit note" (QC 16025)
Business requirement is to create one new sale order document type (for credit note managemen) in order to isolate this new
intercompany sale flows from the existing intercompany flow.
3.1.2.2 Action required
3.1.2.2.1 Business requirement for news order type
Action required is to create one new sale order type. (This new document type is created in order to raise credit for adjustments
one)).
Bellow the description of the two sale order document type to create.
Sales order type Document type Document type Comment

Description in English Description in french
ZMIC “Interco Credit Adj” “Interco Credit Adj” Don’t forget to do the translation
Attention point
This new sale order type must be restricted to the current scope of entities concerned by this process listed in section “1.1 Business
requirement summary”.
The new document type ZMIC will have the same control done for document type ZMIA
3.1.2.2.2 Business requirement for billing document type
The current Agora process to invoice customer in the Selling Company is kept.
No changes required
3.1.2.2.3 Business requirement for accounting document type)
To check with FI team.

3.1.3 Check PO number in SO - QC15604
Today the vendor invoice is posted without reference to the PO number of the customer invoice.
The business requirement is to store manually the purchase order document number in the field PO number of the sale order
document and replicated in the AR & AP invoices.
Each line item in a Purchase Order document will have to be replicated in the Sale Order document (1 to 1 link).
For “Adjustment SO”, as many line items as line items to be adjusted from the original PO will be created. This will ensure a perfect
data consistency and audit trail as it will enable for end user to match the “sold” services with the “received” ones, including
adjustments.
Attention point
To avoid system regression, this control can be performed only if the sale order document type is ZMIR or ZMIA. All others
document type is out scope.
3.1.3.1.1 Business rule
- The system must control that the purchase order document number (enter in the PO number field) exist in the system
- In the original Sales Order (process 1), the reference to the PO must be mandatory and the value entered must be the
purchase order document number.
- In the adjustment Sales Order (process 2) (document type ZMIA and ZMIC), the reference to the PO mustn’t be
mandatory and the value entered must be the purchase order document number.
o At the saving of document type ZMIA and ZMIC, if the PO number field is empty, the system mustn’t display the
PO number as information missing.
3.1.3.1.2 What the system is unable to do
Today the control describes in the business rules doesn’t exist.

As a consequence, the system is unable to check if the PO number of the sale order document exists in the system and if the sale
order must be block or not if the field PO number is empty or not valid.
3.1.3.1.3 What the system must do (expected result)
The system must do the following control:
- Requirement 1 (Only for Process 1)

o Case 1 The field PO number is empty
 If the field PO number is empty
 Then the system must raise a error message
 The description of the message to display is in section “Error message”
- Requirement 2 (Process 1 and process 2)

o Case 2 The field PO number is filled but doesn't exist in the system
 If the field PO number is not empty
 Then the system must control that the value entered by the user is a valid Purchase Order
document number in the system
o If the PO number doesn't exist, the system must raise a error message “Please enter
a valid PO number”
 The description of the message to display is in section “Error message”

3.1.4 New SO Type with default pmnt term Z001 - QC15606
For this new intercompany flow, all the customer invoices must be paid immediately (payment terms = cash payment).
But today the payment term is a value that it automatically filled by the system from customer master data and can be change
manually by the user.
The business requirement is to replace automatically the value of the field payment term by “Z001” immediate payment. (Change to
be done in the header and item level of the sale order document.).
Attention point
To avoid system regression, this control can be performed only if the sale order document type is ZMIR or ZMIA. All others
All the customer invoices must be paid immediately (payment terms = cash payment). As a consequence, the payment terms:
- Must be automatically set to “immediate” in the Sale Order
- Must be automatically set to “immediate” in the FI-AR document (in case of adjustment flows)
- If the value of the payment term is change manually by the user, the system must automatically set to Z001 “immediate”
Today the system is unable to replace the existing payment term of the sale order document by “Z001” immediate payment.
The rule is to determine payment term automatically from master data.
- The system must check the document type.

o If the sale order document type is ZMIR or ZMIA.
 Then the system has to replace the value of the payment term by Z001” immediate payment.

3.1.5 New SO Type for Intragroup Customers only - QC15608
Today the field customer is used to enter all type of customer (group customer and non-group customer)
The business requirement is to set up a control on the customer field in order to ensure only group customer are used in the two
news sales order document type (ZMIR or ZMIA).
Attention point
- To avoid system regression, this control can be performed only if the sale order document type is ZMIR or ZMIA. All others
Non Group Customer must be forbidden for these two news sales order document type (note: at the moment, it is not requested to
trigger a control against a list of predefined and authorized customer but only against the customer type “Group”)
Today the system is unable to control if the customer filled in the field customer is a group customer or a non-group customer.
- The system must check the document type, if the sale order document type is ZMIR or ZMIA.
- Then the system has to control if the customer filled in the field customer is a group customer.
o if the customer is a non-group customer, the system must display a message error
 Description of the message to display in section “Error message”

3.1.6 New field in SO item for recording the cost center - QC15611
Today the cost assignment objects are stored in the purchase order.
In the process 2 you don’t have a purchase order.
The business requirement is to store the cost assignment objects of the buyer from the original SO (is manually filled) in a dedicated
field in the “Adjustment SO” in order to allow the mirroring flow (i.e. be able to automatically post the vendor invoice document on
P&L cost accounts)
Attention point
- To avoid system regression, this control can be performed only if the sale order document type is ZMIA. All others document
type is out scope.
- The cost assignment objects must exist in the system.

- The cost assignment objects must be valid in order to allow the mirroring flow (for the good receipt done the cost element must
be valid).
The checking of the cost center is based on the comparison of its validity period and the Schedule line date of the item of the ZMIA
SO.
Validity period of the

Cost center
Schedule line date of the

item of the ZMIA SO
So, the functional process regarding the management of the cost center has to be as described below:
 Compare the validity period of the cost center and the Schedule line date of the item of the ZMIA SO. We can have
different cases:
- Case 1: The checking is succeeded

=> It means that the validity period of the cost center and the Schedule line date of the item of the ZMIA SO are aligned.
- Case 2: The checking is failed

=> It means that the validity period of the cost center is not aligned to the Schedule line date of the item of the ZMIA SO.

System is unable to do the control describes in the business rule only for document type ZMIA.
- The system must check the document type, if the sale order document type is ZMIA.
- Then the system has to control if the cost assignment objects exist in the system.
o if the cost assignment objects doesn’t exist, the system must display a message error
o If the cost assignment objects is not valid for this good receipt, the system must display a message error

3.2 Screen design
Not applicable
Selection screen functional Details
Field Translatio Multiple/ Mandatory/ Defaul Notes/ Scree Lengt Type

descriptio n Single Optional t Value Rules n shot h
n 3.3
Order text EN Single M N/A N/A Max 17 CHAR Sta
FR
ETC.
rting Conditions :

4 Security Requirements/ Authorization Details
.
Creation of a new transaction [not relevant for BI]
Transaction description in SAP menu – EN version
Transaction description in SAP menu – FR version
Functional business description (short information about the

transaction, business process description)
Provide similar transaction or functionality
Update of an existing transaction [not relevant for BI]
Authorization Checks to perform The requirement is to create two news sale order document type in the system and
business requirement is to set up a control in order to ensure that only the current
scope of entities define in section “Business requirement summary” are authorized to
create a sale order with the two new sale order type.
Constraint
- The company code is an organization structure used in FI for document
creation.
- In sale and distribution, the organization code, distribution channel and division
is an organization structure used to create sale order document.
Expected result
Only the current scope of entities define in section “Business requirement summary”
are authorized to create a sale order with the two new sale order type.
5 Error handling
Error* or Warning Error/Warning How error/warning Error/warning Error/warning Corrective Actions
Message Condition message should message text – 70 message text
be reported characters (EN) translation (fill in
language FR)
Error (QC15604) If the field PO Pop up message Enter PO number Veuillez introduire Nº The user needs to
number is empty. on selection commande d'achat enter a PO number
NB: Nº message (Only for process 1) screen in message in the field “PO
VU001 / status area number”
Error (QC15604) If the field PO Pop up message Enter a valid PO Veuillez introduire Nº The user needs to
number is filled but on selection number before to commande d'achat enter a valid PO
doesn't exist in the screen in message save your Valide avant de number in the field
system. / status area document sauvegarder. “PO number”
(For process 1 and
process 2)
Error (QC15608) The user has put Pop up message Enter Sold-to with Renseigner un The user needs to
an incorrect entry in on selection the account group donneur d'ordre correct the input in
a field customer. screen in message Z001 appartenant au the field “Customer”
/ status area groupe de
compte Z001
Error (QC15611) The user has put Pop up message Profit center Centre de cout The user needs to
an incorrect entry in on selection XXXXXX does not XXXXXX inexistant correct the input in
Nº message a field cost center screen in message exist for au JJ/MM/ANNEE the field “cost
DD/MM/YYYY

KM026 / status area center”
NB: XXXXXX = cost

center
DD/MM/YYYY =
system date
*error does not allow further execution while warning does not stop a user from processing
6 Test cases
<Please provide the list of the test cases (both positive and negative) that would need to be performed to prove that
development is working as expected. Scope of the testing should be complex enough to test whether the rules of the
development are implemented. Negative testing should include error handling tests>
6.1 Test case New SO Type for Intragroup Customers only - QC15608
6.1.1 Positive test cases
This test has to be done for the two news sales order type.
Number Prerequisite Test steps Expected results

1 Valid user access and authorization to 1- Execute transaction VA01 New screen is display in order to enter
perform this test step and sale order type and sale area
information.
2 1- Enter the following value in the following New screen is display in order to enter
field of the transaction VA01 (screen sale information.
“Create sales order: Initial screen”):
- Sale order type = ZMIR or ZMIA

- Sale organization =
- Distribution channel =
- Division
Then press enter

3 1- Enter the following value in the following No message error
field of the transaction VA01
- Customer = (account group = group customer)
2- Then press enter.
6.1.2 Negative test cases
This test has to be done for the two news sales order type.

1 Valid user access and authorization to Execute transaction VA01 New screen is display in order to enter
perform this test step and sale order type and sale area
information.


- Division
Then press enter.

3 1- Enter the following value in the following - The following message error is
field of the transaction VA01 display “Enter Sold-to with the
account group Z001”.
- Customer = (account group =non-group
customer) - The user needs to correct the input
in the field “Customer”

6.2 New SO Type with default pmnt term Z001 - QC15606
This test has to be done for the two news sales order type

1 - Sale order type ZMIR is created 2- Execute transaction VA01 New screen is display in order to enter
- valid user access to perform this test sale order type and sale area
step information.

- Division
Then press enter

3 3- Enter the following value in the following The payment term is Z001

1 - Sale order type ZDIV is created Execute transaction VA01 New screen is display in order to enter
step information.
field of the transaction VA01 (screen sale order information.
- Sale order type = ZDIV

- Division
Then press enter.
3 3- Enter the following value in the following - The payment term is different of
field of the transaction VA01 Z001

6.3 Check PO number in SO - QC15604
6.3.1 Positive test cases ZMIR

step information.
- Sale order type = ZMIR

- Division
2- Then press enter

3 1- Enter the customer ID No message error

4 1- Enter the PO number No message error
- The purchase order number = (Purchase order

number must exist in the system)
2- Then save the document
6.3.2 Negative test cases ZMIR

step information.
- Sale order type = ZMIR

- Division
2- Then press enter


4 1- Enter the PO number - The following message error is
display “Enter PO number”
- The purchase order number = empty
- The user needs to enter a PO
2- Then save the document number in the field “Customer”
5 1- Enter new PO number - The following message error is

display “Enter a valid PO number
- The purchase order number = 1234567890 before to save your document”
2- Then save the document - The user needs to correct the input
in the field “PO number”

6 1- Enter new PO number No message error

6.3.3 Positive test cases ZMIA

1 - Sale order type ZMIA is created 1- Execute transaction VA01 New screen is display in order to enter
step information.
- Sale order type = ZMIA

- Division
2- Then press enter


4 1- The PO number is empty No message error
- The purchase order number =
2- Then save the document.
6.3.4 Negative test cases ZMIA

1 - Sale order type ZMIA is created 1- Execute transaction VA01 New screen is display in order to enter
step information.

- Division

2- Then save the document.

4 1- Enter new PO number - The following message error is
display “Enter a valid PO number
- The purchase order number = 1234567890 before to save your document”
2- Then save the document - The user needs to correct the input
in the field “PO number”
5 1- Enter new PO number No message error for the PO number


6.4 New field in SO item for recording the cost center - QC15611

step information.

- Division
Then press enter

3 1- Enter the following value in the following

4 1- Enter material
5 1- Enter the cost center open

1 - Sale order type ZDIV is created Execute transaction VA01 The following screen is display
- valid user access to perform this test “Create sales order: Initial screen”
step
field of the transaction VA01 (screen sale order information.

- Division
Then press enter.

3 1- Enter the following value in the following - The payment term is different of
field of the transaction VA01 Z001

4 1- Enter Material -
5 1- Enter cost center which doesn’t exist in Profit center XXXXXX does not exist for
the system DD/MM/YYYY
-
6 1- Enter a cost center with a validity period in Profit center XXXXXX does not exist for
the past. DD/MM/YYYY
-

7 FSR Quality Gate (CoE consultant)
<Below questions should be answered by CoE consultant to verify if the FSR is clear and if work on FSD may start. If
any of the below questions answer would be “No” when it is not justified (e.g. when Aris link does not exist) then
approval of the FSR should not take place and document should be returned to the MPRD owner for correction>
Quality Controller
ID Question Yes/No Name and Last
Name
1 Are all the mandatory sections filled in?
2 Is the business process clarified?
3 Is the business process flow graph provided?
4 Are the selection screen details given?
5 Are the enhancement execution details given?
6 Is the desired outcome provided?
7 Are the translations available in all cases?
8 Are all authorization details clarified?
9 Are both positive and negative test cases given?
10 Are there prerequisite approval steps passed
successfully?
11 Is the error handling provided?

BUG - 15620 - FSR-Enhancement-QC15608-New SO Type For Intragroup Customers Only - V3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BUG - 15620 - FSR-Enhancement-QC15608-New SO Type For Intragroup Customers Only - V3

Uploaded by

Copyright:

Available Formats

AGORA

Functional Specification Requirement document for

Author: Mamadou TOGOLA

Date Created: 15-09-2017

FSR_Template: ENHANCEMENT 06/07/2015 Page 1 / 26

SAP System / Module ECC

Scope of requirement: VESA

Document Change History

Initial / Reason for change QC number QC GRC Author Date

FSR Template: Enhancement 06/07/2015 Page 2 / 26

3.1.1 CORE - Mirroring process implementation - SD customizing (QC 15620)............................9

6.1.1 Positive test cases..............................................................................................................16

6.2.1 Positive test cases..............................................................................................................18

6.3.1 Positive test cases ZMIR....................................................................................................19

6.4.1 Positive test cases..............................................................................................................21

FSR Template: Enhancement 06/07/2015 Page 3 / 26

FSR Template: Enhancement 06/07/2015 Page 4 / 26

FSR Template: Enhancement 06/07/2015 Page 5 / 26

2 Business process flow

Process step description

2 - Manual creation of Sales Order (SO) in the selling company

4 - Posting of the customer invoice in the accounting of the Selling company

5 - The Buying company performs the good receipt manually

FSR Template: Enhancement 06/07/2015 Page 6 / 26

Process step description

1 - Manual creation of Sales Order (SO) in the selling company

3 - Posting of the customer invoice in the accounting of the selling company

FSR Template: Enhancement 06/07/2015 Page 7 / 26

Process step description

Optional adjustment flow

FSR Template: Enhancement 06/07/2015 Page 8 / 26

3.1 Enhancement description

3.1.1.1 Business requirement

3.1.1.2 Action required

3.1.1.2.1 Business requirement for news order type

Sales order type Document type Document type Comment

3.1.1.2.2 Business requirement for billing document type

3.1.1.2.3 Business requirement for accounting document type)

To check with FI team.

FSR Template: Enhancement 06/07/2015 Page 9 / 26

3.1.2.1 Business requirement

3.1.2.2 Action required

3.1.2.2.1 Business requirement for news order type

Sales order type Document type Document type Comment

3.1.2.2.2 Business requirement for billing document type

3.1.2.2.3 Business requirement for accounting document type)

To check with FI team.

FSR Template: Enhancement 06/07/2015 Page 10 / 26

3.1.3.1 Business requirement

3.1.3.1.1 Business rule

3.1.3.1.2 What the system is unable to do

Today the control describes in the business rules doesn’t exist.

3.1.3.1.3 What the system must do (expected result)

The system must do the following control:

- Requirement 1 (Only for Process 1)

- Requirement 2 (Process 1 and process 2)

FSR Template: Enhancement 06/07/2015 Page 11 / 26

3.1.4.1 Business requirement

3.1.4.1.1 Business rule

3.1.4.1.2 What the system is unable to do

3.1.4.1.3 What the system must do (expected result)

- The system must check the document type.

FSR Template: Enhancement 06/07/2015 Page 13 / 26