1 Feature Summary

The enhancements below are included in this release.

Noteworthy Enhancements

This guide outlines the information you need to know about new or improved functionality in the Oracle Retail Order Management Suite Cloud Services update and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.

Column Definitions

• Feature: Provides a description of the feature being delivered.

• Module Impacted: Identifies the module associated with the feature, if any.

• Scale: Identifies the size of the feature. Options are:

  • Small: These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.

  • Medium: These UI or process-based features are typically comprised of field, validation, or program changes. Therefore the potential impact on users is moderate.

  • Large: These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.

• Delivered: Is the new feature available for use immediately after upgrade or must the feature be enabled or configured? If no, the feature is non-disruptive to end users and action is required (detailed steps below) to make the feature ready to use.

• Customer Action Required: You must take action before these features can be used. These features are delivered disabled and you choose if and when to enable them.

Feature	Module Impacted	Scale	Delivered	Customer Action Required?
New and Updated Features
Business Time Zone	Order Administration – Modern View, Classic View, Web Services, Payments, Pricing, Billing, Invoicing, Integrations	Large	Yes	Yes
Tax Compliance-Consolidated Tax Request	Order Administration – Vertex, Avatax, Generic Tax Interface	Large	Yes	No
Tax Compliance-Vertex Retail Delivery Fees	Order Administration – Vertex	Medium	No	Yes
Tax Compliance-Generic Tax Interface	Order Administration – Web Services	Medium	No	Yes
Payment Cardholder Name and Address	Order Administration – Modern View, Web Services	Medium	Yes	Yes
External Payment Service Level 2 and 3 Discounting	Order Administration – Modern View, Web Services	Small	No	Yes
Personalization Enhancements	Order Administration – Modern View, Web Services	Medium	Yes	No
Order Entry and Summary-Display Shipping Weight	Order Administration – Modern View Contact Center	Small	No	Yes
Customer Engagement Enhancement-Customer Match Logic	Order Administration – Customer Engagement Integration	Small	No	Yes
Collect and Receive Enhancements	Order Administration	Small	No	Yes
Web Service Enhancements	Order Administration	Medium	No	Yes
Database and Retail Data Store Updates	Order Administration	Small	Yes	No
Business Time Zone	Order Orchestration – Order Administration Integration	Small	Yes	No
Web Service Enhancements	Order Orchestration – Web Services	Small	Yes	Yes
Database and Retail Data Store Updates	Order Orchestration	Small	Yes	No

Order Administration Enhancements

Important Announcement about New Functionality

Important:

This update has significant changes related to how dates and times are tracked and how tax is calculated. To understand specific changes and understand what setup should be performed immediately upon updating, see sections Order Administration: Business Time Zone and Order Administration: Tax Compliance.

When updating the Time Zone in Work with Company (WCMP), consider whether your business supports Daylight Savings Time and select an applicable IANA Time Zone.

Business Time Zone

With this update, Order Administration now supports the ability for retailers to define their business time zone by company. The business defined time zone is used as the standard across the application regardless of where individual users, customers, stores, or warehouses are located geographically.

Order Administration stores dates and timestamps in Coordinated Universal Time (UTC) to allow your business to display and convert into your own business date for reconciling order, sales and return activity along with integrating with external applications.

Order Administration requires the use of IANA (Internet Assigned Numbers Authority) Time Zones to avoid issues across different browsers and technology. IANA Time Zones follows the convention of {AREA}/{LOCATION} and should be used when entering the Time Zone code in the Company (WCMP). An {AREA} corresponds to a continent or an ocean and the {LOCATION} to the name of the largest city within the region containing the clocks. For example, instead of CST you would use US/Central or America/Chicago. Additionally, when selecting a time zone, consider whether your business handles Daylight Savings Time and select an appropriate IANA Time Zone.  The latest Time Zone data can be found from the IANA TZdata page website for use in selecting the applicable time zone for your business.  A simplified and reader-friendly representation of the IANA (TZDB) time zone information can be found on the IANA (TZDB) time zone information. This page is accurate and up to date as of today and reflects the latest IANA version 2025a which was released on 2025-01-15. This page can be used as an example or for quick reference, but the users are advised and encouraged to use the data from IANA TZdata page.

Note:

Regarding Java Runtime support for IANA Time Zones, the latest TZDB version from IANA is 2025a. However, this version is yet to be supported by Java Runtime. Documentation for Time Zone Data Versions supported by the Java Runtime can be found from Timezone Data Versions in the Java Runtime. Order Administration would support the Time Zones supported by Java Runtime version in use.

Important:

Only time zones that are equal to or have a negative offset (time is west) of UTC are currently supported in this update. Time zones that have a positive offset (time is east) of UTC are not supported. The support for this feature is currently planned and in active Oracle Retail development.

Example: US/Central (UTC-05:00) is supported and Europe/Amsterdam (UTC+01:00) is not.

The application identifies dates in the following ways:

• Retailer Business Day: Business day refers to the day the retailer conducts normal business operations for the application. The current day is defaulted based on the company time zone value when not passed or overridden. This date field is always stored as a date with no time or time zone in the database. Examples include order date, arrival date, cancel date and deposit release date fields.

• Retailer Timestamp: Retailer timestamp refers to two different sets of dates that are derived from one another: the existing legacy fields where date and time are stored in separate fields and a new corresponding combined date and time stored in a single field.

  • Certain existing date and time fields are derived and stored based on the company time zone value when not passed or overridden. No time zone is included. Examples include entered date and entered time, authorization date and authorization time, ship date and ship time (when exists) in multiple tables. If these fields are overridden, they should be overridden based on company time zone value and are used to derive the corresponding combined date/time below. 

  • New combined date/time timestamp with time zone identifier fields are always stored in UTC. If not passed or overridden, they are derived from the current UTC date and time or converted from the existing date / time fields using the company time zone. Examples include entered, authorization, and shipped fields. If these fields are overridden, they should be overridden using the time zone offset from UTC

• System Timestamp: System timestamp refers to the date, time, and UTC time zone the application uses for all processing. This can be either a new combined date/time field such as CREATED which is stored with a time zone in UTC or existing separate date and time fields such as the order transaction history date and order message date and time, which are in UTC without a time zone.

Important:

Dates in transactional and historical tables not specifically mentioned may also reflect the Retailer Business Day or Retailer Timestamp if derived from a date field already converted. For example, the Inventory Transaction History table uses the shipped date, which is in Retailer Timestamp, for shipments but currently still uses the System Timestamp for returns.There may be processes that use the Order Date to compare against the Current System Timestamp. For example, if the Order Date is used to set the Arrival Date and it is in the Future, the order does not perform an Online Authorization because the date is greater than the current date.

Time Zone Configuration

Define the business time zone by entering a supported time zone in the Time Zone field of the Change Company (WCMP) screen.

The company time zone is used by multiple features including Inbound APIs, Modern View UI and Integrations. See below for full details.

• Time Zone is set to UTC by default, and the system will automatically reset back to UTC if an invalid or unsupported time zone is entered, and the changes are saved.

  • The value must be an exact match of case and format of the IANA Time Zones.

• Updating the Time Zone will take effect immediately. Existing records in the database will not be modified.

Important:

Use caution when changing the time zone after daily processes have occurred for the company since this will take effect for new transactions only. Oracle Retail recommends displaying the company after making a change to ensure it was considered valid and did not reset back to UTC.

Not all browsers support the same time zone naming convention. Only enter a valid IANA Time Zone to avoid issues. For example, instead of CST you would use US/Central or America/Chicago. It is important to verify the time zone is working in Modern View and core processes.

Modern View User Interface

With this update, most of the date and time fields displayed on Modern View pages have not been changed. The following describes the enhancements that have been made to support the Retailer Time Zone.

• Retailer Business Day fields such as order date, arrival date, cancel date display the date stored. No time or time zone are included.

• Retailer Timestamp fields such as authorization date/time display the date and time without a time zone. For transactions after the update, these are converted and stored based on the company time zone configured at the time of the transaction.

• The Date Entered, on the Order Header, is stored in the database in UTC; however, the application converts the timestamp to the company time zone for display in the Modern View Order Summary. Only the Additional Order Details and Edit Additional Order Details pages within Order Summary have been updated.

  • For example, if the company time zone is set to US/Central, it will be displayed as 01/12/2025 07:42:48 AM US/Central, and if it’s set to America/Chicago, it will be displayed as 01/12/2025 07:42:48 AM America/Chicago.

• When a Shipment occurs through CWPickIn or Manual Confirmation (MCON), the Ship Date is now included in the Order Activity description within Order Summary. Previously, it was used as the activity date which may have presented the records out of sequence. The activity date is now the current System timestamp when the shipment was processed by Order Administration.

  • The shipped timestamp is displayed in UTC. For example, regardless of the company time zone, it is displayed as 01/12/2025 15:35:00 UTC in this update.

The Modern View UI now uses the defined Retailer Business Day (Time Zone for the Company) to determine which date is defaulted when a user opens the Calendar Date Picker to choose a date. Previously, this used the System Timestamp in UTC

• The date picker for all date fields that are enterable support the company time zone.

