Setting Up E-Commerce Values

Purpose: The Enterprise Direct Commerce section of the System Control table defines parameters that control:

•         system information

•         program names

•         program information

Note:            If you do not use the e-commerce interface, you do not need to complete the system control values in this section.

For more information:

•         general information on e-commerce: E-Commerce Interface

•         e-commerce setup: E-Commerce Setup

Quick Reference of E-Commerce System Control Values

This table describes briefly each system control value for the e-commerce interface and lists the control code, control value, a short definition, other control values to which you should refer in this section, if necessary, and a column where you can indicate the value that you assigned for your company.

If you have more than one company on your system, make a copy of this table for each.

Company: ________________________________

Additional System Control Values Related to E-Commerce

Get Orders from E-Commerce (G35)

Purpose: Use this screen to indicate whether you will be processing orders through the e-commerce interface.

Yes/No field: Select this field if you will be processing internet orders through the e-commerce interface.

You need to have this value selected in order to complete the download of e-commerce data from Order Management System to the web storefront, as described in Downloading E-Commerce Static Tables (ESTF). Also, the ORDER_CLN job does not automatically purge abandoned e-commerce (order API) orders once the Time Limit for Suspended E-Commerce Orders (G43) has elapsed if this value is not selected.

Leave this field unselected if you will not be downloading data to the web storefront or processing e-commerce (order API) orders.

Quantity Available Threshold for Inventory Downloads (G36)

Purpose: Use this screen to define the quantity available that serves as a trigger for the generic inventory download.

Quantity field: Enter the quantity to trigger the generic inventory download. The generic inventory download enables you to communicate inventory information to external systems, such as through Order Broker.

Note:            This field is also included under the Generic Integration Values (I13) system control value as the Download Threshold Quantity.

Threshold hierarchy: You can also define a Avail thrshld (Item-level availability threshold) for an individual item, and/or a Availability threshold (item class-level) for an item class. The system determines which threshold to use for an item by checking the:

1.      item threshold

2.      if there is no item threshold, the threshold for the item class assigned to the item

3.      if there is no item or item class threshold, the system control value setting

Example:                    An item’s threshold is 20; its item class threshold is 15; and the system control value is set to 25. The interactive inventory download takes place based on the item-level threshold of 20.

Interactive download: A trigger record is created (generic inventory download):

•         if an item or SKU’s available quantity is greater than or equal to this threshold, and then it falls below the threshold

Example:                    Available quantity for item AB100 is 21, and the web threshold is 20. You enter an order line for a quantity of 2, reducing the available quantity to 19.

•         once an item or SKU’s available quantity is below the threshold, each time the available quantity is reduced until it is zero

Example:                    After entering the order line in the above example, you enter another line on a different order for a quantity of 4, reducing the available quantity from 19 to 15.

•         if an item or SKU’s available quantity is below this threshold, and then it increases to the threshold quantity or more

Example:                    After entering the order line in the above example, you cancel an order for 5 units, bringing the available quantity for the item from 15 to 20.

If you leave this field blank, the system checks the item-level and item class-level thresholds as described above. If all of these thresholds are blank, the system will not automatically create inventory download trigger records based on availability thresholds.

About the Generic Inventory Download API

Generic inventory download: If the Create Generic Inventory Download Triggers (I32) system control value is selected, the system creates ITW trigger records in the IL Outbound Trigger table to determine which items to include in the download. The INV_DOWNLD process in Working with Integration Layer Processes (IJCT) then generates the Inventory Download XML Message (CWInventoryDownload) based on the trigger records. However, the system does not create a trigger record if the Include Non-Allocatable Warehouses (I34) is unselected, and none of the existing Item Warehouse records for an item/SKU are non-allocatable.

Interactive trigger creation: The system creates an ITW trigger whenever an item’s available quantity breeches the appropriate threshold, as described above.

Other ways to create inventory download triggers: You can also create ITW triggers for all eligible items through Generating Outbound Interface Triggers (GOIT) or through a periodic function. See Generic Inventory Download API for more information.

Default Batch for E-Commerce Orders in Error (G41)

Purpose: Use this screen to define the order batch number to assign to e-commerce (order API) orders that are in error.

Number field: Enter the order batch number to assign to order API orders that are in error, so that you can use batch order entry to correct the errors.

