POEM

From UG

(Difference between revisions)
Jump to: navigation, search
(Database (DDL changes - new/modified tables, indexes, stored procedures, etc..))
(BR1.4 [Upload Purchase Orders])
 
(45 intermediate revisions not shown)
Line 17: Line 17:
<tr>
<tr>
<td>DEV Environment</td>
<td>DEV Environment</td>
-
<td>To Be Determined</td>  
+
<td>dev3-kuchma.jaguarfreight.com</td>  
</tr>
</tr>
<tr>
<tr>
<td>QA Environment</td>
<td>QA Environment</td>
-
<td>To Be Determined</td>  
+
<td>dev3-kuchma.jaguarfreight.com</td>  
</tr>
</tr>
Line 28: Line 28:
<tr>
<tr>
<td>SIT Environment</td>
<td>SIT Environment</td>
-
<td>To Be Determined</td>  
+
<td>dev3-kuchma.jaguarfreight.com</td>  
</tr>
</tr>
</table>
</table>
 +
 +
== Statements of Work ==
 +
SOW1 - Prototype - http://ct.jaguarfreight.com/wiki/POEM:_SOWs
= Purchase Order Event Management Overview =
= Purchase Order Event Management Overview =
''<Executive summary of business justification(s), business objective(s), high level project deliverables, project vision, all stakeholders, etc..>''
''<Executive summary of business justification(s), business objective(s), high level project deliverables, project vision, all stakeholders, etc..>''
-
[[File:POEM Context Level0.jpg]]
+
[[File:POEM Context Level0.jpg | 1000px]]
-
[[File:POEM Context Level0 2.jpg]]
+
[[File:POEM Context Level0 2.jpg | 1000px]]
== Business Objectives ==
== Business Objectives ==
Line 88: Line 91:
== High-Level Timelines ==
== High-Level Timelines ==
-
''<High-level milestone dates>''  
+
''<High-level milestone dates>''
 +
 
 +
=== Prototype1 Milestones ===
 +
 
 +
{| {{table}}
 +
| align="center" style="background:#f0f0f0;"|'''Task Name'''
 +
| align="center" style="background:#f0f0f0;"|'''Duration'''
 +
| align="center" style="background:#f0f0f0;"|'''Start'''
 +
| align="center" style="background:#f0f0f0;"|'''Finish'''
 +
|-
 +
| Infrastructure (Server Builds & Configuration)||2 days||Wed 5/23/12||Thu 5/24/12
 +
|-
 +
| Requirements (BRD & SRS Document)||25 days||Mon 5/21/12||Tues 6/12/12
 +
|-
 +
| Design Documentation||25 days||Mon 5/21/12||Fri 6/15/12
 +
|-
 +
| Construction - New Purchase Order Objects||8 days||Mon 6/4/12||Wed 6/13/12
 +
|-
 +
| Construction - Review/Update/Fulfill Purchase Orders||14 days||Mon 6/4/12||Thu 6/21/12
 +
|-
 +
| Construction - SKU Management||4 days||Wed 6/20/12||Mon 6/25/12
 +
|-
 +
| Construction - Reporting||5 days||Thu 6/21/12||Wed 6/27/12
 +
|-
 +
| Construction - Shipping Documents||13 days||Thu 6/14/12||Mon 7/2/12
 +
|-
 +
| Validation||17 days||Wed 6/20/12||Thu 7/12/12
 +
|-
 +
|
 +
|}
== Risks ==
== Risks ==
Line 113: Line 145:
''<List each business requirement under a separate heading. Also include process flows (UML, Sequence Diagrams, Swimlane, Flow chart, etc..) as applicable>''  
''<List each business requirement under a separate heading. Also include process flows (UML, Sequence Diagrams, Swimlane, Flow chart, etc..) as applicable>''  
 +
<span style="color:#0f0">
 +
'''NOTE: ALL GREEN USE-CASES ARE IN SCOPE FOR PROTOTYPE-PROPOSAL (SOW1)'''
 +
 +
http://ct.jaguarfreight.com/wiki/POEM:_SOWs
 +
</span>
== Purchase Order Event Management Context Diagram ==
== Purchase Order Event Management Context Diagram ==
-
[[File:POEM UML Context.jpg]]
+
[[File:POEM UML Context.jpg | 700px]]
== BR1.0 [Manage Purchase Order Life cycle] ==  
== BR1.0 [Manage Purchase Order Life cycle] ==  
-
The primary objective of Project POEM is to manage the Purchase Order life cycle of Elizabeth Arden Purchase Orders within CyberTrax2. This includes all domestic EA Purchase Orders that are managed and transported by Jaguar Freight Services.  
+
The primary objective of Project POEM is to manage the Purchase Order life cycle of Elizabeth Arden Purchase Orders within CyberTrax2. This includes all domestic and international EA Purchase Orders that are managed and transported by Jaguar Freight Services.
 +
 
 +
The life cycle of a Purchase Order is born within Elizabeth Arden's ERP system. The purchase order is a contract between Elizabeth Arden and it suppliers. Once a Purchase Order is "ready" it is then sent to CyberTrax2 where it will await fulfillment by an EA Supplier and Shipper. If a shipper fulfills a PO, then he/she can create an Advanced Shipment Notification (ASN) and proceed through the normal life cycle of an ASN (with some new variations).
 +
 
 +
Note that Supplier roles and Shipper roles are independent. They can be filled by different people.
 +
 
 +
 
 +
'''[[Purchase Order Release Concept]]'''
 +
 
 +
Purchase Orders can have releases associated with them. An open Purchase Order can have multiple releases - each release specifying their own due dates and quantities. Basically a release can be thought of a child to a Purchase Order and should inherit all functionality of a Purchase Order.
 +
 
 +
[Notes from meeting with Marc 6/28/12]
 +
 
 +
A client will either utilize releases with all their purchase orders, or they won't. We can treat each PO:Release combination as its own entity. If a client utilizes releases, they should only send us PO:Release combinations, if they send us a PO w/o a release, we should reject that record.
 +
 
 +
