Report Specification

Customer: [ Chobani ]
RICEF/Issue Number [ ]
Module(s): [ OTC ]
Specification Name: [ SAP - OTC – Freight Cost App ]
Brief Description: [ ]
Related RICEF(s): [ ]
Created By: [ Vinod Kumar ]
Document Date: [ 05/16/2023 ]
Target Completion Date: [ ]
Priority Level (Low, Medium,
[ Medium ]
High):
Reusable Object(Yes/No): [ Yes / No ]

Contact Information:
Company / Phone
Name Email
Role #
Client Owner Dan
BPIM
(BPO) Wengerhoff
Functional Owner
Vinod Kumar OTC
(Consultant)
Technical Owner (Consultant)

Developer

Change History:
Section
Date Revised By Description of Change
Changed
05/15/202 Vinod
Original
3 Kumar
Vinod
5/19/2023
Kumar
Vinod
5/23/2023 Removed reporting requirements
Kumar
Vinod Updated based on the review
5/19/2023
Kumar discussion

Functional/Technical Estimate Information:

(Represents the functional/technical effort for analysis, development and unit testing)

Functional Effort Technical Effort

Estimate hours
694397197.doc 1 of 21
REV - MAY 2011
Report Specification
Actual hours

694397197.doc 2 of 21
REV - MAY 2011
Report Specification
Instructions:
CRP/BLUEPRINT PHASE:
Section 1 Voice of the Customer (VOC) – All fields in light blue are required for the high-level
specification. This section is completed by the Client Owner (BPO).

Section 2 Response of the Consultant (ROC) – All fields in black are required for the RICEF justification.
This section is completed by the Functional Owner (Consultant).

 Sections 1 & 2 comprise the High Level Functional Spec.

They are required prior to leaving the CRP/Blueprint phase.

 Functional Owner (consultant) and BPO Sign-off Required.

SOLUTION PERSONALIZATION/REALIZATION PHASE:

Section 3 Functional Design – All fields in dark blue are required for a complete functional specification.
This section is completed by the Functional Owner (Consultant).

 Functional Design Sign-off Required.

Section 4 Technical Design – All fields in orange are required for a complete technical specification.
This section is completed by the Technical Owner (Tech Lead located onsite unless other is
specified).

 Technical Design Sign-off Required.

Section 5 Technical Documentation – All fields in red are required for complete technical
documentation, including documented unit test results. This section is completed by the
Developer.
Section 6 Functional Testing Results – All fields in purple are required for complete documentation of
functional testing. This section is completed by the Functional Owner (Consultant).
Section 7 User Acceptance Testing Results – All fields in green are required for complete
documentation of user acceptance testing. This section is completed by the Client Owner
(BPO).

 User Acceptance Testing Sign-off Required.

 Exceptions copied to the project Issues List.
 Transports released and migrated to QA.

694397197.doc 3 of 21
REV - MAY 2011
Report Specification

Approvals / Sign-offs:

Functional Design (section 3)

Electronic Signature Date
Functional Owner (Consultant)
Client Owner (BPO)

Technical Design (section 4)

Electronic Signature Date
Technical Owner (Technical Lead)

User Acceptance Testing Results* (section 7)

Electronic Signature Date
Client Owner (BPO)
(*with exceptions noted below)

Issue #
Priority Description of Exception
(optional)

Final Acceptance Agreement

Electronic Signature Date
Project Manager
Client Owner (BPO)

694397197.doc 4 of 21
REV - MAY 2011
Report Specification
Section 1: Voice of the Customer (VOC) – 5 W’s and a H
To be completed by the Client Owner (BPO)

WHAT: Functional Description: (Short description of the required report)

WHY: Business Benefit / Need: (Short description of the why the report is needed, impact if report is
not implemented)

WHO/ WHERE: Who will be using this or where will it be used? (Who are the stakeholders?
Which BPOs, departments, and users will benefit? Identify the organizational units: plants, sales organizations,
etc.)

WHEN: When will this be used? (Daily, weekly, monthly, annually, etc.)

This will be used on a daily / weekly basis.

HOW: Input: (Functional description of the input)