• Once a date is entered into the field, the date picker uses that date as the starting point.

• For date fields that have restrictions (that is, cannot be earlier than today), the UI uses the Retailer Timestamp as the current date for comparing against the entered date.

• When the Order Date is manually overridden through MV Order Entry or MV Order Summary for an order in error, the date populated is stored with the order. If the Order Date is left blank, the System Timestamp is converted to the Retailers Business Day and stored.

Web Service Changes

Order Administration has created new Inbound and Outbound API versions that now include attributes that support ISO 8601 standard date and time with offset formats. These new attributes allow your business to send in various dates in any time zone, and Order Administration will store in UTC and return in UTC.

All existing date and time attributes have been retained to maintain backwards compatibility. If old attributes (for example, enter_date, enter_time) are populated, they are treated as if they are already in the Time Zone configured for the Company. See below for the logic on how the system handles the different attributes passed.

Note:

Web Services not listed have not been modified for handling retailer time zone as part of this update.

The following Inbound message versions and attributes were added to support a Retailer Timestamp in ISO 8601 format. Oracle Retail recommends leveraging the new attributes to be able to define the time zone offset from the external system mapping to avoid mismatch in dates across the applications.

• CWOrderIn 14.0 updated the logic for setting the ORDER_DATE and ARRIVAL_DATE when not overridden in the message.

  • The Retailer Business Day is derived based on how the attributes are populated. Once derived, no additional conversion will be done.

    • ORDER_DATE

      • If populated and valid, it will be the Retailer Business Day.

      • If not populated or invalid, convert the System Timestamp to the company time zone, and the resulting date will be the Retailer Business Day.

    • OST_ARRIVAL_DATE or ODT_ARRIVAL_DATE

      • If populated and valid, it will be the Retailer Business Day.

      • If not populated or invalid, uses the derived ORDER_DATE as the Retailer Business Day if it is equal to or greater than the current Retailer Timestamp. If greater than the current Retailer Timestamp, it will be set to the current Retailer Timestamp.

    • Existing columns in the database will be used.

• CWOrderIn 14.0 added an ENTERED timestamp attribute in the Header element.

  • The Retailer Timestamp will be derived based on how the attributes are populated:

    • The ENTERED attribute is to be supplied by the retailer with the time zone offset from UTC to derive the Retailer Timestamp. For example, if your business operates in US/Central time zone, you can pass “2025-01-12T14:30:21.000-05:00” as the value. If populated, the existing ENTER_DATE and ENTER_TIME attributes will be ignored.

    • The ENTER_DATE and ENTER_TIME attributes are to be supplied by the retailer in the retailer business time zone to derive the Retailer Timestamp. Using the ENTER_DATE, ENTER_TIME and the company (WCMP) time zone, the ENTERED timestamp will be converted to UTC.

      • If ENTER_TIME is not supplied, the time will be midnight (00:00:00).

      • If ENTERED and ENTER_DATE is not supplied, the current system timestamp (in UTC) is converted to the company time zone to derive the Retailer Timestamp.

  • ORDER_HEADER database table updates:

    • The new ENTERED column in the database is stored with the derived Retailer Timestamp converted to UTC.

    • The existing OHD_ENTERED_DATE and OHD_ENTERED_TIME columns in the database is stored in the company time zone.

  • ORDER_DETAIL database table updates:

    • The existing ODT_ENTERED_DATE and ODT_ENTERED_TIME columns in the database is stored in the company time zone. These do not use attributes passed in the message and instead use the current system timestamp (in UTC) converted to the company time zone to derive the Retailer Timestamp.

    • The new ENTERED column in the database stores the System Timestamp in UTC.

• CWOrderIn 14.0 added an AUTHORIZED timestamp attribute in the Payments element.

  • The Retailer Timestamp is derived based on how the attributes are populated:

    • The AUTHORIZED attribute is to be supplied by the retailer with the time zone offset from UTC to derive the Retailer Timestamp. For example, if your business operates in US/Central time zone, you can pass “2025-01-12T14:30:21.000-05:00” as the value. If populated, the existing AUTH_DATE and AUTH_TIME attributes are ignored.

    • The AUTH_DATE and AUTH_TIME attributes are to be supplied by the retailer in the retailer business time zone to derive the Retailer Timestamp. Using the AUTH_DATE, AUTH_TIME and the company (WCMP) time zone, the ENTERED timestamp will be converted to UTC.

      • If AUTH_TIME is not supplied, the time will be midnight (00:00:00).

    • If AUTHORIZED and AUTH_DATE is not supplied, the current system timestamp (in UTC) is converted to the company time zone to derive the Retailer Timestamp.

  • AUTHORIZATION_HISTORY database table updates:

    • The new AUTHORIZED column in the database is stored with the derived Retailer Timestamp converted to UTC.

    • The existing AUH_AUTH_DATE and AUH_AUTH_TIME columns in the database is stored in the company time zone.

• CWPickIn 5.0 added a new SHIPPED attribute the CartonHeader element:

  • The Retailer Timestamp is derived based on how the attributes are populated:

    • The SHIPPED attribute is to be supplied by the retailer with the time zone offset from UTC to derive the Retailer Timestamp. For example, if your business operates in US/Central time zone, you can pass “2025-01-12T14:30:21.000-05:00” as the value. If populated, the existing SHIP_DATE and SHIP_TIME attributes will be ignored.

    • The SHIP_DATE and SHIP_TIME attributes are to be supplied by the retailer in the retailer business time zone to derive the Retailer Timestamp. Using the SHIP_DATE, SHIP_TIME and the company (WCMP) time zone, the SHIPPED timestamp will be converted to UTC.

      • If SHIP_TIME is not supplied, the time will be midnight (00:00:00).

      • If SHIPPED and SHIP_DATE is not supplied, the current system timestamp (in UTC) is converted to the company time zone to derive the Retailer Timestamp.

    • ORDER_SHIPMENT_DETAILS database table updates:

      • The new SHIPPED column in the database will be stored with the derived Retailer Timestamp converted to UTC.

      • The existing SHIP_DATE column in the database is stored in the company time zone.

• CWReceiptIn 2.0 added a new RECEIVED attribute to the Receipt element:

  • The Retailer Timestamp is derived based on how the attributes are populated:

    • The RECEIVED attribute is to be supplied by the retailer with the time zone offset from UTC to derive the Retailer Timestamp. For example, if your business operates in US/Central time zone, you can pass “2025-01-12T14:30:21.000-05:00” as the value. If populated, the existing RECEIPT_DATE and RECEIPT_TIME attributes will be ignored.

    • The RECEIPT_DATE and RECEIPT_TIME attributes are to be supplied by the retailer in the retailer business time zone to derive the Retailer Timestamp. Using the RECEIPT_DATE, RECEIPT_TIME and the company (WCMP) time zone, the RECEIVED timestamp will be converted to UTC.

      • If RECEIPT_TIME is not supplied, the time will be midnight (00:00:00).

    • If RECEIVED and RECEIPT_DATE is not supplied, the current system timestamp (in UTC) is converted to the company time zone to derive the Retailer Timestamp.

  • ­PO_RECEIPT and PO_RECEIPT_ERROR database table updates:

    • The new RECEIVED column in the database is stored with the derived Retailer Timestamp converted to UTC.

    • The existing RECEIPT_DATE and RECEIPT_TIME/TIME columns in the database is stored in the company time zone.

ISO 8601 formats supported for the inbound attributes are (the .mmm is optional):

• yyyy-mm-ddThh:mi:ss.mmmZ where the Z is Zulu, an abbreviation for UTC.

• yyyy-mm-ddThh:mi:ss.mmm+00:00 where the +00:00 represents a time offset from UTC of 0 hours which is UTC or GMT

• yyyy-mm-ddThh:mi:ss.mmm-06:00 where the -06:00 represents a time offset from UTC of - 6 hours which is US/Central Standard Time

The following Outbound message versions and attributes were added to support a Retailer Timestamp in ISO 8601 format with 3 milliseconds (no rounding): yyyy-mm-ddThh:mi:ss.mmmZ where Z is Zulu, an abbreviation for UTC. Oracle Retail recommends leveraging the new attributes to be able to allow your business to convert into your own business date for reconciling order, sales and return activity along with integrating with external applications.

• CWCustHistOut 3.0 added:

  • entered to the Header element. New attribute representing the timestamp the order was entered. From the ENTERED column of the ORDER_HEADER table.

• CWEmailOut 15.0 added:

  • invoiced to the Invoice element in UTC. Legacy attribute is ist_ship_date in company time zone.

• CWInvoiceOut 8.0 added:

  • invoiced to the InvoiceHeader>InvoicePaymentMethod element in UTC. Legacy attribute is ipm_invoice_date in company time zone.

  • invoiced to the InvoiceHeader>InvoiceShipTo element in UTC. Legacy attribute is ins_invoice_date in company time zone.

  • entered to the InvoiceHeader>OrderHeader element in UTC. Legacy attribute is ohd_enter_date and ohd_enter_time in company time zone.

  • entered to the InvoiceHeader>InvoiceShipTo>InvoiceDetail>OrderDetail element in UTC. Legacy attribute is odt_entered_date and odt_entered_time in company time zone.

