Shopping cart
Describes the standard Optimizely Configured Commerce process for defining and maintaining orders and carts.
Note
The default quantity limit on any one product item is set to 6 digits. This is not a platform constraint and can be overridden in JavaScript.
Create an order
When a user accesses Optimizely Configured Commerce, regardless of being logged in, a record is created in the CustomerOrder table, which is equal to a cart. After a user submits an order, a record is created in the OrderHistory table, which is equal to an order.
There are different actions that cause the cart status to change. The table below defines these actions and their effect on the cart status for guest users. The table also notes where in the process the record type transitions from a cart record to an order record.
User Action | Effect on Order | Order Status in Admin Console |
---|---|---|
Accesses site | Order created and Cart ID Assigned (Cart record is created) | Cart |
*User Logs In (before checking out) | User ID added to cart record in the commerce database (Cart record is created) | Cart |
Adds item to cart | Order updated (Cart record is created) | Cart |
Checks out | Order submitted (Cart record is cloned as an Order record- once cloned, the Cart record is no longer updated and it becomes a historical record) | Submitted |
User waits for shipment | Reviewed by ERP (if used) (changes are made to the Order record) Accepted by ERP (changes are made to the Order record) Order Fulfilled and Payment Processed (changes are made to the Order record) | Review Processing Complete |
User receives shipment | Â | Â |
If the user decides to log into the site and continues shopping or returns to the checkout page, an additional step is added to the process*:
User Action | Effect on Order | Order Status in Admin Console |
---|---|---|
Accesses site | Order created and Cart ID Assigned (Cart record is created) | Cart |
Adds item to cart | Order updated (Cart record is created) | Cart |
Checks out | Order submitted (Cart record is cloned as an order record- once cloned, the Cart record is no longer updated and it becomes a historical record) | Submitted |
User waits for shipment | Reviewed by ERP (if used) (changes are made to the Order record) Accepted by ERP (changes are made to the Order record) Order Fulfilled and Payment Processed (changes are made to the Order record) | Review Processing Complete |
User receives shipment | Â | Â |
Submit and process an order
Once the user clicks the Submit Order button, the system submits the order to the ERP in real time. An Application Setting, ERP_SubmitOrders, must be configured for this submission to take place. The Submit Orders to ERP setting must be correctly configured for the submission to take place. If a client decides not to submit orders in real-time, they will be submitted to the ERP via a Scheduled Task at a pre-determined time and frequency. At the time of submission, a copy of the order is saved to post to the ERP at a later point, in case the real-time does not work for some reason. If the order still cannot be posted to the ERP, it will be moved to a queue, and when the connection is restored, the system will try to pick up the queue and submit the order again.
Once it receives the order, the ERP reviews and approves the order based on its rules. If there is no ERP, the order moves on to the Processing status to process the payment for the order. When the order moves to Processing, the commerce database order status is updated to Processing. Processing typically includes fulfilling the order and charging the user. Once these steps are complete, the order moves to the Complete status.
If an order is submitted but does not go into the ERP for some reason, the ERP will inform Configured Commerce that the order was rejected. Any rejections will show up as errors found in the job status reports. The order remains in the Order queue until it is corrected and resubmitted for processing.
Change or correct an order
There are times when an order needs to be changed due to a processing error or a user requests a change after the order has been placed. Changes can take place in either the ERP or the Admin Console, depending on the change that needs to be made.
If a change to an order is requested after it has been submitted, the user would need to contact the website's Customer Support Team. These representatives need to have access to the Admin Console. After receiving a call from a user, the Customer Support Representative can view the order in the Admin Console Cart History and make the appropriate changes.
Keep in mind, editing can only occur in the Cart History on what we consider a cart – once an order is submitted, the record that ties to the ERP (Order History record) cannot be edited directly, as this record reflects the ERP data. In theory, editing a cart that has already been submitted and resubmitting it to the ERP via the actions icon would result in the ERP updating the order information and then our Order History would update when the next refresh happens. This would likely depend on what status the order is in and how the ERP is set up to handle changes.
The following fields can be updated by a website's Customer Support Representatives:
- ERP Order Number
- Customer PO
- Customer PO Type Code
- Price Code
- Terms Code
- Currency
- Status
- Buyer
- Customer Reference 1
- Customer Reference 2
- Notes
- Bill To information (except Customer Number)
- Ship To information (except Customer Number and Ship To)
- Order Totals - Ship Code
- Shipment Quote Number
- Tax Code 1
- Tax Code 2
- Ship Early
- Ship Partial
While changes can be made to the Order in the Admin Console, the preferred option is to make the change in the ERP, which is considered the database of record.
Remove abandoned cart records from the database
If you want to remove the Abandoned and Orphaned cart records from the database, you can do that with a Scheduled Task. The task can be configured to run at your preferred time.
Tie the cart to the user, BillTo or ShipTo
Websites can be configured to tie carts to the Ship To address, Bill To address or the User. If configured to tie the cart to the ShipTo or BillTo, a new cart is created when switching between Ship To or Bill To addresses. If the website is configured to tie the cart to the User, any products added to the cart will persist if the user logs into the same account using a different browser or device. This is configured through the Cart Provider setting:
-
Go to Admin Console > Administration > System > Settings.
-
Enter Cart Provider in the search box.
-
From the Cart Provider menu, select one of the three following options:
-
ByCustomer- by Bill To address
-
ByShipTo- by Ship To address
-
ByUser (default)- Cart is specific to the user and the cart contents will persist across both device and browser when logging into the same account.
This field can be configured Globally or uniquely per website. Select the desired website from the Configuring menu.
Note
Selecting ByCustomer or ByShipTo should only be used when the Storefront Access setting is set to SignInRequiredToBrowse. Otherwise, when a user signs in and selects the Customer, the cart will be replaced with a new one.
-
Depending on the configuration, a new cart will automatically be created when switching between Ship To, Bill To, or User. However, it is not possible to view multiple carts concurrently and carts will not persist between devices or browsers, as they are cookie based.
Updated over 1 year ago