Functional Specification

Product/Project: Doc.No: Issued By: Date: Page::

Vital
Title:

Asim Siddiqi Enhancements in Debrief

19/11/2012

1(12)

Document Revision History

Revision A1 Date 19/11/2012 By Asim Siddiqi Remarks Created.

INTRODUCTION

3 3 4 4 Error! Bookmark not defined. Error! Bookmark not defined. 5 Error! Bookmark not defined. 5 Error! Bookmark not defined. Error! Bookmark not defined. 5 7 8 8 8 Error! Bookmark not defined. 10 10

1.1 Background and Purpose 1.1.1 Foundation for Functional Specification 1.2 Scope 1.2.1 Return of Stock 1.2.2 Load List Reconciliation 1.3 1.4 2 Related Customizations Delimitations FUNCTIONALITY DESCRIPTION

2.1 Return of Stock 2.1.1 Explanation 2.1.2 Functional Solution 2.1.3 Client Implementation 2.2 Load list Reconciliation 2.2.1 Explanation 2.2.2 Functional Solution 2.3 Credit Charges on Reconciliation ID 2.3.1 Explanation 2.3.2 Functional Solution

Title:

Date:

Page:

Enhancements in Debrief

19/11/12

This document has been approved by:

Date / Name of IFS Solution Designer

Date / Name of Customer Process Manager or authorized Customer Process Specialist

Title:

Date:

Page:

Enhancements in Debrief

19/11/12

Introduction

This document describes a customization to IFS Applications and represents the foundation for the implementation of a customization that covers the identified purpose in a way that satisfies the requirements for the solution. It is sometimes be difficult to understand a Functional Specification, but it is still necessary to have a formal approval of the document before developing the solution. We recommend the following reading method: The Background and Purpose paragraph states why a customization is needed. This description is the foundation for the definition of the solution, consequently if this is not correct; there is little reason to expect the proposed solution to be relevant. The Scope, defines what will be delivered. It should be possible to verify that the suggested deliveries are likely to satisfy the needs for customizations described as the Background and Purpose for the customization. The Delimitations describes what is explicitly not covered by this customization. Make sure that this matches what has been agreed. Related Customizations identifies any customizations that are related to this one. The Functionality Description describes how the user is supposed to interact with the solution and how the solution will be implemented. Verify that this matches the definition of the Scope and that the suggested solution covers the requirements.

1.1

Background and Purpose

Debrief process will happen when the truck and crew return from delivery where the possibility is that they would have managed to deliver everything that was on the load list or few products were not delivered which will then be returned. There is also a possibility that at the Delivery address, Customer has given some products to take it back and warehouse it for them. VITAL need option to capture the opening and closing Km readings of their trucks, trailers and their Start and End Times. Further it is required that there should be only 1 stock return record for each load which is being debriefed, irrespective of the no. of principals to which the various stock items belong.

Title:

Date:

Page:

Enhancements in Debrief

19/11/12

A functionality is required to check that the Petty cash given to the driver gets knocked off at the time of raising the AOD. At any point of time, there could be more than 1 user working on a Reconciliation Id. Hence multiple users should be able to work upon each Recon id, wherein each user select a different group of lines and reconciles. The user who counts the Invoice, does not need to see the details of the invoice. Hence we need to provide a separate tab, called Invoices, which would only show the Invoice Nos and hence the user can just check the Invoices which were received and shall not need to go and select each line of the invoice. 1.1.1 Foundation for Functional Specification

This requirement was raised by Vital Distribution as a critical requirement for business.

1.2

Scope