• CWOrderOut 15.0 added:

  • entered to the Header element in UTC. Legacy attributes are entered_date and entered_time in company time zone.

  • created to the Header element in UTC. New attribute representing the timestamp the order was created within Order Administration. From the CREATED column of the ORDER_HEADER table.

  • shipped to the ShipTo>Detail>Shipment element in UTC. Legacy attribute is invoice_ship_date in company time zone.

  • lastShipped to the ShipTo>Detail element in UTC. Legacy attribute is last_ship_date in company time zone.

  • authorized to the Header>Payment element in UTC. Legacy attribute is credit_card_auth_dt in company time zone.

• CWPickOut 7.0 added

  • entered to the PickHeader>OrderHeader element in UTC. Legacy attribute is entered_date and entered_time in company time zone.

• CWReturnRAOut 4.0 added

  • returned to the RADetail element in UTC. Legacy attribute is return_date in company time zone.

• Generic Tax API, CWTaxRequest 2.0 added:

  • requested to the Header element in UTC. New attribute representing the current System Timestamp.

  • order_date to the CustomerShipTo element in Retailers Business Day. New attribute representing the date of the order. From the OHD_ORDER_DATE column of the ORDER_HEADER table.

  • shipped to the CustomerShipTo>OrderDetail element in UTC. New attribute representing the date of the shipment. From the SHIPPED column of the ORDER_SHIPMENT_DETAILS table.

  • entered to the CustomerShipTo>OrderDetail element in UTC. New attribute representing the timestamp the order was entered. From the ENTERED column of the ORDER_HEADER table.

• External Payment Service (EPS) 4.0 added

  • authorized to the authorizationHistory and orderPaymentMethod elements for an Authorization, Deposit and Authorization Reversal requests in UTC. Legacy attribute is authDate in company time zone.

  • authorizationSent to the authorizationHistory elements for an Authorization, Deposit and Authorization Reversal requests in UTC. Legacy attribute is sentDate in company time zone.

• Update Order Header Info Response (../OrderUpdateResource/updateOrderHeaderInfo/) added:

  • entered to the Header element in UTC. Legacy attribute is enteredDateMMDDYYYY in company time zone.

  • enteredTime to the Header element. New attribute representing the entered time in the company time zone.

Item Pricing

Pricing methods that use an offer start and end date, effective date or a date range to identify which price an item qualifies for have been updated to compare the Retailer Timestamp. The current System Timestamp is converted to the company time zone to derive the Retailer Timestamp for comparison.

The following pricing methods have been modified:

• Item and SKU Offer Pricing including Price Breaks (MITM)

• Coupon Promotions (WCPR)

• Customer Price Groups (WCPG/WPRG)

• Customer Contract Pricing (WCST)

Note:

Pricing Methods not listed have not been modified for handling retailer time zone as part of this update. They either do not use dates for qualifiers, or they leverage the Order Date for comparison which is already stored as the Retailer Business Day and does not require a conversion.

Payment Processing

As payment transactions occur through authorization, deposits, refunds and reversals, the current timestamp is derived based on the current Retailer Timestamp. This can be used to tie out transactions against the payment service provider. All existing date and time columns in the database are stored with the date and time from the derived Retailer Timestamp.

• AUTHORIZATION_HISTORY, AUTHORIZATION_HIST_PRINT, ON_LINE_AUTHORIZATION, ORDER_PAYMENT_METHOD and INVOICE_PAYMENT_METHOD database tables have a new AUTHORIZED column stored with the derived Retailer Timestamp converted to UTC.

• AUTHORIZATION_HISTORY and AUTHORIZATION_HIST_PRINT database tables have a new AUTHORIZATION_SENT column stored with the derived Retailer Timestamp converted to UTC.

• CC_DEPOSIT_HISTORY database table has a new DEPOSITED column stored with the derived Retailer Timestamp converted to UTC.

• INVOICE_PAYMENT_METHOD database table has a new DEPOSIT_CREATED column stored with the derived Retailer Timestamp convert to UTC.

• REFUND database table has a new REFUNDED and PROCESSED column stored with the derived Retailer Timestamp converted to UTC.

When a user adds a manual authorization for a payment through Modern View Order Entry or Order Summary, the Retailer Timestamp is derived by using the Authorization Date populated, appended with midnight (00:00:00) as the time and the company time zone as the offset.

Submit Deposits (SDEP) and SCHDDEP periodic function have been modified to identify all pending deposit transactions where the Deposit Release Date is equal to or less than the current Retailer Timestamp. The application takes the current System Timestamp and converts it to the company time zone to create the Retailer Timestamp for use in the comparison

Manually Confirming Shipments (MCON)

When a user performs a manual confirmation of pick tickets (individual or batch) through Manually Confirm Shipments (MCON), the Retailer Timestamp is derived by using the Billing Date populated, appended with midnight (00:00:00) as the time and the company time zone as the offset.

• ORDER_SHIPMENT_DETAILS database table updates:

  • The new SHIPPED column in the database is stored with the derived Retailer Timestamp converted to UTC.

  • The existing SHIP_DATE columns in the database is stored in the company time zone.

• The Billing Date defaults based on the current date in UTC. Classic View was not modified to use the company time zone in the date picker.

Billing and Invoicing

As billing transactions occur and an invoice is generated, the billing timestamp is calculated based on the setting of Use Async Start Date for Billing Transactions (E95) system control value.

• When Use Async Start Date for Billing Transactions (E95) system control value is set to No, the system uses the SHIPPED timestamp as the billing Retailer Timestamp for shipment events. For all other events, it will use the current System Timestamp.

  • See CWPickIn section of Web Service Changes and Manually Confirming Shipments (MCON) for how the SHIPPED timestamp is set.

• When Use Async Start Date for Billing Transactions (E95) system control value is set to Yes, the system always uses the Async Start Timestamp as the Invoiced date and time.

  • Each ASYNC job within Work with ASYNCS (MBJC) now tracks the Start and Stop times as a Timestamp with Time Zone.

  • MBJC along with START_ASYNC, END_ASYNC and JOBCLEAN Periodic Functions have been modified to store the start and end times in new database columns of the ASYNCHRONOUS_JOB_CONTROL table

• BILLING_HEADER_DATA_QUEUE, BILLING_DETAIL_DATA_QUEUE, BILLING_LOC_DATA_QUEUE, BILLING_SVC_DATA_QUEUE and ORDER_DETAIL_DATA_QUEUE database tables have a new BILLED column stored with the derived Retailer Timestamp converted to UTC.

As invoices are generated after processing through billing, the Invoice Date Timestamp is derived from the new billing Retailer Timestamp and stored in a new INVOICED column.

• INVOICE_SHIP_TO and INVOICE_PAYMENT_METHOD database tables have a new INVOICED column stored with the derived Retailer Timestamp converted to UTC.

Additionally, the following database table updates are included to track additional timestamps related to shipments, returns and exchanges:

• BILLING_DETAIL_DATA_QUEUE and ORDER_DETAIL_DATA_QUEUE database tables have new RETURNED and EXCHANGED columns stored with the derived Retailer Timestamp converted to UTC.

• INVOICE_DETAIL database table has new SHIPPED and RETURNED columns stored with the derived Retailer Timestamp converted to UTC.

Integrations

Order Administration has enhanced base Oracle and External integrations to use the Retailer Timestamp as part of its communications.

Note:

Base Integrations not listed here were not modified for handling retailer time zone as part of this update.

• Vertex

  • Only message version 9.0 is supported. 7.0 has been removed.

  • The DocumentDate is set to the Retailer Business Day. The current System Timestamp is converted to the company time zone, and the resulting date will be the Retailer Business Day. The Quotation, Invoice and Distribute Tax Request have been modified.

  • The flexibleDateField is set from the Order Date which is already stored as the Retailer Business Day.

• Order Orchestration

  • The OROB_MESSAGE_VERSION property is automatically set to 25.1 and can no longer be changed.

  • The datetime attribute in all messages that Order Administration calls were modified to pass the current System Timestamp in an ISO 8601 format.

    • Messages changed include: getInventoryAvailability, Fulfillments, Order Status Inquiry, Order Status List, Order Status Update, Order Update, Product Availability, Submit Order

  • The transaction_date in the Submit Order message is now being populated from the ENTERED timestamp on the Order Header in an ISO 8601 format. Previously, this was sending the current System Timestamp.

  • The status_date in the Status Update message is now being populated from the SHIPPED timestamp, in an ISO 8601 format, for an intransit or fulfilled status update change on a Ship For Pickup, Retail Pickup and Delivery order. Previously, this was not mapped.

  • For each Delivery and Retail Pickup order that is created from a Fulfillments message, the ENTERED timestamp on the ORDER_HEADER table is mapped from the transaction_date attribute. This will be in an ISO 8601 format as UTC

    • The existing OHD_ENTERED_DATE and OHD_ENTERED_TIME columns in the database will be stored with timestamp converted to UTC.

Refer to the Order Orchestration Business Time Zone section for more information on the enhancements in Order Orchestration.