HOW: Process: (Describe the process, what the program should do on functional level)

HOW: Output: (Functional description of the output)

Additional Comments: (Add any additional information necessary to assist in development as needed)

.
[Insert attachment here]

694397197.doc 5 of 21
REV - MAY 2011
Report Specification
Section 2: Response of the Consultant (ROC)
To be completed by the Functional Owner (Consultant)

Alternatives Considered: (A listing of the various alternative approaches that were considered – i.e. Standard
SAP Reports, BI reports, SAP Query, LSMW, Manual Process, etc.)

Numbe Descriptio Pro Con

r n s s

Agreed Upon Approach: (Which alternative was selected?)

Important Assumptions:
.

Additional Comments: (Add any additional information considered during the decision making process)

.
[Insert attachment here]

694397197.doc 6 of 21
(Report Spec Form – v6)
Report Specification
Section 3: Functional Design
To be completed by the Functional Owner (Consultant) Rework(Y/N) Yes

Reference SAP R/3 Transactions/Tables/Programs: (Include all known transactions, tables and
programs that are used, or reports containing similar data. Screenshots are recommended.)

We have a third-party partner Koerber (formerly enVista) that collects, collates, and validates
freight related invoices from our carriers / vendors and sends the validated invoice to Chobani on
a weekly basis.
The invoice is then processed in our system and payment is made to Koerber. Subsequently
Koerber makes the payment to the partners.
Currently, Koerber sends us the invoice PDF and a corresponding xls file with load id level details
over email. This information is used to post the invoice in our system manually.
We plan to automate this process by developing a BTP App that will allow Koerber to upload the
invoice PDF and xl file and create invoice in SAP with status as ‘Parked/Hold’. Subsequently our
AP team will post the Parked invoice manually in SAP.
This App will be used by Koerber team as well as Chobani team (if required).
Users will need SAP access to log into the App.
The app will have the following landing page:

When the Login button is clicked, the system will check if the user / password exists in SAP
system. If authentication is successful then the next screen will be shown and if the
authentication fails, the error message will be shown as per below:

When the user clicks on OK button, Username and password fields will be cleared and user will be
able to enter the user name and password again.

7 of 21
Report Spec Form v5 – REV: FEB 2009
Report Specification
Upload Process:
User with the Upload access will have the following landing page:

Invoice Number / Invice Date/ Total Amount will be entered by the user.
Invoice Number will be validated for duplication against RBKP- XBLNR If invoice has been posted
with the same invoice number already then app will show an error ‘’ Invoice already exits/ posted
for CHOB2023191 ‘’
Invoice Date will have a calendar attached so user can select the required date. User should also
be able type the date manually.
Total Amount will be entered manually by the user. Invoice details will be uploaded in the form of
xl file and PFD invoice.
All of the above mentioned fields are mandatory.
User can click on Back button to abort the processing and re-upload the files.
When the Next button is pressed, following high level validations will be carried out:
1. All fields on the screen are mandatory, error if any one the fields in empty
2. File format check else error “File format is not allowed’’. Valid format - pdf and Excel.
3. Total Amount field should have more than zero
If high level validations are successful then the line level validations will be carried out and
errors(if any) will be shown in the next screen as per below:

8 of 21
Report Spec Form v5 – REV: FEB 2009
Report Specification
Invoice Amount – From input as entered by user
Total Amount – sum of all lines (will be changed auotmatically if a line in updated)
This screen will show item level details alongwith errors (color code -red) /sucesss (color code-
green). User should be able to sort/ filter rows on the screen based on error / success, Laod id,
Order, Order Type, SCAC, G/L, Cost Center, Amount.
User should be allowed to change / update any field to clear errors (similar to spreadsheet)

Following fields need to be validated:

-SCAC Code:LFA1-SCACD- no need to valiate this field
-Load Number: Get the Load Number from the xl file and check if it exists in table
ZTMS_STAGE_DOCS - LOAD_ID
-Order: Get the BOL# from the xl file and check if it exists in table ZTMS_STAGE_DOCS -
DOC_NUM.
-Combintion of Load Number and Order should also be validated against table
ZTMS_STAGE_DOCS, if combination does not exist then error should be shown- ‘’Order xx and
Laod Numebr yy combination does not exist in TMS table’’
-Invoice / Run # from xl file should be checked against the Invoice # entered by the user in the
landing page. If it does not match then error should be shown- ‘Invoice Number entered vs xl file
does not match’’
-Total Amound Due at line level: should be more than zero

