Urban Outfitters will require direct SQL access to the databases. Service provider will furnish an Entity Relationship Diagram (ERD) for the database after implementation. In addition, updated versions will be provided as changes are made to the solution over time. The allocation system will support a multi-brand implementation (currently Urban Outfitters, Anthropologie, and Free People) which maintains a master merchandise view that supports enterprise-wide reporting and analysis, but that allows brand-level analysis and maintains privacy between brands where appropriate. A brand’s own audience should be its primary view into the database, but sales data from other brands should still be available for comparison, analysis, and selection. For example, Free People may want to use the sales history for a similar tank top that was carried by Anthropologie as the sales basis for the allocation of the Free People tank top. The system will be constructed to easily support expansion of the data model to include new data elements as well as additional brands in the future. 1.4.2 Historical Data Conversion Assumptions: The following highlights the general guidelines and assumptions that will be followed in the conversion of historical sales data from Island Pacific to the new allocation system. HISTORICAL DATA CONVERSION ASSUMPTIONS No formal database will be migrated, but rather a host of different source system historical data elements will be extracted and loaded to build tables in the allocation database. Approximately 2 years of daily history will be converted to the line item detail level for retail sales (currently planned to take data starting from 6/1/2008 to present). UOI may adjust this date forward depending on the system implementation timeline. 18 months of merchandise and assortment plan data will be converted and imported (currently planned to take data starting from 12/1/2008 to present). UOI may adjust this date forward depending on the implementation timeline. It should be assumed that no unique purchase key exists (for distros). A purchase order ID is provided by the order management system (IP), but because of duplication issues where PO numbers are reused, PO records should not be considered unique. Other keys such as PO receipt date and vendor ID will be available. Data transformations may be required to establish unique consistent keys during the historical load of data. All historical customer records loaded will have the agreed-upon data validation rules applied to them prior to loading.
MAIN SUCCESSFUL SCENARIO 1.) Allocator views current store group listings and clicks on a button to create a store group 2.) A pop-up window appears prompting the user to create a store group name 3.) Allocator adds name and presses enter 4.) System prompts user to checkmark all of the stores that should be added to the group 5.) Allocator check marks all stores that should be added to the group and clicks the submit button 6.) Store group is created and is immediately available for allocators to choose when creating allocations OTHER SUCCESSFUL SCENARIOS Step Branching Action 1a.) Allocator views current store group listings and clicks a link adjacent to the store named “delete store group” group is deleted and is removed from being available to be selected when making a new allocation 1b.) Allocator views current store group listings and clicks on a link adjacent to the store group named “edit group’s stores” System lists all of the stores available. The ones currently belonging to the store group are check-marked. The allocator checks and unchecks stores from the listing depending on whether they need to be added or removed respectively. When the allocator is finished, he/she presses the submit button and all new created allocations using that store group will include the store group changes UNSUCCESSFUL SCENARIOS (erroneous situations) Conditions Actions c* At any point in time, the user can decide to quit by pressing a ‘return home’ key Transaction is aborted and user is back to main portal Frequency 10 times a week non-functional requirements Superordinates NA Developer GB, FL, CS Creation date / Last modified date 6/1/2010; 6/7/2010 Other Comments USE CASE UC9 USE CASE Name Define alternate merchandise hierarchies Relating Feature 25 ACTOR(s) Allocator Description Division, department, and color is an example of a standard hierarchy but not all standard hierarchies prove useful as a as a sales basis (to create an allocation) for new products. Alternate merchandise hierarchies allow an allocator to create a customized hierarchy using an array of attributes. The
Web Server HP • 4 CPU • 8GB RAM • Windows 2003 Staging Server (Testing Only) HP DL385 • 8 CPU • 32GB RAM • Windows 2003 (64bit) 9.3 Software Interfaces This section describes software interfaces to other components of UOI’s merchandising software system. These are components with which this software application must interact. Each data type is also represented in the system level data flow diagram in section 4.4.1 of this specification. Data Source File Details: The following details the source systems for files, number of files, and formats to be expected in the conversion of data. There are always two files coming from Island Pacific because the US and the UK operations are each using a separate instance of the ERP system. Other data types, such as initial POs and PO changes, consist of two files because the PO header and PO details are separated. DATA TYPE NUMBER OF FILES FORMAT FREQUENCY GRAIN SOURCE SYSTEMS Sales 2 Pipe delimited Daily Island Pacific Inventory 2 Pipe delimited Daily Island Pacific Merchandise Item Master 2 Pipe delimited Daily SKU Island Pacific Merchandise Attributes Reference 2 Pipe delimited Daily Attribute Island Pacific Facilities Master (Stores, Distribution Centers, Backstock Locations) 2 Pipe delimited Weekly Location Island Pacific
Facilities Attributes Reference 2 Pipe delimited Weekly Attribute Island Pacific Level Selling Plans 1 Pipe delimited Daily Class NSB Planning Assortment Plan 1 Pipe delimited Daily Buyer’s Workmate Size Profiles 1 Pipe delimited Daily Class Buyer’s Workmate Initial POs 2 Pipe delimited 10 Minutes SKU Workmate PO Changes 2 Pipe delimited Every 30 minutes SKU Island Pacific DC Receipts 1 Pipe delimited Every 30 Minutes Manhattan WMS ASNs 1 Pipe delimited Daily Tradestone Image URLs 1 Pipe delimited As Needed SKU Library Data Output File Details: The following table details the destination systems for files generated by the new allocation system as well as the respective formats to be expected. DATA TYPE NUMBER OF FILES FORMAT FREQUENCY GRAIN DESTINATION SYSTEMS Allocation Picking Instructions 2 Pipe delimited Every 10 Minutes Manhattan WMS