Database

Order Administration has added new database columns with a type of TIMESTAMP(6) WITH TIME ZONE to persist dates and times in UTC. Each new column is available through Retail Data Store for custom reporting.

Database View	Columns Added
ASYNCHRONOUS_JOB_CONTROL	JOB_STARTED, JOB_ENDED, CREATED
AUTH_HISTORY_SVC_REVERSAL	APPROVED, CREATED
AUTHORIZATION_HIST_PRINT	AUTHORIZED, AUTHORIZATION_SENT, CREATED
AUTHORIZATION_HISTORY	AUTHORIZED, AUTHORIZATION_SENT, CREATED
BILLING_DETAIL_DATA_QUEUE	BILLED, RETURNED, EXCHANGED, CREATED
BILLING_HEADER_DATA_QUEUE	BILLED, CREATED
BILLING_LOC_DATA_QUEUE	BILLED, CREATED
BILLING_SVC_DATA_QUEUE	BILLED, CREATED
CARTON_CONTENTS	PACKED, CREATED
CC_AUTHORIZATION_TRANS	CREATED
CC_DEPOSIT_HISTORY	DEPOSITED, CREATED
CC_DEPOSIT_TRANSACTION	CREATED
INVOICE_DETAIL	SHIPPED, RETURNED, CREATED
INVOICE_PAYMENT_METHOD	INVOICED, AUTHORIZED, DEPOSIT_CREATED CREATED
INVOICE_SHIP_TO	INVOICED, CREATED
MANIFEST_UPLOAD_AUDIT	SCANNED, CREATED
ON_LINE_AUTHORIZATION	AUTHORIZED, CREATED
ORDER_BILLING_HISTORY	CREATED
ORDER_BROKER	CREATED
ORDER_BROKER_HEADER_ORDER	CREATED
ORDER_BROKER_HISTORY	CREATED
ORDER_DETAIL	ENTERED, CREATED
ORDER_DETAIL_DATA_QUEUE	BILLED, RETURNED, EXCHANGED, CREATED
ORDER_HEADER	ENTERED, CREATED
ORDER_MESSAGE	CREATED
ORDER_PAYMENT_HISTORY	CREATED
ORDER_PAYMENT_METHOD	AUTHORIZED, CREATED
ORDER_SHIPMENT_DETAILS_VIEW	SHIPPED, CREATED
ORDER_TRANSACTION_HISTORY	TRANSACTED, CREATED
PICK_CONTROL_HEADER	CONFIRMED, CREATED
PO_RECEIPT	RECEIVED, CREATED
PO_RECEIPT_ERROR	RECEIVED, CREATED
RA_DETAIL	RETURNED
REFUND	PROCESSED, REFUNDED, CREATED
REFUND_PRINT	PRINTED, CREATED
REFUND_RECONCILIATION	RECONCILED, PRINTED, VOIDED, CREATED

Tax Compliance

With this update, several enhancements have been incorporated relating to Order Administration standard tax as well as the external tax service integrations.

Consolidated Tax Request

Modern View Order Entry and Order Summary were modified to make a consolidated tax request for all charges associated with an Order Ship To. For Multi-Ship to orders, Order Administration makes separate consolidated tax requests per Order Ship To. Previously, Order Administration would send individual request messages for each order line and extra charge (shipping, additional shipping, handling, duty, etc.) associated with the order. The consolidated tax request occurs regardless of whether Order Administration is configured to use standard tax, or an external tax service (Vertex, Avatax, and Generic Tax Interface). Making a consolidated call, reduces the traffic and provides a complete picture of the order ship to when assessing tax.

In Order Entry, a consolidated tax request for all charges associated with the Ship To is made when initially advancing to the Review train stop and when selecting the ‘Refresh’ button in the case where the user went back to a prior train stop before submitting the order.

In Order Summary, a consolidated tax request for all charges associated with the Order Ship To will be made at the point the order is ‘Unlocked’.

Note:

The unlock activity will only trigger the tax request when there is at least one order line that is open on the Ship To. For example, if a user maintains an order canceling the entire ship to, the unlock activity will not trigger a tax request.

It is important that the order be unlocked before providing order totals to your customers.

For Example:

• During Order Entry an order with 3 ship to's will have 3 request messages, each containing all charges for the individual ship to's, triggered from the Review train stop. 

• If a single ship to on that order is updated from Order Summary, a single consolidated request with all charges related to that ship to, will be triggered when the order is unlocked.

Important:

When requesting tax for multiple lines/charges in a single consolidated request, the total calculated tax may differ slightly from the sum of individual tax request values due to rounding logic inherent in Vertex. This is expected behavior, resulting from applying rounding rules based on the complete transaction versus individual charges. Due to the requirement to submit a consolidated tax request, retailers could see slight variations in tax for transactions assessed prior to the update compared to post-update.

Vertex Tax Interface - Retail Delivery Fees

The Vertex Integration now supports Retail Delivery Fees (RDF) that have been implemented for Colorado and Minnesota. These RDFs are flat taxes applicable to deliveries to a location in the respective states. It does not apply to items that are picked up at a retailer location. Therefore, Ship for Pickup and Pickup orders will not assess the flat tax. Proper assessment of the RDF flat tax requires coordination and configuration within Order Administration and Vertex applications.

Note:

Retail Delivery Fee eligibility from Order Administration is limited to orders that are being delivered to the end customer where Order Administration is responsible for billing the end customer. This includes direct delivery from a Warehouse or Store. Retail Delivery Fees do not apply to orders that Order Administration is fulfilling from Order because the originating system should assess and bill the RDFs.

Orders eligible are identified by a blank value in the OST_OBR_DELIVERY_TYPE field of the Order Ship To table. 

Colorado

Colorado’s RDF legislative requirement is to charge a one-time predefined RDF flat tax for all orders shipping to Colorado regardless of shipping charges or number of shipments. Vertex automatically assesses the fee based on the 'OF' record which Order Administration includes for shipping charges in the request message. 

Since Vertex automatically assesses the RDFs for all orders with a Colorado ship to destination, Order Administration must include an RDF exemption indicator in the tax request message whenever a transaction should not assess the RDF flat tax. (In a multi-ship to order, each Ship To will be submitted in a separate tax request which includes all charges for the individual order Ship To.) A Flexible Code Field with a hardcoded value of RDFEXEMPT is included in quotation, invoice and distribute tax requests when:

• the OST_OBR_DELIVERY_TYPE field of the Order Ship To table in populated.

• a subsequent invoice for split shipments is occurs as the flat tax would have already been assessed on the initial invoice.

When a CWOrderIn request includes order line tax overrides but does not include a freight override tax value, or includes a freight override tax value that is less than the RDF Flat Tax Value (currently 0.29 for CO), Vertex will return an error response when the DistributeTax Request is received, and the tax request will not be recorded for that transaction/invoice.

See RDF Setup In Order Administration for more information on Flexible Code Field configuration

Note:

The Order Administration enhancement to support the RDF flat tax for Colorado was implemented irrespective of the ship to location. Vertex will ignore the RDF exemption indicator when it is not mapped to a taxability category applicable for the ship to location. Refer to RDF Setup In Vertex for setup information.

Reference the following link to learn more about the Colorado Retail Delivery Fee: https://tax.colorado.gov/retail-delivery-fee 

Minnesota

Minnesota’s RDF legislative requirement is to charge a one-time predefined RDF flat tax for all orders shipping to Minnesota regardless of shipping charges or number of shipments, only IF the retailer meets the criteria to pay the flat tax and IF the order meets specific eligibility requirements based on the merchandise items and their dollar value. The order must total $100 or more of qualifying merchandise + shipping for the fee to be assessed. 

Note:

Not all merchandise qualifies toward the order threshold value of $100. Certain items are excluded when calculating the threshold, such as drugs, medical devices/accessories/supplies, food, food ingredients, prepared food, certain baby products, electronics deliveries (such as computer software), utilities delivered thru pipes or wires (natural gas, electricity, etc.) and items purchased for the purpose of resale. 

Vertex requires that Order Administration include an RDF flat tax indicator in the tax request message whenever a transaction should assess the RDF flat tax for Minnesota. (In a multi-ship to order, each Ship To will be submitted in a separate tax request which includes all charges for the individual order Ship To.) When configured in Order Administration, a Flexible Code Field with a hardcoded value of ‘DFP’ will be included in all quotation request for delivery orders.

When Vertex reviews the quotation request that includes the Flexible Code Field with a value of ‘DFP’, it will evaluate the order, and if it qualifies, the flat tax will be returned in the quotation response. Order Administration evaluates the quotation response data and when an RDF flat tax is present, the Order Ship To table is updated identifying that RDF was assessed. At billing, Order Administration checks the Order Ship To and includes a Flexible Code Field with a hardcoded value of ‘RDFTAX’ with the first invoice request. The Flexible Code Field value of ‘RDFTAX’ does not evaluate if the transaction qualifies; instead, it automatically adds the RDF fee to the tax response to account for a split shipment scenario where the order threshold is not met within the first invoice.

See RDF Setup In Order Administration for more information on Flexible Code Field configuration.