-Total Invoice Amount: All lines total also should match the total of invoice.
-Currency: should be USD
Search Logic:
To clear the errored lines, user can click on the respective error field on search button by
selecting a errored lined; and the following pop-up will appear:

User can enter one or more parameters in the above screen and click on the Search button. On
clicking the the Search button, follow information will be fetched from table (ZTMS_STAGE_DOCS
and ZTMS_HEAD)

9 of 21
Report Spec Form v5 – REV: FEB 2009
Report Specification

Fields:
Load id: ZTMS_STAGE_DOCS - LOAD_ID {In case of load id value ‘blank’ fixed value (e.g NS) or
3PL (where SCAC code is ‘USCP’) load id validation can not be done but order can be vaidated }
Order: ZTMS_STAGE_DOCS - DOC_NUM, orders that do not exit in ZTMS_STAGE_DOCS to be
validated from table VBAK- VBELN for sales order and from EKKO- EBELN for STO /PO
Order Type: ZTMS_STAGE_DOCS - DOC_ID
SCAC: ZTMS_HEAD- LOAD_SERVICE_AGENT for the corrosponding Load id.
When user clicks on Update button, the information from the search pop-pup will be updated on
the error screen for the selected line. In case of multiple lines on the search pop-up user will need
to select one of the lines and click on Update button to update the errored line.
If value does not exist for the parameters entered, then the following error will be shown:
‘’No value found ‘’
User should be able to Save her work so that in case of interruption she is able to resume her
work.
Invoice amount and Total amount should match before the invoice can be posted. If there is a
mismatch, then error should be shown. ‘’Invoice amount does not match’’.
Total amount field can be chnaged only for decimal points to allow rounding error match if any.
Once all the errors have been cleared and all validations are successful, user will click on the
Submit button to post the invoice with hold status (RBK- RBSTAT= D)
Invoice Posting Scenarios:
Xls file can have different types of of load number.
Load Id Format (Regular example - LD00446515)
G/L Account Description Comments Load ID format
0061600300 Repairs & Maintenance - Other Load Id -Blank
0065401080 Frt Fruits & Flavors PO Load id starting with regular format
0065401130 Frt Dry Ingredients PO Load id starting with regular format
0065406000 Freight - Plant to Plant FG STO Load id starting with regular format

0065407000 Freight - Plant to DC FG STO Load id starting with regular format

0065408000 Freight - Plant to Customer FG Customer order from 3PL Load it not to be used from XLS file
0065409000 Freight - DC to Customer FG Customer order from TF/SE Load id starting with regular format

0065412000 Freight Outbound Cream Load Id = NS

0065000000 Postage & Mailing Services Second file No load id/ Blank

10 of 21
Report Spec Form v5 – REV: FEB 2009
Report Specification
When Submit button is pressed, the file will be processed and invoice doucment will be created
with Parked status. PDF document will also be attached to the invoice document and an email
notification will be generated for the AP team to inform them to process the invoice.

Email format:
Sub: Freight Cost Upload Alert: RUN# CHOB2022071

Invoice #5100096508 Created with Status -Hold by user VKUMAR for vendor-21021 Korrber.
(we can have the email id in TVAR table)

AP team will then go to MIR4 and post the invoice after verification.