Supporting PO:Release reporting will need to be implemented and designed (pending further clarification & requirements). We can treat Purchase Order:Release as a single entity. When a PO:Release is imported into our system, it will be treated as an actionable order. See below for a very rough draft of a PO data feed.  
-
The life cycle of a Purchase Order is born within Elizabeth Arden's ERP system. The purchase order is a contract between Elizabeth Arden and it suppliers. Once a Purchase Order is "ready" it is then sent to CyberTrax2 where it will await confirmation or rejection by an EA Shipper. If a shipper confirms a PO, then he/she can create an Advanced Shipment Notification (ASN) and proceed through the normal life cycle of an ASN (with some new variations).
+
[[File:POEM PO DataFeed Draft1.jpg]]
=== BR1.1 [Elizabeth Arden ERP Integration] ===
=== BR1.1 [Elizabeth Arden ERP Integration] ===
-
[[File:POEM UML ERP Integration.jpg]]
+
[[File:POEM UML ERP Integration.jpg | 700px]]
Elizabeth Arden employ multiple ERP systems. Purchase orders originate from within Elizabeth Arden ERP systems. These Purchase Orders will need to be imported into CT2. The support for bi-directional updates have yet to be determined by Elizabeth Arden. Imports should be logged so that we can backtrack and troubleshoot interface issues if necessary.  
Elizabeth Arden employ multiple ERP systems. Purchase orders originate from within Elizabeth Arden ERP systems. These Purchase Orders will need to be imported into CT2. The support for bi-directional updates have yet to be determined by Elizabeth Arden. Imports should be logged so that we can backtrack and troubleshoot interface issues if necessary.  
=== BR1.2 [Review/Update PO] ===
=== BR1.2 [Review/Update PO] ===
-
[[File:POEM UML ReviewUpdatePO.jpg]]
+
[[File:POEM UML ReviewUpdatePO.jpg | 700px]]
Elizabeth Arden Suppliers will need the ability to review all uploaded Purchase Orders. They need to be able to review Purchase Orders and then update dates and other elements as necessary. Read-only/edit permissions should be flexible and controlled on a per-supplier basis.
Elizabeth Arden Suppliers will need the ability to review all uploaded Purchase Orders. They need to be able to review Purchase Orders and then update dates and other elements as necessary. Read-only/edit permissions should be flexible and controlled on a per-supplier basis.
=== BR1.3 [Purchase Order Fulfillment - open, full, partial, or reject] ===
=== BR1.3 [Purchase Order Fulfillment - open, full, partial, or reject] ===
-
[[File:POEM UML Fulfil PO.jpg]]
+
[[File:POEM UML Fulfil PO.jpg | 700px]]
Shippers need the ability to confirm or reject purchase orders. Shippers will need the ability to fulfill purchase orders. POs will need to be mapped to specific shippers. All updates to POs must be logged.  
Shippers need the ability to confirm or reject purchase orders. Shippers will need the ability to fulfill purchase orders. POs will need to be mapped to specific shippers. All updates to POs must be logged.  
-
* Open Purchase Orders - Purchase Orders that are issued in advance and expires after set interval (either date/time or number of executions). These POs may also be have their ASN's rejected, but have their PO's reopened by the Planner.  
+
* Open Purchase Orders - Purchase Orders that are issued in advance and expires after set interval (either date/time or number of executions). Open POs also include ASN Rejected shipments.  
* Full Purchase Orders - Purchase Orders that can be fulfilled in FULL. Shipper has all items in stock and can ship the entire purchase order.  
* Full Purchase Orders - Purchase Orders that can be fulfilled in FULL. Shipper has all items in stock and can ship the entire purchase order.  
-
* Partial Purchase Orders - Purchase Orders that can only be fulfilled partially. Shipper has subset of items in stock and can only fulfill a part of the order. The option to allow for partial shipments will be client configurable.  
+
* Partial Purchase Orders - Purchase Orders that can only be fulfilled partially. Partial Purchase Orders remain in an OPEN state until it has been fulfilled in its entirety, cancelled, or expired.  
==== Order Fulfillment Workflow ====
==== Order Fulfillment Workflow ====
-
[[File:POEM Workflow OrderFulfillment.jpg]]
+
[[File:POEM Workflow OrderFulfillment.jpg | 1000px]]
==== BR1.3.1.4 [Create ASN] ====
==== BR1.3.1.4 [Create ASN] ====
Once a Purchase Order is confirmed & fulfilled. The shipper should have the ability to create an ASN. Most of the information in the new ASN should be populated by the PO data. The ASN will then go through a variation of its normal life cycle. Details for automatic approval need to be determined.
Once a Purchase Order is confirmed & fulfilled. The shipper should have the ability to create an ASN. Most of the information in the new ASN should be populated by the PO data. The ASN will then go through a variation of its normal life cycle. Details for automatic approval need to be determined.
 +
 +
=== BR1.4 [Upload Purchase Orders] ===
 +
 +
[[File:POEM UML PO Upload.jpg | 700px]]
 +
 +
Planners should have the ability to bulk upload Purchase Orders directly into CyberTrax2. We need to build a module for them to upload their Purchase Order files (*.txt, *.xls, *.csv - filetype to be determined). This should provide similar validation as the ERP integration. This will include a new user interface for them to upload Purchase Order file(s) and will also need an interface to report and log invalid files. The reports should be detailed enough such that they can direct the Planner on how to fix the discrepancies in their file before re-uploading.
 +
 +
We must design the file format and also determine which data elements are required for us to successfully import POs into our system.
== BR2.0 [Communication] ==  
== BR2.0 [Communication] ==  
-
[[File:POEM UML Communication Center.jpg]]
+
[[File:POEM UML Communication Center.jpg | 700px]]
CT2 must be able to send notifications to stakeholders regarding PO updates and events. CT2 should have the ability to send automated notifications as well as ad-hoc communications that are initiated by end-users.  
CT2 must be able to send notifications to stakeholders regarding PO updates and events. CT2 should have the ability to send automated notifications as well as ad-hoc communications that are initiated by end-users.  
* Automated Notifications  
* Automated Notifications  
-
** Send notification to all stakeholders if:
+
** Send notification to all stakeholders when:
-
*** <placeholder for cases>
+
*** PO messages are rejected by our ERP Interface
 +
