FS 291227 PROD Supimix Web Client: Difference between revisions
From Calidus HUB
| Line 89: | Line 89: | ||
*Run the following sql against the Steel DB, replacing all fields marked with *, with the relevant values. | *Run the following sql against the Steel DB, replacing all fields marked with *, with the relevant values. | ||
"INSERT INTO websupport_users (wu_client, wu_project, wu_site, wu_product, wu_user, wu_pass, wu_name, wu_contact) | "INSERT INTO websupport_users (wu_client, wu_project, wu_site, wu_product, wu_user, wu_pass, wu_name, wu_contact) | ||
VALUES ('*client*','*project*','*site*','*product*','*user*','*password*','*name*','*contact')"; | VALUES ('*client*','*project*','*site*','*product*','*user*','*password*','*name*','*contact')"; | ||
Latest revision as of 16:27, 18 April 2012
OBS
Supimix Web Client
CALIDUS Supimix
3rd Jan 2012 - 0.1
Reference: FS 291227
Contents
Functional Overview
Client Requirement
The Client (being potentially all OBS clients), DHL will need access to the Supimix system allowing for easy logging of TIDs and potentially other calls.
They will require access to view log activity only.
Solution Overview
A ASP .NET solution has been developed. This has gone through several revisions, and now remains at v0.1.
Scope
Set-up
Pre-requisites
- IIS
- .NET Framework 4.0
- Informix SDK installer
Menu Structure
Data
This runs from the Informix database hosted on Steel.
System Config
The host machine requires the following configurations:
- Installation of Informix Client SDK version 3.70 xC1
- Network access to steel
- Services adding for the Informix TCP/IP services
sqlexec 1528/tcp ---No Longer Needed informix1 1529/tcp #Informix server
- IIS
- .NET 4
Functional Description
System Functionality
The system provides the following functionality:
- User access restrictions
- OBS users can access everything and can log/update calls for all clients.
- Client users cannot update calls and can only view log relating to their client.
- Call logging
- View and update call details
- Attach files relating to the log
- Email based on events (status updated, details updated ect)
User Access
The Web Client provides user access control, limiting users access to Supimix's content based on the users account settings.
The users account must exist both as a member of staff within supimix with a client flag set and a record within the Web Support table which holds their access details and level. Internal users will require this configuration as well.
Access will initially be given to Julie Scott, Julie Ann Taylor, Peter Greer and myself for testing purposes.
Once released to production, Peter Greer will specify the users to be given access.
Access from the application to the Steel machine and Database will be setup using a specified netowrk user account.
To add users to the system:
*Create a new staff record
*Run the following sql against the Steel DB, replacing all fields marked with *, with the relevant values.
"INSERT INTO websupport_users (wu_client, wu_project, wu_site, wu_product, wu_user, wu_pass, wu_name, wu_contact)
VALUES ('*client*','*project*','*site*','*product*','*user*','*password*','*name*','*contact')";
Note: Only the client field is used by the system at this time.
Testing
Internal testing has been completed using the SEC client within supimix.
Testing for the Client aspects of the system will be compelted externally by Peter Greer, this will include UAC testing.
First Call testing for the purpose of internal use (helpdesk) will be preformed by Julie Ann Tayor.
Test to Production
Once the current version of the system has been approved both internally (no bugs found during external texting) and externally (UAC), the system will need to be migrated from the testing environment to a production machine with external web access, ideally hosted under a OBS domain.
Migration of Other Web Systems
Functionality provided in other web system will need to be identified and migrated. During this phase any additional functionality required will need to be assessed.
Basic requirements for WEB Supimix for ease of logging for Firstcall (OBS Helpdesk) - JAT
Facility to;
- Add a new incident
- Update an incident
- View an incident
Ability to log ‘new incidents’
- Populate default values where possible dependent on client code entered ie support queue and product code.
- Populate default values dependent on site code entered ie project, job codes.
- To provide drop down list for easy entry (using current supimix maintained tables).
- To have the facility to send automatic external emails for new call confirmations, with date/time stamped records written to supimix as proof. Using standard text template from current supimix version. Auto close any prompt windows on email delivery, ensure status text is also displayed in header section ‘Call confirmation has been sent’
- To have the facility to send automatic chase emails to the user id currently assigned the call, with date/time stamped records written to supimix as proof. Using standard text template from current supimix version. Auto close any prompt windows on email delivery, ensure status text is also displayed in header section ‘Chase has been sent’
- To have the facility to write records to supimix on ‘passing a call’ out of hours. Date/time stamped when the call was handed over to and accepted by the support analyst on call. Auto close any prompt windows on update, ensure status text is also displayed in header section ‘Passed to oncall’
- On completion of logging a new call, display summarised call information for ease of entry into forwarding email subject (for copy&paste) displayed as ‘client code:priority:site:log number:reference’ eg EXL:4:COV:294250:EARS00031823587
- New call Alert emails must be automatically sent to OBS support queue once logged triggered by default support queue in point 1 above.
- Audit History record is required for new call status Logged and Confirmed – the audit record written is to include date, time, who, type.
- Call details should be displayed in record date/time order showing call history from earliest entry (call logging) to latest entry (call closure).
- Ability to cancel a call half way through logging.
- Ensure all display text is correctly formatted and justified.
- Ensure OBS logo and OBS Helpdesk contact details are displayed in each of the screens.
Ability to ‘update’ incidents
- Update action should display the same screen familiar with during ‘new call entry’
- Record/Field updates should prompt for details (narrative) to be added by the user, thus providing a full history of the call.
- Updates of status, substatus, assigned, priority, call type must all have audit history records written along with ‘passed to oncall’ and ‘chase’ actions – this audit record should include date, time, who, type, old value, new value. NB: Important for month end statistical reporting.
- Also requires call confirmation, chase and passed to on call facility.
Ability to ‘view’ incidents
- Introduce a new ‘search’ screen to allow the user to search for an incident uniquely by OBS Log number, or via reference number (with wildcard search) or client/date range.
- On selection, a list of ‘matching’ records should be displayed to the user, allowing sort action on each field value displayed.
- OBS log number should be manually selected and user taken to ‘Update Calls’ screen allowing any updates if required.
Important points to highlight
- Check session inactivity period settings.
- Multiple logins should be enabled for the same user account.
- Emails should be sent from the email account of the user logged on
- Ensure search boxes are not case sensitive and allow the use of * as a wildcard value.
- Date and time values should be UK formatted DD/MM/YYYY, HH:MM:SS
- Any code values should also have full text displayed (eg status 0 means nothing without the text ‘LOGGED’).
- Ensure screens are ID’d to assist with any support assistance from OBS.
Appendix B: Document References
B.1 References
| Ref No | Document Title & ID | Version | Date |
| 1 | Reference1 | 0.1 | 01/03/2012 |
B.2 Glossary
| Term or Acronym | Meaning |
|---|---|
| Ad Hoc | A task instigated on the device (spec. Ad Hoc Pallet Move), rather than a task instigated from the WMS and Stock Control. |
| Advice Note Number | An external reference linked to a Goods Receipt. |
| Aisle | A component of a location; usually a space through rows of racking or storage locations; a collection of locations; |
| Anchor Point | A starting location for a search for a suitable storage location; auto-putaway location suggestion start point. |
| Area | A collection of aisles; an area in the warehouse for a particular purpose. |
| Batch | A production batch of a product; a quantity of product that is considered to have the same characteristics; |
| Bay (Warehouse) | A physical loading or unloading point for the warehouse. |
| Bay | A component of a location; usually a space between uprights in racking, comprising several levels (horizontal beams). |
| Block Stack | A stable stack of pallets. |
| Bulk | Bulk storage; Usually full-pallet storage areas, racked or stacked. |
| Cancellation | The facility to cancel a task due to some problem, identified by the user when performing the task. |
| Check Digit | A short code, usually randomly generated and stored against a location, used to help identify that a user is at the right location before they proceed with a warehouse task. |
| CSV | Character-separated values; a text file with multiple rows and values, usually separated with commas. |
| C-WCS | CALIDUS WCS, the name of the OBS Logistics Warehouse Control system |
| C-WMS | CALIDUS WMS, the name of the OBS Logistics Warehouse Management system |
| Dead Leg | A movement of a truck without a pallet; wasted resource. |
| Despatch | The final physical stage of an order; handover of goods to the haulier. |
| Drive-In | A drive-in location, typically multi-level, multi-deep location. |
| Dual Cycling | Processes utilizing P&D locations for interleaving tasks in and out of specific areas, reducing dead leg movements. |
| Exchange | Specifically Pick Exchange or Task Exchange. The process of allowing a user to select a different pallet in a multi-pallet location and exchanging the expected pallet for this one. If the pallet is planned for another task, task exchange will complete this task instead of the expected one first. If the pallet is not planned, pallet exchange will swap the pallet (if suitable). |
| GR; GRN | Goods Receipt; Goods Receipt Number or Note |
| High Bay | Typically tall (greater than 5 level) racking, usually full pallet storage, usually Narrow Aisle. |
| JIT | Just In Time; processes designed to trigger at the last instant. |
| KPI | Key Performance Indicator. |
| Level | A component of a location; usually the vertical compartments of an area, delineated by horizontal beams. |
| Loading | The act of loading pallets onto a vehicle. |
| Location | A uniquely identified space in the warehouse for storage of product. There are many types, most commonly Floor locations (for example, Marshalling, Inbound), Racking or Bulk Storage Locations and Pick faces. |
| Manifest | The contents of a vehicle or container. |
| Marshalling | The act of bringing pallets for an order or load together; an area to do so. |
| Multi-deep | A location with 2 or more pallets stored sequentially i.e. only one can be accessed at a time. |
| NA | Narrow Aisle; usually any area in the warehouse that is restricted access due to space limitations, Narrow Aisles have associate P&D locations. |
| P&D | Pick-up and Drop-off locations; locations used to control the handover of pallets between distinct areas, for example between chambers and the wider area of the warehouse. |
| PI; Perpetual Inventory | The act of continuously checking locations in a warehouse, identifying and correcting product quantity issues. Usually used in Bulk environments rather than Pick Faces. In pick faces, this process is called is called Residual Stock Balance and usually takes place after picking from a pick face. |
| Pick Face | A location designed for picking part of a pallet of stock. Usually a low- or ground-level location. |
| Pick List (order) | The instructions to pick pallets or cases from locations; the paper report associated to this; the stage of preparing these instructions; the sending of these instructions to WCS. |
| PO | Purchase Order. |
| Pre-advice; Goods Receipt Pre-advice | An advanced notification of what is being received. Part of a manifest. Pre-advices can be stock and quantity, or individual pallet level. |
| Putaway | The physical move of a pallet to a storage location as a result of receiving it into the warehouse. |
| RAG | Acronym for Red/Amber/Green, a traffic light colouration system depicting (in sequence) Errors, Warnings or Informational messages. Usually used in operational monitoring to effectively display when certain processes are not working as expected. |
| RDT | Radio Data Terminal. |
| Replen; Replenishment | The act of moving product (usually a pallet) from bulk storage to a pick face. |
| Reposition | The facility to change the location of a movement or putaway when at the final destination, sue to some issue discovered when performing the task. |
| RF | Radio Frequency; An RF device is an RDT, typically used by CALIDUS WCS for executing warehouse tasks. |
| SCR; CR | Software Change Request. |
| Short Pick | The process of not fulfilling an order due to failure to identify sufficient product when picking. May also be used as a term to indicate Short Allocation. |
| SO | Sales Order. |
| Truck Types | Plants, Mechanical Handling Equipment. For example, Reach trucks, Counter-balance trucks, pallet riders, etc. |
| UOM | Unit of Measure. |
| WA | Wide Area; usually any area in the warehouse that is not restricted access due to space limitations, for example, floor areas, not Narrow Aisle. |
| WCS | Warehouse Control System |
| WMS | Warehouse Management System |
B.3 Authorised By
Julie Scott | Project Manager | _____________________________ |
