I-Portal REQUIREMENTS
From UG
Mantis
Introduction
The primary objective of International Portal (I-Portal) is to create a platform for CyberTrax2 to transform into Software-As-A-Service (SaaS) system that Jaguar Freight Services can offer as a fee-based service to external clients. Clients would be able to manage all aspects of their shipments from within CyberTrax2 for both domestic and international shipments. The portal should provide client users with the ability to create shipments, approve shipments, track shipments, etc.. This will streamline a business process of submitting and approving shipments and seamless communication at Elizabeth Arden. It is proposed to provide a web portal. Required software is a tool that allow a supplier to enter an Elizabeth Arden international traffic order.
The portal must be web accessible, secure, user-friendly, flexible, and scalable. The portal must also take into account data visibility rules (Clients will only be able to edit/view their own data) and system performance. This portal is mimic from ASN portal (Trucking domestic portal for Elizabeth Arden)
There are a number of features that should be postponed and released in phase two. This was done to launch international portal with core features as soon as possible.
Functionality Overview
QUESTIONS
Admin Panel:
Q1. I-portal and ASN are separated?
- Roles:Iportal: Shipper and planner
- MOT: Air and Ocean only or specify MOT for each shipper one to one MOT?
- Suggest for JG role to specify FCL, LCL, Console? with out letting shipper/planner assign
- E0: Elizabeth Arden?
- Roles:Truck-Dom: Shipper and Planner
- MOT: Truck Dom only
- E0: EA DOM PORTAL
- Roles: combine shipper and planner?
- All MOT: Air, Ocean, Truck Dom --> what about other trucks such as Truck air and Truck ocean
- Should we even give International shipper to assign the breakdown of ocean from the beginning? FCL, LCL, Console?
- Roles:Iportal: Shipper and planner
Q2. If it does, how? what is the process? Will we change the current business process for EA DOM? If it does not, THEN?
Q3. Shipper Role:
- one:one? for Shipper: EO.client Company?
Q4. Shipper Role:
- one:one? one:many? For Shipper: MOT(s)?
- Do they have ability to choose MOT?
- MOT Air/Ocean --> available for shipper to assign? and keep the way it is for truck dom?
- What is about Truck-air and truck-ocean? Could you describe the situation of when shipper wants to ship by truck air/ocean? When to consider? are they apart of i-portal? Should we not consider these yet only air and ocean first and we will think about that for future phase?
Q5. Who will assign MOT? Shipper? Planner? Jaguar? Do we have to give all the ability for all roles to assign/edit?
Q6.
Use case 1: Shipper assigns MOT by default from admin, or actual assign by shipper?
- THEN Planner will approve the shipment...with date, etc including MOT?
- THEN Planner (skip) --> automate approval
Use case 2: Shipper (NO MOT assign) view only once MOT is approved by Planner?
- THEN Planner approves the shipment....etc including MOT assign
- What would MOT be if automate approval for planner process. (Skip approval process)
Use case 3: Shipper and Planner (NO MOT assigned)
- THEN Planner only approve the shipment...with date...etc without MOT assign.
- THEN JAGUAR assigns the MOT
- Work for AUTO approval as well
Q7. Any other fields? should allow shipper to edit? Label for all fields should be consistent for all MOTs? such as Pick up and Ship to location --> apply for all modes?
Q8. If we combine all modes, then drop down list of address should be all for all modes? or we have to narrow list of address for dom only when Truck dom is selected?
Q9. Currently create shipment Truck DOM - one line item = 1 CT (work well for TMS). for International--> what should it be (Will we use Descarte system for routing shipment same as TMS? and how as one CT can have many lines items? Should each line = each CT then Jaguar consolidates all the CT (line items) together to ship together by group/master?
Q10. Cont Tab for each mode for i-portal? not on one page--> separate shipment detail for each mode on Cont tab?
- Any fields should be there for MOT selected? as Air and Ocean modes--> require fields can be different, should we make it common for both Air and Ocean?
Q11. Planner role: What is the process of this role for i-portal? what are the process of approvals? such as auto approval, etc?
Q12. Summary, What data feed from POEM and what process should change? such as the submission for QTY...detail of shipments....how to separate what is a part of POEM and I-portal? POEM Feed with submission ability for Shipper...if POEM not feed, shipper should create shipment from scratch like currently Truck Dom?
Q13. Shipment detail for edit or from data feed from POEM (must include in each mode for shipper and planner?)
- FCL
- Container#
- Seal#
- Size
- Type
- Est collection
- Act collection
- Request deliver
- Act deliver
- PO
- SKU
- QTY
- Ttl# of Plts
- Ttl PKG on plt
- Loose PKGs
- Ttl GW KG/LB
- Piece price
- total value
- Stackable
- Haz/non-haz
- Ttl HU
- CBM
- VIEW EXP
- streamshipline
- booking#
- Master BOL
- HBOL
- Origin terminal
- Est/Act
- Port of lading
- Est/Act
- Port of discharge
- Est/Act
- Destination Terminal
- Any standard/common info for Cont tab for different modes if we allow shipper to assign MOT (air/ocean) as line by line can be different mode within one creation from shipper.
Core International Shipper
High Level Deliverables
- Flexible Entitlements Management System
- User Interface Templates
- Client Specific Reporting
- Optimize current CT2 Client performance
Project Stakeholders & Roles
- Simon Kaye - CEO - Project Sponsor
- Marc Selter - VP - Product Manager
- Alex Dobrovolsky - Director of Technology - Solutions Architect
- Montira Renfrew - CT2 Systems Analyst/ CT2 Project manager
- Alex Pivniak - CT2 Software Developer (Elcosol)
- Denise Guastella - CT2 Support Manager
Project Scope
<Identify in-scope and out-of-scope items>
Out-Of-Scope
- SAS 70 & ISO27001 Compliance
- Web Application Penetration Tests
- High Availability (HA) Disaster Recovery environment(s)
- 100% integration of both Internal CT2 & Client CT2
- Functional & Non-Functional gaps in Internal CT2
Project Dependencies
<Identify internal and external dependencies to the project>
High-Level Timelines
<High-level milestone dates>
Risks
<Identify internal and external risks to the project: schedule, resources, technical, business, cost, market conditions, external vendors/partners, etc..>
Assumptions / Constraints
<Identify all assumptions and constraints for this project>
Business Requirements
<List each business requirement under a separate heading. Also include process flows (UML, Sequence Diagrams, Swimlane, Flow chart, etc..) as applicable>
Business Requirement 1...
Business Requirement 2...
Business Requirement 3...
Business Process Flow 1...
Business Process Flow 2...
Business Process Flow 3...
Functional/Non-Functional Requirements
<Identify all functional and non-functional requirements. Maintain standard headings. If a specific requirement is not required, note as Not Applicable. Each functional requirement must trace back to a specific business requirement.>
CyberTrax2 Internal Application
<Identify all functional requirements for CT2 Internal Application>
User Interface Requirements
Reporting Requirements
User Access / Security Requirements
Logging Requirements
Group / Master Requirements
Filtering Requirements
Archiving Requirements
CyberTrax2 Client Application
<Identify all functional requirements for CT2 Client Application>
User Interface Requirements
Reporting Requirements
User Access / Security Requirements
Logging Requirements
Group / Master Requirements
Filtering Requirements
Archiving Requirements
Non-Functional Requirements
<Identify all non-functional requirements for both CT2 Client Application and CT2 Internal Application>
Performance Requirements
Capacity Requirements
Support / Maintenance Requirements
User Guides
Training
Log(s) Accessibility
Testing Requirements
Security Requirements
Technical Design & Solution
Mock ups
<Include mock-ups of UI changes, report changes, etc..>
Technology Stack & Architecture
<Include changes to existing Technology Stack & Architecture - new libraries, updated library versions, new software/hardware, new interfaces, etc..>
Technical Diagrams (Flow Chart, Sequence, UML, Systems Architecture, Technical Architecture, Data Architecture, etc..)
<Include architecture diagrams and flow charts>
Web / Application (New/Modified classes, methods, etc..)
<List new or modified classes and methods>
Database (DDL changes - new/modified tables, indexes, stored procedures, etc..)
<Summarize database changes>
Configuration (Config File changes)
<Summarize config changes>
Logging (Log File changes)
<Summarize Log File changes and locations>
External Interfaces (EDI Message(s), external vendors)
<Identify any new external interfaces. Include sample request and reply along with field definitions. Include Source/Target server(s)/webservice(s) and functional accounts. If this is a modification of an existing EDI message, include samples of current message(s) and new message(s)>
