In order to bring you the best possible user experience, this site uses Javascript. If you are seeing this message, it is likely that the Javascript option in your browser is disabled. For optimal viewing of this site, please ensure that Javascript is enabled for your browser.
Login  |   On Demand  |   Home  |   qad.com




Release Notes for Release 4.2
QAD CSS Version: 4.2
Release Date: September, 2005
MFG/PRO Compatibility: MFG/PRO eB2 SP9 and eB2.1 SP2 and SP3
The release of QAD CSS 4.2 removes all known limitations in terms of integration with MFG/PRO standard functionality and MFG/PRO currently supported versions. With this release, QAD CSS becomes fully compliant with MFG/PRO eB2 and eB2.1. This release also adds enhancements to support available to promise (ATP) functionality, credit card processing, security, and security reporting.
The following documentation has been updated for this release:
Installation Guide: QAD Customer Self Service (78-0638A)
Implementation Guide: QAD Customer Self Service (78-0627C)
1
MFG/PRO and QAD CSS Integration
A number of optional features in MFG/PRO affect the fields and frames that display in Sales Order Maintenance (7.1.1). QAD CSS now integrates correctly with MFG/PRO when any of the following optional features are enabled:
Logistics Accounting
Customer Consignment Inventory
Customer Reserved Locations
Shipment Performance
Container and Line Charges
2
Available to Promise (ATP)
Order processing can now be controlled based on the projected quantity available to promise (ATP) for sales order line items.
For details, see Available to Promise (ATP).
3
Security Enhancements
Program pages are now secured from unauthorized access through entering a page URL. Two new security reports support this enhancement and an existing report provides additional security-related details. For details, see Security Enhancements.
4
Credit Card Enhancements
Credit card processing is now able to manage authorization and delayed capture as separate transactions.The Credit Card Menu now replaces the previously named Storefront Integration Menu.
Implementing these enhancements requires modifications to MFG/PRO that are included on the QAD CSS CD in version and service-pack specific directories. Installation Guide: QAD Customer Self Service describes the steps necessary to use these enhancements.
For details, see Credit Card Enhancements.
5
Enhanced Reporting
The Order Tracking Report and the Internal Order Tracking Report now provide additional information relating to lot or serial number associated with shipped items. Promised date and/or due date information can now be provided on 14 external and internal reports relating to orders.
For details, see Enhanced Reporting.
New security reports are available. For details, see Security Reports.
MFG/PRO and QAD CSS Integration
The data load from QAD CSS now populates the proper MFG/PRO fields with the appropriate values when the following sales order maintenance features are enabled:
Logistics Accounting
Customer Consignment Inventory
Customer Reserved Locations
Shipment Performance
Container and Line Charges
This assumes that, for the enabled functionalities in MFG/PRO, you have set the appropriate defaults in all fields that require an input value.
When these features are not being used in MFG/PRO, any associated frames or pop-ups are skipped during the QAD CSS data load, which proceeds to populate the fields in the remaining frames.
In the case of Shipment Performance, sales orders initiated from QAD CSS are created in MFG/PRO with a blank line-item category. If you want a different category to be used, you must manually edit the sales order in Sales Order Maintenance (7.1.1) before initiating the shipment.
Available to Promise (ATP)
QAD CSS now works in conjunction with ATP functionality introduced in MFG/PRO eB2. Using a combination of new registry settings in QAD CSS, you can take advantage of ATP calculations to let shoppers know whether inventory is available to fill their orders before the order is submitted.
You can also take advantage of promise date (delivery date) calculations based on the setup of delivery transit times in MFG/PRO. If you do not have delivery transit times available, you can continue to use the due date for calculating availability for shipment. You can configure which dates display in the product catalog, shopping cart, and order summary pages.
If you have defined ATP enforcement levels in MFG/PRO, QAD CSS now recognizes those levels and appropriately creates errors or warnings when shoppers submit orders that cannot be fulfilled on the due date.
Since ATP enforcement level check applies only to confirmed orders in MFG/PRO, QAD CSS now provides more control over whether orders are entered into MFG/PRO as confirmed or unconfirmed.
Note: Regardless of the setting for confirmed orders in QAD CSS, ATP calculations occur during order entry in QAD CSS when ATP enforcement is enabled.
ATP features in QAD CSS take advantage of ATP features in MFG/PRO; however, additional features are provided in the Web order-entry system to accommodate the need for shoppers to have information about availability in real time.
Determining Confirmed Orders
In MFG/PRO, orders are entered as confirmed when Confirmed Orders is Yes in Sales Order Control (7.1.24). In previous versions of QAD CSS, the Submit Confirmed setting in QAD CSS Order Control determined if orders were entered as confirmed. This version no longer uses the setting in QAD CSS Order Control Maintenance (Administration Menu|System Control Menu|Order Control).
In this version, you can use a new confirmedOrders registry setting to determine if orders are entered as confirmed based on user ID, customer ID, security group, customer group, or marketing group, or as a global setting.
Requesting a Delivery Date
In QAD CSS 4.1.4, you could use the combination of three registry settings to control the display of information in the Available column in the product catalog. These settings access the standard MFG/PRO Sales Order Control settings to determine quantity on hand (QOH) for the default site or all sites, and to display the actual quantity or a text message indicating availability.
In CSS 4.2, you can continue to use the settings introduced in version 4.1.4. However, you can now let shoppers request the earliest possible available date (either ship date or delivery-to-customer date) for a requested quantity based on ATP calculations or QOH calculations.
Note: ATP calculations only work for the default site; if you plan to implement ATP features, your QOH settings should also reference the default site, not all sites.
To let users request a delivery date, a new Delivery button can be displayed in the following places:
Beside the Add button for each item in the product catalog
Beside the Add button in the express order cart
Beside the Delete button for each order line on the shopping cart
The display of this button is controlled by a new showDeliveryIcon system registry setting with the following values:
Yes: The Delivery button displays.
No: The Delivery button does not display.
Note: This feature can be used even when ATP enforcement has not been enabled in MFG/PRO. The way dates and quantities are calculated varies as described in the following sections.
Calculating Quantities
MFG/PRO supports two methods of calculating availability:
Standard quantity-on-hand calculation
Expanded available-to-promise calculation based on control settings and item setup
If you have done the setup required for ATP enforcement calculations, QAD CSS now determines quantities by executing the same ATP calculations that occur in MFG/PRO ATP Enforcement Check (7.1.19.2). ATP applies when:
ATP Enforcement Enabled is Yes in MFG/PRO Sales Order Control (7.1.24).
ATP Enforcement Level is Warning or Error for the item/site combination in MFG/PRO Item-Site Planning Maintenance (1.4.17) or for the item in Item Master Maintenance (1.4.1).
Note: Regardless of the setting of ATP Enforcement Enabled, standard calculations are always used to determine quantities for configured items, family items, and for items in an Enterprise Material Transfer (EMT) transaction.
Calculating Dates
Your QAD CSS system can interact with three dates associated with a sales order in MFG/PRO:
Required Date
This is the date the shopper wants to have the items. If not specified, it is assumed to be the earliest possible date, which is today. In QAD CSS, this date is referred to as the request date.
Due Date
This is the date the order will be ready to ship from your shipping dock. In MFG/PRO the system calculates the default due date by adding the shipping lead time from Sales Order Control (7.1.24) to the order date. Due date is an important factor in many internal MFG/PRO calculations such as Material Requirements Planning (MRP). In QAD CSS, this date is also referred to as the ship date.
Promise Date
This is the date that items are expected to arrive at the shopper’s location. MFG/PRO can calculate this date when Calculate Promise Date is Yes in Sales Order Control and data has been defined in Delivery Transit Time Maintenance (2.16.1). In QAD CSS, this date is also referred to as the delivery date.
When a user clicks the Delivery button, QAD CSS calculates either a ship (due) or delivery (promise) date based on how you have configured your MFG/PRO system:
When Calculate Promise Date is No and a shopper clicks the Delivery button on the product catalog page, a message displays about the ship date (due date) for the requested quantity. Promise Date fields in the shopping cart—if displayed—are blank.
When Calculate Promise Date is Yes and a shopper clicks the Delivery button on the product catalog page, a message displays about the delivery date (promise date) for the requested quantity. Promise Date fields on the shopping cart display the delivery date (promise date), calculated as the request date plus the shipping lead time plus transit time.
You can choose which dates to display on the shopping cart and the Finish Order pages using QAD CSS registry settings. Promise date can be displayed based on the following new settings:
showPromDate determines whether to display the promise date in the order header.
showLinePromDate determines whether to display the promise date for each order line item.
These new settings correspond to the existing settings for showReqDate and showLineReqDate, which have the same effect for the request date.
Important: Since Promise Date fields have a value only when Calculate Promise Date is Yes in Sales Order Control, you should not enable these settings unless MFG/PRO is set up to calculate promise dates.
A new CSS registry setting setReqDate can be used to set the default value of the request date in the shopping cart to either the promise date (when Calculate Promise Date is Yes) or due date (when Calculate Promise Date is No). When showReqDate and showLineReqDate are Yes, an Apply All button displays beside the header Request Date field. This lets users apply the header Request Date to all order lines.
Displaying Messages
When a shopper clicks the Delivery button, the system returns one of three possible messages about item availability based on either the standard or ATP calculation method.
A message indicating the ship date—when Calculate Promise Date is No—or delivery date—when Calculate Promise Date is Yes
A message indicating the maximum quantity that could be delivered on the ship or delivery date for partial availability
A message indicated no availability
Note: Message content is affected by whether the QAD CSS registry setting for confirmedOrders is Yes and whether you are on the shopping cart page or a different page. If the order is submitted unconfirmed (that is, confirmedOrders is set to No), the messages indicate that this is an estimated date. Instead of stating that items can be delivered on a particular date, the message states they can be delivered around that date.
Product Catalog
The messages in the following table are displayed in the product catalog when confirmedOrders is Yes.
 
