Open APIs

Hello,

I am looking at upgrading a component to support the latest and greatest TMF622 and would be interested to hear others' views on the best way to handle Delivery (as in Shipping) Address.

Scenario:

A customer places an order for Home Broadband and a WiFi Router. It is already established that no technician visit is required, so they will self-install. They ask for the router to be delivered to their office (or a Post Office, Amazon locker - adjust as necessary) rather than to the home address where the Broadband service will actually be.

The frontend system will create a Shopping Cart (or perhaps a Quote) , that eventually gets converted to Product Orders (via Product Configuration)

Assume both the Broadband and the Router are Products since they have their own qualifications, prices, payments etc.

Question - how best to model the Delivery (Shipping) address , as opposed to the address where the Broadband Service will ultimately live.

I would see this as a single Product Order since the two things are clearly related, the customer will want one set of communications explaining what's going on 

(If you disagree, we can substitute different products - e.g. FWA access point. Anything where the 'service address' and 'where to deliver some box this time' differ)

• Any address associated to the Product representing the Broadband should be the home address
• Storing this as a characteristic of the Wifi router product seems wrong - because the address here is not really a property of the Product (once it's shipped we don't care any more). 
  • For example, if the router is later sent back , there might be another ProductOrder to handle this (with action=remove), with the 'shipping' being some sort of return envelope.

Logically it feels like a property of the ProductOrderItem, but I can't see anywhere sensible to put it.

On the other hand, I've been trying to use the same data structure across Quote, Cart, Configuration, Order items - so systems don't spend half their code rejigging fields for no good reason. So a field that exists in all of these would be good (which slightly nudges me to putting it under Product)

I understand that TMF700 Shipping Order exists too, but this feels like something that should be created downstream (probably using the Product Order or a downstream Service Order as input), since it has no relationship to pricing or service delivery. But if the Product Order doesn't hold this information we've not got much hope!

This feels like it is a fairly common scenario, so I am interested where others would store the Shipping Information during the initial Cart/Order creation. Do we all just stick it in a Characteristic?

------------------------------
Andrew Torrance
Cerillion Technologies Limited
------------------------------

for question about product and shipping, you should always look into GB922 (Product Sub-Guide).

IG1228 complement GB922 by providing concrete (process, UI, model) examples from 2 optics: Catalogue and Order views

TMF622 probably offers further guidance on how to store delivery addresses.

To clarify:

1. ✅ Storing the address as a characteristic on a dedicated ShippingProductSpec is valid and recommended by TMF SID team.

2. ✅ Capturing the address at the order line level (e.g. on the Wi-Fi item) or at order header level is valid (very common in Retail industry)

3. ❌ Storing it directly on the Wi-Fi productSpec itself is not recommended

4. 🔁 Shipping ProductSpecs are defined in the catalogue and instantiated in the cart or order. There's no need to persist them in product inventory, doing so would be redundant.

I would also recommend to model for B2B first, it's the most demanding scenario. If your approach handles that, it will scale across all customer segments.

And for data patterns, I'd take inspiration from leading retail eCommerce solution suppliers (some vendors are very open with their documentation). Nobody masters shipping like retail does!

Ask ChatGPT

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------

Original Message:
Sent: Jul 09, 2025 12:46
From: Andrew Torrance
Subject: TMF622 and Customer Shipping Information

Hello,

I am looking at upgrading a component to support the latest and greatest TMF622 and would be interested to hear others' views on the best way to handle Delivery (as in Shipping) Address.

Scenario:

A customer places an order for Home Broadband and a WiFi Router. It is already established that no technician visit is required, so they will self-install. They ask for the router to be delivered to their office (or a Post Office, Amazon locker - adjust as necessary) rather than to the home address where the Broadband service will actually be.

The frontend system will create a Shopping Cart (or perhaps a Quote) , that eventually gets converted to Product Orders (via Product Configuration)

Assume both the Broadband and the Router are Products since they have their own qualifications, prices, payments etc.

Question - how best to model the Delivery (Shipping) address , as opposed to the address where the Broadband Service will ultimately live.

I would see this as a single Product Order since the two things are clearly related, the customer will want one set of communications explaining what's going on 

(If you disagree, we can substitute different products - e.g. FWA access point. Anything where the 'service address' and 'where to deliver some box this time' differ)

• Any address associated to the Product representing the Broadband should be the home address
• Storing this as a characteristic of the Wifi router product seems wrong - because the address here is not really a property of the Product (once it's shipped we don't care any more). 
  • For example, if the router is later sent back , there might be another ProductOrder to handle this (with action=remove), with the 'shipping' being some sort of return envelope.

Logically it feels like a property of the ProductOrderItem, but I can't see anywhere sensible to put it.

On the other hand, I've been trying to use the same data structure across Quote, Cart, Configuration, Order items - so systems don't spend half their code rejigging fields for no good reason. So a field that exists in all of these would be good (which slightly nudges me to putting it under Product)

I understand that TMF700 Shipping Order exists too, but this feels like something that should be created downstream (probably using the Product Order or a downstream Service Order as input), since it has no relationship to pricing or service delivery. But if the Product Order doesn't hold this information we've not got much hope!

This feels like it is a fairly common scenario, so I am interested where others would store the Shipping Information during the initial Cart/Order creation. Do we all just stick it in a Characteristic?

------------------------------
Andrew Torrance
Cerillion Technologies Limited
------------------------------