Orders you receive through the order API go through an edit process. Any orders that fail this edit are placed in error (E) status, and assigned to the batch number you specify here. Additionally, the system generates the Print Remote Order Errors Report, so you can review the errors on particular orders.

You should use batch order entry periodically to check whether any orders are in error, and to correct the errors.

When the order is accepted, the system clears the batch number from the order header if the batch number matches this system control value.

Order Broker: If the Order Broker Error Batch Number (K90) is blank, retail pickup and delivery orders in error are assigned to the same batch as e-commerce orders in error.

Order confirmation? The order API generates the order confirmation when it creates the order regardless of whether the order is in error, provided the Suppress Order Confirmations for Orders in Error (K09) system control value is unselected; otherwise, if this system control value is selected, the confirmation is not generated until you correct the errors and the order is processed by the ORDR_ASYNC background job.

E-Commerce Order Type (G42)

Purpose: Use this screen to define the order type to assign to orders you receive through the e-commerce (generic order) interface.

Code field: Enter the order type code to assign to orders you receive through the e-commerce (generic order) interface. You should not use this order type code for any other types of orders.

This field controls:

•         generation of shipment and return notification emails; see Shipment Confirmation Program (G51) and Return Confirmation E-Mail Program (H53)

•         whether the ORDER_CLN job “rejects” orders that seem to have been abandoned by the customer (for example, if the customer simply closed the web browser window without completing the order); see Time Limit for Suspended E-Commerce Orders (G43)

•         whether the order goes on EH hold if the merchandise total exceeds the Maximum Order Amount for E-Commerce Orders (H54)

You can also use the order type for tracking and reporting.

Reserving orders against a non-allocatable warehouse: If the Retail warehouse field for the e-commerce order type contains a non-allocatable warehouse and the Reserve from Non-Allocatable Warehouse (J25) system control value is selected, the system allows you to reserve inventory against the non-allocatable warehouse defined for the e-commerce order type. If the item is not in stock, the system backorders the item against the non-allocatable warehouse. However:

•         If a warehouse override is defined for the web order (in the ship_to_warehouse attribute), the system applies the override warehouse to the web order instead of the warehouse defined for the e-commerce order type.

•         If a warehouse override is defined for an order line on the web order (in the line_warehouse attribute), the system applies the override warehouse to the order line instead of the warehouse defined for the e-commerce order type.

Order type required: If no order type is specified here and the CWOrderIn message also does not specify an order type, the order will be in error with an error code of X2: Invalid Order Type.

For more information: Order type codes are defined in and validated against the Order Type table. See Establishing Order Types (WOTY). Also, see Generic Order Interface (Order API).

Time Limit for Suspended E-Commerce Orders (G43)

Purpose: Use this screen to define the number of minutes to wait before rejecting a suspended e-commerce order (order API) due to inactivity.

Number field: Enter the number of minutes to wait before rejecting a suspended e-commerce (order API) order. The system waits this amount of time after the customer has selected to “check out” at the web storefront. The cleanup is necessary for cases when customers simply close the browser window or advance to another web page without completing the order.

The ORDER_CLN job, submitted through Working with Integration Layer Processes (IJCT), performs the cleanup and rejection. This cleanup occurs only if:

•         the Get Orders from E-Commerce (G35) system control value is selected

•         the order type matches the E-Commerce Order Type (G42) system control value

•         there is a record in the E-Commerce Order Reference (ECORXR) table, which is used to track the e-commerce cross-reference order number passed in the order_number in the CWOrderIn message

When the ORDER_CLN job deletes a rejected order, it generates the E-Commerce Order Cleanup Log.

Quotes: Because a quote does not reserve inventory and may not require a payment method, the ORDER_CLN job does not include quotes. You will need to manually delete quotes that are incomplete in batch order entry. See Entering Pre-Order Quotes.

Order Acknowledgement Program (G50)

Purpose: Use this screen to define the program to generate email acknowledgments for orders.

System name field: Enter the program name to generate order acknowledgment emails. The standard base program is OrdConf, which generates a notification email in HTML format. Unless you are using a unique order confirmation program or the outbound email API, described below, you need to have this system control value set to OrdConf in order to generate the order confirmation email.

For more information: See Order Confirmation Email Sample and Contents.