Calculation
Method
Calculate
Promise Date
Date Used
Possible Message
Standard
No
Due Date xx/xx/xx
Request Date yy/yy/yy
Ship date for the requested quantity of # item xxx is xx/xx/xx.
A maximum quantity of # item xxx can be shipped on yy/yy/yy. Please contact Customer Service for further information.
This item is currently not available. Please contact Customer Service for further information.
Standard
Yes
Promise Date xx/xx/xx
Request Date yy/yy/yy
Delivery date for the requested quantity of # item xxx is xx/xx/xx.
A maximum quantity of # item xxx can be delivered on yy/yy/yy. Please contact Customer Service for further information.
This item is currently not available. Please contact Customer Service for further information.
ATP
No
Due Date xx/xx/xx
Request Date yy/yy/yy
Ship date for the requested quantity of # item xxx is xx/xx/xx.
Ship date for the requested quantity of # item xxx is xx/xx/xx. A maximum quantity of # item xxx can be shipped on yy/yy/yy. Please contact Customer Service for further information.
Ship date for the requested quantity of # item xxx is xx/xx/xx. Items are not available before yy/yy/yy.
ATP
Yes
Promise Date xx/xx/xx
Request Date yy/yy/yy
Delivery date for the requested quantity of # item xxx is xx/xx/xx.
Delivery date for the requested quantity of # item xxx is xx/xx/xx. A maximum quantity of # item xxx can be delivered on yy/yy/yy. Please contact Customer Service for further information.
Delivery date for the requested quantity of # item xxx is xx/xx/xx. Items are not available before yy/yy/yy.
Shopping Cart
The effect of the Delivery button on the shopping cart is similar to the product catalog but adds even more features by letting a shopper try out different dates and quantities and then choose to accept the calculated results. The same messages can display, but they are followed by an Accept link.
On the shopping cart, the user can change the request date and click the Delivery button to see how the change affects quantity and delivery date. When the request date is sooner than the delivery date, messages like the following display:
Delivery date for the requested quantity of 10 item A500 is 08/15/05. Accept
Maximum Quantity of 8 item A500 can be delivered on 08/10/05. Accept
When the shopper clicks the Accept hyperlink at the end of the first message, the system changes the request date of the order to the earliest possible promise date. Clicking the Accept hyperlink at the end of the second message changes the ordered quantity to the maximum quantity available on the request date.
ATP Enforcement Level
When a shopper first displays the shopping cart page or clicks Submit Order on the Finish Order page, QAD CSS executes the same ATP calculations that occur in MFG/PRO when ATP Enforcement Enabled is Yes in MFG/PRO Sales Order Control (7.1.24).
The system determines the ATP enforcement level for the item based on how it is set up in MFG/PRO Item-Site Planning Maintenance (1.4.17) or Item Master Maintenance (1.4.1), and proceeds accordingly.
When level is None, the shopper can submit the order regardless of availability.
When level is Warning, a warning message displays, but the shopper can submit the order.
When level is Error, an error message displays, the Check Out button is disabled, and the order cannot be submitted.
The same ATP enforcement validation occurs again during the order transmission to MFG/PRO, in case quantities have changed in the MFG/PRO database. If warnings or errors occur, an e-mail event is generated to the Customer Service Representative (CSR). When the ATP enforcement level is Error, the order fails to load and is not created in MFG/PRO.
New Registry Settings
 
