Same as shipping logic - Revision history

Tulipanf: /* B. Logged-in checkout */

2022-02-21T09:16:32Z

B. Logged-in checkout

← Older revision		Revision as of 09:16, 21 February 2022
Line 49:		Line 49:
	Previously a new Sender was added to the Checkout, then ''Same as shipping'' is selected.		Previously a new Sender was added to the Checkout, then ''Same as shipping'' is selected.

	* no * no Sender in db >> create new Sender with Recipient details		* no Sender in db >> create new Sender with Recipient details
	* the Sender entity remains in the Checkout, but will be removed upon Order creation.		* 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.		** we don't remove it because the flag tells us to ignore it.

Tulipanf: /* Same as shipping address */

2022-02-20T11:37:57Z

Same as shipping address

← Older revision		Revision as of 11:37, 20 February 2022
Line 40:		Line 40:
	==== A. Guest checkout ====		==== A. Guest checkout ====

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

	* ~~the flag becomes true and~~		* no Sender in db >> create new Sender with Recipient details
	* ~~the~~ Sender ~~entity is updated~~ with Recipient details ~~ONLY upon Order creation.~~		* already a Sender in db >> overwrite Sender with Recipient details

	==== B. Logged-in checkout ====		==== B. Logged-in checkout ====

	~~If previously~~ a new Sender was added to the Checkout, then ~~when choosing~~ ''Same as shipping'':		Previously a new Sender was added to the Checkout, then ''Same as shipping'' is selected.

	* ~~the flag becomes true and~~		* no * no Sender in db >> create new Sender with Recipient details
	* the Sender entity remains in the Checkout, but will be removed upon Order creation.		* 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.		** we don't remove it because the flag tells us to ignore it.

Tulipanf: /* Add new billing address */

2022-02-20T11:27:30Z

Add new billing address

← Older revision		Revision as of 11:27, 20 February 2022
Line 66:		Line 66:
	==== A. Guest checkout ====		==== A. Guest checkout ====

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

	==== B. Logged-in checkout ====		==== B. Logged-in checkout ====

	If no Sender in db >> create new one		* no Sender in db >> create new one
			* Sender already in db >> create new one
	If Sender already in db >> create new one

	Note: there is a verification if the new sender already exists in previously saved list.		Note: there is a verification if the new sender already exists in previously saved list.
Line 80:		Line 78:
	==== C. Abandoned checkout URL ====		==== C. Abandoned checkout URL ====

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

Tulipanf: /* Add new billing address */

2022-02-20T11:26:41Z

Add new billing address

← Older revision		Revision as of 11:26, 20 February 2022
Line 67:		Line 67:

	If a Sender is in db >> replace it.		If a Sender is in db >> replace it.

	If no Sender >> create a new one.		If no Sender >> create a new one.

Line 72:		Line 73:

	If no Sender in db >> create new one		If no Sender in db >> create new one

	If Sender already in db >> create new one		If Sender already in db >> create new one

Line 79:		Line 81:

	If no Sender in db >> create new one		If no Sender in db >> create new one

	If Sender already in db >> apply either A. or B. from above		If Sender already in db >> apply either A. or B. from above

Tulipanf at 11:26, 20 February 2022

2022-02-20T11:26:23Z

← Older revision		Revision as of 11:26, 20 February 2022
Line 64:		Line 64:
	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 ====

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

			==== B. Logged-in checkout ====

			If no Sender in db >> create new one
			If 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 ====

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

Tulipanf: /* Same as shipping address */

2022-02-20T11:15:53Z

Same as shipping address

← Older revision		Revision as of 11:15, 20 February 2022
Line 38:		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.

	==== Guest checkout ====		==== A. Guest checkout ====

	Previously a new Sender was added to the Checkout, then with ''Same as shipping'':		Previously a new Sender was added to the Checkout, then with ''Same as shipping'':

	* the flag becomes true and		* the flag becomes true and
	* the Sender entity is updated with Recipient details		* the Sender entity is updated with Recipient details ONLY upon Order creation.

	~~upon Order creation.~~		==== B. Logged-in checkout ====

	==== Logged-in checkout ====

	If previously a new Sender was added to the Checkout, then when choosing ''Same as shipping'':		If previously a new Sender was added to the Checkout, then when choosing ''Same as shipping'':
Line 54:		Line 52:
	* the Sender entity remains in the Checkout, but will be removed upon Order creation.		* 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.		** 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 ==		== Add new billing address ==

Tulipanf: /* Same as shipping address */

2022-02-20T11:09:37Z

Same as shipping address

← Older revision		Revision as of 11:09, 20 February 2022
Line 43:		Line 43:

	* the flag becomes true and		* the flag becomes true and
	* the Sender ~~details will be~~ updated with Recipient details		* the Sender entity is updated with Recipient details

	upon Order creation.		upon Order creation.
Line 49:		Line 49:
	==== Logged-in checkout ====		==== Logged-in checkout ====

	If previously a new Sender was added to the Checkout, then when choosing ''Same as shipping'' the flag becomes true and the Sender ~~is removed (from~~ the Checkout) upon Order creation.		If previously a new Sender was added to the Checkout, then when choosing ''Same as shipping'':

			* the flag becomes true and
			* 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.

	== Add new billing address ==		== Add new billing address ==

Tulipanf: /* Guest checkout */

2022-02-20T11:02:27Z

Guest checkout

← Older revision		Revision as of 11:02, 20 February 2022
Line 40:		Line 40:
	==== Guest checkout ====		==== Guest checkout ====

	~~If previously~~ a new Sender was added to the Checkout, then ~~when choosing~~ ''Same as shipping'' the flag becomes true and the Sender details will be updated with Recipient details upon Order creation.		Previously a new Sender was added to the Checkout, then with ''Same as shipping'':

			* the flag becomes true and
			* the Sender details will be updated with Recipient details

			upon Order creation.

	==== Logged-in checkout ====		==== Logged-in checkout ====

Tulipanf: /* 3. Abandoned checkout URL */

2022-02-20T11:00:08Z

3. Abandoned checkout URL

← Older revision		Revision as of 11:00, 20 February 2022
Line 24:		Line 24:
	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.		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 overwritten.		So, when editing a Recipient / Sender the entity linked to the Checkout is therefore overwritten.

	= The "Same As Shipping" workflow =		= The "Same As Shipping" workflow =

Tulipanf: /* Prerequisites */

2022-02-20T10:58:31Z

Prerequisites

← Older revision		Revision as of 10:58, 20 February 2022
Line 11:		Line 11:
	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 18:		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.

	=== 3. Abandoned checkout URL ===		== 3. Abandoned checkout URL ==

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