Outbound email API: Order Management System generates a generic outbound XML message, rather than an actual email, for order acknowledgments if the XML only? flag for the order acknowledgment template is selected and this system control value is not blank. The Outbound Email XML Message (CWEmailOut) includes additional information that is not included in the standard email notice. You might choose to generate the XML message so that you can use the information to produce a reformatted HTML email that includes promotional information.

For more information: See Outbound Email API for an overview and message details.

Company-level or entity-level email template? The system generates an email using the text from the order confirmation email template, set up through the Working with E-Mail Notification Templates (WEMT) menu option. If you have not set up a template, the system emails the standard order confirmation. You can also set up an email template at the entity level as an override; see Email Setup within Order Management System for more information.

How to generate order confirmations: The order API generates the order confirmation email for orders it creates; however, it does not generate confirmations for orders in error if the Suppress Order Confirmations for Orders in Error (K09) system control value is selected. The order async background job generates the order confirmation email for all other eligible orders as part of background processing, including corrected order API orders which have not already generated confirmations due to the setting of the related system control value.

Determining when to email an order confirmation: See When Does the System Generate an Email Notification? for a discussion on the criteria required to generate an email.

Order history message: When it sends an order confirmation email or Outbound Email XML Message (CWEmailOut), Order Management System creates an order history message such as Ord Conf to kbrown@example.com. You can review order history messages at the Display Order History Screen.

Leave this field blank if you do not want to generate order confirmation emails.

Shipment Confirmation Program (G51)

Purpose: Use this screen to define the program to generate shipment confirmations for order shipments.

System name field: Enter the program name to generate shipment confirmation emails. The standard base program is ShpConf, which generates a notification email in HTML format. Unless you are using a unique shipment confirmation program or the outbound email API, described below, you need to have this system control value set to ShpConf in order to generate the shipment confirmation email.

For more information: See Shipment Confirmation Email Sample and Contents.

Outbound email API: Order Management System generates a generic outbound XML message, rather than an actual email, for shipment confirmations if the XML only flag for the shipment acknowledgment template is selected and this system control value is not blank. The Outbound Email XML Message (CWEmailOut) includes additional information that is not included in the standard email notice. You might choose to generate the XML message so that you can use the information to produce a reformatted HTML email that includes promotional information.

For more information: See Outbound Email API for an overview and message details.

Note:             If you use the Narvar Integration, Narvar generates shipment confirmation emails to the customer based on an order request message sent through billing, and the shipment confirmation is does not use this confirmation program.

Company-level or entity-level email template? The system generates an email using the text from the shipment confirmation email template, set up through the Working with E-Mail Notification Templates (WEMT) menu option. If you have not set up a template, the system emails the standard shipment confirmation. You can also set up an email template at the entity level as an override; see Email Setup within Order Management System for more information.

To generate a shipment confirmation: Order Management System generates a shipment confirmation email or Outbound Email XML Message (CWEmailOut) when you:

•         process a shipment through billing if the Send Shipment Confirmation from Billing (L98) system control value is selected.

•         generate e-commerce shipment confirmations using the Send Internet Order Ship Confirmations menu option; see Sending Internet Order Ship Confirmation (ESCF).

•         execute the ECSHCNF periodic function; see Working with Periodic Functions (WPER).

Determining when to email a shipment confirmation: The system generates an email shipment confirmation or Outbound Email XML Message (CWEmailOut) only if:

•         the Email notification field for the order type is selected, and,

•         the customer’s Opt-in/out setting is O1 or O2 (see Determining the Opt-in/out Setting), and,

•         the customer has an Email address, and,

•         the E-Mail Shipment Confirmations for All Orders (H52) is selected, or,

•         the order type matches the E-Commerce Order Type (G42)

See When Does the System Generate an Email Notification? for more information on the criteria required to generate an email.

Order history message: When it generates a shipment confirmation email or Outbound Email XML Message (CWEmailOut), Order Management System creates an order history message such as Ship Conf to kbrown@example.com.

Return shipments: Order Management System uses the program name from the Return Confirmation E-Mail Program (H53) system control value for return shipments.

Leave this field blank if you do not went to generate shipment confirmation emails.

Status Message for E-Commerce Partial Reserved Lines (G52)

Purpose: Use this screen to define the status to display in emails for order lines that are partially reserved.