Key
Default
Usage
confirmedOrders
Yes
This setting determines if orders are entered as confirmed.
setReqDate
No
This setting determines the default value of the request date when the shopping cart first displays.
Yes, and promise dates are being calculated in MFG/PRO: Order line request date defaults from the calculated order line promise date.
Yes, and promise dates are not being calculated in MFG/PRO: Order line request date defaults from the calculated order line due date.
No: Order line request dates are blank.
showDeliveryIcon
Yes
This setting determines whether the Delivery button is displayed beside the following buttons:
Add button for each item on the product catalog
Add button in the express order cart
Delete button for each line in the shopping cart
The setting values are Yes or No.
showLinePromDate
Yes
This setting determines whether the promise date is shown for each order line item on the shopping cart and the Finish Order pages. The setting values are Yes or No.
showPromDate
Yes
This setting determines whether the promise date is shown in the order header on the shopping cart and on the Finish Order pages. When the promise date varies per line, the header promise date shows the latest promise date for all lines on the order.
If you want shoppers to see different dates for each line, set showLine PromDate to Yes.
 
Modified Registry Settings
 
Key
Default
Usage
showDueOrPromDate
PromiseDate
This setting determines which dates, if any, display on the order-related reports that can be viewed by customers as well as the order summary page that displays during checkout.
PromiseDate: Promise date displays.
Both: Both dates display.
None: No dates display.
(Any other value): Due date displays.
showReqDate
Yes
This setting determines whether an updateable Request Date field displays in the order header on the shopping cart and the Finish Order pages. The setting values are Yes or No.
When this field is Yes and showLineReqDate is No, the header request date applies to each line on the order and cannot be changed.
If you want shoppers to be able to change the date for each line, set showLineReqDate to Yes.
When showReqDate and showLineReqDate are Yes, an Apply All button displays beside the header Request Date field. This lets users apply the header Request Date to all order lines.
showLineReqDate
No
This setting determines if a field displays next to each item in the shopping cart so the buyer can specify a request date. Values are:
No: Line item request dates are not entered. showReqDate is typically Yes in this case.
Yes: Line item request dates are entered. The showReqDate field is typically set to No. However, when both showReqDate and showLineReqDate are Yes, an Apply All button displays beside the header Request Date field. This lets users apply the header Request Date to all order lines.
Required: Same as Yes but input of the field is mandatory during order entry.
 