A new rdf_flat_tax attribute in the ShipTo element has been added to the CWOrderIn 14.0 message. This new field should be used in conjunction with a freight tax override to indicate whether the Retail Delivery Fee has been included within the freight tax amount.

• When a CWOrderIn request has the RDF Flat Tax field set to Y but does not include a freight override tax value, or includes a freight override tax value that is less than the RDF Flat Tax Value (currently 0.50 for MN), Vertex will return an error response when the DistributeTax Request is received, and the tax request will not be recorded for that transaction/invoice. 

Note:

This field is currently only applicable for freight tax override Ship To destinations where Vertex does not automatically assess the Retail Delivery Fee. For example, setting this value to N or Blank will not prevent the Colorado RDF from being assessed since there are no qualifying conditions to exclude it for a delivery order.

• Set to Y to indicate a tax override is on the order and the RDF flat tax amount has been included within the freight tax amount.

  • The Order Ship To record will track that RDF was assessed.

  • At billing the distribute tax request will include the RDF tax indicator with the first invoice request. In this scenario, Vertex will include the RDF flat tax when dividing the freight tax override amount across all applicable jurisdictions. 

  • For example, if the freight tax override amount was 5.00, Vertex will allocate 0.50 to the RDF flat Tax fee first and then divide the remaining 4.50 across the applicable jurisdictions.

• Set to N (blank or not included) to indicate the RDF Flat Tax is NOT included within the freight tax override amount

  • At billing the distribute tax request will NOT include the RDF tax indicator with the first invoice request and Vertex will NOT include the RDF flat tax when dividing the freight tax override amount across all applicable jurisdictions. 

  • For Example, if the freight tax override amount was 5.00, Vertex will divide the full 5.00 across the applicable jurisdictions. 

    Note:

    The Order Administration enhancement to support the RDF flat tax for Minnesota was implemented irrespective of the ship to location. Vertex will ignore the RDF tax indicators when they are not mapped to a taxability category applicable for the ship to location. Refer to RDF Setup In Vertex for setup information.

Reference the following link to learn more about the Minnesota Retail Delivery Fee: https://www.revenue.state.mn.us/retail-delivery-fee

RDF Setup In Order Administration

The following setup is required in Order Administration to support Retail Delivery Fees with Vertex and the Generic Tax Interface.

Integration Layer Process

Since the Generic Tax Interface is leveraged to communicate with Vertex, version 2.0 of the TAX_INT IJCT process must be selected when using Vertex to properly assess the Colorado and Minnesota Retail Delivery Fees.

Important:

Changes to the outbound xml version for the TAX_INT process in the Integration Job Layer Processes (IJCT) screen will take effect immediately on the next tax request message.   

Tax Files

The Vertex DefaultValue_<company>.xml file has been enhanced to include two new properties associated with the Retail Delivery Fee Flat Taxes that have been implemented for Colorado and Minnesota. Download the current files through the Tax Files Upload page in Modern View to update the properties and re-upload for each company where Vertex is enabled.

Note:

Files for companies 49 and 51 will have the new properties included with a blank value. All other companies will need to have the properties manually added. The properties are case sensitive and must be added exactly as shown below.

• Flexible_Code_Field_For_RDFEXEMPT property ID controls whether Order Administration includes the RDF exemption indicator in the Vertex tax request messages. Used for Colorado.

  • The value defines the Vertex Flexible Code Field sequence number that will be used to send the RDFEXEMPT driver for the Order Freight line (Product class=OF) for all Pickup/Ship for Pickup tax requests and when billing subsequent shipments on a delivery order.

  • The value populated in this property must match the sequence number defined in the Vertex UI for the RDFEXEMPT driver.

  • Refer to RDF Setup In Vertex for additional details.

• Flexible_Code_Field_For_RDFTAX property ID controls whether Order Administration includes the RDF tax indicators in the Vertex tax request messages. Used for Minnesota.

  • The value defines the Vertex Flexible Code Field sequence number that will be used to send the DFP and RDFTAX drivers for the Order Freight line (Product class=OF) for delivery order quotation requests and the first invoice when billing orders where the RDF flat tax was assessed.

  • The value populated in this property must match the Vertex Flexible Code Field sequence number defined for the DFP/RDFTAX drivers.

  Refer to RDF Setup In Vertex for additional details

These new properties are independent of each other, meaning Colorado logic can be enabled without Minnesota logic enabled and Minnesota logic can be enabled without Colorado logic enabled. Properties must be included in the file AND populated with a value for the logic to be enabled.

RDF Setup In Vertex

The following setup is required in Vertex to support Retail Delivery Fees for Colorado and Minnesota.

Colorado RDF Tax Exemption Configuration

1. Designate a Flexible Field with a Data Type of Code to use for RDF Exemptions.

   1. This value will be input in the Flexible_Code_Field_For_RDFEXEMPT property within the DefaultValues<company>.xml file(s).

2. Create an RDFEXEMPT Taxability Driver for the Flexible Code Field and associate it to the company.

   1. Set Type to the Flexible Field (created in step 1)

   2. Set Code as ‘RDFEXEMPT’

   3. Set Taxpayer to the Order Administration Company Code

3. Map the RDFEXEMPT driver to the 'Colorado Retail Delivery Fee 100% Exempt' Taxability Category

Minnesota RDF Tax Configuration

1. Designate a Flexible Code Field with a Data Type of Code to indicate RDF Flat Tax Assessment. 

   1. This value will be input in the Flexible_Code_Field_For_RDFTAX entry within the DefaultValues<company>.xml file(s).

2. Create a DFP Taxability Driver for the Flexible Code Field and associate it to the company.

   1. Set Type to the Flexible Field (created in step 1)

   2. Set Code as ‘DFP’

   3. Set Taxpayer to the Order Administration Company Code

3. Map the DFP driver to the ‘Delivery Fee Passthrough’ Taxability Category.

4. Create a RDFTAX Taxability Driver for the Flexible Code Field and associate it to the company.

   1. Set Type to the Flexible Field (created in step 1)

   2. Set Code as ‘RDFTAX’

   3. Set Taxpayer to the Order Administration Company Code

5. Map the RDFTAX Taxability Driver to the ‘Delivery Fee Passthrough’ Taxability Category and the ‘MN RDF Threshold Reached’ Taxability Category.

Note:

In addition to the Vertex setup noted above, the OF product class driver must be mapped to the Common Carrier, FOB Destination taxability category and the taxable merchandise item product class(es) must be mapped to a TPP/Goods taxability category. These are part of the core Configuration Steps called out within the Vertex Setup in the OACS Implementation Guide (Configuration and Administration section). 

External Tax Response Data

Order Administration will persist the tax response details returned from the Vertex external tax service. Given the large amount of data returned, Order Administration stores the entire response received from Vertex within a blob, rather than parsing out individual fields.  

• The tax response data will be stored new ORDER_SHIP_TO_TAX_RESPONSE and INVOICE_SHIP_TO_TAX_RESPONSE tables.

• The tax response data will be included in CWOrderOut, CWInvoiceOut and CWEmailOut. This will allow retailers to consume all of the information and determine what tax jurisdiction details they want to include in customer facing communications/documents.

Order Ship To Tax Response

This table is leveraged to capture and store the tax data (jurisdiction details) returned in the quotation response messages for requests that included the ‘complete’ order ship to.  Entries in this table will have a process of either Order Entry or Order Maintenance. A single quotation response entry including the most recent blob data for the 'complete' order ship-to will be stored.

When multiple quotation requests are triggered during Order Entry (due to selecting the 'Refresh Order' one or more times or if using the Order In API 2 pass method), the quotation response entry will be updated, replacing the existing blob data with the latest blob data. The 'Updated Date/Time' will be updated to the current system date/time each time the blob data is replaced for a tax entry.

When an order is edited, that triggers a complete order ship to tax request (not to create a return or return authorization), when it is unlocked, a new quotation request will be initiated that includes all order charges (except canceled/soldout lines).  The quotation response entry for that order ship-to will be updated, replacing the prior blob data.

When a quotation request is initiated by pick generation, broker processing or drop ship processing, the request could potentially be a partial snapshot of the order. Quotation requests initiated by these processes will NOT update the entry, replacing the existing blob for the order ship to since it may not reflect the 'complete' order ship to. 

The data from this table will be included in the CWOrderOut and the CWEmailOut outbound XML messages.

Invoice Ship To Tax Response table

This table is leveraged to capture and store the tax data (jurisdiction details) returned in the tax response messages, triggered from billing. Response types that can be found in this table include, Invoice Response messages, DistributeTax Response messages and when Send Tax to Tax Interface as Quote not Invoice (L11) system control value is selected, Quotation Response messages.

This table structure supports multiple tax entries for a single invoice, which would be possible when Consolidated Invoice (B49) system control value is selected. When Consolidated invoicing is enabled, there may be multiple tax response entries with different blob data for a single invoice, since the invoice will be appended with each shipment that occurs in the same day. Subsequent shipments will trigger a tax request limited to the charges associated with that shipment (not the full invoice). The subsequent tax response blobs will be stored as individual entries associated with the same invoice.