The scope of this customization is to develop the debrief functionality required to bridge the Gap. The purpose of this document is to serve the following enhancements: A.) Physical Debrief / Stock Return Screen: Fields needed to record the Opening and Closing Km reading of the truck. Principal Id should be removed from the header of Stock return screen and to be added as a column at the line level. The user shall type the Product No. in case there are multiple parts with the same part no. (from multiple Principals), then a pop-up box will come up and the user can select the appropriate value. The Application must check the amount of Petty cash, which is outstanding on that load list. 2 additional fields needed i.e. to capture Trailer 1 End Km, Trailer 2 End Km. These fields shall be mandatory for only some users. 2 more fields are needed to capture the Start Trip Date and End Trip Date (In 24 hour format i.e. hh:mm). An additional tab is needed to capture the Invoice Nos which are being reconciled on that Reconciliation Id. For 3rd Party functionality, add some more fields on the AOD tab of Load List Reconciliation screen.

B.) Admin Debrief / Load List Reconciliation Screen:

Title:

Date:

Page:

Enhancements in Debrief

19/11/12

1.3
None

Related Customizations
Customization Name Comments

Customization ID None

Functionality Description

Debrief process must happen for each and every load list that is send out for delivery. The process starts with physical debrief where a user captures the product that is brought back by the truck which went out for delivery. At this point the physical debrief user will have no visibility what was send out for delivery and he accepts and records all products that came back. All the documents like Load list, Invoices, Proof of delivery are handed over to user in Admin debrief department where reconciliation happens with respect to the quantity delivered for each invoice line and proof of delivery exists. The user in admin debrief also analyses the possible reason of returns and the person responsible for the reason of return. records products that are lost or damaged.

2.1
2.1.1

Stock Return Additional Fields Needed

Explanation

The following changes are required: 1. Remove the field named Principle id from the header of the Stock Return screen. 2. Add a new field named Start Kilometer, wherein the users can capture the Start Kilometer reading of the Truck. It should be a Numeric field similar to the existing field named End Kilometer. 3. Add a field named Principal Id on the line level, which should validate for the correct Principal Id through the Sales Part Cross Reference master.

2.1.2

Functional Solution

The following changes are required: 1. Remove the field named Principle id from the header of the Stock Return screen. 2. Add a new field named Start Kilometer, wherein the users can capture the Start Kilometer reading of the Truck. It should be a Numeric field similar to the existing field named End Kilometer.

Title:

Date:

Page:

Enhancements in Debrief

19/11/12

On the line level an additional field named Principal Id is required. This field shall have validation w.r.t the field named Principals Product Code. The user will enter Principal code and tab to Product code column, if the user clicks on list of values, system should filter and display only product codes linked to Principal as maintained on Sales part cross reference, or if the user manually keys in the product code and tabs to go to quantity column, and if the same product code is setup for multiple principals, system should display a POP up window with all principals who are linked with that product code. Hence, as soon as the user selects the Principals Product Code, the system should automatically fetch the Principal Id in that field.

In case there are 2 or more principals with the same Principals Product Code, the Application must pop-up a box wherein it should bring up all the values and the user should then be able to select the correct one, which he needs to.

Title:

Date:

Page:

Enhancements in Debrief 2.1.2.1 Prerequisites

19/11/12

Appropriate Data must exist on the Sales Part Cross Reference master, for the site on which one needs to work. 2.1.2.2 Validation Principal Id on the line level must have validation against the Principals Product Code from the Sales Part Cross Reference table. 2.1.3 Client Implementation

This functionality is going to be part of Vital Distribution implementation. 2.1.3.1 Window behavior System will allow user to create stock return header and save it, and then user will capture line details and will be able to save it without any validation. 2.1.3.2 Navigator The form is placed in Customer Order --> Return Material Authorization - Stock Return 2.1.3.3 Screen Shots and Functions The proposed Stock Return Header outlook:

The proposed Stock Return Line level outlook:

Title:

Date:

Page:

Enhancements in Debrief

19/11/12

2.2

Load list Reconciliation Additional Fields Needed

Load list reconciliation process is required for each and every delivery that goes out for delivery to respective customer address, as the customer only pays for the completed delivery according to proof of payment issued. Any losses or damages in the delivery process is on delivery company account which in turn tries to identify the person responsible to recover the value of losses or damages. 2.2.1 Explanation