Security Enhancements
Additional security features now prevent a user from bypassing menu security to access an unauthorized page. In addition, two new security reports are available and security information has been added to an existing report.
Security Groups
Previously, users who currently have a valid QAD CSS session could access some programs directly from the browser Address bar by entering a page URL. Since this method bypassed the QAD CSS menus, a user could access a restricted page. Changes to QAD CSS security now let system administrators restrict a parent page and all its subordinate pages, regardless of how it is accessed.
To support this enhancement, the following changes have been made to Detail System Module Maintenance (Administration Menu|System Control Menu|System Module Maint):
The existing Parent Page field is now a text box where you can enter or modify the parent pages of the current program page. Default data for parent-child relationships in the system is loaded during installation of QAD CSS 4.2.
A new Security Required field indicates whether access to the current program page is restricted
A list of security groups displays to indicate which security groups have access to the current program page. These groups were assigned access to the parent page in Administration|Menu Maintenance. Changing the security groups in Detail System Module Maintenance is possible but not recommended.
Security Reports
The existing Module Report has been updated to include a new column that indicates for each module if access is needed.
A new Module Security Report (Administration Menu|Administration Reports|Module Security Report) lists security groups associated with all modules that require security protection.
Another new Module Hierarchy Report (Administration Menu|Administration Reports|Module Hierarchy Report) displays information about the modules according to their place in the parent-child hierarchy in an indented listing. The parent modules are shown at the left side and the child modules on the right side of the report.
Credit Card Enhancements
Credit Card Menu
In MFG/PRO, the Storefront Integration Menu (7.21) has been renamed Credit Card Menu to include QAD CSS credit card transactions. The term Storefront has also been removed from the menu items and replaced by the term Credit Card. The 7.21 menu now appears as shown below:
 