*** When elemenets of a PO are updated
 +
*** When PO is fulfilled
 +
*** Other PO Events (TBD)
== BR3.0 [Documentation] ==
== BR3.0 [Documentation] ==
-
[[File:POEM UML Shipping Docs.jpg]]
+
[[File:POEM UML Shipping Docs.jpg | 700px]]
CT2 must be able to generate and store standard PO related documents (regulatory compliance, shipping labels, shipping instruction, etc..). Shipping instructions will be stored in the system as-is. However, shipping labels, regulatory compliance documents must be generated from within CT2.
CT2 must be able to generate and store standard PO related documents (regulatory compliance, shipping labels, shipping instruction, etc..). Shipping instructions will be stored in the system as-is. However, shipping labels, regulatory compliance documents must be generated from within CT2.
* Templates and layout to be defined
* Templates and layout to be defined
 +
 +
Sample documents can be found in Mantis: http://ct.jaguarfreight.com/mantis/view.php?id=3574
== BR4.0 [Reporting] ==
== BR4.0 [Reporting] ==
-
[[File:POEM UML Reporting.jpg]]
+
[[File:POEM UML Reporting.jpg | 700px]]
CT2 should allow for exception reporting for certain PO events (Dashboard reports). Must also implement KPIs from PO metrics (cycle times).
CT2 should allow for exception reporting for certain PO events (Dashboard reports). Must also implement KPIs from PO metrics (cycle times).
Line 183: Line 248:
International Suppliers, Shippers, and Planners are in scope for this project. All modes of Transportation will need to be supported.
International Suppliers, Shippers, and Planners are in scope for this project. All modes of Transportation will need to be supported.
-
* Need to sync up with Tira
+
* Need to sync up I-Portal Project
=== BR5.1 [International Currency Support] ===
=== BR5.1 [International Currency Support] ===
-
POEM will need to support multiple currencies.  
+
POEM will need to support multiple currencies. Currency conversion rules are TBD.
== BR6.0 [SKU Management] ==
== BR6.0 [SKU Management] ==
-
[[File:POEM UML SKUManagement.jpg]]
+
[[File:POEM UML SKUManagement.jpg | 700px]]
Users will need to be able to manage SKUs/Items within CT2. They need the ability to manually enter in SKU/Items. CT2 must also support SKU updates via an automated process (EDI..?).
Users will need to be able to manage SKUs/Items within CT2. They need the ability to manually enter in SKU/Items. CT2 must also support SKU updates via an automated process (EDI..?).
 +
 +
