JRI's Help page for StoreFront

StoreFront is a subset of Dayton Access (ePortal). Its sole purpose is to allow users to enter sales orders into Avante via the web. Access to StoreFront is given to users via the Admin section.

StoreFront

Yearly Sales
SELECT SOHDR WITH YEAR = "2017" AND WITH CSR = "WEB"
LIST SOHDR TOTAL CNTR TOTAL ORDER.VALUE2 ID.SUPP DET.SUPP

Item Search
Unlike the Product search in Dayton Access, the Item search in StoreFront does not show all the items that Dayton Superior sells. Instead, it only shows those items that have been flagged as being available for on-line sales. These are further restricted based on the customer.
After enterring search criteria, the results of the search will be displayed on the screen. From this point, the user has the option of clicking on a part description hyperlink or clicking the [Add to Basket] button. If they simply click the button to add an item to their shopping cart, the system will place the item in their basket and refresh the page. The shopping cart info on the left of the web page will now reflect this change. If the item is sold in specific quantities (ex. a drum of chemicals might be sold in increments of 55 gallons), the user will be alerted to this fact, and asked if they wish to continue. If they do, then this quantity will be added to their basket as opposed to just a single unit.
If the user clicks on the item description hyperlink, it will take them to a 2nd web page. This 2nd web page has more details about the item, and allows the user to choose a requested ship date and a specific quantity. Both of these values are pre-filled for the user.
The default requested shipping date will be todays date plus 3 days (bumping up if that date should be a non-work day). The user may override this date via either the dropdown menu dates (month, day & year), or by clicking on the calendar icon. Note that they can not choose a weekend, a date in the past, or a holiday. Holidays are defined in a tab-delimited text file call holidays.txt which is located in \eCommSuite\STD\Storefront\date_scripts.
The default qty will be 1 unless the item has an order qty factor. In this case, it will default to the order qty factor. If the user changes the default value and the item has an order qty factor, then they must choose a qty that is evenly divisible by the order qty factor.

Shopping Cart
When a user enters the StoreFront side of Dayton Access (ePortal), they may choose from a list of items to add to their shopping cart. This shopping cart is unique to each login (E-mail address) and customer number combination. Thus, if a user has access to 3 different customer accounts (affiliated customers in Avante), they could have up to 3 different shopping carts. Note, however, that they can only access the shopping cart for that customer account that they are currently linked to (this can be changed via the Welcome link at the bottom of each page). The shopping cart can be viewed at any time by simply clicking on the text or icon on the left side of the web page.

shopping cart file = SF_PREORDER

Load Storefront Parts
SET.SF.ITEMS is a utility run from TCL to load changes to existing items and to add new ones to Storefront. A file of the changes will be submitted to IT, most likely as an Excel file. Save this file as a tab-delimited file in your home dir. This file will have a minimum of 5 column (anything after the 5th is used by the user and is ignored by this program).
  • Item #
  • Sellable on Storefront (Y/N)
  • Sales Group Code
  • Order Qty Factor
  • Catalog Code
It is assumed that the 1st line is a header line for the columns and is skipped. The program will then do a pre-load pass through the entire file. If there are any problems, the problems are reported and the import aborts w/o any updates. If there are no errors, the data is loaded into Storefront and Avante, and an E-mail is sent to the person running this program. This E-mail will contain a total number of items updated, as well as an attachment showing what was updated.

Note that this routine only updates those items that are on the list. This list should contain ALL Sellable Parts for Storefront, not just new changes to specific parts. At this time (06/18/09), it is not a big deal, but the intent is that this program will be changed to disable parts that are not on the list.

Find Missing Price Lists
FIND.MISSING.PRICE.LIST is a utility run from TCL to find parts that are flagged as sellable in Storefront but are missing pricing info. This is run against ePortal user ids and can be run in one of three ways:
  • all users
  • all active users
  • a specific user (user's E-mail address/Dayton Access login ID
It will then collect the user IDs based on this selection. Next it builds a list of unique customer IDs (CUSTMST IDs). The program then compares the parts that are available to each customer and determines if they have all the pricing info for the customer/part combination. When complete, the program will send an E-mail to the user who ran the utility program. This E-mail will contain all the details of what was found, including any errors. All errors will be detailed in an Excel attachment. This attachment will contain:
  • Price List
  • Part #
  • Sales Category
  • Major Group
Note that if a part/customer combination is missing, it does strange things in Storefront, but does not cause any actual harm. When showing a list of parts (such as in a search), all parts that a customer should have access to see are collected. Next, Storefront will display these parts (20 items/web page) along with a total number of pages (at the bottom of each page). Part of the logic to display these items is to calculate the price. If an item/customer combo is missing pricing, that part drops off the list. However, that part was still used to calculate the total number of pages as well as a block of 20 items/page. This can lead to web pages having fewer than 20 items/page as well as the total number of pages being incorrect.

II RECORD CORRUPT
I have no idea what causes this, but whatever it is, it can have fatal effects when StoreFront tries to save a sales order. This message is caught in the out_DEV.DATA..., out_PILOT.DATA..., or out_LIVE.DATA... Redback log (not the EPORTAL logs). If the filing of a StoreFront order hangs, try these things:
  • Copy the XML file to the appropriate STOREFRONT_SO_IN, then try to file the order manually (using the received email's instructions)
    else
  • From the appropriate SB account, run /CLEAN.SYSTEM1
1 This does not eliminate the error trapped in the RB logs, but does seem to get the order to process.

FORCE.HUSH
This is a fix/work-around for II RECORD CORRUPT above.

As part of the filing of an order in StoreFront, there is some logic that calls SB.SET.COMMON. It has begun giving the error above. At first, this was only happening in PILOT, but has begun happening in DEV (but not LIVE). Why? No idea.

The subsequent filing of the order all worked as expected, so this is not a fatal error. I also found that all Redback logging (CRTs) was missing after this cryptic error.

What appears to be happening is that there is a HUSH ON in SB.SET.COMMON, but if it encounters the error, it does not do a HUSH OFF. Thus, all further logging for that order is lost.

What I have found is that I can force a HUSH ON before calling SB.SET.COMMON and then do a HUSH OFF, the error is not logged (though it still happens), and all the subsequent Redback logging is captured in the logs.

This is controlled by a variable called FORCE.HUSH (TRUE/FALSE). This is set in 2 programs:
  • SFEXECUTEORDER (which actually passes it off to SFORDERAPI)
  • SFINITAV

This flag should be set to TRUE unless we are actively trying to resolved the error message.