Code field: Enter the code representing the status to display in order confirmation and order line cancellation emails when a customer orders an item that is partially reserved and partially backordered or soldout.

Valid values are:

•         BACKORDER: Partially backordered lines are listed as Backordered.

•         RESERVED: Partially backordered lines are listed as Reserved.

•         PARTIAL: The email lists the details on partially backordered or soldout lines; for example, 7 reserved, 3 B/O or 2 reserved, 2 S/O.

Leave this field blank if you do not generate order confirmation or order line cancellation emails.

For more information: See the Order Confirmation Email Sample and Contents and the Order Line Cancellation Confirmation Email Sample and Contents.

Price Override Reason for E-Commerce (G73)

Purpose: Use this screen to specify the price override reason code to use when overriding the regular price of an item for e-commerce (order API) orders.

Code field: Enter the price override reason code to use when overriding the regular price of an item added through the generic order interface (order API).

Price overrides through the generic order interface: When you send the CWORDERIN message, you can include a price override amount in the actual_price attribute. To have this price override amount apply to the order, you can specify a valid price override reason code in the prc_ovr_rsn attribute; or you can use either this system control value or the Default Price Override Reason (B35) system control value to provide the price override reason code to assign to the order. The system uses the following logic if there is an actual_price in the CWORDERIN message:

•         First check the prc_ovr_rsn specified in the message. If it is valid, use this reason.

•         If a prc_ovr_rsn is specified in the message, but is invalid:

•         If this system control value (Price Override Reason for E-Commerce) specifies a price override reason, use this reason; otherwise,

•         If the Default Price Override Reason (B35) system control value specifies a price override reason, use this reason; otherwise,

•         Do not use the actual_price from the message. Use regular pricing logic

•         If no prc_ovr_rsn is specified in the message, do not use the actual_price from the message. Use regular pricing logic

.

Price override reason codes are defined in and validated against the Price Override Reason table.   See Establishing Price Override Reason Codes (WPOR).

Leave this field blank if you do not allow price overrides through the order API.

For more information:

•         processing cancellation or maintenance requests from the web storefront: Working with Batch Order Maintenance Transactions (WBOM)

•         processing orders through the generic order API: Generic Order Interface (Order API)

Hold Reason for Failed E-Commerce Maintenance Transactions (H11)

Purpose: Use this screen to define the order hold reason code to use when a customer’s attempt to cancel an order on the web storefront fails.

Code field: Enter the hold reason code to assign to an order if a customer attempts to process a cancellation from the web storefront, and the request fails. For example, a cancel request might fail if any items on the order have pick slips printed.

Hold reason codes are defined in and validated against the Order Hold Reason table; see Establishing Order Hold Reason Codes (WOHR).

Note:            If a cancel request fails because the order is in use, the order does not go on hold.

Leave this field blank if you do not want orders to go on hold due to a failed cancellation attempt from the web storefront.

For more information: See Working with Batch Order Maintenance Transactions (WBOM) for more information on processing cancellation requests from the web storefront.

Order Maintenance Confirmation E-Mail Program (H12)

Purpose: Use this screen to define the program to use for generating an email confirmation when a customer attempts to cancel an order on the web storefront and the order cannot be canceled.

System name field: Enter the program name to use for generating notification emails for unsuccessful cancellation requests you receive through the web storefront. The base program is OCFAILNOTF.

Unsuccessful attempt: If the attempt is not successful, the system generates a notice to the customer. See When Does the System Generate an Email Notification? for a discussion of how the system determines whether to generate a notice and see Cancellation Request Failure Email Sample and Contents for a sample notice.

Successful attempt: If the attempt is successful, the system generates an order or order line cancellation email confirmation. See the Order Cancellation Confirmation Email Sample and Contents and Order Line Cancellation Confirmation Email Sample and Contents.

For more information: See Working with Batch Order Maintenance Transactions (WBOM) for more information on processing cancellation requests from the web storefront, and see Working with E-Mail Notification Templates (WEMT) for information on setting up a template for the cancellation failure notice and more information on email notifications.

Default Salesrep for E-Commerce Interface (H24)

Purpose: Use this screen to define the default salesrep number to use on e-commerce (order API) orders if the Require Salesrep Number in Order Entry/Order Maintenance (E87) system control value is selected.