* NOTE: Should be able to leverage current SKU2Planner mapping feature and tack on additional requirements [http://ct.jaguarfreight.com/wiki/Cybertrax_2.1_Client_%28requirements%29#SKU_to_Planner_Mapping_Feature SKU to Planner] to import SKU information.
== BR7.0 [Quality Assurance Module] ==
== BR7.0 [Quality Assurance Module] ==
-
[[File:POEM UML QAModule.jpg]]
+
[[File:POEM UML QAModule.jpg | 700px]]
Suppliers frequently send their products out to quality assurance vendors for quality testing. CT2 should be able to support this workflow. Supplier can mark an item as "ready for QA", CT2 will send a notification  
Suppliers frequently send their products out to quality assurance vendors for quality testing. CT2 should be able to support this workflow. Supplier can mark an item as "ready for QA", CT2 will send a notification  
Line 204: Line 271:
== BR8.0 [POEM Admin] ==
== BR8.0 [POEM Admin] ==
-
[[File:POEM UML POEMAdmin.jpg]]
+
[[File:POEM UML POEMAdmin.jpg | 700px]]
-
All POEM related admin activities should be managed within it's own area. Similar to GM Split Admin.  
+
All POEM related admin activities should be managed within it's own area. Similar to GM Split Admin. However, address book objects (Suppliers, Shippers, Buyers, etc..) should remain in the Address Book admin area.  
== BR9.0 [User Admin] ==
== BR9.0 [User Admin] ==
-
[[File:POEM UML UserAdmin.jpg]]
+
[[File:POEM UML UserAdmin.jpg | 700px]]
-
POEM should enable a large amount of flexibility. Users should be assigned access to POEM portal as well as read/write privleges.  
+
POEM should enable a large amount of flexibility. Users should be assigned access to POEM portal as well as read/write privileges.  
== BR10.0 [Client Admin] ==
== BR10.0 [Client Admin] ==
-
[[File:POEM UML ClientAdmin.jpg]]
+
[[File:POEM UML ClientAdmin.jpg | 700px]]
We will need to be able to enable POEM at the client level. There are also various data elements that are related to POEM (Regulatory, Suppliers, EDI interfaces) that should be configurable.  
We will need to be able to enable POEM at the client level. There are also various data elements that are related to POEM (Regulatory, Suppliers, EDI interfaces) that should be configurable.  
== BR11.0 [ShipperSupplier Admin] ==
== BR11.0 [ShipperSupplier Admin] ==
-
[[File:POEM UML ShipperSupplierAdmin.jpg]]
+
[[File:POEM UML ShipperSupplierAdmin.jpg | 700px]]
We will need the ability to update each Shipper and Supplier's regulatory information and contact information. Most of this information should come from address book, but will leave that design question open.
We will need the ability to update each Shipper and Supplier's regulatory information and contact information. Most of this information should come from address book, but will leave that design question open.
Line 444: Line 511:
== Mock ups ==
== Mock ups ==
''<Include mock-ups of UI changes, report changes, etc..>''
''<Include mock-ups of UI changes, report changes, etc..>''
 +
 +
Refer to SOWs:
 +
 +
Statement of Work 1 (http://ct.jaguarfreight.com/wiki/POEM:_SOWs)
 +
== Technology Stack & Architecture ==
== Technology Stack & Architecture ==
''<Include changes to existing Technology Stack & Architecture - new libraries, updated library versions, new software/hardware, new interfaces, etc..>''
''<Include changes to existing Technology Stack & Architecture - new libraries, updated library versions, new software/hardware, new interfaces, etc..>''
Line 457: Line 529:
Mantis: http://ct.jaguarfreight.com/mantis/view.php?id=3574
Mantis: http://ct.jaguarfreight.com/mantis/view.php?id=3574
-
 
-
{| {{table}}
 
-
| align="center" style="background:#f0f0f0;"|'''Data Element'''
 
-
| align="center" style="background:#f0f0f0;"|'''Exists in CT2 (Y/N)'''
 
-
| align="center" style="background:#f0f0f0;"|'''Primary Data Source'''
 
-
| align="center" style="background:#f0f0f0;"|'''Data Type'''
 
-
| align="center" style="background:#f0f0f0;"|'''Description'''
 
-
| align="center" style="background:#f0f0f0;"|'''Related to'''
 
-
|-
 
-
| Purchase Order #||Y||Elizabeth Arden||Alphanumeric||Purchase Order number from Elizabeth Arden ERP||tblCommodityItem.PurchaseOrder
 
-
|-
 
-
| Purchase Order Status||N||CT2||Alphanumeric||Current Status of PO through it's lifecycle||Status of CT
 
-
|-
 
-
| Supplier||Y||Elizabeth Arden||?||Must be mapped from EA ERP to CT2||?
 
-
|-
 
-
| Buyer||?||Elizabeth Arden||?||?||?
 
-
|-
 
-
| Incoterm||?||Elizabeth Arden||?||?||tblGenericShipment.ShippingTermId
 
-
|-
 
-
| Purchase Order Created Date||N||CT2||Date/Time||Automatically generated when PO is imported||tblGenericShipment.CreatedOnDate
 
-
|-
 
-
| Purchase Order Confirmed Date||N||CT2||Date/Time||Automatically populated when Supplier confirms PO||?
 
-
|-
 
-
| Earliest Ship Date||N||Elizabeth Arden||Date/Time||||?
 
-
|-
 
-
| Latest Ship Date||N||Elizabeth Arden||Date/Time||||?
 
-
|-
 
-
| HTS Code||N||CT2||Alphanumeric||Harmonized Tariff Schedule. (Standard code for almost every item in the world. First 6 digits are item specific, last 4 are country specific)||tblCommodityItem.HTS
 
-
|-
 
-
| Ship To Address||Y||CT2||In Address Book||||CT Delivery Address
 
-
|-
 
-
| Importer of Record||?||?||?||||?
 
-
|-
 
-
| Customs Broker Name||Y||CT2||In Address Book||||tblAddressJaguarVendor.IsCustomsBrocker
 
-
|-
 
-
| Ultimate Consignee||Y||CT2||In Address Book||||?
 
-
|-
 
-
| Ship From||Y||CT2||In Address Book||||CT Pickup Address
 
-
|-
 
-
| Ship Mode||Y||CT2||Alphanumeric||||CT Transport Mode
 
-
|-
 
-
| Freight Forwarder||Y||CT2||In Address Book||||?
 
-
|-
 
-
| Due Date||?||Elizabeth Arden||Date/Time||?||tblTruckingShipment.CargoDueDate (only TRUCK)
 
-
|-
 
-
| SKU||Y||Elizabeth Arden||Alphanumeric||Must be managed within CT2. Not just pass through. ||tblCommodityItem.SKU
 
-
|-
 
-
| Supplier SKU||N||Elizabeth Arden||Alphanumeric||Must be managed within CT2. Not just pass through. ||?
 
-
|-
 
-
| Quantity||Y||Elizabeth Arden||Numeric||Pass through||tblCommodityItem.Quantity
 
-
|-
 
-
| Value||?||Elizabeth Arden||?||?||tblCommodityItem.TotalValue
 
-
|-
 
-
| Ctns||Y||?||Numeric||||tblContainer records count
 
-
|-
 
-
| Plts||Y||?||Numeric||||tblCommodityItem.TotalOfPlts
 
-
|-
 
-
| Gross KG||Y||?||Numeric||||tblCommodityItem.TotalGrossKg
 
-
|-
 
-
| Manufacturer ID||N||Elizabeth Arden||Alphanumeric||Manufacturer ID used by customs||?
 
-
|-
 
-
| Tax ID||N||Elizabeth Arden||Alphanumeric||TaxID used by customs||?
 
-
|-
 
-
| Customs ID||N||Elizabeth Arden||Alphanumeric||Customs ID||CT Customs Status; tblCustomsStatus
 
-
|-
 
-
| Regulatory ID||N||Elizabeth Arden||Alphanumeric||Regulatory ID used by customs||?
 
-
|-
 
-
| Packaging Information||Y||CT2||Alphanumeric||||?
 
-
|-
 
-
| Price||Y||Elizabeth Arden||Numeric||||tblCommodityItem.PiecePrice
 
-
|-
 
-
| Supplier Order Confirmation Date||N||CT2||Date/Time||||?
 
-
|-
 
-
| ASN Creation Date||N||CT2||Date/Time||||?
 
-
|-
 
-
| Delivery Date||Y||CT2||Date/Time||||CT Delivery date
 
-
|-
 
-
| Documents||N||CT2||BLOB||||?
 
-
|-
 
-
|
 
-
|}
 
== Configuration (Config File changes)==
== Configuration (Config File changes)==
Line 554: Line 545:
[Submitted by Perry (5/30/20120)]
[Submitted by Perry (5/30/20120)]
* Please confirm definitions for below PO states...
* Please confirm definitions for below PO states...
-
** Open [Once a PO is created and imported in CT2]
+
** Open [A PO that has been imported into CT2 and have yet to be fulfilled in its entirety (either partial fulfillment or recurring PO)]
-
** Impending [Once a PO has been confirmed by Shipper]
+
** Impending [A PO where Late Ship Date < today + x]
-
** Past Due [If a PO has not been confirmed and due date is < X days]
+
** Past Due [A PO where Late Ship Date < today + x]
-
** Cancelled [If a PO has been rejected by Shipper or rejected by Supplier]
+
** Cancelled [If a PO has been cancelled by ERP]
** In Transit [Once a PO has been fulfilled, ASN created, and shipped]
** In Transit [Once a PO has been fulfilled, ASN created, and shipped]
** Delivered [Once shipment has been received]
** Delivered [Once shipment has been received]
Line 566: Line 557:
** Regulatory ID
** Regulatory ID
** Manufacturer ID
** Manufacturer ID
 +
*** All Regulatory information will most likely be managed inside Address Book by a Jaguar account/ops manager.
* Need samples of required documents..  
* Need samples of required documents..  
Line 573: Line 565:
* Should we create a new CT for each item in each PO that is imported in our system? We might have to take this approach as the entire system revolved around CT records.
* Should we create a new CT for each item in each PO that is imported in our system? We might have to take this approach as the entire system revolved around CT records.
 +
** Yes
* Will we also support bulk imports of SKUs?
* Will we also support bulk imports of SKUs?
 +
** Not for Prototype
* If PO is partially fulfilled, will the due dates need to be adjusted?
* If PO is partially fulfilled, will the due dates need to be adjusted?
 +
** No
* Do we need to provide an interface to create POs as well?
* Do we need to provide an interface to create POs as well?
 +
** Not at the moment
* Should we just add a few new tabs to ASN for Shippers who have PO enabled? Doesn't make sense for a Shipper to enter the POEM portal to review POs, and then enter the ASN portal to view/update ASNs.
* Should we just add a few new tabs to ASN for Shippers who have PO enabled? Doesn't make sense for a Shipper to enter the POEM portal to review POs, and then enter the ASN portal to view/update ASNs.
 +
** No. Keep POEM and ASN separate. May merge portals at a future date, but not anytime in the near future.
* Will a single PO ever have multiple Ship To locations? (example, Item 1 ships to Location1, Item 2 ships to Location2, etc..)
* Will a single PO ever have multiple Ship To locations? (example, Item 1 ships to Location1, Item 2 ships to Location2, etc..)
-
* How should the PO Editor function? If we create a CT for each SKU in a PO, then the PO List can have multiple line items for a single PO. However, what happens if a user opens a single line item in the PO list? Will it allow the user to update all items in the PO or just that single line item?
+
** Not for our purposes. It will be 1 PO to 1 Ship To location for our purposes.
 +
* Should the PO editor display all SKUs in a single PO? Or just a single line item per window? If we create a CT for each SKU in a PO, then the PO List can have multiple line items for a single PO. However, what happens if a user opens a single line item in the PO list? Will it allow the user to update all items in the PO or just that single line item?
 +
** The PO Editor should open all SKUs for that PO.
 +
* Can a single PO have multiple SKUs with different dates (early ship, late ship, delivery, cargo due, etc..)?
 +
** For our purposes, no. All dates should be at the PO level.
 +
* Can a single PO be fulfilled by multiple Shippers from different locations? Ie.. PO issued to a Supplier and then Supplier passes PO over to 2 shippers (1 in US, 1 in China)?
 +
** Yes, but that can be handled at the ASN level. (ability to select Ship From location - which already exists).
 +
 
 +
* Will customs documentation differ based on MOTs?
 +
** No. Also note that ISF is only for US-bound Ocean shipments.
 +
 
 +
* Are the shipping documents created at the CT, PO, ASN, or Group level? Some documents may have to be generated at Group level (customs), while others (packing slips) might be at the PO (full) or CT (partial) level.
 +
** Must be flexible - ability to multi-select CTs, create documents at the Group or CT level. Pallet/Shipping labels may have to be created via a template. Think of it as a label generator with some pre-populated fields, but shipper will still have to enter in additional temporary information.
 +
 
 +
* Should Manufacturer IDs be related to the POs or SKUs? If it's linked to only POs, then what if a supplier ships the same product from multiple warehouses/factories?
 +
** Manufacturer IDs (MIDs) are linked to addresses. If a an address is marked as a Manufacturer, then it will require an MID.
 +
 
 +
* Release Number Field - need additional clarification.

Current revision as of 15:56, 2 July 2012


Contents

[edit] Mantis / Code Branch / Environments

Mantis 3547 http://ct.jaguarfreight.com/mantis/view.php?id=3574
Code Branch To Be Determined
DEV Environment dev3-kuchma.jaguarfreight.com
QA Environment dev3-kuchma.jaguarfreight.com
SIT Environment dev3-kuchma.jaguarfreight.com

[edit] Statements of Work

SOW1 - Prototype - http://ct.jaguarfreight.com/wiki/POEM:_SOWs

[edit] Purchase Order Event Management Overview

<Executive summary of business justification(s), business objective(s), high level project deliverables, project vision, all stakeholders, etc..>

[edit] Business Objectives

[edit] The need for management information – context

Management information is at the heart of any business that strives for continuous improvement. The principal benefits are that the provision of the right information not simply data:

  • Ensures that activity is linked to outcome;
  • Effort is focused upon needs of customers;
  • The management perspective migrates from providing excuses to delivering results;
  • Makes performance a culture of continuous process, instead of occasional ‘snapshots’;
  • Promotes communication and collaboration.

[edit] CyberTrax™ Purchase Order Event Management – overview and benefits

For CyberTrax™ customers, POEM is designed as a web-based platform that provides management tools and visibility of Supplier PO Events and milestones, from the PO Issued date, to the creation of an ASN. There are several benefits:

  • Elimination of redundant data entry, built in documentation (pallet labels, shipping instructions, Proforma Invoices and Packing Lists), Embedded regulatory compliance tools and exception reporting will improve and streamline the overall processes, and provide centralized visibility and automated event management efficiencies across global inbound supply chain stake holder groups;
  • Delivery of performance data and BI will support a continuous cycle of improvement within a company’s planning, purchasing, and transportation (inbound Supply Chain) groups;
  • Reliability and predictability of inbound supply chain events and improved regulatory compliance management tools, along with improved expectation management.

CyberTrax™ KPI and BI module Jaguar Freight Services

[edit] CyberTrax™ Purchase Order Event Management – interface

POEM will be designed to provide the same intuitive user experience associated with the Jaguar Freight Services brand, and will be fully integrated with other CyberChain™ solutions (Cybertrax™, ASN Portal™). POEM is a User Interface providing various users with customizable access types (visibility, edit) for the viewing, monitoring, updating and reporting on Supplier Purchase Orders. POEM facilitates a number of functionalities, principally as it relates to managing Purchase Order Events, and provides a centralized, cloud based process, communication and management solution. In line with Cybertrax™, flexibility, customization and scalability underpin POEM’s architecture.

[edit] Project Stakeholders & Roles

  • Simon Kaye - CEO - Project Sponsor
  • Marc Selter - VP - Product Manager
  • Alex Dobrovolsky - Director of Technology - Solutions Architect
  • Denise Guastella - CT2 Support Manager
  • Kostiantyn Ushakov - CEO/CTO Elcosol
  • Perry Lee - CT2 Project Manager
  • <TBD> - Elizabeth Arden Engagement/Relationship Manager
  • <TBD> - Elizabeth Arden Technical Project Manager

[edit] Project Management Plan

<Scope Management Plan, Integrated Change Control Process, Quality Management Plan, Communications Plan>

[edit] Project Scope

<Identify in-scope and out-of-scope items>

[edit] Project Dependencies

<Identify internal and external dependencies to the project>

Internal Dependencies

  • International Portal
  • DR/KPI

External Dependencies

  • Full participation & commitment by Elizabeth Arden

[edit] High-Level Timelines

<High-level milestone dates>

[edit] Prototype1 Milestones

Task Name Duration Start Finish
Infrastructure (Server Builds & Configuration)2 daysWed 5/23/12Thu 5/24/12
Requirements (BRD & SRS Document)25 daysMon 5/21/12Tues 6/12/12
Design Documentation25 daysMon 5/21/12Fri 6/15/12
Construction - New Purchase Order Objects8 daysMon 6/4/12Wed 6/13/12
Construction - Review/Update/Fulfill Purchase Orders14 daysMon 6/4/12Thu 6/21/12
Construction - SKU Management4 daysWed 6/20/12Mon 6/25/12
Construction - Reporting5 daysThu 6/21/12Wed 6/27/12
Construction - Shipping Documents13 daysThu 6/14/12Mon 7/2/12
Validation17 daysWed 6/20/12Thu 7/12/12

[edit] Risks

<Identify internal and external risks to the project: schedule, resources, technical, business, cost, market conditions, external vendors/partners, etc..>

  • [External Risk] Elizabeth Arden has 5 ERP systems that may not be able to meet all integration specifications.
  • [External Risk] Elizabeth Arden Technical Project Managers will dictate timelines. Jaguar Freight Services has no control over EA resources or schedules.
  • POEM is the first project to integrate CT2 with Elizabeth Arden ERP systems.

[edit] Assumptions / Constraints

<Identify all assumptions and constraints for this project>

Assumptions

  • Critical resources (1 FTE Analyst and 1 FTE Developer) will be fully allocated to this project for its entire duration.
  • Elizabeth Arden will provide resources and technical assistance when necessary. Any delays or costs associated with EA resources will not be controlled by Jaguar Freight Services.
  • All major requirements would have been identified during the requirements/design phase of this project. Any requirements identified post design-phase will have minimal impact on project schedule and scope.
  • All changes will undergo formal change control process.
  • All non-working periods (personal vacations, holidays, etc..) will be baked into project plan.
  • All resources will have adequate knowledge of business & technology to fulfill their roles & responsibilities with minimal training.

Constraints

[edit] Business Requirements

<List each business requirement under a separate heading. Also include process flows (UML, Sequence Diagrams, Swimlane, Flow chart, etc..) as applicable>

NOTE: ALL GREEN USE-CASES ARE IN SCOPE FOR PROTOTYPE-PROPOSAL (SOW1)

http://ct.jaguarfreight.com/wiki/POEM:_SOWs

[edit] Purchase Order Event Management Context Diagram

[edit] BR1.0 [Manage Purchase Order Life cycle]

The primary objective of Project POEM is to manage the Purchase Order life cycle of Elizabeth Arden Purchase Orders within CyberTrax2. This includes all domestic and international EA Purchase Orders that are managed and transported by Jaguar Freight Services.

The life cycle of a Purchase Order is born within Elizabeth Arden's ERP system. The purchase order is a contract between Elizabeth Arden and it suppliers. Once a Purchase Order is "ready" it is then sent to CyberTrax2 where it will await fulfillment by an EA Supplier and Shipper. If a shipper fulfills a PO, then he/she can create an Advanced Shipment Notification (ASN) and proceed through the normal life cycle of an ASN (with some new variations).

Note that Supplier roles and Shipper roles are independent. They can be filled by different people.


Purchase Order Release Concept

Purchase Orders can have releases associated with them. An open Purchase Order can have multiple releases - each release specifying their own due dates and quantities. Basically a release can be thought of a child to a Purchase Order and should inherit all functionality of a Purchase Order.

[Notes from meeting with Marc 6/28/12]

A client will either utilize releases with all their purchase orders, or they won't. We can treat each PO:Release combination as its own entity. If a client utilizes releases, they should only send us PO:Release combinations, if they send us a PO w/o a release, we should reject that record.

Supporting PO:Release reporting will need to be implemented and designed (pending further clarification & requirements). We can treat Purchase Order:Release as a single entity. When a PO:Release is imported into our system, it will be treated as an actionable order. See below for a very rough draft of a PO data feed.

File:POEM PO DataFeed Draft1.jpg

[edit] BR1.1 [Elizabeth Arden ERP Integration]

Elizabeth Arden employ multiple ERP systems. Purchase orders originate from within Elizabeth Arden ERP systems. These Purchase Orders will need to be imported into CT2. The support for bi-directional updates have yet to be determined by Elizabeth Arden. Imports should be logged so that we can backtrack and troubleshoot interface issues if necessary.

[edit] BR1.2 [Review/Update PO]

Elizabeth Arden Suppliers will need the ability to review all uploaded Purchase Orders. They need to be able to review Purchase Orders and then update dates and other elements as necessary. Read-only/edit permissions should be flexible and controlled on a per-supplier basis.

[edit] BR1.3 [Purchase Order Fulfillment - open, full, partial, or reject]

Shippers need the ability to confirm or reject purchase orders. Shippers will need the ability to fulfill purchase orders. POs will need to be mapped to specific shippers. All updates to POs must be logged.

  • Open Purchase Orders - Purchase Orders that are issued in advance and expires after set interval (either date/time or number of executions). Open POs also include ASN Rejected shipments.
  • Full Purchase Orders - Purchase Orders that can be fulfilled in FULL. Shipper has all items in stock and can ship the entire purchase order.
  • Partial Purchase Orders - Purchase Orders that can only be fulfilled partially. Partial Purchase Orders remain in an OPEN state until it has been fulfilled in its entirety, cancelled, or expired.

[edit] Order Fulfillment Workflow

[edit] BR1.3.1.4 [Create ASN]

Once a Purchase Order is confirmed & fulfilled. The shipper should have the ability to create an ASN. Most of the information in the new ASN should be populated by the PO data. The ASN will then go through a variation of its normal life cycle. Details for automatic approval need to be determined.

[edit] BR1.4 [Upload Purchase Orders]

Planners should have the ability to bulk upload Purchase Orders directly into CyberTrax2. We need to build a module for them to upload their Purchase Order files (*.txt, *.xls, *.csv - filetype to be determined). This should provide similar validation as the ERP integration. This will include a new user interface for them to upload Purchase Order file(s) and will also need an interface to report and log invalid files. The reports should be detailed enough such that they can direct the Planner on how to fix the discrepancies in their file before re-uploading.

We must design the file format and also determine which data elements are required for us to successfully import POs into our system.

[edit] BR2.0 [Communication]

CT2 must be able to send notifications to stakeholders regarding PO updates and events. CT2 should have the ability to send automated notifications as well as ad-hoc communications that are initiated by end-users.

  • Automated Notifications
    • Send notification to all stakeholders when:
      • PO messages are rejected by our ERP Interface
      • When elemenets of a PO are updated
      • When PO is fulfilled
      • Other PO Events (TBD)

[edit] BR3.0 [Documentation]

CT2 must be able to generate and store standard PO related documents (regulatory compliance, shipping labels, shipping instruction, etc..). Shipping instructions will be stored in the system as-is. However, shipping labels, regulatory compliance documents must be generated from within CT2.

  • Templates and layout to be defined

Sample documents can be found in Mantis: http://ct.jaguarfreight.com/mantis/view.php?id=3574

[edit] BR4.0 [Reporting]

CT2 should allow for exception reporting for certain PO events (Dashboard reports). Must also implement KPIs from PO metrics (cycle times).

  • Download to Excel feature

Purchase Order should be reportable on "Where is" and "Main report"

KPI Dashboards:

  • On-time: Ship Date
    • Number of shipments that were shipped on time. Purchase Order may specify a ship date (so that shipments are not delivered too early).
  • On-time: Due Date
    • Number of shipments that were delivered on time.
  • In Full - Partial Shipments
    • Number of Purchase Orders that were fulfilled in FULL.
    • Number of Purchase Orders that were fulfilled in PARTIAL.
  • Lead Times (created to approved, approved to ASN, etc..)

[edit] BR5.0 [International Support]

International Suppliers, Shippers, and Planners are in scope for this project. All modes of Transportation will need to be supported.

  • Need to sync up I-Portal Project

[edit] BR5.1 [International Currency Support]

POEM will need to support multiple currencies. Currency conversion rules are TBD.

[edit] BR6.0 [SKU Management]

Users will need to be able to manage SKUs/Items within CT2. They need the ability to manually enter in SKU/Items. CT2 must also support SKU updates via an automated process (EDI..?).

  • NOTE: Should be able to leverage current SKU2Planner mapping feature and tack on additional requirements SKU to Planner to import SKU information.

[edit] BR7.0 [Quality Assurance Module]

Suppliers frequently send their products out to quality assurance vendors for quality testing. CT2 should be able to support this workflow. Supplier can mark an item as "ready for QA", CT2 will send a notification out to the QA vendor. A quality tester can then log back into CT2 to either pass or fail a specific item.

Item/SKU Data Elements

  • Hazardous - YES/NO
    • If an item is Hazardous, additional attributes will need to be associated with the item.

[edit] BR8.0 [POEM Admin]

All POEM related admin activities should be managed within it's own area. Similar to GM Split Admin. However, address book objects (Suppliers, Shippers, Buyers, etc..) should remain in the Address Book admin area.

[edit] BR9.0 [User Admin]

POEM should enable a large amount of flexibility. Users should be assigned access to POEM portal as well as read/write privileges.

[edit] BR10.0 [Client Admin]

We will need to be able to enable POEM at the client level. There are also various data elements that are related to POEM (Regulatory, Suppliers, EDI interfaces) that should be configurable.

[edit] BR11.0 [ShipperSupplier Admin]

We will need the ability to update each Shipper and Supplier's regulatory information and contact information. Most of this information should come from address book, but will leave that design question open.

[edit] Requirements Checklist

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

Application Requirements Complete (Started/InProgress/Complete) Comments
CyberTrax2 Internal Application User Interface Requirements InProgress
  • User Admin to manage entitlements
Reporting Requirements InProgress
  • NO REQUIREMENTS AS OF YET
User Access / Security Requirements InProgress
  • New EA Shipper Role
Logging Requirements InProgress
  • Exceptions in ERP uploads should be logged in system log
  • PO updates should be logged
Group/Master Requirements InProgress
  • Conform with standard Trendset/Jewels Master & Grouping process
Filtering Requirements InProgress
  • NO REQUIREMENTS AS OF YET
Archiving Requirements InProgress
  • Closed POs need to be archived
CyberTrax2 Client Application User Interface Requirements InProgress
  • PO Management Interface
  • SKU Management Interface
  • Document Center
Reporting Requirements InProgress
  • Exception Reports
  • Automated notifications
  • Dashboard KPIs
User Access / Security Requirements InProgress
  • EA Suppliers and Shippers should only be able to view/update their own Purchase Orders.
Logging Requirements InProgress
  • All PO updates must be logged
Group/Master Requirements InProgress
  • NO REQUIREMENTS AT THE MOMENT
Filtering Requirements InProgress
  • Search/Filter capabilities on PO Management Interface
Archiving Requirements InProgress
  • Closed POs must be archived.
  • Deleted POs must be archived.
Non-Functional Requirements Performance Requirements InProgress
  • < 3 second response time
Capacity Requirements InProgress
  • Additional International Users - should not have impact on system
Support / Maintenance Requirements InProgress
  • Level 1 Support should be managed by EA DOM Team
  • Level 2 Support would be escalated to Denise & team.
User Guides InProgress
  • PO Management User Guides will need to be created
Training InProgress
  • NO REQUIREMENTS AT THE MOMENT
Log(s) Accessibility InProgress
  • NO SPECIAL REQUIREMENTS AT THE MOMENT
Testing Requirements InProgress
  • NO REQUIREMENTS AT THE MOMENT
Security Requirements InProgress
  • 128-bit SSL supported only.
  • Only support Mozilla 10.0.2+ and IE 8+
On-Boarding / Migration Requirements InProgress
  • Provide User Entitlements
  • Import Full list of EA Shippers & PO Mappings
Deployment Requirements InProgress
  • NO REQUIREMENTS AT THE MOMENT

[edit] Technical Design & Solution

[edit] Mock ups

<Include mock-ups of UI changes, report changes, etc..>

Refer to SOWs:

Statement of Work 1 (http://ct.jaguarfreight.com/wiki/POEM:_SOWs)

[edit] Technology Stack & Architecture

<Include changes to existing Technology Stack & Architecture - new libraries, updated library versions, new software/hardware, new interfaces, etc..>

[edit] Technical Diagrams (Flow Chart, Sequence, UML, Systems Architecture, Technical Architecture, Data Architecture, etc..)

<Include architecture diagrams and flow charts>

[edit] Web / Application (New/Modified classes, methods, etc..)

<List new or modified classes and methods>

[edit] Database (DDL changes - new/modified tables, indexes, stored procedures, etc..)

<Summarize database changes>

Data Elements (Refer to Excel document in Mantis)

Mantis: http://ct.jaguarfreight.com/mantis/view.php?id=3574

[edit] Configuration (Config File changes)

<Summarize config changes>

[edit] Logging (Log File changes)

<Summarize Log File changes and locations>

[edit] 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)>

[edit] Open Questions

[Submitted by Perry (5/23/2012)]

  • Determine ALL Elizabeth Arden integration points (P.O. Issued by companies?) Need to figure out where and how many data sources we’ll need to deal with.
  • Try to obtain sample Purchase Orders from all EA P.O. Issued by companies..
    • Using sample Purchase Orders, clarify required data elements to support Purchase Order Event Management within CT2. Will EA provide requirements or will JFS provide requirements? Need to verify that their ERP systems have those data elements available.

[Submitted by Perry (5/30/20120)]

  • Please confirm definitions for below PO states...
    • Open [A PO that has been imported into CT2 and have yet to be fulfilled in its entirety (either partial fulfillment or recurring PO)]
    • Impending [A PO where Late Ship Date < today + x]
    • Past Due [A PO where Late Ship Date < today + x]
    • Cancelled [If a PO has been cancelled by ERP]
    • In Transit [Once a PO has been fulfilled, ASN created, and shipped]
    • Delivered [Once shipment has been received]
  • Who will provide regulatory information?
    • Tax ID
    • Customs ID
    • Regulatory ID
    • Manufacturer ID
      • All Regulatory information will most likely be managed inside Address Book by a Jaguar account/ops manager.
  • Need samples of required documents..
    • Shipping Labels
    • Shipping Instructions
    • Pro-forma invoices
  • Should we create a new CT for each item in each PO that is imported in our system? We might have to take this approach as the entire system revolved around CT records.
    • Yes
  • Will we also support bulk imports of SKUs?
    • Not for Prototype
  • If PO is partially fulfilled, will the due dates need to be adjusted?
    • No
  • Do we need to provide an interface to create POs as well?
    • Not at the moment
  • Should we just add a few new tabs to ASN for Shippers who have PO enabled? Doesn't make sense for a Shipper to enter the POEM portal to review POs, and then enter the ASN portal to view/update ASNs.
    • No. Keep POEM and ASN separate. May merge portals at a future date, but not anytime in the near future.
  • Will a single PO ever have multiple Ship To locations? (example, Item 1 ships to Location1, Item 2 ships to Location2, etc..)
    • Not for our purposes. It will be 1 PO to 1 Ship To location for our purposes.
  • Should the PO editor display all SKUs in a single PO? Or just a single line item per window? If we create a CT for each SKU in a PO, then the PO List can have multiple line items for a single PO. However, what happens if a user opens a single line item in the PO list? Will it allow the user to update all items in the PO or just that single line item?
    • The PO Editor should open all SKUs for that PO.
  • Can a single PO have multiple SKUs with different dates (early ship, late ship, delivery, cargo due, etc..)?
    • For our purposes, no. All dates should be at the PO level.
  • Can a single PO be fulfilled by multiple Shippers from different locations? Ie.. PO issued to a Supplier and then Supplier passes PO over to 2 shippers (1 in US, 1 in China)?
    • Yes, but that can be handled at the ASN level. (ability to select Ship From location - which already exists).
  • Will customs documentation differ based on MOTs?
    • No. Also note that ISF is only for US-bound Ocean shipments.
  • Are the shipping documents created at the CT, PO, ASN, or Group level? Some documents may have to be generated at Group level (customs), while others (packing slips) might be at the PO (full) or CT (partial) level.
    • Must be flexible - ability to multi-select CTs, create documents at the Group or CT level. Pallet/Shipping labels may have to be created via a template. Think of it as a label generator with some pre-populated fields, but shipper will still have to enter in additional temporary information.
  • Should Manufacturer IDs be related to the POs or SKUs? If it's linked to only POs, then what if a supplier ships the same product from multiple warehouses/factories?
    • Manufacturer IDs (MIDs) are linked to addresses. If a an address is marked as a Manufacturer, then it will require an MID.
  • Release Number Field - need additional clarification.
Personal tools