Customisation - Functional Specification Enhancements in Debrief

7/30/2019 Customisation - Functional Specification Enhancements in Debrief

1/12

Functional SpecificationProduct/Project: Doc.No: Issued By: Date: Page::

Vital Asim Siddiqi 19/11/2012 1(12)Title:

Enhancements in Debrief

Document Revision History

Revision Date By Remarks

A1 19/11/2012 Asim Siddiqi Created.

1 INTRODUCTION 3

1.1 Background and Purpose 3

1.1.1 Foundation for Functional Specification 4

1.2 Scope 4

1.2.1 Return of Stock Error! Bookmark not defined.

1.2.2 Load List Reconciliation Error! Bookmark not defined.

1.3 Related Customizations 5

1.4 Delimitations Error! Bookmark not defined.

2 FUNCTIONALITY DESCRIPTION 5

2.1 Return of Stock Error! Bookmark not defined.

2.1.1 Explanation Error! Bookmark not defined.

2.1.2 Functional Solution 5

2.1.3 Client Implementation 7

2.2 Load list Reconciliation 82.2.1 Explanation 8


2.3 Credit Charges on Reconciliation ID Error! Bookmark not defined.

2.3.1 Explanation 10



2/12

Title: Date: Page:

Enhancements in Debrief 19/11/12 2

This document has been approved by:

Date / Name of IFS Solution Designer Date / Name of Customer Process Manager

or authorized Customer Process Specialist


3/12

Title: Date: Page:


1 IntroductionThis 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 thatthe 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 thiscustomization. Make sure that this matches what has been agreed.

Related Customizations identifies any customizations that are related to thisone.

The Functionality Description describes how the user is supposed to interactwith 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 PurposeDebrief process will happen when the truck and crew return from delivery where thepossibility 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.


4/12

Title: Date: Page:


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 SpecificationThis requirement was raised by Vital Distribution as a critical requirement for business.

1.2 ScopeThe 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.

B.)Admin Debrief / Load List Reconciliation Screen: 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 (In24 hour format i.e. hh:mm).

An additional tab is needed to capture the Invoice Nos which are beingreconciled on that Reconciliation Id.

For 3rd Party functionality, add some more fields on the AOD tab of Load ListReconciliation screen.


5/12

Title: Date: Page:


1.3 Related CustomizationsNoneCustomization ID Customization Name Comments

None

2 Functionality DescriptionDebrief 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 Stock Return Additional Fields Needed2.1.1 ExplanationThe 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 thecorrect Principal Id through the Sales Part Cross Reference master.

2.1.2 Functional SolutionThe 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.


6/12

Title: Date: Page:


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.


7/12

Title: Date: Page:


2.1.2.1 PrerequisitesAppropriate Data must exist on the Sales Part Cross Reference master, for the site on which

one needs to work.

2.1.2.2 ValidationPrincipal Id on the line level must have validation against the Principals Product Code from

the Sales Part Cross Reference table.

2.1.3 Client ImplementationThis functionality is going to be part of Vital Distribution implementation.

2.1.3.1 Window behaviorSystem will allow user to create stock return header and save it, and then user will captureline details and will be able to save it without any validation.

2.1.3.2 NavigatorThe form is placed in Customer Order --> Return Material Authorization - Stock Return

2.1.3.3 Screen Shots and FunctionsThe proposed Stock Return Header outlook:

The proposed Stock Return Line level outlook:


8/12

Title: Date: Page:


2.2 Load list Reconciliation Additional Fields NeededLoad 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

ExplanationThe following are the additional fields which are needed:

1. Trailer 1 End Km2. Trailer 2 End Km3. 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 SolutionThe 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 field2. Trailer 2 End Km - This shall be a number field3. 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 havethe (2012/10/02 09:05:58 AM) format.


9/12

Title: Date: Page:


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 PrerequisitesLoad list should be in delivered status.

2.2.2.2 System effectsNone

2.2.2.3 ValidationNone

2.2.2.4 Window behaviorThe 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.


10/12

Title: Date: Page:


2.2.2.5 Navigator PositionReconciliation 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 AddedA 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 ExplanationA 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 receivedand 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 SolutionA 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.


11/12

Title: Date: Page:


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 PrerequisitesThere must be Load lists in the delivered status.

2.3.2.2 System effects2.3.2.3 ValidationNone

2.3.2.4 Window behavior


12/12

Title: Date: Page:


2.4 Load List Reconciliation Other Enhancements2.4.1 ExplanationWhile 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 Solution2.4.2.1 PrerequisitesThere must be Load lists in the delivered status.

2.4.2.2 System effects2.4.2.3 ValidationNone

2.4.2.4 Window behavior

Customisation - Functional Specification Enhancements in Debrief

Documents