Review the need for duplicate address data

[mikejolley]

This probably fits in with the custom table work we plan on doing, but it could be reviewed and possibly worked on separately as an enhancement.

• Currently, each order has post meta values for the full billing address, and full shipping address.
• This address data is also stored in customer meta and linked to an account.
• User meta populates checkout fields by default.

This leads to each order needing to store the full address each and every time.

I think we could make this more efficient by having a table for addresses which links to orders + customers by ID.

Name	Type	Example
address_id	int	1
first_name	varchar	Mike
last_name	varchar	Jolley
company	varchar	A8C
address_1	varchar	Some house
address_2	varchar	Some street
city	varchar	Somewhereville
state	varchar	Nowhere
country	varchar	GB
postcode	varchar	XX11 X11

A second address_relationships table would link customer IDs and order IDs to each address. Columns object_id, object_type (customer or order), address_id, address_type (billing or shipping).

Issues and concerns:

• If an address is updated or changed, old orders will change with it. Does this matter? Research.
• Customer facing UI; do we allow them to add multiple addresses and then choose their default for shipping/billing from a dropdown?
• Do we add an address dropdown to checkout? Are fields readonly unless 'new address' is chosen?
• Does admin need address editing tools, beyond the user meta editing done now?
• Do admin edits of addresses update the address in the DB for the user to see?

cc'ing @kloon for implementation feedback.
cc'ing @jameskoster for design feedback too.

[jameskoster]

Customer facing UI; do we allow them to add multiple addresses and then choose their default for shipping/billing from a dropdown?

Sounds like a useful feature. Don't we have an extension that does this already?

Do we add an address dropdown to checkout? Are fields readonly unless 'new address' is chosen?

We'll look in to this as a part of our checkout flow research for #10672

cc @kellychoffman

[claudiosanches]

Customer facing UI; do we allow them to add multiple addresses and then choose their default for shipping/billing from a dropdown?
Do we add an address dropdown to checkout? Are fields readonly unless 'new address' is chosen?

Yes, please :)

Storing multiple address should help a lot of customers and store owners, not mention that this is something common in any store.

[claudiosanches]

@jameskoster

Sounds like a useful feature. Don't we have an extension that does this already?

Related to addresses I could only find this extension: https://woocommerce.com/products/shipping-multiple-addresses/
But it's to allow ship products to multiples locations at the same time... So this extension can benefit from this new feature. Everyone wins 🎉

[DavidAnderson684]

If an address is updated or changed, old orders will change with it. Does this matter?

There might be an issue with VAT compliance in some countries with that. Currently, people rely on the order billing address (especially if it was sent to the card processor and accepted by them) as part of mandatory recording of data that can be required later for audit / proof that the customer's location was correctly identified (and hence correct VAT charged - e.g. in the EU where it varies by country for digital goods).

[kloon]

To have address book functionality we can use the table structure as proposed, however as mentioned by @DavidAnderson684 to be compliant with the various VAT rules in countries we will need to store the actual addresses with the order, that will form part of the custom table work we plan on doing. The reasoning behind that is to avoid tax fraud, you do not want customers to be able to change addresses linked to existing order which is what can happen when you use separate tables with links between them.

[ghost]

If an address is updated or changed, old orders will change with it. Does this matter? Research.

At least one issue comes to my mind if a customer has moved from one city to an other and needs to print an invoice (all invoice plugins I know off use the address data stored in woocommerce) for an old order for taxation purpose. The tax authorities won't accept the old invoice if it carries the new address. I don't know whether this counts for any country in this world but tax authorities throughout Europe work that way.

You would need to keep an address history for each user in case of changes which will still cause less data to be stored compared to the way it works today.

[ghost]

Please consider adding the field vat_id to the address table as well. In Europe the VAT ID is a must have in B2B shops. As for now all plugins dealing with the European taxation system store the VAT ID in a custom meta key/value pair. Shop owners moving from one plugin to an other loose this information. Having a defined place to store the VAT ID would solve the problem.

[marcusquinn]

Would making Customer/User Addresses a Term + Term Meta be in-keeping with the site being an application for their (shopping) use?

As an example, we store Barcodes and external UIDs as Terms - there's only one of each them and the Terms table is unique by design.

Therefore, being de-duped by design and updatable to whatever their latest details are.

You could have a reserved Woocommerce Order Attribute, eg: 'User Addresses' storing the fields either as termmeta records or a serialised array.

Then the latest values used on Order Posts remain crystallized as read-only data for accounting compliance as mentioned by @DavidAnderson684

[marcusquinn]

@jameskoster that plugin quite elegantly creates a Custom Post Type 'Order Shipments' that we use to address #13097 & #11259 - easy enough to relate Shipment Statuses to that as well and add Tracking Number / Carrier metadata etc.

[marcusquinn]

If an address is updated or changed, old orders will change with it. Does this matter? Research.

Yes this would matter and be a legal issue. An Order Post is a legal document and forms part of a contract between the consumer and the service provider and should never be edited without revisions stored. It can be appended though (with an invoice ID, shipping details etc), which are parts of the contract execution.

The billing address is one party to the contract so needs to be retained separately to the Shipping Address - although I can see it being acceptable to reference the billing address if shipping is the same.

It's worth a look at Microsoft Dynamics NAV data design because as an accounting and ERP system, the data structure is designed to retain records that are digital legal contracts and make "posted" records non-editable (to a separate read-only table) in the same way a printed and signed contract would be filed.

This has the added advantage of keeping the working Orders table small and efficient, and the archive table(s) for posted records partitionable by accounting period.

[LetMeKnow1]

The questions asked here has answers in many sites... Amazon, Vitacost, Iherb, Asos.

Save addresses in Address table (Which is linked to Customer table). Customer may change the addresses as he pleased.
When Placing new order the default address from Customer table will be copied to the order (actual copy to the order table or whatever it is saved). The customer may change the address as he wishes. When order is placed customer is unable to edit this address any more (the address is saved in the order itself). The store owner can edit the address as long as the status is processing.

You can extend this to also support shipment/billing address with no problem.

[woocommercebot]

Thanks for the suggestion @mikejolley.

We'll keep an eye on the popularity of this request :)

[lutrov]

If an address is updated or changed, old orders will change with it. Does this matter? Research.

Yes, it does. Addresses for old orders must not change since the only valid address for an order is the address at the time the order was placed.