Number field: Enter the salesrep number to default on e-commerce (order API) orders if the Require Salesrep Number in Order Entry/Order Maintenance (E87) system control value is selected.

Note:

•         If you specify a salesrep number to default, but the Require Salesrep Number in Order Entry/Order Maintenance (E87) system control value is unselected, a salesrep number does not default.

•         If you do not enter a salesrep number on this screen and the Require Salesrep Number in Order Entry/Order Maintenance (E87) system control value is selected, the order is placed in an error status regardless of whether you have defined a value for the Default Salesrep Number (E86) system control value.

•         If you specify a salesrep number to default, but the Active flag for the salesrep is not selected, the order is placed in an error status.

Salesrep numbers are defined in and validated against the Salesrep table; see Working with Sales Representatives (WSLS).

Default Recipient Type for E-Commerce Orders (H33)

Purpose: Use this screen to define the default type of alternate ship-to address to create for orders you receive through the order API.

Code field: Enter the code identifying the default type of recipient customer to create for an alternate shipping address if a shipping address type is not specified in the inbound order message. Valid codes are:

•         ORDER or blank - Create an ship-to address for this order only. This setting has the same effect as setting the ship_to_type to 1 in the inbound order message.

•         CUSTOMER - Create a recipient address for a separate sold-to customer. This setting has the same effect as setting the ship_to_type to 2 in the inbound order message.

•         PERMANENT - Create a permanent ship-to address for the customer. This setting has the same effect as setting the ship_to_type to 3 in the inbound order message.

Leave this field blank to have the order API default to creating an order-level ship-to address, or if you do not create ship-to addresses through the order API.

For more information: See Creating or Selecting Shipping Addresses or Customers for an overview of how the order API creates or selects a shipping address.

Generate E-Commerce Customer Merge Staging Files (H86)

Purpose: Use this screen to define whether Order Management System generates the E-Commerce Customer Merge Web XML File (CustomerMergeWeb) when you run the customer sold to merge/purge program.

Yes/No field: Select this field if you want Order Management System to generate the E-Commerce Customer Merge Web XML file (CustomerMergeWeb) when you run the customer sold to merge/purge program.

File storage API exports enabled? If this system control value is selected and the FILE_STORAGE_EXPORTS_ENABLED property is selected, the merge/purge program uses the OMS-ECOMMERCE container of the FILE_STORAGE table to create a zip file containing the E-Commerce Customer Merge Web XML File (CustomerMergeWeb). You can use the file storage API to download the file. See the File Storage API for background.

Otherwise, if the file storage API is not enabled for exports, the ECOMMERCE_DIRECTORY_PATH in Working with Admin Properties (CPRP) defines the location on the application server where the system downloads the E-Commerce Customer Merge Web XML file.

Leave this field unselected if you do not want Order Management System to generate the E-Commerce Customer Merge Web XML file (CustomerMergeWeb) when you run the customer sold to merge/purge program.

Delay Order API Edit (I56)

Purpose: Use this screen to indicate whether the order edit and accept runs in synchronous or asynchronous sequence for orders received through the Generic Order Interface (Order API).

Yes/No field: Select this field to run the order edit and accept in asynchronous sequence, or in parallel with the remaining order processing, for orders received through the Generic Order Interface (Order API).

Note:            If the web site is expecting only an order acknowledgement from OROMS on the final submit of an order with payment, select this system control value in order to receive the response faster.

Why use asynchronous order edit? Use the asynchronous order edit to improve the performance of processing orders received through the Generic Order Interface (Order API). When the system reaches the step to perform the order edit, the system runs the order edit in a separate thread so that the remaining order processing can happen at the same time.

The same order processing occurs as when you run the order edit in synchronous, or interactive, sequence; however if the order is received with payment, the system continues with order processing and will generate the response message before the order edit completes. The order will remain in an error status and the order ship-to in a suspended status until the order finishes processing through the asynchronous order edit.

Leave this field unselected to run the order edit in synchronous, or interactive, sequence for orders received through the Generic Order Interface (Order API).

Note:            If you are doing a lot of end of order promotions through OROMS and the web site integration is waiting for a response to provide final totals and other end of order updates, deselect this system control value.

For more information: See Order API Processing Overview for the steps the system performs when processing an order received through the Generic Order interface (Order API).

Download Prepaid Payment Types to E-Commerce (I69)