The following are the additional fields which are needed: 1. Trailer 1 End Km 2. Trailer 2 End Km 3. Start Trip Date & Time (1 field only) 4. End Trip Date & Time (1 field only) 5. 3rd Party AOD Values per person 2.2.2 Functional Solution

The following are the 4 new fields which need to be added on the header of the Load List Reconciliation screen: 1. Trailer 1 End Km This shall be a number field 2. Trailer 2 End Km - This shall be a number field 3. Start Trip Date & Time (1 field only) - This shall be a date & time field and shall have the (2012/10/02 09:05:58 AM) format. 4. End Trip Date & Time (1 field only) This shall be a date & time field and shall have the (2012/10/02 09:05:58 AM) format.

Title:

Date:

Page:

Enhancements in Debrief

19/11/12

Further, we need to add 5 fields on the AOD tab for the 3rd Party AOD Value/Person. They should be in line with the fields under the heading AOD Value Recovered. i.e. The user should be able to enter any numeric values in these fields and save it.

2.2.2.1 Prerequisites Load list should be in delivered status. 2.2.2.2 System effects None 2.2.2.3 Validation None 2.2.2.4 Window behavior The Application must allow the user to capture the details in the new fields as long as the Load List Recon screen is not in the Reconciled state.

Title:

Date:

Page:

Enhancements in Debrief 2.2.2.5 Navigator Position

19/11/12

10

Reconciliation of Load List form is placed in Customer Order --> Return Material Authorization --> Reconciliation of Load List

2.3

Load List Reconciliation New Tab to be Added

A new tab called Invoices needs to be added and should appear as the first tab on the Load List Reconciliation screen. This tab shall contain only 2 columns i.e. Invoice received and Invoice No. 2.3.1 Explanation

A new tab called Invoices needs to be added and should appear as the first tab on the Load List Reconciliation screen. This tab shall contain only 2 columns i.e. Invoice received and Invoice No. This shall be the default tab which the user sees when he opens this screen. This tab shall display only unique Invoice Nos. and shall not show any duplicates. 2.3.2 Functional Solution

A new tab called Invoices needs to be added and should appear as the first tab on the Load List Reconciliation screen. This tab shall contain only 2 columns i.e. Invoice received and Invoice No. This shall be the default tab which the user sees when he opens this screen. This tab shall display only unique Invoice Nos. and shall not show any duplicates. Further we need the same validation (between the Invoice Count field on the header and the Invoice Received columns) which presently exist on the Connected Order Lines tab. Hence if the Invoice Count entered on the header does not match the no. of Invoices, the Application will give the same Invoice Count Mismatch Error. The user shall then have to come and select each invoice individually. If however, the Invoice count matches the no. of invoices, then all the checkboxes shall get ticked. Further, this effect shall be replicated to the Connected Order Lines tab. i.e. if the Invoice Received checkbox for a particular Invoice No. say 96 is checked on the Invoices tab, then the corresponding Invoice Received checkboxes for all the lines related to that Invoice No. shall also get ticked on the Connected Order Lines tab. Also the POD status shall change to clean.

Title:

Date:

Page:

Enhancements in Debrief

19/11/12

11

The rest of the functionality should continue to work in the same way, as it works currently. Further on the Connected Order Lines tab, we need to rename the field Delivery Note No. to Invoice No.

2.3.2.1 Prerequisites There must be Load lists in the delivered status. 2.3.2.2 System effects 2.3.2.3 Validation None 2.3.2.4 Window behavior

Title:

Date:

Page:

Enhancements in Debrief

19/11/12

12

2.4
2.4.1

Load List Reconciliation Other Enhancements

Explanation

While saving the header of Load List Reconciliation screen, the Application must give a Warning message that XXX amount of Petty Cash is still outstanding on this Load. This XXX amount can be fetched from the Petty Cash field on the General tab of the Customer Order Load List screen.

2.4.2

Functional Solution

2.4.2.1 Prerequisites There must be Load lists in the delivered status. 2.4.2.2 System effects 2.4.2.3 Validation None 2.4.2.4 Window behavior