The following enhancements will be made to the current 'address screen' validation logic:
LDLIB RPC$SHOPPINGCART_VALIDATECHECKOUTSTEP
STEP.NBR = 1 (Address)
When a new shipto customer is being created:
- Validate that none of the address lines contain a P.O. BOX by stripping out all "." and uppercasing, then looking for PO BOX. Return an error to the web.
- Currently, we check to see if the new customer entered matches an existing shipto customer on CUSTMST when we are creating the order. If a match is found, we use that shipto# instead of creating a new customer record. Please 'duplicate' the match logic from the order creation process here and check for an existing customer match. If you find a match:
- Write the existing shipto customer number back to the SHOPPINGCART.USR record
- Null out the shipto address fields onthe SHOPPINGCART.USR record
- Leave the shipto matching/customer creation logic in the create order area. We don't want to actually create the customer here. By doing the match again when creating the order, we ensure that the customer wasn't already created before this order is actually checked out.
NOTE: The UI side must always re-read the SHOPPINGCART.USR record to refresh data on the screen after validations occur.
02/27/14 - Clear shopping cart data if shipto customer# is changed (TIMELINE 8-4):
LDLIB RPC$SHOPPINGCART_SAVE:
If the shipto customer# is changed (SHOPPINGCART.USR<11> # CUST.NBR) and this is not a 'customer pickup' cart, bundling and labeling info will be cleared out:
- If not a customer pickup (SHOPPINGCART.USR<43> # 1) and SHOPPINGCART.USR<11> # CUST.NBR:
- Null out SHOPPINGCART.USR fields 47-59 and field 61 (bundling/shipping instructions)
- If labeling choice = 'my customers label' (SHOPPINGCART.USR<18>=2): Null out SHOPPINGCART.USR fields 18-23 and 25-29.