Purpose: Use this screen to define whether the system includes prepaid (cash/check payment category 1) payment types in the e-commerce pay type extraction.

Yes/No field: Select this field to include prepaid (cash/check payment category 1) payment types in the e-commerce pay type extraction.

The system downloads credit card payment types (payment category 2) to the EC Payment Type file when you select the Payment type field at the Process E-Commerce Downloads Screen. If the Download Prepaid Payment Types to E-Commerce system control value is selected, the system also downloads cash/check payment types (payment category 1) to the EC Payment Type file.

Leave this field unselected to exclude cash/check payment types from the e-commerce pay type extraction. The system downloads only credit card payment types to the EC Payment Type file.

Suppress Order Confirmations for Orders in Error (K09)

Purpose: Use this screen to indicate whether to generate order confirmation emails for orders you receive through the order API even if the order is in error, or wait until the errors are corrected.

Yes/No field: Select this field to delay generation of the order confirmation email for orders you receive through the order API if the order is in error. The order API generates an order confirmation email for an order only if it is created in open or held status, but not for an order that is created in suspended status because of any errors. Once you correct any errors and accept and process the corrected order batch, the system generates the order confirmation email. Otherwise, if the order is rejected, no order confirmation email is generated. In addition, the ORDR_ASYNC job generates the order confirmation for any eligible orders that have not previously generated confirmations.

Why suppress? You might want to suppress initial generation of the order confirmation email so that you are generating emails only for valid orders, and that the emails contain valid information. For example, if you generate a confirmation for an order that includes an invalid ship-to name and address, this information cannot be displayed correctly in the email.

Leave this field unselected to generate the order confirmation through the order API, regardless of whether there are any errors on the order.

Order confirmation generation hierarchy: Provided the order is eligible, the system generates an order confirmation email when:

•         you accept an order in interactive Order Entry.

•         the order is processed by the order API, including orders in error if the Suppress Order Confirmations for Orders in Error (K09) system control value is unselected.

•         you accept and process a corrected order batch, if an order confirmation has not previously been generated for the order ship to.

•         the order is processed by the ORDR_ASYNC job if an order confirmation has not previously been generated for the order ship to.

Eligible for order confirmation? See When Does the System Generate an Email Notification? for a discussion of when an order is eligible for an order confirmation.

Email or CWEmailOut message? The XML only? flag for the order confirmation email template indicates whether to generate an actual email or the CWEmailOut XML message. See the Outbound Email API for an overview.

Populate Ship Status for EmailOut XML (L61)

Purpose: Use this screen to define whether the system populates the ist_ship_status attribute when generating the Outbound Email XML Message (CWEmailOut) for a shipment or return confirmation.

Yes/No field: Select this field to have the system populate the ist_ship_status when generating the Outbound Email XML Message (CWEmailOut) for a shipment or return confirmation.

The system includes the ist_ship_status attribute in the Invoice element of the CWEmailOut message. The ist_ship_status attribute defines the status of the shipment.

•         Partial = Partial shipment. The OST Order status for the Order Ship To is:

•         O Open.

•         X Closed, but there are newer non-credit invoice records for the Order Ship To. The system looks at the IHD Invoice type in the Invoice Header table to determine if the invoice record is a debit or credit invoice: I = Invoice, C = Credit Invoice.

•         Complete = Complete shipment. The OST Order status for the Order Ship To is X Closed and there are no other invoices for the order, regardless of date.

•         Final = Final shipment. The OST Order status for the Order Ship To is X Closed and there are older invoice records for the Order Ship To. Note: Order maintenance and item exchanges to previously closed orders will send the customer a second Final shipment confirmation status. This occurs because the originally closed order was opened again with the addition of the new order line.

Note:            The ist_ship_status attribute is available in version 8.0 of the CWEmailOut message (version 3.5 of Order Management System).

Leave this field unselected to exclude the ist_ship_status attribute when generating the Outbound Email XML Message (CWEmailOut) for a shipment confirmation.

Example 1

An order contains three order lines that ship together. When you bill the shipment, the system generates one invoice for the order and updates its status to X Closed. When the system generates a CWEmailOut message for the shipment, the system populates the ist_ship_status attribute with Complete.

Example 2