The data from this table will be included in the CWInvoiceOut and the CWEmailOut outbound XML messages.

Note:

When an order is submitted via the Order In API with Tax override values, Order Administration will not trigger quotation requests; therefore, no quotation response data blobs will be stored at the Order Ship To level. When the tax override order is billed, the corresponding distribute tax response blob data will be stored at the Invoice level

Web Service Changes

The following Inbound message versions and attributes were added to support Tax compliance.

• CWOrderIn 14.0 added:

  • rdf_flat_tax attribute to the ShipTo element to indicate if the RDF flat tax amount has been included with the freight tax amount. Refer to Vertex Tax Interface - Retail Delivery Fees for details on how to set this flag

The following Outbound message versions and attributes were added to support Tax compliance.

• CWEmailOut 15.0 added:

  • InvoiceTaxResponse repeating element to the Invoice element. Included for shipment and return confirmation email notification types. The data within this element contains tax response details specific to the associated invoice from the Invoice Ship To Tax Response table.  Refer to External Tax Response Data.

  • ShipToTaxResponse element to the Order element. Included for the order confirmation email notification type. The data within this element contains tax quotation response details for the complete order ship to from the Order Ship To Tax Response table.  

  • ost_freight_tax and ost_addl_freight_tax attributes to the Order element. Included for all notification types except the membership cancellation notification and the Oracle Retail Customer Engagement loyalty registration notification.

  • odt_addl_frt_tax, odt_duty_tax, odt_frt_tax, odt_hand_tax, and odt_merch_tax attributes to the Order Detail element. Included for the order confirmation, quote confirmation, order cancellation, order line cancellation, and store pickup email notifications.

• CWInvoiceOut 8.0 added:

  • TaxResponse repeating element to the InvoiceShipTo element. Includes tax response details specific to the associated invoice from the Invoice Ship To Tax Response table. Refer to External Tax Response Data..

  • ins_freight_tax_amt and ins_addl_freight_tax_amt attributes to the InvoiceShipTo element.

  • idt_merchandise_tax_amt, idt_handling_tax_amt, and idt_freight_tax_amt attributes to the InvoiceDetail element.

  • idc_tax_amt attribute to the InvoiceDetailCharge element.

• CWOrderOut 15.0 added:

  • TaxResponse repeating element to the ShipTo element. Includes tax quotation response details for the complete order ship to from the Order Ship To Tax Response table. Refer to External Tax Response Data.

  • freight_tax and additional_freight_tax attributes to the ShipTo element.

  • merchandise_tax, handling_tax, freight_tax, additional_freight_tax and duty_tax attributes to the Detail element.

Generic Tax API (CWTaxRequest/CWTaxResponse)

When using any external tax engine, the Generic Tax API is leveraged to generate the CWTaxRequest.  The CWTaxRequest message is then mapped into the format used by the external system (Vertex, Avatax). When the response is received from the external system, the data is mapped into the CWTaxResponse message and Order Administration uses the data from CWTaxResponse to apply tax to the order.

With this update, version 2.0 was created for the Generic Tax API. Version 1.0 leverages the existing message structure but sends a single consolidated request for the complete Order Ship To (no new tags have been introduced). Version 2.0 sends a single consolidated request for the complete Order Ship To, and includes new tags as specified in the request/response messages below.

Important:

Since the Generic Tax Interface is leveraged to communicate with Vertex, version 2.0 of the TAX_INT IJCT process must be selected when using Vertex to properly assess the Colorado and Minnesota Retail Delivery Fees.

Changes to the outbound xml version for the TAX_INT process in the Integration Job Layer Processes (IJCT) screen will take effect immediately on the next tax request message.

CWTaxRequest 2.0 added:

• charge_delivery_flat_fee attribute to the TaxInterfaceRequest element. Indicates whether the transaction is exempt from the Delivery Fee for Colorado.

  • Order Administration sets to true, when:

    • the OST_OBR_DELIVERY_TYPE field of the Order Ship To table is NOT populated.

    • Subsequent tax requests for delivery orders triggered from billing.

    • This includes Invoice Requests/Distribute Tax Requests and Quotation Requests initiated from Billing when Send Tax to Tax Interface as Quote not Invoice (L11) system control value is selected. (Not the first Invoice) 

  • Order Administration sets to false, when:

    • the OST_OBR_DELIVERY_TYPE field of the Order Ship To table IS populated.

• include_delivery_tax_indicator attribute to the TaxInterfaceRequest element. Indicates whether the transaction assessed the Delivery Fee for Minnesota

  • Order Administration sets to true, when:

    • All tax requests for delivery orders triggered by the billing process, when OACS is configured to assess RDF tax and the Order Ship To record has the RDF_TAX field set to 1, indicating that RDF tax was assessed during the quotation request.

  • Order Administration sets to false, when:

    • the Order Ship To record has the RDF_TAX field set to 0.

    • for Quotation, Invoice, DistributeTax requests where the OST_OBR_DELIVERY_TYPE field of the Order Ship To table IS populated.

    • Invoice Requests/Distribute Tax Requests (or Quotation Requests initiated from Billing when Send Tax to Tax Interface as Quote not Invoice (L11) system control value is selected) for delivery orders associated with a subsequent invoice (not the first Invoice).

CWTaxResponse 2.0 added:

• delivery_fee_tax_assessed attribute to the OrderDetail>JurisdictionLevel element. Indicates whether the tax provider includes an RDF greater than 0.00 for Minnesota.

  • Set to true, when, the quotation response includes a retail delivery fee value greater than 0.00. When set to true, the generic tax interface logic will set the RDF_TAX field in the Order Ship To table to 1, indicating that the RDF flat tax has been assessed and should be billed on the first invoice.

  • Set to false, when, the quotation response does not include a retail delivery fee value greater than 0.00

• FullInterfaceResponse element. Populate with the complete response, typically XML or JSON, of any remote tax engine service that was called to facilitate this response.

  • Includes the full message for quotation, invoice and distribute tax response so that the tax response data could be stored and made available within the outbound API’s.

  • This will allow retailers to consume all of the tax response data and determine what tax jurisdiction details they want to include on customer order confirmations, shipment confirmation, invoices, and so on. 

Database

As part of the Tax Compliance project, some of the existing Order Administration database tables were expanded to include additional tax fields, to allow for easier tax reconciliation. The new tax fields will only be populated for external tax integrations (Vertex, Avatax, and Generic Tax Interface).

• The following will not populate the new tax fields:

  • Order Administration Tax logic

  • Tax overrides passed in the Order In API. The Order API has NOT been updated to include tags for the new tax fields.

• Existing records will show the new fields with a value of '0' upon update. If an existing order is modified and resulting in a tax update, the new fields would be updated based on the tax update.

Order Administration has added the following database columns for storing additional tax data. Each new column is available through Retail Data Store for custom reporting.

