This article documents the behaviour of the basket.

• Basket and login customers
• Basket customer address compliance
• Default shipment address behavior

Basket and login customers

The following behavior applies for baskets and login customers.

If the session has NO items in basket (no basket at all or the basket only has payment and shipment fees) prior to logging in:

Logging in as customer login: If there is an existing basket for that login, this existing basket is now becoming the session's current basket.

If session has some items in basket prior logging in:

Logging in as customer login: Any existing basket for that login is merged with the session's current basket.

How baskets are merged

"Old basket" = existing basket on the login
"New basket" = basket created before the customer logs in

• Basket lines of the new basket and the existing basket are merged:
  - If this means that incompatible (mutually exclusive) products exist in the basket after the merge, the products will remain in the basket, but the shop will notify the customer and prevent the order from being completed until the incompatible product has been removed.
  - If the merging baskets contain the same item at the same basket line level, the basket line properties for the merged basket line such as Quantity, UserCode1-3 and isLineDeleteable are saved from the new basket. This only applies if the items exist at the same basket line level. If the items exist at different basket line levels, they are treated as individual lines.
  - Configured products are treated as individual items, regardless of the configuration.
  
• Both delivery address and payment address are kept from the old basket.
• Both delivery form and payment form are kept from the old basket (provided that the contents of the new merged basket is compatible). Payment and delivery fees will be recalculated.
• Location is kept from the new basket.
• Time selected with the collection time picker (OrderLeadTimePicker) is saved from the new basket.
• Desired delivery date selected with the delivery date picker (DeliveryDateSelectDropdown) is saved from the old basket.
• Gift cards are merged:
  - If both baskets have a redeemed gift card, the new basket will have both gift cards redeemed.
  - If one of the baskets contain a gift card product and the other contains a redeemed gift card, a shop message will say that it is not possible to purchase a gift card using a gift card.
• Coupons are merged:
  - Currently only 1 coupon code usage is allowed per basket. If the old basket already has a coupon code, the coupon code of the new basket will be discarded.
  
• Basket values are merged:
  - If the old basket already has a uservalue with the same key, the value of the new basket will be discarded.

Impact on using multiple concurrent customer logins

When the shop is configured to DISALLOW multiple baskets ([IsMultipleBasketsEnabledWhenLoggedIn]=false + [IsMultipleBasketsEnabledWhenNotLoggedIn]=false), and adding products to the basket from two different computers (herafter called sessions, session A and session B), the behaviour described above applies.

The consequence is, that if having session "A" and session "B" running off 2 different computers (or browsers), both logging in, the they will be working on the same basket - any changes session "A" will make is subsequently visible to session "B" Also, when session "A" submits the order, session "B" will loose its basket.

If the shop is set up to allow multiple baskets, when a basket is completed into an order, the most recently abandoned (trashed) basket of the customer is used as the currently active basket. If no such exists, a new basket will be created.

Basket customer address compliance

The purpose of the shop group setting “Basket_AddressFollowsCustomer” is to configure whether the shop should ensure that baskets (and thereby orders) comply with known customer data.

Known customer data refers to information stored in the shop about customers that may log in and place orders or for which a salesperson may place orders. Usually this customer data origin from an ERP system.

Note that this setting does not apply to “unknown” customers, that is, customers that are neither logged in nor selected by a salesperson.

This setting is located at Base setup > Webshops > Shop Groups > [Shopgroup] > All settings tab > Basket tab in the shop administration.

The possible values of this setting are: Enforce | Ignore | Vague

Enforce: The shop forces the known customer data on the basket, if the field is set as "read only". This is useful for when the shop owner wishes to ensure that orders are created with predefined customer data, usually originating the ERP system (e.g. payment address/shipment address).

Defining which fields to lock/force to comply with customer data is done by setting the desired fields as "Read-only" in the shop administration (Settings > Customers > Customer information). It is possible to define the setting for the fields depending on whether or not the customer is logged in.

Note that customer data will only be forced onto a field in the basket if the shop group setting "Basket_AddressFollowsCustomer" is set to "Enforce" AND if the field is set to "Read-only".

Note also that this setting does not mean that the customer is not able to enter a new shipment address during checkout! It may still be possible for the customer to enter a new shipment address during checkout, dependent on the setup of the ShipmentAddress control (UseOnlyExistingAddresses setting must be False if the customer is allowed to enter a new shipment address).

Ignore: The shop does not attempt to force known customer data on the basket. This means that there is no guarantee that data on the order is identical to what is specified on the customer / customer shipment address(es) - even if using “Protected” inputMode on PaymentAddress/ShipmentAddress controls or making the fields read-only using the customer data field setup in the shop administration.

Vague: This serves as a compatibility option. Allows partly enforcement via basket content controls. It is strongly advised to select either Enforce or Ignore. Note that changing this setting for existing shops may be a breaking change as behavior changes according to what is specified above. When setting up a new shop this setting should be regarded and set to either Enforce or Ignore (do not select “vague” option!).

USE CASES/EXAMPLES

1) My shop does not support logging in and customers may change any of the customer information during checkout.
=> Shop group "Basket_AddressFollowsCustomer" setting should be set to "Ignore" (or "Enforce") and none of the fields should be configured as "Read-only".

2) My shop supports logging in and customers may change any of the pre-filled customer information during checkout.
=> Shop group "Basket_AddressFollowsCustomer" setting should be set to "Enforce" and none of the fields should be configured as "Read-only".

3) My shop supports logging in and customers may not change the fields "company name", "e-mail" and "country" during checkout - it must be ensured that this data on the basket/order complies with what is specified on the customer (for example, from my ERP system).
=> Shop group "Basket_AddressFollowsCustomer" setting should be set to "Enforce" and the payment address fields "company name", "e-mail" and "country" should be configured as "Read-only (Logged in)".

Default shipment address behavior

The following section describes how the shop behaves when creating new baskets and a default shipment address is set up on the customer and/or customer login.

When a logged-in customer creates a new basket:

• If a default shipment address is specified for the customer login and the shipment address is forced/locked, then new baskets default to this shipment address of the customer login. The customer may not choose a different shipment address.
• If a default shipment address is specified for the customer login and the shipment address is not forced/locked, then new baskets default to this shipment address of the customer login. If the design allows it, the customer may be able to select a different shipment address.
• If no default shipment address is specified for the customer login but a default shipment address is specified for the customer, then new baskets default to the baskets default to this shipment address of the customer. If the design allows it, the customer may be able to select a different shipment address.
• If no default shipment address is specified for the customer login and no default shipment address is specified for the customer, then new baskets default to “no shipment address”. If the design allows it, the customer may be able to select a shipment address.

The general rule is that if a default shipment address is specified for the login, the shop defaults to this shipment address – only if no default shipment address is specified for the login, will the shop fall back on any default shipment address of the customer.

When a salesperson having selected a customer creates a new basket:

• If a default shipment address is specified for the customer, then new baskets will default to this shipmen address. If the design allows it, the salesperson may select a different shipment address.
• If no default shipment address is specified for the customer, then new baskets default to “no shipment address”. If the design allows it, the salesperson may be able to select a shipment address.
• Default shipment address of any customer logins of the customer has no influence on behavior for salespersons having selected a customer.