An order contain three order lines. Order line 1 ships. When you bill the shipment, the system generates an invoice for the order. The status for the Order Ship To remains O Open since there are two other lines to ship. When the system generates a CWEmailOut message for the shipment, the system populates the ist_ship_status attribute with Partial.

You ship line 2 on the order. When you bill the shipment, the system generates another invoice for the order. The status for the Order Ship To remains O Open since there is one other line to ship. When the system generates a CWEmailOut message for the shipment, the system populates the ist_ship_status attribute with Partial.

You ship line 3 on the order. When you bill the shipment, the system generates another invoice for the order and updates the status for the Order Ship To to X Closed. When the system generates a CWEmailOut message for the shipment, the system populates the ist_ship_status attribute with Final.

Example 3

An order contains three order lines. All three order lines ship; however each item on the order is flagged as a ship alone item. Because all three of the order lines have shipped, the system updates the status for the Order Ship To to X Closed.

When you bill the shipment for the first ship alone item, the system generates an invoice for the order. When the system generates a CWEmailOut message for the shipment, the system populates the ist_ship_status attribute with Partial since there are other outstanding invoices for the Order Ship To.

When you bill the shipment for the second ship alone item, the system generates an invoice for the order. When the system generates a CWEmailOut message for the shipment, the system populates the ist_ship_status attribute with Partial since there is an outstanding invoice for the Order Ship To.

When you bill the shipment for the third ship alone item, the system generates an invoice for the order. When the system generates a CWEmailOut message for the shipment, the system populates the ist_ship_status attribute with Final since there are no other outstanding invoices for the Order Ship To.

Example 4

An order contains three order lines that ship together. When you bill the shipment, the system generates one invoice for the order and updates its status to X Closed. When the system generates a CWEmailOut message for the shipment, the system populates the ist_ship_status attribute with Complete.

In order maintenance, you add two items to the order.

One of the newly added items ship. When you bill the shipment, the system generates one invoice for the order. The status for the order ship to remains O Open since there is one other line to ship.When the system generates a CWEmailOut message for the shipment, the system populates the ist_ship_status attribute with Partial.

The other newly added item ships. When you bill the shipment, the system generates one invoice for the order and updates its status to X Closed. When the system generates a CWEmailOut message for the shipment, the system populates the ist_ship_status attribute with Final.

Consolidate invoice: If you consolidate invoices for the same order on the same date (the Consolidated Invoice (B49) system control value is selected), the setting of the ist_ship_status attribute depends on when you generate shipment confirmations for the day. Example: If an order contains two ship alone items, the ist_ship_status will be Partial if you generate a shipment confirmation after you ship one of the items and will be Complete if you generate a shipment confirmation after both of the items have shipped.

Important:                           In Order Management System 21.0 or higher, you cannot select the Consolidated Invoice system control value if it is not already selected. If the system control value is currently selected (set to Y) and you deselect it (change it to N or blank), you cannot then change it back to selected. The option to consolidate invoices will be removed at a later date.

For more information: See Outbound Email API.

Generate E-Commerce Offer Tables (M29)

Purpose: Use this screen to define whether the e-commerce offer download (EOFR) populates the E-Commerce Offer tables or generates the E-Commerce Product Web XML message (ProductWeb).

Yes/No field: Select this field if you want the e-commerce offer download (EOFR) to populate the E-Commerce Offer tables.

Deselect this field if you want the e-commerce offer download (EOFR) to generate the E-Commerce Product Web XML File (ProductWeb).

Note:            Removing Offers and Items from Download (ERMV) is available only if the Generate E-Commerce Offer Tables (M29) system control value is selected.

File storage API exports enabled? If this system control value is unselected and the FILE_STORAGE_EXPORTS_ENABLED property is selected, the e-commerce offer download creates a zip file in the OMS-ECOMMERCE container of the FILE_STORAGE table. The zip file contains the E-Commerce Product Web XML File (ProductWeb). You can use the file storage API to download the file. See the File Storage API for background.

Otherwise, if the file storage API is not enabled for exports, the file is created in the ECOMMERCE_DIRECTORY_PATH in Working with Admin Properties (CPRP)

For more information: See Downloading E-Commerce Offer Files (EOFR).

________________________________

Contents    SCVs    Reports   XML Messages   Glossary

Copyright © 2022, Oracle and/or its affiliates. All rights reserved.
Legal Notices