Invatron

preload_login_button
My Support Login

PeriScope - New Features in Version 3.2

 

Backroom product physical inventory

Adding store unique backroom products

Release 3.2 enables you to add user-defined items to the inventory count screen for financial inventory purposes. Just like corporate backroom product, you can add description, count, weight, and value for items. However, unlike corporate backroom products, system on hand values for store unique product counts are not updated - counts for store unique backroom products are only made available for extract by external systems. To leverage the data entry effort, items remain in the system for retrieval until the next count making them easy to re-use. Data can be sent to the financial reporting system as an external feed.

To clear the count weight and dollar fields of a user defined item, use the Inventory count 'Apply' option. The descriptions of cleared items are preserved.

Determining SKU numbers with Pocket PeriScope

To make it easier to count product, Pocket PeriScope can now scan entire EAN Code 128 barcodes and extract the Vendor Product Code (VPC), along with the weight in kilograms or pounds if present. Based on the scanned VPC, Pocket PeriScope then looks up the SKU# and if it cannot find it, immediately gives you the option of entering it manually.

Manual entry of VPCs has also been improved: if a VPC is being manually entered, Pocket PeriScope can verify the existence of the VPC and prompt the user for weight (if random-weight backroom product) or for quantity (if a non-random-weight backroom product).

Improved retail physical inventory support

To meet the requirements for financial reporting and ordering purposes, we have enabled PeriScope to capture weights as part of the physical inventory count process. Pocket PeriScope collects the data, which can be made available to external systems as required.

Traditionally, maintaining inventory by weight has been difficult because it is either too time consuming to measure or too difficult to estimate accurately. To enable you to use weight as part of your physical inventory process, you have the option to adopt one or both of the following:

  • An average weight of counting unit
  • NSC-2 bar codes (random weight UPC)

The average weight of counting unit makes it possible to treat random-weight items like non-random-weight items: you count random-weight items rather than weighing them. This requires establishing a standard weight to be used as a counting unit for each item. For example, if you decide that the standard counting unit for grapes is a small bunch (200 grams), all the store personnel would need to do is count the number of small bunches. The system would calculate the total weight based on the following formula:

Number Of Bunches x Average Weight Of Counting Unit

The use of NSC-2 bar codes provides retailers with a way to calculate weight rather than physically weighing them or estimating a weight. Because NSC-2 bar codes include retail package values, actual weights can be calculated according to the following formula:

Retail Price / Unit Price = Weight.

For example, if T-bone steaks have a unit price of $10.00 per lb and the self-service case contained one steak priced at $5.00 and another priced at $15.00, then the system would calculate a total weight of 2 lb (5/10 + 15/10).

Note the following possible sources of factors of error:

  • Because the pack date can be different from the count date, a factor of error would be introduced if the unit price were subsequently changed at the time of counting from its original value.
  • Scanning a marked down item could also introduce a factor of error.

New reports and reporting capabilities

Backroom Product Listing Report

Release 3.2 includes a new Backroom Product Listing report that groups backroom products by Department and, if available, sub-groups them by Cutting Test. You can optionally filter the report to only display those backroom products that are not associated with a UPC or conversely, to only display those backroom products that are associated with one or more UPCs.

Recipe Listing Report

Release 3.2 includes a new Detailed Recipe Listing report that lists recipes in a one-recipe-per-page format. You can optionally filter the report to only display those recipes that are not associated with a UPC or to only display those recipes that are associated with one or more UPCs. You can also optionally filter the report to only display those recipes that are associated with sellable products sold during a specified date range or to only display those recipes that are associated with sellable products not sold during a specified date range.

In addition, we have added a new Summary Recipe Listing report to PeriScope. This report groups recipes by department and, if desired, can sub-group them by recipe category.

Scheduling reports as static HTML email attachments

To provide another option besides printed reports, PeriScope 3.2 includes the ability to publish reports as static HTML pages that you can distribute by email or file transfer. This includes the Production Worksheet, which in previous releases could not be saved as a report profile. Electronic versions of reports look identical to their PeriScope user interface counterparts and do not include the repeating headers that appear when reports are printed from PeriScope.

In addition, a new scheduling option makes it possible to send a Production report to coincide with a given production cycle, less a specified lead time (in hours). The selection of a production cycle does not limit the output of the report. This option is strictly for the timing of the report execution - there is no validation to check that all products on the report are associated to the specified production cycle.

Recipe management improvements

Release 3.2 includes significant enhancements to recipe management. System administrators and Administrators can now:

  • Use an expanded set of search criteria to more easily find recipes
  • Copy existing recipes for editing purposes
  • Set PeriScope to automatically generate unique IDs for new recipes

Automatic discards on returns/refunds

To eliminate the need to manually capture discards resulting from returns, PeriScope now automatically processes each return as a discard transaction.

Core case locations upgrade

To help you accommodate higher demand for your region, PeriScope now provides the ability to specify minimum exceptions for core corporate case locations if the values you specify are equal to or greater than the corporate minimum.

Optional storage of business-related settings in the database

In previous releases, PeriScope's business-related settings were always stored only in the solution's initialization files. Now you have the option of storing them in your database to ensure that all application servers connected to the database have the same configuration of business-related settings.