Database View	Columns Added
ORDER_SHIP_TO	FREIGHT_TAX, ADDL_FREIGHT_TAX, RDF_FLAT_TAX Note: The existing OST_TAX field remains unchanged and will continue to represent the total tax for the ship to.
ORDER_DETAIL	FREIGHT_TAX, ADDL_FREIGHT_TAX, MERCHANDISE_TAX, SPECIAL_HANDLING_TAX, DUTY_TAX Note: The existing ODT_TAX field remains unchanged and will continue to represent the total tax for the order detail line.
INVOICE_SHIP_TO	FREIGHT_TAX, ADDL_FREIGHT_TAX Note: The existing INS_TAX field remains unchanged and will continue to represent the total tax for the invoice ship to.
INVOICE_DETAIL	FREIGHT_TAX, MERCHANDISE_TAX, HANDLING_TAX Note: The existing IDT_TAX field remains unchanged and will continue to represent the total tax for the order detail line.
INVOICE_DETAIL_CHARGE	TAX_AMOUNT Note: This field is populated when the detail charge type is Shipper/Item (S) {Add'l Freight} and tax has been assessed.
ORDER_SHIP_TO_TAX_RESPONSE_VIEW	COMPANY, ORDER_NO, SHIP_TO_NO, CREATED, UPDATED, TAX_INTERFACE, PROCESS, RESPONSE_TYPE, TAX_RESPONSE Refer to External Tax Response Data for more information.
INVOICE_SHIP_TO_TAX_RESPONSE_VIEW	COMPANY, INVOICE_NO, SEQ_NO, ORDER_NO, SHIP_TO_NO, CREATED, UPDATED, TAX_INTERFACE, PROCESS, RESPONSE_TYPE, TAX_RESPONSE Refer to External Tax Response Data for more information.

Payment Cardholder Name and Address

With this update, cardholder name and address details can now be entered for each Credit or Debit payment method on an order. Previously, when Order Administration sent payment card requests to the Payment Service Provider (PSP), the customer’s name and address details were sent.

For scenarios where the customer requests to use someone else’s payment card, for example a spouse or a parent or child, the name and address associated to the payment card will be different and can result in the PSP raising address verification errors and possibly suspected fraud errors, meaning the authorization is rejected. To avoid this situation occurring, Order Administration now allows the payment cards “cardholder” name and address to be captured, when it is different from the customer’s name and address.

Modern View User Interface

A number of screens have been updated including Order Entry, Order Summary and Manage Rejected Deposits, to allow cardholder name and address data to be added or edited.

In Order Entry and Order Summary:

• If the authorization fails, an authorization failure popup window is now displayed with a button to allow “Edit Cardholder Details”. The user can add cardholder details (when different to the customer details) and try the authorization again.

In Manage Rejected Deposits:

• Cardholder details can now be added or edited for a payment, so that an additional Authorization+Capture can use the correct cardholder data.

• When “Replace Payment Method” selected and new payment details are captured in the Payment Form, if the authorization fails, an authorization failure popup window is now displayed with a button to allow “Edit Cardholder Details”. The user can add cardholder details (when different to the customer details) and try the authorization again.

Web Service Changes

Order Administration has modified existing or created new Inbound and Outbound API versions that now include attributes that support cardholder details on an order payment.

• CWOrderIn 14.0 added a Cardholder node to the Payment element.

  • Attributes included are: first_name, last_name, company_name, address_line1, address_line2, apartment, city, state, zip, country

  • The Cardholder node must include the following attributes otherwise it is not persisted: company_name or last_name, address_line1, city and country.

  • The Cardholder details are only persisted for EFTConnect or External Payment Service (EPS) payment methods.

• CWOrderOut 15.0 added a Cardholder node to the Payment element.

  • Attributes included are: first_name, last_name, company_name, address_line1, address_line2, apartment, city, state, zip, country.

• Private Data added:

  • cardHolderAddressList element to the getPrivateData 3.0 response message when a match is found for search type OHD (Order) that includes the cardholder name and address details associated to the order and invoice payment method tables.

  • removal (anonymizing) of cardholder name and address details from the Order and Invoice Payment Method tables when the order qualifies in the forgetPrivateData message.

Payment Integrations

Order Administration has modified existing Payment Integrations and Services to always map from the cardholder name and address fields if populated, otherwise from the customer sold to for Authorization, Authorization+Capture, Capture, Refund and Void messages.

• EFTConnect BillingDetails.AddressDetails element have been modified.

• External Payment Service (EPS) CCA and CCD elements have been modified. This mapping will occur regardless of the EPS message version.

Database

Order Administration has added new database columns to persist cardholder details. Each new column is available through Retail Data Store for custom reporting.

Database View	Columns Added
ORDER_PAYMENT_METHOD	CARDHOLDER_FIRST_NAME, CARDHOLDER_LAST_NAME, CARDHOLDER_COMPANY_NAME, CARDHOLDER_ADDRESS_LINE1, CARDHOLDER_ADDRESS_LINE2, CARDHOLDER_APARTMENT, CARDHOLDER_CITY, CARDHOLDER_STATE, CARDHOLDER_POSTAL_CODE, CARDHOLDER_COUNTRY
INVOICE_PAYMENT_METHOD	CARDHOLDER_FIRST_NAME, CARDHOLDER_LAST_NAME, CARDHOLDER_COMPANY_NAME, CARDHOLDER_ADDRESS_LINE1, CARDHOLDER_ADDRESS_LINE2, CARDHOLDER_APARTMENT, CARDHOLDER_CITY, CARDHOLDER_STATE, CARDHOLDER_POSTAL_CODE, CARDHOLDER_COUNTRY

External Payment Service Level 2 and 3 Discounting

With this update, the External Payment Service now supports the ability for a Retailer to leverage new attributes within the request and response messages to qualify for Level 2 and Level 3 discounts. Certain Business to Business (B2B) and Business to Government (B2G) credit card types and their transactions can qualify for Level 2 or Level 3 discounts on processing fees, and when applied can save the retailer a significant amount of money on the fees.

In order to qualify for Level 2 or Level 3 discounts, additional data must be sent on the authorization transactions to the Payment Service Provider that is now included in the latest External Payment Service message version.

For example, to qualify for Level 2 discounts, the following additional fields can be sent:

• Customer Reference, Sales Tax Amount, Requestor Name, Ship To Name, Ship To Address, Customer Tax Id

For Level 3 discounts, send the Level 2 fields and the following additional Order and Item fields:

• Order Number, Order Date, Invoice Number, Duty Amount, Freight Amount, Ship To Country, Discount Amount, Freight Tax Amount

• Item Id, Item Description, Item Quantity, Item Unit Of Measure, Item Price, Item Line Total, Item Commodity Code, Item Line Discount, Item Tax Amount, Item Class, Item Tax Rate

Additionally, some Payment Service Providers can return a Card Level Indicator on payment transaction responses. This indicator could be used by the Retailer when sending payment transactions to the payment provider, in order to determine whether to forward the Level 2/3 data fields, where the payment provider wants to be selective in what data is transmitted to the different issuers.

• Optionally, pass the Card Level Indicator with a Card Payment when available through EPS or CWOrderIn.

  • Blank or not set - It is not eligible for Level 2/3 discounts, or is unknown

  • "2" - It is eligible for Level 2 discounts (generally commercial, corporate and government cards)

  • "3" - It is eligible for Level 3 discounts (generally commercial, corporate and government cards)

• The Card Level Indicator will be updated if the card is replaced through Manage Rejected Deposits and Customer Membership based on the new card entered.

• The Card Level Indicator will be stored with Customer Memberships and included in the order payment method of generated child membership orders.

Modern View User Interface

The card level will be displayed on the Payment Method Details screen in Modern View Order Entry and Order Summary when populated.

Web Service Changes

• External Payment Service (EPS) 4.0 added:

  • cardLevelIndicator to the Header element of the request and response.

  • cardLevelDiscount element with the following attributes: customerId, customerTaxId, purchaseOrderRef, orderDate, invoiceNumber, invoiceTaxAmount, freightAmount, discountAmount, billToCustomerName, shippingDetails element, saleLineItems element

    • Refer to the Order Administration Web Services Guide for a full list of Level 2 and Level 3 fields.

  • Order Administration sends all Level 2 and Level 3 data that it has in version 4.0, irrespective of the Card Level Indicator setting.

• CWOrderIn 14.0 added card_level¬_indicator to the Payment element.

• CWOrderOut 15.0 added card_level¬_indicator to the Payment element.

Database

Order Administration has added new database columns to persist the card level indicator. Each new column is available through Retail Data Store for custom reporting.

Database View	Columns Added
ORDER_PAYMENT_METHOD	CARD_LEVEL_INDICATOR
INVOICE_PAYMENT_METHOD	CARD_LEVEL_INDICATOR
CUSTOMER_MEMBERSHIP	CARD_LEVEL_INDICATOR

Personalization Enhancements

With this update, enhancements have been made to the Personalization Information windows in Modern View Order Entry and Order Summary.

• The Add and Edit Personalization windows now allow the detailed custom charges to be overridden for a Custom Personalization type when the S/H Charge is not populated on the offer.

  • The Enter or Override Personalization Charge (A40) secure feature must be set to ALLOW for editing the custom charges. If set to DISPLAY, you can view the charges but cannot edit them. If set to EXCLUDE, the charges are hidden.

  • The system looks at the offer associated to the Source Code to determine if the S/H Charge is populated.

  • The total Personalization Charge in the Order Summary panel will reflect the updated personalization charges after Review/Refresh Order like they do for Standard personalization charges.

• The Add Personalization window now defaults values from the Customer record based on the Default Text code selected in Custom Special Handling Formats (WSHF) screen.

  • Default Text codes include Name, Company, Address and Phone number fields.

  • If the default text is overridden, the new value entered will be saved with the personalization.

• At each place in Order Entry and Order Summary where an Error window, with a message of “Personalization cannot be changed for this item”, previously appeared, the Personalization Information window will now display as read only.

  • This occurs when the Suppress S/H Window field is set to Suppress in an Additional Charge (WADC) record that has a Special Handling Format assigned.

  • The Personalization Information window will NOT allow the ability to Edit or Remove the personalization.

  • If an S/H Price is defined with a value on the offer, the Personalization Charge field will display. If it does not have a value, for a Custom personalization, each custom detail label with value in parenthesis will be displayed and for Standard personalization, no additional data will display.

Web Service Changes

• CWOrderIn 14.0 added personalization_charge attribute in the personalization_line element to allow a retailer to also pass the custom personalization charges as an override from an external system.

  • If populated and valid, the charge will override the personalization custom charges defined in the Custom Special Handling Formats (WSHF) details, otherwise the system will use the charge defined.

  • Stored in the OSF_CHARGE of the ORDER_SPECIAL_FORMAT table.

Modern View Contact Center

With this update, Modern View Order Entry and Order Summary now display total Shipping Weight.

• Order Entry displays the Shipping Weight in the Ship To Information section of the Shipping and Review steps.

  • The shipping weight is a sum of the ship weight for each item from Work with Items (MITM), in the cart, except for sold out and unverified return items.

  • The shipping weight on the Shipping step is estimated. Once at the Review step and after each Refresh of the order, the shipping weight will be recalculated based on the current items in the cart.

• Order Summary displays the Shipping Weight in the Additional Information and Totals section and in the Edit Ship-To Information page.

  • The shipping weight is a sum of the ship weight for each item, from Work with Items (MITM), in the cart, except for sold out, canceled, returned and unverified return items.

  • The shipping weight will be updated as lines are added and updated.

Note:

Shipping Weight always comes from the Item (MITM) and is not stored with the order line. Changes to the item will be reflected the next time the item is displayed in Order Entry and Order Summary.

Shipping Weight is available only when selected to display in the Work with Contact Center Field Display (WWCC) menu option.

Customer Engagement Enhancements

With this update, the match logic has been expanded when searching customers in Oracle Retail Customer Engagement Cloud Service to better handle shared emails or addresses across different people.

This only applies to the search when Order Administration created a customer sold to and it needs to find a match or create a new customer in Customer Engagement. Previously, Order Administration only looked for a matching customer record in Customer Engagement using email, which may select a customer that has a different name and address causing the data to be consolidated or overridden incorrectly.

Emails & Addresses may be shared for different reasons like:

• Members of the same household.

• Business orders being placed by different individuals but have a shared email and address.

• Single email used for both personal and business purchases with different address.

Send Name and Address for ORCE Customer Search (M88) system control value has been created to control which data is sent to Customer Engagement when searching for an existing customer. Set to Yes to include Email Address, Company, First Name, Last Name, Address Line 1, City, State Code, Postal Code and Country Code. This happens during new customer creation in Order Administration through:

• CWOrderIn

• SYNCRDB periodic function when there is no ORCE Customer ID or Ecommerce ID in the Customer Sold To table and the Synchronize with Remote DB flag is set to Y.

• ChannelAdvisor

• Delivery and Retail Pickup orders created from Order Orchestration

Set Send Name and Address for ORCE Customer Search (M88) system control value to No to only search by Email Address.

Note:

If the Customer Sold To does not have a first name, a search with all the other values is sent. If a match is found, the customer in Customer Engagement may have a first name and the record will be as empty fields are not part of the search process.

The Company Name (BusinessName) uses a starts with search, so Customer Engagement will consider a record a match if all the other data is an exact match and only the first part of the company is an exact match. So, if “ABC” is passed and Customer Engagement has “ABC Company”, this will be considered a match, but “ABCD” would not be a match.

Collect and Receive Enhancements

With this update, Order Administration has modified the integration to Oracle Retail Collect and Receive Foundation Cloud Service to be able to configure the integration per company which allows support for multiple tenancies in Collect and Receive.

Note:

The Retail Data Store Collect and Receive feature is no longer supported and has been replaced with Collect and Receive Foundation Cloud Service. Order Administration continues to support the same functionality, only the Scope and URL are different.

The following system control values have been created and will need to be configured to communicate to Collect and Receive for the Return Courier Pickup feature:

• CaR Service Endpoint Scope (M89) to specify the scope that will be used to get the authentication token.

• CaR Service Endpoint URL (M90) to specify the CaR URL for communication.

• Use CaR Delivery (M91) – not currently implemented.

The following properties have been modified:

• Removed oms.car.scope, instead use SCV M89.

• Removed oms.car.service.url, instead use SCV M90.

• Removed oms.car.status.enabled, as it is not used.

• Added oms.car.service.version to display the Collect and Receive API Version currently in use for troubleshooting purposes.

Note:

Upon upgrade, if Use CaR Returns (M81) system control value is set to Y, the system will automatically copy the values from the scope and URL from the properties to the SCVs for that company.

Web Service Enhancements

With this update, Order Administration has made several web service enhancements. Following is a complete list with reference back to the specific feature changes.

• CWOrderIn v14.0 and CWOrderOut v15.0

  • Business Time Zone Web Service Changes

  • Tax Compliance

    • For CWOrderIn, see Vertex Tax Interface - Retail Delivery Fees

    • For CWOrderOut, see Web Service Changes

  • Payment Cardholder Name and Address Web Service Changes

  • External Payment Service Level 2 and 3 Discounting Web Service Changes

  • Personalization Enhancements Web Service Changes

• CWPickIn 5.0 and CWPickOut 7.0

  • Business Time Zone Web Service Changes

• CWReceiptIn 2.0

  • Business Time Zone Web Service Changes

• CWCustHistOut 3.0

  • Business Time Zone Web Service Changes

• CWEmailOut 15.0

  • Business Time Zone Web Service Changes

  • Tax Compliance Web Service Changes

• CWInvoiceOut 8.0

  • Business Time Zone Web Service Changes

  • Tax Compliance Web Service Changes

• CWReturnRAOut 4.0

  • Business Time Zone Web Service Changes

• Generic Tax API 2.0

  • Business Time Zone Web Service Changes

  • Tax Compliance Generic Tax API (CWTaxRequest/CWTaxResponse)

• External Payment Service (EPS) 4.0

  • Business Time Zone Web Service Changes

  • Payment Cardholder Name and Address Web Service Changes

  • External Payment Service Level 2 and 3 Discounting Web Service Changes

• getPrivateData 3.0

  • Payment Cardholder Name and Address Web Service Changes

• Return Authorization 3.0 added the shipVia attribute to the exchangeOrderDetail element in the Create Return Authorization and Update Return Authorization request messages.

  • Regardless of version, removed addLineReason from the ExchangeOrderDetail element. This was not used.

  • Regardless of version, removed shipVia from the returnOrderDetail element. This was not used.

Additionally, several web services have been enhanced to improve the error validation message returned in the response message. This allows for better troubleshooting when an error is returned. ·

• Before: {"errorCode":202,"errorMessage":"must be greater than or equal to 1","field":"orderNumber","value":"0","errorType":"VALIDATION"}

• After: {"errorCode":202,"errorMessage":"must be greater than or equal to 1","field":"arg0.orderNumber","value":"0","errorType":"VALIDATION"}

There are no changes to the response structure, however, the value returned in the “field” attribute is now more descriptive. The following web services have been modified:

• Return Authorization REST Services

• Courier Pickup REST Services

• Customer REST Services

• Price Table REST Services

• Pick Ticket REST Services

Database and Retail Data Store Updates

The Data Dictionaries include changes related to this update of Order Administration Cloud Service.

Many of the database changes have been referenced in the feature enhancement sections.

Order Orchestration Enhancements

Business Time Zone

With this update, Order Orchestration has enhanced the Order Administration base integration to handle ISO 8601 date and time formats.

• Order Administration now populates the datetime attribute in all messages with the current System Timestamp in UTC.

  • Messages changed include: getInventoryAvailability, Fulfillments, Order Status Inquiry, Order Status List, Order Status Update, Order Update, Product Availability, Submit Order

• Order Administration now populates the transaction_date in the Submit Order message from the Entered timestamp from the Order Header in UTC. Previously this was sending the current System Timestamp. This displays as the Order Date in Order Orchestration.

• Order Administration now populates the status_date in the Status Update message from the Shipped timestamp from the Order Shipment Details in UTC, for each intransit and fulfilled status update change on a Ship For Pickup, Retail Pickup and Delivery order. Previously, this was not mapped.

  • Order Orchestration will persist the shipped date in UTC in the SHIPPED column of the XOM_ORDER_ITEM_CARTON table, XOM_ORDER_SHIPMENT table, RDS_XOM_ORDER_ITEM_CARTON view and RDS_XOM_ORDER_SHIPMENT view as a TIMESTAMP(6) WITH TIME ZONE data type.

• Order Administration uses the transaction_date attribute in the Fulfillments response message to populate the Entered timestamp on the Order Header in UTC.

• Order Administration uses the shipped attribute in the Real-Time Status Update to store the Shipped timestamp in the Order Shipment Details in UTC on a Brokered Backorder and Ship For Pickup order when available.

Refer to the Order Administration: Business Time Zone section for more information on the enhancements in Order Administration.

Web Service Enhancements

With this update, several web services have been enhanced to improve the error validation message returned in the response message. This allows for better troubleshooting when an error is returned.

For example, this message previously only indicated that phoneNumber was blank, but not which phoneNumber. Now it will include pickupContact to identify which type of phoneNumber.

• Before: {"errorCode": 202, "errorMessage": "must not be blank", "field": "phoneNumber", "errorType": "VALIDATION" }

• After: { "errorCode": 202, "errorMessage": "must not be blank", "field": "argRequest.pickupContact.phoneNumber", "errorType": "VALIDATION" }

There are no changes to the response structure, however, the value returned in the “field” attribute is now more descriptive. The following web services have been modified:

• Foundation Data REST Services

  • Boxes API

  • Cancel Order or Reject Order Reason Codes API

  • Carriers API

  • Location Types API

  • Brands API

  • Attribute Definitions API

  • External Services API

• Locate REST Services

  • Availability Update API

  • Fulfillments API

  • Intransit Orders API

  • Locate Items API

  • Location Update API

  • Order Search API

  • Order Update API

  • Product Availability API

  • Product Update API

  • Status List + Status API

  • Status Update API

  • Submit Order API

• Store Associate Location Assignment API

Database and Retail Data Store Updates

The Data Dictionaries include changes related to this update of Order Orchestration Cloud Service.