Data received after uplaod will be processed in SAP and a single invoice document with status
‘Parked/Hold’ will be created.
Only one invoice will be posted for one file /Invoice Number (Run#)

11 of 21
Report Spec Form v5 – REV: FEB 2009
Report Specification
As a pre-requisite PGI check needs to be carried out for all deliveries in a load number. Based on
load id fetch the deliveries from table ZTMS_STAGE_DOCS- VBELN and check if the PGI has
happened for all the deliveries (LIKP- WBSTK = ‘C’). If PGI has not happened for one of more
deliveries in the load Id, then it will be errored out.

Following fields will be used to process the invoice:

Assuming the invoice will be posted for one vendor (Envista) number only.
-Invoice date- current date
-Posting Date- current date
-Reference – Invoive Number
-Amount- amount for the load id from the file
-Tax id-(Ignore for now or default to I0 if required for BAPI)

Possible BAPI for invoice posting:

BAPI_INCOMINGINVOICE_CREATE /BAPI_INCOMINGINVOICE_PARK /
BAPI_INCOMINGINVOICE_CHANGE/ BAPI_INCOMINGINVOICE_POST)
In case of error where system is not able to post an invoive for a certain line, error message will
appear on the output screen for the failed line and there will not be any invoice created.

Invoice Processing Logic for different Scenarios:

A)Load Id with Regular Format (Customer order from TF/SE, PO,STO)

System will check if the laod id is in regular format, if yes then Invoice will be processed based on
the key field of Load Id with reference to ‘Delivery Note in MIRO’’ for the corrosponding amount.
Posting to be made with reference to Delivery Note (same as Load Id)
12 of 21
Report Spec Form v5 – REV: FEB 2009
Report Specification
Multiple load id can be processed at a time.
Note – we are internally discussing PO scenario and there might be a change for PO related
invoice posting)
B)Customer Orders from 3PL (Load id in regular format)
Orders fulfilled from our 3PL partner have load id in the regular format in the xls file however this
laod id does not exist in SAP system and hence can not be used for invoice posting. For 3PL
orders we need to get the laod id from SAP as per below logic:
Get order (BOL#) from xls file where SCAC=USCP

Now pass these orders to table ZTMS_STAGE_DOCS - DOC_NUM and get the Laod Number
ZTMS_STAGE_DOCS - LOAD_ID.
This load id now can be used to process invoice in the same way as explained in Option A.
C)No Load Id/ Fix Value of Load Id (‘NS’) (MRO/Creame/ Postage)
If load id field is blank or has fixed value (e.g NS) then the load id will be ignored and posting will
be made on the G/L account directly.

G/L Account- from the uploaded file

Amount – from the uploaded file
Note- New 3PL partner scenario - TBD

13 of 21
Report Spec Form v5 – REV: FEB 2009
Report Specification
Unplanned Delivery Cost:
Since we are using multiple G/L accounts while posting freight expense, amount field will be
populated from ‘planned freight cost’ from shipment /PO condition and will not be available for
updading the amount from xls file.
Calculate the difference between Total Invoice Amount and Planned Freight Cost and pass it on to
the ‘’Unplanned Delivery Cost’’ field as per below:

During invoice posting, Unplanned Delivery Cost will be distributed over the respective G/L
account automatically.
Unplanned Delivery Cost= Total Invoice Amount – { Sum of cost from TMS table (ZTMS_HEAD -
LOAD_COST for load id in scenarion A and B) + Cost from XL file for scearion C}

[Insert attachment here]

Input/ Selection Criteria: (What should the user see on the selection screen?)

Parameter Name Special Requirements Reference

Required /
(as it should appear on the (Single value or range of values, checkbox, radio Table-
Optional
selection screen) button, match code, etc.) Field

Process: (Describe the process, what the program should do, if possible in form of a flowchart)

.
[Insert attachment here]

Output/Report Layout: (Description of the layout and screen information, columns, headings, summations, etc.)

Column Title
Reference Table- Group Drill
(as it should appear on the report Sort Hotspot Description
Field Level Down
output)

14 of 21
Report Spec Form v5 – REV: FEB 2009
Report Specification

[Insert attachment here]

Use of ALV List Viewer (yes or no?) (If left blank ALV Grid will be used)- YES- should have option of
sorting / filtering / Variant Creation/ Export Data/ Download data in xls format

.
Special Functionality: (List any additional functionality required, such as drill-down/hotspots, links to
other transactions, etc.)

Error Handling: (Owner Definition & Business Needs)

.

Frequency: (How often will the report be run?)

Data Volume:
.

Security Requirements: (Describe any security considerations requiring explicit authorization checks
within code or special processing considerations)

