Business Requirement Document for Fleet Management System 1 Table of Content Section Content Description Number 1 Customer Section 2 Driver Section 3 Vehicle Section 4 Product Section 5 Location Section 6 Booking Section 7 Maintenance Section 8 Inspection Section 9 Dashboard Section 10 IT Section Page Number 3–9 10 – 12 13 – 19 20 – 22 23 – 27 28 – 33 34 – 37 38 – 41 42 – 44 45 – 49 2 Customers Section 3 1. Purpose: Purpose of this section is to capture customer’s information. BVM needs to be able to create new customer, and amend the existing customer when necessary. 2. Detail Requirement: i. Customer Type: • BVM needs to be able to capture two types of customer being Individual Customer and Entity Customer. o Individual Customer is customer who is a legal person. o Entity Customer is customer who is a legal entity. ii. Customer Category: • BVM needs to be able to categorize the customers, either Individual or Entity, into three categories being Wholesaler, Dealer, Client. o Wholesaler is Individual/Entity who is, on a contractual basis, purchase goods from BVM and distribute to other BVM clients. o Dealer is Individual/Entity who, on a contractual basis, purchases goods from BVM for retailing or for use. o Client is Individual/Entity who, on a non-contractual basis, purchases goods from BVM for retailing or for use. Client is also referred to customer who purchases goods from BVM’s Wholesaler; therefore, when creating Client, the customer may/may not need to be linked to Wholesaler’s Number (Customer Number of the Wholesaler). iii. Required Information: • For Individual Customer: when selected Individual Customer below should be the required information fields. No. 1 2 3 Data Field First Name Last Name Phone Number Data Input Type Alpha Alpha Numeric 4 Email Address Alpha Numeric 5 Password Alpha Numeric 4 Mandatory Data Field Description Yes First Name of the customer. Yes Family Name of the customer. Yes o Phone Number of the customer. o BVM should be able to add additional line to input another phone number should the customer has. However, the addition is nonmandatory. No o Email address of the customer. o BVM should be able to add additional line to input another email address should the customer has. Yes o Password which customer uses to log into Customer Mobile Application. o Password must at least have 8 characters which is a combination of alpha character, numeric character, and special character. 6 Customer Number Numeric Yes 7 Contract Number Alpha Numeric No 8 Contract Expiry Date Date (DD/MM/YY) No 9 ID Type List of Value Yes 10 ID Number Alpha Numeric Yes 11 ID Issue Date Date (DD/MM/YY) Yes 12 ID Expiry Date Date (DD/MM/YY) Yes 13 Credit Term (Days) Numeric No 14 Credit Limit (USD) Numeric No 15 Gender List of Value Yes 5 o The password combination can later be amended by BVM internal IT team if necessary. o Unique number used to identify customer in the Fleet Management System. o Customer number should be automatically generated when BVM creates a new customer. o It should start with 0000001 (six digits of zero and incremental number starting from number one). o This field must not be editable. o Number referencing to the Sales Purchase Contract between BVM and the customer. o Expiry date of the Sales Purchase Contract between BVM and the customer. o Type of the customer’s Legal Identification document. o List of Value should contain 2 values: o NID (National ID) o Passport o NID or Passport number of the customer. o Issue date of the customer’s NID or Passport. o Validation Requirement: this date cannot be postdated. o Expiry Date of the customer’s NID or Passport. o Validation Requirement: o This date cannot be backdated. o This date cannot be earlier or equal to ID Issue Date. o Maximum credit repayment term of the customer. o Maximum credit limit of the customer. o Gender of the customer. o List of Value: o Male o Female 16 Address Line 1 Alpha Numeric No. Data Field 1 Entity Name 2 Representative Name 3 Phone Number Data Input Type Alpha Numeric Full Alpha 17 18 19 20 21 22 23 4 o Customer’s house number and street number. Address Line 2 Alpha Numeric Yes o Khan or District Address Line 3 Alpha Numeric Yes o Sangkat or Commune Address Line 4 Alpha Yes o City/Province Billing Address Alpha Numeric No o Billing address of the customer which is to be filed on the invoice. o There should be a button called “Same as Customer’s Address” which allows user to click to copy customer address line 1 to line 4 into bill address. Formula should be: “Address Line 1” + “,” + “space” + “Address Line 2” + “,” + “space” + “Address Line 3” + “,” + “space” + “Address Line 4”. Wholesaler’s CID Numeric No o Wholesaler’s Customer Number that needs to be linked with the Client category customer. o A validate button need be created next to this field to allow user to validate their input. o When clicked, Wholesaler’s Full Name should be displayed. Refer to below. Wholesaler’s Name Alpha No o Wholesaler’s Full Name (Wholesaler’s Last Name + Wholesaler’s First Name) retrieved automatically after user clicks Validate Button in the above requirement. Customer Location Alpha Numeric No o Customer location code in BVM’s Code current accounting system. • For Entity Customer: when selected Entity Customer below should be the required information fields. Email Address No Numeric Alpha Numeric 6 Mandatory Data Field Description Yes Full Name of Entity Customer Yes Full Name of the entity customer’s representative. Yes o Phone Number of the customer. o BVM should be able to add additional line to input another phone number should the customer has. However, the addition is nonmandatory. No o Email address of the customer. 5 Password Alpha Numeric Yes 6 Customer Number Numeric Yes 7 Contract Number Alpha Numeric No 8 Contract Expiry Date Date (DD/MM/YY) No 9 Registration Number Alpha Numeric Yes 10 11 Patent Number Representative Legal ID Type Alpha Numeric List of Value Yes No 12 Representative’s Legal ID number Representative’s ID Issue Date Alpha Numeric No Date (DD/MM/YY) No Representative’s ID Expiry Date Date (DD/MM/YY) No 13 14 7 o BVM should be able to add additional line to input another email address should the customer has. o Password which customer uses to log into Customer Mobile Application. o Password must at least have 8 characters which is a combination of alpha character, numeric character, and special character. o The password combination can later be amended by BVM internal IT team if necessary. o Unique number used to identify customer in the Fleet Management System. o Customer number should be automatically generated when BVM creates a new customer. o It should start with 0000001 (six digits of zero and incremental number starting from number one). o This field must not be editable. o Number referencing to the Sales Purchase Contract between BVM and the customer. o Expiry date of the Sales Purchase Contract between BVM and the customer. o Registration number of the entity customer. o Number of the Patent. o Type of the representative’s Legal Identification document. o List of Value should contain 2 values: o NID (National ID) o Passport o NID or Passport number of the representative. o Issue date of the representative’s NID or Passport. o Validation Requirement: this date cannot be postdated. o Expiry Date of the representative’s NID or Passport. o Validation Requirement: This date cannot be backdated. o This date cannot be earlier or equal to ID Issue Date. o Maximum credit repayment term of the customer. o Maximum credit limit of the customer. o Customer’s house number and street number. o Khan or District o Sangkat or Commune o City/Province o Billing address of the customer which is to be filed on the invoice. o There should be a button called “Same as Customer’s Address” which allows user to click to copy customer address line 1 to line 4 into bill address. Formula should be: “Address Line 1” + “,” + “space” + “Address Line 2” + “,” + “space” + “Address Line 3” + “,” + “space” + “Address Line 4”. o Wholesaler’s Customer Number that needs to be linked with the Client category customer. o A validate button need be created next to this field to allow user to validate their input. o When clicked, Wholesaler’s Full Name should be displayed. Refer to below. o Wholesaler’s Full Name (Wholesaler’s Last Name + Wholesaler’s First Name) retrieved automatically after user clicks Validate Button in the above requirement. o Customer location code in BVM’s current accounting system. o 15 Credit Term (Days) Numeric No 16 Credit Limit (USD) Numeric No 17 Address Line 1 Alpha Numeric No 18 19 20 21 Address Line 2 Address Line 3 Address Line 4 Billing Address Alpha Numeric Alpha Numeric Alpha Alpha Numeric Yes Yes Yes No 22 Wholesaler’s CID Numeric No 23 Wholesaler’s Name Alpha No 24 Customer Location Alpha Numeric No Code iv. Customer’s Reference Requirement: • Customer’s reference(s) is required to be uploaded by BVM for both individual or entity customer, when creating new customer. Customer reference document to be uploaded shall be: o Image file or PDF file 8 v. o Mandatory • Multiple files or references are allowed to be uploaded. • When uploading new files or references, the new upload should override the older version. Other Rules: • Customer, once created, cannot be deleted from the system. • Used customer number cannot be recycled. • Maker/checker principle must be applied to all customer creation and amendment. • Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. • Before approving the record, approval must be able to check every point of data input by the maker. 9 Driver Section 10 1. Purpose: Purpose of this section is to capture driver’s information. BVM needs to be able to create new driver, and amend the existing driver when necessary. 2. Detail Requirement: i. Required Information: When creating driver, below should be the required information fields. No. 1 2 3 Data Field First Name Last Name Gender Data Input Type Alpha Alpha List of Value 4 Assigned Vehicle List of Value 5 Phone Number Numeric 6 7 License Number License Type Alpha Numeric List of Value Mandatory Data Field Description Yes First Name of the driver. Yes Family Name of the driver. No o Gender of the customer. o List of Value: o Male o Female No o Vehicle which the driver is assigned to. o All trucks created in the system should appears in the list. o When not selected, value should be “Null” meaning the driver is a spare driver. Yes o Phone Number of the driver. o BVM should be able to add additional line to input another phone number should the customer has. However, the addition is nonmandatory. Yes Driving license number of the driver. Yes o Type of driver’s driving license. o List of Value should be: o A1 (ក1) o A2 (ក2) o B (ខ) o C (គ) o D1 (ឃ2) o D2 (ឃ2) o BE (ងខ) o CE (ងគ) o DE (ងឃ) 11 8 License Issue Date Date Yes 9 License Expiry Date Date Yes 10 Password Alpha Numeric Yes 11 Employment Status List of Value Yes i. vi. o Issue date of the driver’s driving license. o Validation Requirement: this date cannot be postdated. o Expiry date of the driver’s driving license. o Validation Requirement: o This date cannot be backdated. o This date cannot be earlier or equal to License Issue Date. o Password which driver uses to log into Driver Mobile Application. o Password must at least have 8 characters which is a combination of alpha character, numeric character, and special character. o The password combination can later be amended by BVM internal IT team if necessary. o Status to show if driver is still in service with BVM or not. o List of value should be “In service”, “Resigned”, or “Dismissed”. Driver’s Reference Requirement: • Driver’s driving license is required to be uploaded by BVM for when creating new driver. • Multiple files or references are allowed to be uploaded (Optional). • When uploading new files or references, the new upload should override the older version. Other Rules: • Driver, once created, cannot be deleted from the system. • Maker/checker principle must be applied to all driver creation and amendment. • Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. • Before approving the record, approval must be able to check every point of data input by the maker. 12 Vehicle Section 13 1. Purpose: BVM needs to be able to create vehicle in the system so that the vehicle can later on be used to manage daily goods delivery. 2. Detail Requirement: i. Vehicle Type: • There are two types of truck that BVM is using for daily goods delivery: o Tanker Truck: Truck which the fuel tank and the truck head is attached to each other as a single body. o Prime Mover: Truck which tractor head and the semitrailer tank are separated from each other as separate components. ii. Required Information: Different vehicle type has different fields of information to captured. • For Tanker Truck: No. Data Field 1 Vehicle Type 2 3 4 5 6 7 8 9 10 11 Vehicle Brand Vehicle Model Vehicle Manufacturing Year Vehicle Registration ID Chassis/Frame Number Engine Number Vehicle Weight Gross Weight Vehicle Calibration Inspection Date Data Input Type Mandatory List of Value/ Yes Radio button Alpha Numeric Alpha Numeric Date (YYYY) Yes Yes Yes Alpha Numeric Yes Alpha Numeric Yes Alpha Numeric Numeric Numeric Date (DD/MM/YY) Yes Yes Yes Yes Vehicle Calibration Date Inspection Expiry (DD/MM/YY) Date Yes Data Field Description Type of vehicle to be created in the system. List of Value/Choices for selection should be: o Tanker Truck o Prime Mover Brand of the vehicle to be created. Model of the vehicle to be created. Year in which vehicle is manufactured. ID number of the vehicle obtained after being registered. Chassis or Frame Number of the Truck Engine number of the truck Weight of the truck. Maximum gross weight of the truck. The date in which the vehicle passed calibration. Validation Requirement: o Calibration inspection date cannot be postdated. The date in which the vehicle calibration is expired. Validation Requirement: o Calibration inspection expiry date cannot be backdated or earlier than Vehicle Calibration Inspection Date. 14 12 13 14 15 16 17 18 19 20 21 License Number Maximum Distance Plate Alpha Numeric Delivery Numeric Transportation Calibration Date Date (DD/MM/YY) Servicing Status License plate number of the vehicle Yes o The maximum distance in which the vehicle can deliver goods to customer. o This links to Booking in a sense that breaches the maximum delivery distance shall now be allowed and shall required special approval. Date which vehicle passed the transportation calibration requirement. Yes Transportation Date Calibration Expiry (DD/MM/YY) Date Vehicle Road Tax Payment Date Fuel Transportation Vehicle ID Number Fuel Vehicle Transportation ID Issue Date Pump Built-in Yes Yes Date (YYYY) Yes Alpha Numeric Yes Date (YYYY) Yes List Value/Radio Button of List of Value Yes Yes Fuel Consumption Numeric Rate/km Yes 15 Validation Requirement: o Transportation Calibration date cannot be postdated. Date which the transportation calibration requirement is expired. Validation Requirement: o Transportation Calibration expiry date cannot be backdated or earlier than Transportation Calibration Inspection Date. Year in which the vehicle road tax is paid. Fuel Transportation vehicle ID number of the truck Year in which the Fuel Vehicle Transportation ID is valid. Determine whether the truck has built-in pump or not. List of Value/Choices for selection should be: o Yes o No Status to show whether the truck is still in service. List of Value shall be: o Active o Disposed Fuel consumption rate of the truck. 22 Mileage 23 Insurance Policy Date (YYYY) Issue Date Scheduled Numeric Inspection Interval 24 25 Numeric 6 7 8 9 10 11 o o For Prime Mover: No. Data Field 1 Vehicle Type 5 Mileage of the truck. Mileage shall be automatically updated by adding the delivery distance every time a trip is assigned to the created truck. Yes Date which insurance policy of the truck is issued Yes o Interval of mileage in which a truck requires schedule inspection. Autogenerated o Mileage in which scheduled inspection is due. o This is to be recalculated after scheduled maintenance is created for the truck by adding Scheduled Inspection Interval to Inspection Mileage. Next Scheduled Numeric Inspection Mileage • 2 3 4 Yes Vehicle Brand Vehicle Model Vehicle Manufacturing Year Vehicle Registration ID Chassis/Frame Number Engine Number Vehicle Weight Gross Weight Vehicle Calibration Inspection Date Data Input Type Mandatory List of Value/ Yes Radio button Alpha Numeric Alpha Numeric Date (YYYY) Yes Yes Yes Alpha Numeric Yes Alpha Numeric Yes Alpha Numeric Numeric Numeric Date (DD/MM/YY) Yes Yes Yes Yes Vehicle Calibration Date Inspection Expiry (DD/MM/YY) Date Yes 16 Data Field Description Type of vehicle to be created in the system. List of Value/Choices for selection should be: o Tanker Truck o Prime Mover Brand of the vehicle to be created. Model of the vehicle to be created. Year in which vehicle is manufactured. ID number of the vehicle obtained after being registered. Chassis or Frame Number of the Truck Engine number of the truck Weight of the truck. Maximum gross weight of the truck. The date in which the vehicle passed calibration. Validation Requirement: o Calibration inspection date cannot be postdated. The date in which the vehicle calibration is expired. 12 13 14 15 16 17 18 19 20 License Number Maximum Distance Plate Alpha Numeric Yes Delivery Numeric Transportation Calibration Date Yes Date (DD/MM/YY) Yes Transportation Date Calibration Expiry (DD/MM/YY) Date Vehicle Road Tax Payment Date Fuel Transportation Vehicle ID Number Fuel Vehicle Transportation ID Issue Date Pump Built-in Semitrailer Model Yes Date (YYYY) Yes Alpha Numeric Yes Date (YYYY) Yes List Value/Radio Button of Alpha Numeric Yes Yes 17 Validation Requirement: o Calibration inspection expiry date cannot be backdated or earlier than Vehicle Calibration Inspection Date. License plate number of the vehicle o The maximum distance in which the vehicle can deliver goods to customer. o This links to Booking in a sense that breaches the maximum delivery distance shall now be allowed and shall required special approval. Date which vehicle passed the transportation calibration requirement. Validation Requirement: o Transportation Calibration date cannot be postdated. Date which the transportation calibration requirement is expired. Validation Requirement: o Transportation Calibration expiry date cannot be backdated or earlier than Transportation Calibration Inspection Date. Year in which the vehicle road tax is paid. Fuel Transportation vehicle ID number of the truck Year in which the Fuel Vehicle Transportation ID is valid. Determine whether the truck has built-in pump or not. List of Value/Choices for selection should be: o Yes o No Model of the semitrailer to be attached with the prime mover. 21 Semitrailer Brand Alpha Numeric Yes 22 Semitrailer Plate Number Semitrailer Manufacturing Year Semitrailer Calibration Date Semitrailer VIN Servicing Status Alpha Numeric Yes Date (YYYY) Yes Date (DD/MM/YY) Alpha Numeric List of Value No 23 24 25 26 27 28 29 30 31 Yes Yes Fuel Consumption Numeric Rate/km Mileage Numeric Yes Yes Year of manufacturing of the semitrailer. Date of the last semitrailer calibration. VIN of the semitrailer. Status to show whether the truck is still in service. List of Value shall be: o Active o Disposed Fuel consumption rate of the truck. Mileage of the truck. Mileage shall be automatically updated by adding the delivery distance every time a trip is assigned to the created truck. Yes o Date which insurance policy of the truck is issued. Yes Interval of mileage in which a truck requires schedule inspection. Autogenerated o Mileage in which scheduled inspection is due. o This is to be recalculated after scheduled maintenance is created for the truck by adding Scheduled Inspection Interval to Inspection Mileage. Insurance Policy Date (YYYY) Issue Date Scheduled Numeric Inspection Interval Next Scheduled Numeric Inspection Mileage iii. Brand of the semitrailer to be attached with the prime mover. Plate Number of the Semitrailer. o o Load and Compartment: • All truck must have its loading and compartment information so that booking can be done in accordance to the truck loading capacity and compartment arrangement. • Different truck carries different load and compartment arrangement. • Information to be captured are: No. Data Field 1 Total Load 2 Compartment 1 Data Input Type Numeric Numeric 18 Mandatory Data Field Description Yes Maximum load of the truck. Yes o Maximum load of compartment 1. o Additional line of compartment shall be available so user could add another compartment. When adding another compartment, information requirement #3 is added. There is not limit to the number of compartments that can be added. o When adding, information to be filled is mandatory always. o In correct addition can be removed. Additional compartment maximum load. o 3 Compartment 2, 3, n… Numeric iv. vii. Yes Vehicle’s Reference Requirement: • Below document are required to be uploaded: o Fuel Vehicle Transportation ID. o Transportation Calibration Document. o Vehicle Calibration Inspection. o Vehicle Registration ID. • When uploading new files or references, the new upload should override the older version. Other Rules: • Vehicle, once created, cannot be deleted from the system. • Maker/checker principle must be applied to all vehicle creation and amendment. • Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. • Before approving the record, approval must be able to check every point of data input by the maker. 19 Product Section 20 1. Purpose: BVM needs to be able to create product in the system. Product quantity needs to be managed to ensure accuracy of booking. 2. Detail Requirement: i. Product Type: • BVM has three types of product: o DO – Diesel oil o EA92 – Unleaded 92 gasoline o EA95 – Unleaded 95 gasoline ii. Required Information: All product types should have the same fields of information below No. Data Field 1 Product Type Data Input Type List of Value 2 Physical Stock Numeric 3 Stock Booked Delivery for Numeric 4 Available Stock Numeric 5 Reserved Stock Numeric 6 Physical Adjustment 7 Adjustment Note Stock Numeric List of Value 21 Mandatory Yes Data Field Description o Type of the product o List of value: o DO o EA92 o EA95 Automatic o This field shall be automatically calculated using below formula: Physical Stock = Beginning Physical Stock + Physical Stock Adjustment o Beginning Physical Stock when product first created is zero. Automatic This field shall be automatically calculated. Number should add up automatically when booking is made. Automatic This field shall be automatically calculated using below formula: Available Stock = Physical Stock - Stock Booked for Delivery Yes Amount of stock reserved for measurement prior to next stock intake. No Amount to be adjusted to Physical Stock when addition or subtraction is necessary. Yes (When o Reason to justify the Physical Adjustment Stock adjustment. is o List of value will be: recorded) o Addition for customer o Daily morning stock adjustment o Private truck delivery o Other – when other is selected a free text input field shall be provided for User to type other reason to justify stock adjustment. iii. iv. Daily Reconciliation: • On every T (Day) +1 basis, reconciliation should be done manually where stock controller will reconcile the daily inflow and outflow of stock. Once reconciliation is completed, daily settlement should be performed. • A settlement function is needed to manually perform this settlement. When settlement function is performed, below activities shall occur: a. Completed delivery on T (Day) will be settled with Stock Booked for Delivery. b. Same amount in (a) will be settled with Physical Stock so that physical stock will reduce. Other Rules: • All Automatically calculated value cannot be manually adjusted. • Maker/checker principle must be applied to stock adjustment, and reconciliation. • Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. • Before approving the record, approval must be able to check every point of data input by the maker. 22 Location Section 23 1. Purpose: BVM needs to be able to manage client’s location by categorizing the locations into cluster of Division Code, Location Code, and Route. This classification will allow us to effectively manage customer’s location for accurate delivery, and analytical purposes. 2. Detail Requirement: i. Location Division: • Geographically, Location Division is a section in the system used to define and manage the unique geographic location of the customer. It determines exactly which city/province, district, and down to commune level which the customer is located in. • All components of the Location Division shall be defined by unique numerical code. For example: Example 1 City/Province District/Khan Sangkat/Commune Location Name Phnom Penh 7 Makara Orussey 1 Division Code 12 1225 122504 Example 2 City/Province District/Khan Sangkat/Commune Location Name Siem Reap Angkor Chum Ta Som Division Code 17 1745 174507 • The unique numerical code shall be created and uploaded by BVM team. • Required Information: No. Data Field 1 Province/City Name Data Input Type List of Value 2 Province/City Code 3 District/Khan 4 District/Khan Code Numeric 5 Commune/Sangkat List of Value Mandatory Yes Data Field Description o Name of the province/city. o List of Value to be uploaded by BVM and shall be able to be updated whenever there is official update by the Royal Government of Cambodia. Autogenerated System should automatically retrieve Province/City Code, which is stored in the DB (uploaded by BVM team). Yes o Name of the District/Khan. o List of Value to be uploaded by BVM and shall be able to be updated whenever there is official update by the Royal Government of Cambodia. Autogenerated System should automatically retrieve District/Khan Code, which is stored in the DB (uploaded by BVM team). Yes o Name of the Commune/ Sangkat. o List of Value to be uploaded by BVM and shall be able to be updated whenever there is official update by the Royal Government of Cambodia. Numeric List of Value 24 6 Commune/Sangkat Code Numeric 7 Division Code Numeric Autogenerated System should automatically retrieve Commune/Sangkat Code, which is stored in the DB (uploaded by BVM team). Autogenerated Division Code shall be the same as the autogenerated Commune/Sangkat Code. • ii. Other Rules: o All Automatically calculated value cannot be manually adjusted. o Maker/checker principle must be applied to Location Division creation. o Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. o Before approving the record, approval must be able to check every point of data input by the maker. Station: • Station refers to station of the customer, which is the location to which goods is to be delivered. • Station shall also be identified by unique code which is known as “Location Code”. Location Code shall be identical to Location Code stored in BVM’s accounting system. • BVM already store Location Code in the existing accounting system. Therefore, in order to speed up station creation, BVM should be able to upload the station in bulk into Fleet Management System. • BVM shall be able to upload Location Code to fleet management system and able to update by creating new location code in the fleet management system. • Required Information: No. Data Field 1 Station Name 2 Location Code 3 4 5 Data Input Type Alpha Numeric Alpha Numeric Maximum DO Storage DO Storage Type Maximum Storage EA92 Mandatory Yes Yes Numeric No Radio Button Yes Numeric No 25 Data Field Description Name of the customer station. Location Code of the customer station, which is identical to the Location Code in BVM’s accounting system. Maximum DO storage in customer’s station. o Define whether the storage of the customer is underground or floated. o Choices should be: o Underground o Floated Maximum EA92 storage in customer’s station. 6 EA92 Storage Type Radio Button Yes 7 Numeric No 8 Maximum EA95 Storage EA95 Storage Type Radio Button Yes 9 Division Code Numeric Yes 10 Distance Numeric Yes 11 Customer ID Alpha Numeric Yes 12 Numeric Yes 13 Station Contact Number Station Type List of Value Yes 14 Premise Type List of Value Yes (When End User is selected for Station Type) 15 Route List of Value No 16 Mission Allowances Numeric Yes 26 Define whether the storage of the customer is underground or floated. o Choices should be: o Underground o Floated Maximum EA95 storage in customer’s station. o Define whether the storage of the customer is underground or floated. o Choices should be: o Underground o Floated o Division code linked to the station. o The code is to be fetched from Division Code listing stored DB. Distance between BVM warehouse to and from the customer’s station. o Customer ID linked to the station. o The ID is to be fetched from customer ID listing stored on the DB. o Phone number which can contacted to reach the station. o Type of station created. o List of Value shall contain three choices: o BVM Station o BVM Depot o End User When End User is created User needs to input Premise Type. o Nature of the end user’s premises. o List of value is to be fetched from list of End User Premise Type listing in DB (uploaded by BVM). o Route linked to the station. o The code is to be fetched from Route listing stored DB. o Mission Allowance to be provided to driver during the delivery trip to this location. o • iii. Other Rules: o All Automatically calculated value cannot be manually adjusted. o Maker/checker principle must be applied to station creation. o Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. o Before approving the record, approval must be able to check every point of data input by the maker. Route: • Route is a cluster of locations which goods are delivered too. • Required Information: No. Data Field 1 Route Data Input Type Alpha Numeric 2 Region Alpha Numeric Yes 3 Main Road List of Value Yes • Mandatory Yes Data Field Description Identity of the route to be defined by BVM. Region covers within the geographic boundary of the route. o National Road covered without the boundary of the route. o The list of value is to be fetched from National Road listing stored DB (uploaded by BVM team). Other Rules: o All Automatically calculated value cannot be manually adjusted. o Maker/checker principle must be applied to route creation. o Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. o Before approving the record, approval must be able to check every point of data input by the maker. 27 Booking Section 28 1. Purpose: BVM needs to be able to use Fleet Management System to help manage daily delivery booking. Booking is to be able to be created from Fleet Management system itself. 2. Detail Requirement: i. Required Information: No. Data Field 1 Booking Date Data Input Type Date Mandatory Yes 2 Truck License Plate Number Alpha Numeric Yes 3 Location Code List of Value Yes 4 Customer Name Alpha Numeric Autogenerated 29 Data Field Description o Date of the delivery. o Backdate booking is not allowed. o Postdate booking is allowed for 3 days counting from today (T) date. That means booking is allowed for T, T+1, and T+2. o Truck license plate number to deliver goods. o Truck License Plate Number shall be fetched from Truck Listing in DB. o When fetching the truck license plate number, user need to be able to see the Total Load and Compartment Arrangement of the truck (number of compartment and load for each compartment). o Code defined location of the station to which the goods need to be delivered. o List of value can be fetched from Location Code listing stored on DB. o BVM should be able to add additional line to fetch another location code should the delivery is to be made to more than 1 location. When adding additional location code, the input is always mandatory. o Customer name shall be automatically generated from the location code fetched. o In case more than one location codes are selected, additional customer name shall also be automatically 5 Station Name Alpha Numeric Autogenerated 6 Driver Name Alpha Autogenerated* 7 Distance Numeric Autogenerated 8 Fuel for Mission Numeric Autogenerated* 9 Mission Allowance Numeric Autogenerated* 10 Allowance Type for Pump List of Value Autogenerated* 11 Allowance for Pump Numeric Autogenerated* 30 generated from the additional location code fetched. Station Name should be automatically generated from the location code fetched. o Driver Name to be fetched from Driver Listing. o Driver assigned to the selected truck should be nominated/selected automatically by the system. Distance should be automatically generated from the location code fetched. o Fuel required for the delivery mission. o Formula for calculation: Fuel for Mission = Fuel Consumption/KM multiplied by Distance. Distance should be automatically generated from the location code fetched. o Type of fuel to be allowed for pump. o List of value are EA92 and DO. o System shall check the vehicle selected for mission. If the Pump Built-in for the truck is Yes, the value to be selected is DO. If the Pump Built-in for the truck is No, the value to be selected is EA92. o Extra fuel allowance for pump in case the offload is to be done to floating tank. o System shall check all customer storage type (DO, EA92, and EA95) and the Allowance Type for Pump. o In case all storages are underground, Allowance for Pump should be zero o In case one of the storages are floating and product is to be offloaded to that 12 13 14 15 16 Allowance for City Detour Secondary Driver Name Extra mission allowance for Secondary Driver Specific Offloading Time Specific Number ii. Contact Numeric No Alpha No Numeric No List of Value No Numeric No particular tank, formula in Rule shall apply. Extra fuel allowance for city detour. Secondary driver to be assigned for the mission. Extra mission allowance for secondary driver. Specific offloading time required by the customer. o List of value are: o Day Time Offloading o Night Time Offloading Specific contact number that requires driver to contact for location information or offloading confirmation. o Compartment Arrangement: • When booking system must allow BVM team to arrange the compartment arrangement. Below are the tasks that needs to be perform when performing compartment arrangement: o Specify which Location Code the product in the compartment is to be delivered to. o Specify which product the compartment is loaded with. o Specify whether the compartment(s) is to be loaded as per its maximum load or whether the quantity to be loaded may be less than the maximum compartment storage. • In case quantity to be loaded may be less than the maximum compartment storage (Empty Compartment Delivery), dual approval between Operations Manager and Sales Manager are to be obtained or sole approval from CEO is to be obtained. Example of compartment arrangement is below: Example of compartment arrangement for an 8,000 liters truck booking Compartment Maximum Volume Product Location Code Station Name Explanation Number Load (Liter) Load (Liter) 1 2,000 2,000 DO BVM20.168.77 BVM Station This compartment Moung Russey is to be delivered to BVM Station Moung Russey. 2 2,000 2,000 EA92 BVM20.168.77 BVM Station This compartment Moung Russey is to be delivered to BVM Station Moung Russey. 31 3 4,000 iii. iv. 3,000 DO BVM20.168.44 BVM Station This compartment Ponley is to be delivered to BVM Station Ponley. This delivery needs to be dual approved by Operations Manager and Sales Manager or Sole Approval from CEO given the Volume to be loaded is less than the maximum load of the 3rd compartment of this truck. Booking Rule: • Formula for Trip determination: o If user select night time offloading, automatically this is a 2nd trip delivery. o If user select day time offloading, automatically this is a 1st Trip delivery. o If user select night time offloading, while 2nd trip had been booked, validate the Distance Formula. If Distance Formula validation result is "Okay", automatically this is a 3rd trip delivery. o If user select day time offload, while 1st trip delivery had been booked, validate the Distance Formula. If validation result is "Okay", automatically this is a 2nd trip delivery. • Distance Formula: o For 2nd Trip delivery: Distance of the 1st trip delivery does not exceed 162KM or Total distance of the 2 trips (1st and 2nd trip) added together does not exceed 430KM. o For 3rd Trip delivery: Distance of the 1st trip delivery does not exceed 100KM or Distance of the first two trips (1st and 2nd trip) added together do not exceed 170KM and Total distance of 3 trips (1st, 2nd, and 3rd trip) added together does not exceed 300KM. Other Rules/requirement: • All Automatically calculated value with * sign can be manually adjusted and overridden by Fleet Team with approval from Operations Manager, as long as it is before the delivery is started. • Maker/checker principle must be applied to Booking/cancellation creation. • Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. • Before approving the record, approval must be able to check every point of data input by the maker. 32 • • • • • When fetching truck to be selecting for booking, BVM should be able to see a list of trucks available as of date selected and by the order of trip (i.e. 1st Trip ,2nd Trip, or 3rd Trip). When booking is record is submitted by maker, email notification should be sent to approver as an alert for approval needed. When a truck is booked pending approval, truck shall not be able to be booked by other user unless after the current booking is not approved. Daily truck booking listing should be available for BVM to see the list of booked trucks. Fleet team has the right to override the trip order after the trip is booked, as long as it is before the delivery is started. Overridden is to be approved by Operations Manager. 33 Maintenance Section 34 1. Purpose: BVM needs to also manage truck maintenance/repair on Fleet Management System. Maintenance links directly to booking given its direct influence to the availability of the truck. 2. Detail Requirement: i. Maintenance: • Required Information: No. Data Field Data Input Type 1 Truck License Plate List of Value Number 2 Request Date Date (DD/MM/YY) 3 Truck Broken Date Date (DD/MM/YY) 4 Repair Issue List of Value 5 Maintenance Description Status Free Text Input Field List of Value 6 Mandatory Yes Data Field Description o License plate of the truck to be put under maintenance/repair. o List of Value should be fetched from Truck Listing stored on DB. Autogenerated o Date of which maintenance/repair is requested. o Request date should take the timestamp of the day the request is recorded. The date shall not be changed/edited. Yes o Date of which the truck had broken down. o Validation requirement: Truck Broken Date shall not be greater than Request Date. Yes o Issue which leads to repair. o List of value to be retrieved from Repair Issue listing stored in DB. Yes Description which documents the reason or root cause of the repair. Autogenerated o Status of the maintenance/repair. o List of value should be: o Submitted: Request is submitted pending approval. o Approved: Request is submitted and approved pending procurement of the repair service/required spare parts. o Procured: Procurement part of the maintenance/repair is 35 7 Completed 8 Completion Note Button No Free Text Input Field No completed pending repair. o Completed: Repair is completed. Truck at this stage should be moved back to available. o A button to confirm that repair is completed. Note to describe repair action done on the truck, and other comments from mechanic. • ii. Other Rules: o All Automatically calculated value cannot be manually adjusted. o Maker/checker principle must be applied to maintenance created/amended. o Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. o Before approving the record, approval must be able to check every point of data input by the maker. o When maintenance status is anything else besides “Complete”, the truck shall be automatically be “Under Maintenance” status. When the maintenance status is “Complete” the truck shall be back to “Available” status – meaning available for booking. Repair Issue: • When creating a maintenance, Repair Issue must be specified in order to categorize the issue that leads to the maintenance/repair. • BVM needs to create and maintain Repair Issue for analytical purpose and to support decision making when maintenance/repair is requested. • Repair Issue list shall be able to be created entry by entry on fleet management system, and update live to DB so that it can be, at the same time, retrieve for use as input in Maintenance record. • Required Information: No. Data Field 1 Repair Issue 2 Data Input Type Alpha Numeric Mandatory Yes Issue Description • Data Field Description Specific Issue involving maintenance Description of the repair issue. Free Text Input No Field Other Rules: o Maker/checker principle must be applied to Repair Issue created/amended. o Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. 36 the o Before approving the record, approval must be able to check every point of data input by the maker. iii. Repair Item: • Repair Item is to be input when raising new Maintenance/repair. • Required Information: No. Data Field 1 Vendor Name Data Input Type Alpha Numeric 2 Repair Item Alpha Numeric 3 4 Unit Cost Number of Unit Numeric Numeric 5 Expense Numeric • Mandatory No Data Field Description Vendor who provides spare parts or repair service. Yes Specific spare part or repair service to be replaced and repaired to complete the maintenance/repair. No Unit cost of the repair. Yes Number of unit(s) of spare part or service required to complete the maintenance/repair. Autogenerated o Expense of the repair. o Formula: Expense = Unit Cost multiplied by Number of Unit Other Rules/Requirement: o Repair Item might contain more than one line of item. Therefore, user shall be able to add additional line of items when necessary. o User should be able to extract Maintenance report in the form of PDF so that the document can be used as reference in BVM’s accounting system. 37 Inspection Section 38 1. Purpose: BVM conducts vehicle inspection regularly as part of vehicle maintenance regardless of whether the truck requires maintenance/repair or not. There are two types of maintenance to be conducted on regular basis which are: i. Daily Inspection: • Daily Inspection is conducted on daily basis before/after the delivery trip in order to conduct the very basic check of the truck. The aim is to spot the irregularity of the truck performance before it becomes major repair issue. • Daily Inspection is to be conducted by the driver and supported by the mechanic. ii. Scheduled Inspection: • Scheduled Inspection is conducted by the mechanic on scheduled basis, which is based on the actual usage of each individual truck. Similar to Daily Inspection, Scheduled Inspection aims to spot more specific irregularity or physical condition of the truck parts/components to determine if they need to be replaced before it causes major repair issue. Fleet Management System needs to be able to capture the result of the inspection for analytical purposes. 2. Detail Requirement: i. Inspection: • BVM needs to be able to build questionnaire template for both Daily Inspection and Scheduled Inspection, and keep record of the daily inspection result and view it in report template for analytical purpose. • Information Required for Questionnaire Template: No. Data Field 1 Inspection Type Data Input Type List of Value Mandatory Yes 2 Questionnaire Group Alpha Numeric Yes 3 Inspection Question Alpha Numeric Yes 4 Inspection Mileage Numeric Yes • Other Rules for Questionnaire Template: o Maker/checker principle must be applied to Questionnaire Template created/amended. 39 Data Field Description o Type of inspection in which the template is to be created for. o List of Value will have two choices: o Daily Inspection o Scheduled Inspection Group which the questionnaire belongs to. Group is to be built in order to categorize the questionnaire. Specific question (inspection item) to be checked and answered during the inspection within the Questionnaire Group. Mileage the as of the inspection date. • o Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. o Before approving the record, approval must be able to check every point of data input by the maker. o Questionnaire Template can be amended by adding additional questions or removing any questions when necessary. o All questions in the questionnaire template shall be a multiple choices questions with two radio button options as answer being: o Okay o Issue Found – when Issue Found is checked, below shall be available for input: a. Mandatory Free text input field is to be added underneath the questions for user to input the description of the issue discovered during the inspection on each and any of the specific question/item. b. Multiple input field of Repair Item(s) is to be input. Information Required for Inspection: No. Data Field 1 Inspection Date Data Input Type Date (DD/MM/YY) 2 Inspection Type List of Value 3 Questionnaire Radio Button • Mandatory Data Field Description Autogenerated Date of inspection which shall be automatically the date the record is created. Yes o Type of inspection to be performed. o List of Value shall be: o Daily Inspection o Scheduled Inspection Yes Questionnaire to be available for user to complete as per the selected Inspection Type, and shall follows the Questionnaires Template rules. Other Rules for Inspection: o Maker/checker principle must be applied to all Inspections record created. o Once record is submitted, second confirmation must be sought from user to request user to double check the record before submitting for approval or approving the record. o Before approving the record, approval must be able to check every point of data input by the maker. o Report shall be able to be generated to see result of any specific inspection or consolidated result of any specific truck(s). o In case any of the questions in the questionnaires is/are checked as “Issue Found”, system should check if the user would like to raise Maintenance request to fix the issue immediately. 40 o o When user confirms as “No”, questionnaire/inspection shall be submitted for approval. When user confirms as “Yes”, questionnaire/inspection shall be submitted for approval, and Maintenance screen shall pop-up for user to complete the Maintenance request. Repair Items listed in the questionnaire/Inspection record shall be automatically populated in the Maintenance screen to avoid duplication of work. 41 Dashboard Section 42 1. Purpose: Dashboard will help BVM monitor the information efficiently. There are two dashboards that is required to be available at Fleet Management System. i. CEO Dashboard: provides one of the major parts of the executive summary of the business to the top management. ii. Operations Dashboard: provides the insight for Operations Manager to have an overview of the critical parts of the daily operations. 2. Detail Requirement: i. CEO Dashboard: • Data Presentation: o Delivery Fact: - Total volume in liter of DO delivered (1) - Total volume in liter of EA92 delivered (2) - Total volume in liter of EA95 delivered (3) - Total volume in liter of delivery (1+2+3) - Total Number of Empty Compartment Delivery case - Total number of delivery trips - Total distance of deliver in kilometer - Total number of delivery location o Truck: - Total Number of truck on delivery/idle - Total Number of Maintenance case - Total Number of Inspection cases o Delivery Mission Consumption: - Total Fuel for Mission in liter (4) - Total Fuel allowance for city detour in liter (5) - Total Fuel allowance for pump as DO (6) - Total Fuel allowance for pump as EA92 (6.1) - Total Fuel consumption (4+5+6+6.1) - Total Mission Allowance in KHR currency o Stock: - Total DO consume for Addition for Customer (7) - Total EA92 consume for Addition for Customer (8) - Total EA95 consume for Addition for Customer (9) - Total Product consumption for Addition for Customer (7+8+9) - Total DO Daily Morning Stock Adjustment (10) - Total EA92 Daily Morning Stock Adjustment (11) - Total EA95 Daily Morning Stock Adjustment (12) - Total Product Daily Morning Stock Adjustment (10+11+12) - Total DO Private Truck Delivery (13) - Total EA92 Private Truck Delivery (14) - Total EA95 Private Truck Delivery (15) - Total Private Truck Delivery (13+14+15) - Total DO Stock Outflow (1+4+5+6+7+13) or (a) 43 ii. - Total EA92 Stock Outflow (2+6.1+8+14) or (b) - Total EA95 Stock Outflow (3+9+15) or (c) - Total Stock Outflow (a+b+c) o Booking Arrangement: - Number of booking cancellation - Number of booking amendment • Filtering Options: information shall be filterable by: o Province o Truck License Plate Number o Date Range o Product o Driver Name o Customer Location Code o Customer Name o Sales Representative Operations Dashboard: • Data Presentation: o Truck: - Number of Truck on Mission - Number of Truck returning from mission - Number of Truck Idle - Number of Truck Under Maintenance - Number of Truck Under Inspection o Maintenance: - Number of Truck Repair Day Count - Number of Truck Inspection Due in less than 500KM - Number of Truck Inspection Overdue - Number of Truck Calibration Due in 30 Days - Number of Transportation Calibration Due in 30 Days - Number of Truck Road Tax Expiry Due in 30 Days - Fuel Vehicle Transportation ID Expiry Due in 30 Days o Driver: - Number of Driver assigned to Truck - Number of Driver not assigned to Truck - Number of Driver License Due in 15 Days - Number of Driver License Expired o Task: - Number of Delivery Pending Confirmation • Filtering Options: o Date o Date Range o Route 44 IT Section 45 I. High level of business requirement of User Management Functionality Description User Management ⚫ ⚫ Role and access Right ⚫ ⚫ ⚫ ⚫ Data Management ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ System Management ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ ⚫ Fleet user management 1- Create user group 2- Verify user authorization 3- System terminate user 15min stand by 4- Moving user from HQ to WH Other existing functions UDF Management Allow Admin User to add user define field or dynamic values User management in the system Admin can set any form for any role Admin can set any button in form to access(Ex: Edit,Delete,Save,Search,List,…) Admin can active/deactive role Data Backup and Recovery Data Update Scalability of Data Storage Data Retention Legislation Data Architecture Data Resilience Data Standards and Policies Concurrency Metadata Data Partitioning Replication of Data Model Extensibility DBMS Transformation Service Levels Availability Management Change Management Configuration Management Capacity Management Performance Management Scheduling Management Storage Management Business Continuity Exception Management Event Management Incident and Problem Management Software Distribution System Support Issues 46 II. No 1 2 3 Data fields (User fields) Field name Log-in Name Display Name Start Date 4 Expiry Date 5 Password Validity 6 Start time 7 End Time 8 9 Role Mobile Phone1 Description Define Log-in Name Define Display Name Define Start Date of this user profile Define Expiry Date of this user Define the expiry date of the password and the frequency of password change. Define the Start time for the user. Define the End time for the user. Define the user Role Define phone number 1 10 11 Mobile Phone 2 Email Define Phone number 2 Define email 12 Active Format fields YYYYMMDD MMMDD Example: 20150830 PP0615 Syntax : HH:MM Syntax : HH:MM xxx-xxx-xxx(x) 099-977-756 Length string@xxxx.com/com.kh Ex:seang.chhay@bvmpetroleum.com Define if user active. “Yes” or “No”. If set to “No” user could not access the system. 13 Menu Define the Menu that user will use s/he log-in 14 Attempts Indicate the number of attempt this user has. 15 Access Define Office ID in All, WH,HQ place(WH,HQ) which this user can access. Multiple office separated by Space. Type “ALL” for all Office(WH,HQ) 16 Restrict Office Define Office ID in which this user could transact to. III. Functionality Requirement No. Requirement Function Feature Description I User Login 1. Login User must login so that that the system can determine his access level. 2 Basic Flow - The use case starts when a user indicates that he wants to login. 47 1. The system requests the username and password. 2. The user enters his username and password. 3. The system verifies the username and password against all registered users(4). 4. The system starts a login session and displays a welcome message based on the user's preferences. 3 Alternative Flows: 4 Business Rules 1 2 Register User New register Basic Flow II 5. if username is invalid, the use case goes back to requestion username & password. 6. if the password is invalid the system requests that the user re-enter the password. When the user enters another password the use case continues with step 4 using the original username and new password. Some data and functions are restricted to certain types of users or users with a particular access level. a new user must register a username and password. - The use case start when a user indicates that he wants to register. 1. The system requests a username and password. 2. The Admin enters a username and password. 3. The system checks that the username does not duplicate any existing registered usernames. 4. The system requests a name (*), phone and email address. Items marked by (*) are required. 5. The Admin enters the information. 6. The system determines the user's location and access level and stores all user information. 7. The system executes use case Register Preferences. 8. The system starts a login session and displays a welcome message based on the user's preferences. 48 Alternative Flows - If the username duplicates an existing username the system displays a message and the use case goes back to step 2. If the user does not enter a required field, a message is displayed and the use case repeats step 4. 49
0
You can add this document to your study collection(s)
Sign in Available only to authorized usersYou can add this document to your saved list
Sign in Available only to authorized users(For complaints, use another form )