Difference between revisions of "Same as shipping logic"

From Stulipan Tudástár
Jump to navigation Jump to search
 
(17 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Prerequisites ==
= Prerequisites =


The Recipient and Sender are linked to a User, if any. A user may have more than one Recipient / Sender. Why this is important? In the checkout process there are two scenarios:  
The Recipient and Sender are linked to a User, if any. A user may have more than one Recipient / Sender. Why this is important? In the checkout process there are two scenarios:  
Line 5: Line 5:
# Guest checkout
# Guest checkout
# Logged-in checkout
# Logged-in checkout
# Abandoned checkout URL process


==== 1. Guest checkout ====  
== 1. Guest checkout ==


In this scenario when editing the Recipient / Sender details they are always overwritten. In other words, a Guest checkout will have one Recipient and one Sender object. These Recipient and Sender are not linked to a User.  
In this scenario when editing the Recipient / Sender details they are always overwritten. In other words, a Guest checkout will have one Recipient and one Sender object. These Recipient and Sender are not linked to a User.


==== 2. Logged-in checkout ====  
== 2. Logged-in checkout ==


In this scenario the customer has two options: '''Add a new address''' and '''List previously saved addresses'''.   
In this scenario the customer has two options: '''Add a new address''' and '''List previously saved addresses'''.   
Line 17: Line 18:
* When picking a '''previously saved address''' a different Recipient / Sender is linked to the Checkout.
* When picking a '''previously saved address''' a different Recipient / Sender is linked to the Checkout.


== The "Same As Shipping" workflow ==  
== 3. Abandoned checkout URL ==
 
This is affected by whether the Checkout was previously done with scenario (1) or (2).
 
When resuming an ''Abandoned checkout'', you can edit only data linked to the current Checkout. Therefore, if the checkout was done by a ''logged-in user'' you no longer have access to the previous Recipient / Sender lists.
 
So, when editing a Recipient / Sender the entity linked to the Checkout is therefore overwritten.
 
= The "Same As Shipping" workflow =
When choosing the Billing Address (Sender) the Customer has 2 options:
When choosing the Billing Address (Sender) the Customer has 2 options:


Line 23: Line 32:
* Add new billing address
* Add new billing address


=== Same as shipping address ===
== Same as shipping address ==


Guest and logged-in checkout scenarios do not affect the ''Same as shipping'' logic. With this logic no Sender is created in db, but a flag is marked. As a result, upon checkout completion a Sender will be created and attached to the Order.  
Guest and logged-in checkout scenarios do not affect the ''Same as shipping'' logic. With this logic no Sender is created in db, but a flag is marked. As a result, upon checkout completion a Sender will be created and attached to the Order.  
Line 29: Line 38:
NOTE: Recipient fields must match Sender's. Results that Recipient must have Company and Company VAT fields.
NOTE: Recipient fields must match Sender's. Results that Recipient must have Company and Company VAT fields.


=== Add new billing address ===  
==== A. Guest checkout ====
 
Previously a new Sender was added to the Checkout, then ''Same as shipping'' is selected.
 
* no Sender in db >> create new Sender with Recipient details
* already a Sender in db >> overwrite Sender with Recipient details
 
==== B. Logged-in checkout ====
 
Previously a new Sender was added to the Checkout, then ''Same as shipping'' is selected.
 
* no Sender in db >> create new Sender with Recipient details
* the Sender entity remains in the Checkout, but will be removed upon Order creation.
** we don't remove it because the flag tells us to ignore it.
 
==== C. Abandoned checkout URL ====
 
If previously a new Sender was added to the Checkout, then when choosing ''Same as shipping'':
 
* the flag becomes true and
* then apply either A. or B. from above
 
== Add new billing address ==  


In this case the ''same_as_shipping'' flag is set to false (0) and a new Sender is created and added to the Checkout.  
In this case the ''same_as_shipping'' flag is set to false (0) and a new Sender is created and added to the Checkout.  


==== Dealing with  ====
==== A. Guest checkout ====
 
* a Sender is in db >> replace it.
* no Sender >> create a new one.
 
==== B. Logged-in checkout ====
 
* no Sender in db >> create new one
* Sender already in db >> create new one
 
Note: there is a verification if the new sender already exists in previously saved list.
 
==== C. Abandoned checkout URL ====
 
* no Sender in db >> create new one
* Sender already in db >> apply either A. or B. from above

Latest revision as of 09:16, 21 February 2022

Prerequisites[edit | edit source]

The Recipient and Sender are linked to a User, if any. A user may have more than one Recipient / Sender. Why this is important? In the checkout process there are two scenarios:

  1. Guest checkout
  2. Logged-in checkout
  3. Abandoned checkout URL process

1. Guest checkout[edit | edit source]

In this scenario when editing the Recipient / Sender details they are always overwritten. In other words, a Guest checkout will have one Recipient and one Sender object. These Recipient and Sender are not linked to a User.

2. Logged-in checkout[edit | edit source]

In this scenario the customer has two options: Add a new address and List previously saved addresses.

  • With Add a new address a new Recipient / Sender is created in db and linked to the Checkout.
  • When picking a previously saved address a different Recipient / Sender is linked to the Checkout.

3. Abandoned checkout URL[edit | edit source]

This is affected by whether the Checkout was previously done with scenario (1) or (2).

When resuming an Abandoned checkout, you can edit only data linked to the current Checkout. Therefore, if the checkout was done by a logged-in user you no longer have access to the previous Recipient / Sender lists.

So, when editing a Recipient / Sender the entity linked to the Checkout is therefore overwritten.

The "Same As Shipping" workflow[edit | edit source]

When choosing the Billing Address (Sender) the Customer has 2 options:

  • Same as shipping address
  • Add new billing address

Same as shipping address[edit | edit source]

Guest and logged-in checkout scenarios do not affect the Same as shipping logic. With this logic no Sender is created in db, but a flag is marked. As a result, upon checkout completion a Sender will be created and attached to the Order.

NOTE: Recipient fields must match Sender's. Results that Recipient must have Company and Company VAT fields.

A. Guest checkout[edit | edit source]

Previously a new Sender was added to the Checkout, then Same as shipping is selected.

  • no Sender in db >> create new Sender with Recipient details
  • already a Sender in db >> overwrite Sender with Recipient details

B. Logged-in checkout[edit | edit source]

Previously a new Sender was added to the Checkout, then Same as shipping is selected.

  • no Sender in db >> create new Sender with Recipient details
  • the Sender entity remains in the Checkout, but will be removed upon Order creation.
    • we don't remove it because the flag tells us to ignore it.

C. Abandoned checkout URL[edit | edit source]

If previously a new Sender was added to the Checkout, then when choosing Same as shipping:

  • the flag becomes true and
  • then apply either A. or B. from above

Add new billing address[edit | edit source]

In this case the same_as_shipping flag is set to false (0) and a new Sender is created and added to the Checkout.

A. Guest checkout[edit | edit source]

  • a Sender is in db >> replace it.
  • no Sender >> create a new one.

B. Logged-in checkout[edit | edit source]

  • no Sender in db >> create new one
  • Sender already in db >> create new one

Note: there is a verification if the new sender already exists in previously saved list.

C. Abandoned checkout URL[edit | edit source]

  • no Sender in db >> create new one
  • Sender already in db >> apply either A. or B. from above