Yes/No
No Specific Restrictions
Restriction Based on Certain
Criteria (ex: Restricted
by Sales area?)

Other
Comments:
[Insert attachment here]

Data Sensitivity: (Plant/Level of restrictions, please explain)

15 of 21
Report Spec Form v5 – REV: FEB 2009
Report Specification
Unit testing: (Information the developer can use to unit test the application. This needs to include test
scenarios, instructions, test data, and expected results )

Test Condition / Input Values

Steps Involved Expected Results
Test Scenario (Test Data)

[Insert attachment here]

Additional Comments: (Add any additional information necessary to assist in development as needed)

.
[Insert attachment here]

Rework Log: (The version shown above is the latest, this area may contain previous version(s) of the same
section)
.
[Insert attachment here]

16 of 21
Report Spec Form v5 – REV: FEB 2009
Report Specification
Section 4: Technical Design
To be completed by the Technical Owner (Onsite Tech Lead) Rework(Y/N) Yes

Design Points: (Describe anything that will make the definition of the design more clear, including:
calculations and formulas, particular conditions where the program should behave differently,
recommendations, etc. If applicable, include recommendations or concerns regarding performance. )

Error Handling: (Owner Definition and Technical Components)

Error Messages:
Issue that triggers message Message Text Msg.
ID
NO Data selection as per the Inputs on No Data Available NA
selection screen

Special Configuration Settings/Assumptions: (Describe any special or temporary pre-requisite

configuration requirements)

Additional Comments: (Add any additional information necessary to assist in development as needed, ex.
performance concerns)

.
[Insert attachment here]

Rework Log: (The version shown above is the latest, this area may contain previous version(s) of the same
section)
.
[Insert attachment here]

694397197.doc 17 of 21
(Report Spec Form – v5)
Report Specification
Section 5: Technical Documentation
To be completed by the Developer Rework(Y/N) No

Report Information:
Report Name:
Package:
Custom Function Modules Created:
Custom Dictionary Items Created:
Custom Transaction Codes:
Other Custom Objects:
Development Plan:
Transport Request(s):

Actual Hours Spent: (Including technical documentation, development, and testing)

Offshore Estimate Breakdown: (Provided by offshore partner)

.
[Insert attachment here]

Offshore Approach Document: (Provided by offshore partner)

.
[Insert attachment here]

Unit Test Results: (Attach documents/ screenshots)

Test Condition / Testing
Expected Results Actual Results Tested By
Test Scenario Date

[Insert attachment here]

Development Objects: (Attach the objects & add screenshots if necessary – programs, table definitions,
and search helps, etc.)

.
[Insert attachment here]

694397197.doc 18 of 21
(Report Spec Form – v6)
Report Specification

Rework Log: (The version shown above is the latest, this area may contain previous version(s) of the same
section)
.
[Insert attachment here]

Code Inspector: (Insert screen shots of code inspector below)

.

694397197.doc 19 of 21
(Report Spec Form – v6)
Report Specification
Section 6: Functional Test Results
To be completed by the Functional Owner (Consultant)

Functional Testing: (Document test date, results, & notes/attachments )

(List the test date and results of functional testing, please provide all test data and how the test was executed)

Dat Result Note

e s s

[Insert attachment here]

Errors, Bugs, and Corrections: (Document the fixes required)

(List the problems encountered and changes required. Provide this list to the developer for revisions.)

Design
Number Date Description Change or Proposed Fix
Bug Fix?

[Insert attachment here]

694397197.doc 20 of 21
(Report Spec Form – v6)
Report Specification
Section 7: User Acceptance Test Results
To be completed by the Client Owner (BPO)
[Functional Owner (consultant) should communicate to development team]

User Testing: (Document test date, test results & notes/attachment) (List the date and
results of user acceptance testing here. Any issue found at the end of user acceptance test should be listed here.
If there are remaining issues left to be addressed at the end of user acceptance testing, a sign-off can be given
with the expectation that remaining issues will be addressed before the start of integration testing.)

.
[Insert attachment here]

694397197.doc 21 of 21
(Report Spec Form – v6)