Menu Number
Description
7.21
Credit Card Menu
7.21.1
External Address X-Ref Browse
7.21.2
Credit Card Transaction Browse
7.21.3
Credit Card Sales Order Browse
7.21.24
Credit Card Control
MFG/PRO menus will be updated to reflect these changes during installation of QAD CSS 4.2 if necessary.
Credit Card Processing
If you are implementing credit card processing with QAD CSS, a new creditCardTransType registry setting lets you determine how processing is managed:
The sale process applies when merchants or manufacturers are able to take an order and ship the ordered item the same day.
The authorization and delayed capture process takes place in two phases. Authorization takes place when the shopper submits an order and enters billing information. After the order is accepted and shipped in MFG/PRO, fund capture or settlement takes place during invoice post.
The system creates a credit card history record associated with the sales order submitted to MFG/PRO.
Note: If a credit card does not receive an authentication code, the order is not submitted to MFG/PRO.
In MFG/PRO, Invoice Post (7.13.4) has been enhanced to:
Create the capture transaction and send the capture transaction to the credit card processing service.
Create a credit card transaction history record for the capture transaction.
Create an accounts receivable payment record for credit card transactions from both the sale process and the delayed capture process.
Throughout the sales order cycle in MFG/PRO, the system performs the following validations on orders paid by credit card:
The credit card has not expired.
The total amount of the order does not exceed the authorized amount.
The current date is not after the authorized date.
Six programs perform credit card validations. The first three in the following list validated credit card information in previous releases; the last three have been enhanced in QAD CSS 4.2:
Sales Order Shipments (7.9.15)
Pending Invoice Maintenance (7.13.1)
Pre-Shipper/Shipper Confirm (7.9.5)
Picklist/Pre-Shipper–Automatic (7.9.1)
Pre-Shipper/Shipper Workbench (7.9.2)
Invoice Post (7.13.4)
Enhanced Reporting
On the Order Tracking Report and the Internal Order Tracking Report, QAD CSS users can choose to display the lot or serial number associated with each item shipped on an order. To support this function, a new Show Lot/Serial Numbers Shipped check box is provided on both reports (Order Menu|Account Information|Order Tracking, and Order Menu|Internal Order Reports|Order Tracking INT). For this function to work, Lot/Serial Control must be set to either L for Lot or S for Serial in MFG/PRO Item-Site Planning Maintenance (1.4.17) or Item Maintenance (1.4.1).
The promise date and/or due date can be displayed during order entry on the Finish Order page and on the header and order line for the following 14 external and internal reports accessed from the Order Menu|Account Information menu and the Order Menu|Internal Order Reports menu respectively:
Order Tracking
Order Summary
Order Purchase
Order by Order
Order by Item
Order by Customer
Invoice History Report
To enhance this feature, two new values—Both and None—have been added to the showDueOrPromDate setting in the system registry.