| Does your solution support collection and storage of daily POS data? |
|
Yes. Daily POS can also be rolled into weekly data and the daily activity can be automatically deleted if desired after a designated period of time such as 30 days or 90 days.
|
| What is the load frequency for the data warehouse (and the data mart if applicable)? |
|
Data can be loaded at any time. For retailers sending weekly data, most Velocity sites load activity data multiple times from Sunday night through Tuesday, depending on when the retailers send it. POS data can also be loaded daily, if necessary. Summaries are updated incrementally after each load. If large volumes of data are loaded from multiple customers, Velocity optimizes the summarizations.
|
| Does your solution include aggregate or summary views to enhance performance? |
|
Yes, Velocity has summary tables. The report center will automatically select the table providing the best performance.
|
| How does Velocity manage hierarchies within data that can be considered dimensional (product, customer, time, etc…)? |
|
Velocity has inherent dimensions of time, item, store (location), and customer. For time, Velocity provides fiscal periods based on both the customer (retailer) and your fiscal year so reports can be generated for different audiences. For each item, multiple "customer item" records store retailer-specific data. Attributes can be added to items and stores. Attributes are non-hierarchical, yet can be used in reports in levels of grouping that provide hierarchy. Item and store attributes can also be "master attributes" or "customer attributes". Customer attributes are specific to each retailer, such as a retailer's categories of items, or a retailer's DC alignment of stores.
|
| Can a model of the dictionary be provided? |
|
A manual is provided that describes the database structures and relationships between tables. It also contains sample queries to illustrate the relationships.
|
| Is there a limit to the number of EDI accounts processed? |
|
No
|
| Are there any size limitations to the database? |
|
The size is only limited by the hardware. Based on the number of sku's and retailers managed, we can help you specify the NT Server hardware.
|
| What language is the package software written in? |
| VB.Net and C#. |
| What OS does the Client require? Are there any special hardware requirements? |
| For client programs, the user's computer requires Windows 2000 and above. For web-based applications, it require IE 6.1 or higher. |
| What OS does the server-side of the application run on? |
|
Windows server platforms - Windows Server 2000 and above.
|
| How does Velocity ensure that duplicate EDI transactions are not double counted? |
|
Velocity tracks the transaction control numbers of the incoming EDI transactions to prevent duplicate loading of the same data. For transactions with different control numbers, Velocity has retailer-level configuration settings to control whether the same data for the same item/store/date is summed or overwritten.
|
| How does the application handle messages that do not conform to the EDI standards? |
|
Invalid EDI transactions are rejected and a "problem" is logged for the data administrator.
|
| Does the application identify different user roles in the application, such as administrator versus operator, etc.? |
|
User roles are "administrator", "user", and "read only". In addition, users can be limited to specific customer accounts (retailers).
|
| Does the application log all source records acquired from each source? |
|
Velocity batch loads POS activity data files. All activity data files are compressed and archived by type (EDI, retailer web source, flat file) so that they can be reloaded (manually) as necessary.
|
| Does Velocity log all processing failures on a record-level or on a file-level? |
|
Processing failures are logged on both a record and summary level. For EDI standards errors, the trading partner ID/name, segment type and/or structure violation are reported if they exist. Correctable errors, such as invalid UPCs, are stored in a suspense table. When the error is corrected, the data is loaded from the suspense table. All updates are logged with date/time stamps and operator. A "problem log" identifies failed activities that require administrator attention.
|
| What DBMS is used to store the data? |
|
Microsoft SQL Server, version 2005 and higher.
|
| Are there special tools used to create the analytics? |
|
Velocity includes a proprietary report writer that is optimized for retail analysis.
|
| Does the application include an archiving mechanism? |
|
Answer: All activity data files are automatically archived in Zip compatible files by file type and month as soon as the files are loaded.
|
| How does Velocity maintain the Store/Region relationship table? |
| Velocity can extract and load the relationships from EDI 816 transactions and store lists from vendor portals or Excel spreadsheets. Velocity supports multiple store "attributes", both retailer-specific and common attributes across retailers.
|
| Does the "front-end" of Velocity include acquiring the data (EDI 852, EDI 816, Sears BusinessLink, Wal-Mart RetailLink, Lowes DART, etc.) from a specific source? |
|
Velocity does not "acquire" data. It loads EDI, flat files, and retailer-proprietary files that are delivered to the application server through ftp or a simple file copy mechanism. Velocity can be scheduled to scan for new files on a regular basis. This extends to 3rd party data sources such as AC Nielsen, IRI, Spectra and TDLinx.
|
| How is data loading configured to handle multiple (different) sources? |
|
New data can be imported manually, or Velocity control files can be configured to automate the loading. In either case, the type of file must be specified. For data from certain retailer websites (Wal-Mart, Kmart), the requested reports must be configured in a specific way, which is described in Velocity's user guide.
|
| How does Velocity handle the condition in which two different providers of EDI 852 or 816 data do not interpret the standard in the same manner and thus the data provided might not be as homogenous as one might expect? |
|
"Normalizing" 852 data from different retailers is one of Velocity's main strengths. There are many different scrubbing and post-processing functions that can be configured by customer. Some are specific to EDI 852 transactions, but most are not.
|
| Can Velocity show which DCs service specific stores so we can determine if the DC is sufficiently stocked for the stores? |
|
Yes, DC inventories can be associated with store inventories and sales for supply chain analyses to insure there is appropriate stock for each of the stores that are serviced by the particular DC.
|
| What are examples of special processing that Velocity provides? |
|
For retailers demanding more services from vendors, Velocity can calculate perpetual inventories for Scan Based Trading Programs, track which items are carried or planogrammed at which stores for category captains, and analyze actual sales vs. planned or forecasted sales for account managers managing replenishment for buyers.
|
| Does Velocity process the EDI 867 transaction that contains store locations? |
|
Velocity can load EDI 867 transactions from resellers. Velocity loads their shipment information and summarizes it so the data is consistent with 852 data.
|
| What do your customers usually use before they move to Velocity? |
|
We have several customers who had previously built their own data warehouses for retail POS sales and inventory that migrated to Velocity. They used several different databases, including Access, Oracle, and Teradata. They all found that Velocity's cleansing and normalization functions were much more sophisticated and mature than the ones they were using. Since Velocity is VMT's flagship product, they also appreciated that the functions were updated and enhanced on an on-going basis.
|
| Is there an installation package that installs the database or is it a manual configuration? If it's an installation package, what rights does it require? |
|
The database has a SiteManager program that creates the databases, stored procedures, and views. It also updates existing databases for updates and to apply new user fields.
|
| How frequent are your backup requirements? |
|
We generally recommend full weekly backups and daily incremental backups, but it varies by site. Another option is doing daily full backups of the smaller databases and a weekly full backup of the largest database (POS).
|
| Given the fact that we get 6 millions records/rows per week, how long should we expect our batch window to be? |
|
Retailers send weekly EDI 852s starting Sunday night through Tuesday morning, although the vast majority of 852s arrive Monday morning. Some of the delays are from VAN latency so going to EDI-INT will bring the 852s in sooner as well as save a lot of money in VAN charges. We recommend that you schedule several importing sessions starting early Monday morning.
|
| Can Velocity modules be accessed while new activity is being imported |
|
Clients can access the databases while new activity is being loaded. So your clients can still perform their queries during the scheduled imports. Performance will be slower during the summarizations.
|
| What are some sample load times for Velocity? |
|
The import process validates, loads, and summarizes the activity. With an adequate server system, importing 6M records of store/item combinations should take on the order of 4-6 hours if you wait for all data to arrive, and then load everything in one batch. Importing the data in multiple, smaller batches will shorten each import session and spread the load, although the total processing time will be somewhat longer because of lost optimizations.
|
| What affects import process times? |
|
Several factors affect processing time:
- Foremost is the RAM in your SQL Server. If you stop hitting the cache, summarizations increase at least 5X. Velocity has been optimized to break up large processing functions into smaller "chunks" in order to avoid that.
- Client-side processing. You can manually import data at an administrative client. This significantly slows down the parsing and validation of the import file. However, the load and all of the summarizations are still performed on the server. Depending on the client platform, this can slow the import by a factor of 5 to 20.
- The size of your database (history). The first week of activity that you load will fly. As you accumulate more history, record insertions, updates, and deletions take longer. This also increases the chance of exceeding your RAM allocation (#1). Velocity has been optimized to minimize these types of performance degradations.
- Server hardware (other than RAM). The processor speed affects processing time, but is not a major factor. More significant is the disk configuration. Use a fast RAID configuration with a high performance controller and fast disks. Your level of fault tolerance will have to be factored in.
|
| What is the process Velocity uses to receive POS data from retailers? |
|
Velocity imports raw (untranslated) EDI, translated EDI, and proprietary download files from retailer internet sites, such as Workbench, Retail Link and Partners OnLine. Velocity's load functions are pointed to a folder or a specific filename of the source files to be loaded.
|
| How do other clients use the system to connect to RetailLink (Wal-Mart) and PartnersOnline (Target)? |
|
Due to confidentiality requirements, especially from Wal-Mart, retailers do not allow direct connections to their sites. The Velocity implementation team provides you the format for the queries to be scheduled and the methods to automate the transfer of the files from their sites. These download files can be imported 'as-is' into Velocity.
|
| What is the process for loading POS data from the EDI 852 and EDI 867 into Velocity's POS data warehouse? |
|
The 852 and 867 transactions are parsed and loaded. Other EDI transaction types are skipped. Duplicate transactions, based on having identical control numbers, are rejected. Multiple (non-duplicated) transactions for the same time period can either be summed or overwritten, depending on the customer settings. New "intervals" (time periods) are created based on the fiscal parameters in the retailer's customer record. UPCs are checksummed for validity and can be "translated" to corrected UPCs. New item codes and stores are created as necessary. Invalid information is stored in a "suspense table", which can be reprocessed later after errors are corrected. All case quantities are converted to salable units. If a retailer does not send POS currency sales data, the unit sales can be extended from the customer's standard selling price for that item. Summaries are incrementally updated.
|
| What is the process used to load other data from other sources (customer, product, promotion information) into the POS data warehouse? |
|
Velocity loads flat files with item lists, store lists, customer item lists (such as item code cross references), attributes (dimensional definitions), and activity. Activity files can be merged with activity from other sources, such as EDI transactions.
|
| How is ETL job scheduling done in your application? |
|
The standard Windows Task Scheduler is used to schedule ETL functions. Text-based control files are used to supply the appropriate parameters for each ETL function.
|
| When ETL jobs fail, what kind of notification options exist? |
|
They are logged as problems or errors. We can setup triggers to send notification if necessary.
|
| What are the key measures that are stored in the POS data warehouse? |
|
Velocity can handle daily, weekly, or monthly POS activity. In this explanation, assume all activity is stored weekly. Wal-Mart (RetailLink) and Kmart (Workbench) provide POS data for any time period. Most other retailers provide weekly EDI 852s that are generated after replenishment orders are calculated on Sundays, but some also send daily 852s for warehouse VMI.
Measures that start "QTY" have raw data as reported by the retailers, except that cases are converted to "eaches".
QTY Sold The number of units sold for the week (not relevant for DCs).
On Hand The number of units on hand in a store (not relevant for DCs). For some retailers that send EDI 852s, this filed may be calculated ("propagated") because the retailer does not send inventory if nothing sold at the store or because Velocity is calculating perpetual inventory.
Currency Sold Actual currency (dollar) sales, if the retailer sends it (not relevant for DCs). If not, Velocity can extend the "QTY Sold" by a price in the item record.
QTY Available This is an internal field with the "raw" balance on hand. For reporting, Velocity uses the "On Hand" or "DC On Hand" fields.
QTY On Order The number of units left to ship against open orders, from the retailer's perspective. This is the week-end balance.
QTY Received The quantity received for the week.
QTY Adjustment The number of units adjusted for the week.
QTY in Transit The number of units in transit to a store from its DC.
DC On Hand The number of units on hand in a DC (not relevant for stores).
DC Movement The number of units shipped out of a DC to its stores.
These replenishment factors are also tracked down to store-level if provided by a retailer:
Modeled Whether an item is supposed to be sold at a store (it is in the planogram). This is Wal-mart's "traited" indicator.
Stocked Whether an item is being replenished at a store (usually the same as "Modeled"). This is Wal-mart's "valid" indicator.
Min On Hand An item's reorder point at a store.
Max On Hand An item's maximum on hand to carry at a store ("order up to").
These measures are calculated by Velocity:
Item Avg Price The average selling price, calculated as < Currency Sold > divided by < QTY Sold >.
Intervals Since Sold The number of weeks since the item sold at a store.
Also, Velocity's exception scanning can be used to flag items that have sold less (or more) than a certain number of units over a specified number of weeks (e.g., fewer than 10 items sold over four weeks).
Custom Measures
These measures are calculated "on the fly" during the preparation of custom reports.
Share For category analysis over multiple vendors, it is a vendor's percentage of sales of a category (or fineline).
Share Change The change in a vendor's share from last year.
Pieces/Store/Week The number of units that were sold divided by the number of stores selling the product, divided again by the number of weeks over which the report is run.
The number of stores selling from RetailLink; it is not calculated by Velocity.
Item Unit Retail Wal-Mart's listed selling price.
|
