Pre-conditions

You have created an order using BIC101: Customer Creates Order, it has passed the state and substate of Acknowledged/Received but has not reached the state of Closed.

Post-Conditions

Based on your response, we update the order and it continues through the fulfilment process.

The following use cases support this business process.

Click on the links to view the XML samples.

> Provider to Advise Response

In this example we ask you to update the customer and site contact details in your order by sending:

Amend Order Notification: HELD_PROVIDER_TO_ADVISE message to advise you that we have put your order into held provider to advise while we wait for more information.

You respond using the following Amend Order Request types:

• CONTACT_DETAILS- to update the customer contact details
• ORDER_DETAILS - to update the site contact details
• ANSWER - to advise that you have completed your response.

This section provides a list of the User Story References that we have met in this business process, as defined by the Ultra-Fast Broadband BSS / OSS Business Interaction Framework.

The document is available from:

Refer to the TCF website for documentation.

Pre-conditions

We reschedule a site visit appointment or RFS date in your order.

Post-conditions

You receive our amend order notification advising you of the updated appointment date and time.

The following use cases support this business process.

Click on the links to view the XML samples.

> Reschedule Site Visit Appointment

In this example we have updated the Scope and Install appointments against your order. We advise you by sending:

• AmendOrderNotification: SVM_EVENT to advise you that we have changed the Scope site visit.
• AmendOrderNotification: SVM_EVENT to advise you that we have changed the Install site visit.

> Reschedule RFS Date

In this example, we have updated the RFS date against your order. We advise you by sending:

• AmendOrderNotification: SVM_EVENT.

This section provides a list of the User Story References that we have met in this business process, as defined by the Ultra-Fast Broadband BSS / OSS Business Interaction Framework.

The document is available from:

Refer to the TCF website for documentation.

Pre-conditions

You receive a request from us, or your customer, to modify an order.

Post-Conditions

You receive our response to your amendment request.

Refer to the Exception Codes table for error details.

-- Validation of Requests

The AmendOrderType element defines the type of Amend Order Request, and determines how the request is validated for processing and content.

-- Order State

The following table shows the types of Amend Order Requests and the order states that will allow changes.

-- Cancelled Orders

If we accept a request to cancel your order, i.e. Customer Cancels Order or Supplier Cancels Order, we will cancel any unprocessed Amend Order Requests.

The Exception Codes table lists the exceptions that may be returned by this service.

For a full list of exception codes and their meanings see B2B Exception Codes.

The following use cases support this business process.

Click on the links to view the XML samples.

> Escalate Order

In this example, you use AmendOrderRequest: ESCALATE to escalate an order for medical reasons.

We respond to your message and keep you updated as the escalation is processed by sending:

• AmendOrderNotification: ESCALATION_ACCEPTED to advise you that we have accepted your escalation.
• AmendOrderNotification: SVM_EVENT to change the site visit scoping and install appointments.
• AmendOrderNotification: ESCALATION_COMPLETED to advise you the escalation is complete.

Note: our escalation processes are available from: Managed Provisioning

> Interaction - Withdraw Escalation

In this example, you use AmendOrderRequest: ESCALATE to escalate an order for medical reasons.

We respond to your message and accept your escalation by sending:

• AmendOrderNotification: ESCALATION_ACCEPTED to advise you that we have accepted your escalation.

After further discussions with your end customer you withdraw the order escalation using AmendOrderRequest: INTERACTION.

We respond to your message and your escalation withdrawal by sending:

• AmendOrderNotification: ESCALATION_COMPLETED to advise you the escalation is complete.

> Escalate Order - Escalation Declined

In this example, you use AmendOrderRequest: ESCALATE to escalate an order for medical reasons.

We respond to your message and decline the escalation by sending:

• AmendOrderNotification: ESCALATION_DECLINCED to advise you that the escalation does not meet the standard criteria

> Amend Product Characteristics

In this example, you use AmendOrderRequest: CHARACTERISTICS to change Product Characteristics against an order.

> Amend Order Details

Use case examples showing how to use Amend Order Requests to update order details are provided by:

• BIC108: Supplier Notifies Customer Order Information Required

> Amend Contact Details

Use case examples showing how to use Amend Order Requests to update contact details are provided by:

• BIC108: Supplier Notifies Customer Order Information Required

> Update Appointments

UsecaseexamplesshowinghowtouseAmendOrderRequeststoupdateappointmentdetailsareprovided by:

• BIC109: Customer Reschedules Order Appointment

> Answer Questions

Use case examples showing how to use Amend Order Requests to answer a question are provided by:

• BIC104: Supplier Cancels Order
• BIC108: Supplier Notifies Customer Order Information Required
• BIC116: Supplier Notifies of Order Cost Variation

The following Use Cases provide examples using the AmendOrderRequest to respond to orders we create on your behalf.

-- Answer - Disconnect Secondary

In this example, the CreateOrderNotification: INTENT_TO_DISCONNECT_SECONDARY_ABANDONMENT is sent to advise you that we intend to disconnect your secondary product as the location does not have an existing primary product.

• you reject the disconnection using AmendOrderRequest: ANSWER
• we cancel our order and send you AmendOrderNotification: IN_PROGRESS_INTENT_TO_CANCEL

The product must be promoted to a primary offer using Create Order Request, order type Change Offer.

Note: an order to promote an existing secondary product is treated with the same priority as an order to connect a new primary. This means that if two orders are created for the same ONT, we will process the order we receive first and reject the second order.

-- Answer - Disconnect Abandonment (Accept)

CreateOrderNotification: INTENT_TO_DISCONNECT_ABANDONMENT message is sent to advise you that, due to another customer's order created to replace your product, we have created a disconnection order on your behalf.

In this example,

• you Accept the disconnection using AmendOrderRequest: ANSWER.

-- Answer - Disconnect Abandonment (Reject)

CreateOrderNotification: INTENT_TO_DISCONNECT_ABANDONMENT message is sent to advise you that, due to another customer's order created to replace your product, we have created a disconnection order on your behalf.

In this example, you check with your end customer and find that they are not moving.

• you reject the disconnection using AmendOrderRequest: ANSWER with a reason.

> Chorus Portal Amend

In this example, you use the Chorus Portal to amend your order characteristics.

We respond using the Chorus Portal to accept your request. On the B2B you will receive the following notifications:

• AmendOrderNotification: AMEND_ORDER_COMPLETED to advise you amendment has been complete.

> Use Case Exceptions

The following table describes the use case exceptions that support this business process.

Click on the scenario link to view the XML sample.

This section provides a list of the User Story References that we have met in this business process, as defined by the Ultra-Fast Broadband BSS / OSS Business Interaction Framework.

The document is available from:

Refer to the TCF website for documentation.

Request Success Criteria

Response Success Criteria

Pre-conditions

We notify you of our intent to cancel an order belonging to you. The order will have reached the state and substate of Acknowledged/Accepted but not the state Service Given.

Post-Conditions

You receive our notification and action as required.

The following use cases support this business process.

Click on the links to view the XML samples.

> Supplier Cancels Order - Customer Accepts Request

In this example your order cannot be fulfilled and needs to be cancelled. We advise you by sending:

• AmendOrderNotification:INTENT_TO_CANCELtoadvisethatwewouldliketocancelyourorder.

You accept the cancellation using AmendOrderRequest: ANSWER.

We action the cancellation and advise you by sending:

• AmendOrderNotification: CLOSED_CANCELLED.

> Supplier Cancels Order - No intact available on site

In this example your order cannot be fulfilled and needs to be cancelled. The order has been submitted as an intact however the installer has identified that there is no intact available on site. As this order was submitted via B2B, we request that you submit a new Connect Additional ONT order via your B2B. We advise you by sending:

• AmendOrderNotification:INTENT_TO_CANCELtoadvisethatwewouldliketocancelyourorder.

You accept the cancellation using AmendOrderRequest: ANSWER.

We action the cancellation and advise you by sending:

• AmendOrderNotification: CLOSED_CANCELLED.

> Supplier Cancels Order - Customer Rejects Request

In this example your order cannot be fulfilled and needs to be cancelled. We advise you by sending:

• AmendOrderNotification: INTENT_TO_CANCEL, to advise you that we would like to cancel your order.

You reject the cancellation using an:

• Amend Order Request: ANSWER.

We acknowledge your response using:

• AmendOrderNotification: REJECT_CANCEL.

The next steps in the process will be determined by the order and reason we asked to cancel it, for example,wemayuseanAmendOrderNotification: MANUAL_INTERACTIONtoprovideyouwithfurther information.

This section provides a list of the User Story References that we have met in this business process, as defined by the Ultra-Fast Broadband BSS / OSS Business Interaction Framework.

The document is available from:

Refer to the TCF website for documentation.

Pre-conditions

YouhavecreatedanorderusingBIC101:CustomerCreatesOrder,ithasreachedthestateandsubstate Acknowledged/Accepted but has not reached the state of Service Given.

Post-Conditions

You receive our response notifying you that the state and substate of your order have been changed to In Progress/Intent to Cancel.

If we accept your cancellation request, we will send an Amend Order Notification to advise that the order state and substate have been changed to Closed/Cancelled. The notification will include any outstanding charges.

Refer to the Exception Codes table for error details.

The Exception Codes table lists the exceptions that may be returned by this service.

For a full list of exception codes and their meanings see B2B Exception Codes.

The following use cases support this business process.

Click on the links to view the XML samples.

> Customer Cancels Order

In this example, you use CancelOrderRequest to request the cancellation of an order. We change your order state and substate to In Progress/Intent to Cancel.

We respond to your cancellation request by sending:

• AmendOrderNotification: CLOSED_CANCELLED to advise you that we have accepted your order cancellation.

Use Case Exceptions

The following table describes the use case exceptions that support this business process.

Click on the scenario link to view the XML sample.

Success Criteria

This section provides a list of the User Story References that we have met in this business process, as defined by the Ultra-Fast Broadband BSS / OSS Business Interaction Framework.

The document is available from:

Refer to the TCF website for documentation. 

Request Success Criteria

Response Success Criteria

Pre-conditions

We have a change to make or a question to ask you, regarding your order.

Post-Conditions

You respond to our notification as required.

The following use cases support this business process.

> Order Progresses to Fulfillment

We keep you updated as the order progresses to completion by sending:

• AmendOrderNotification: ACKNOWLEDGED_ACCEPTED to advise you that we have verified the network configuration details and accepted your order.
• AmendOrderNotification: RFS_CONFIRMED to advise you that we have confirmed the RFS date. Note: State / Sub-State should be handled as a wildcard (*/*) because RFS_CONFIRMED can be used at various stages in the message flow.
• AmendOrderNotification: SCOPING_SCHEDULED to advise you that we have scheduled the order scoping, this notification is sent for orders that require a scoping site visit.
• AmendOrderNotification: SCHEDULED to advise you that we have completed scoping and have scheduled the install. It will include details of how we expect to configure the network.
• AmendOrderNotification: SERVICE_GIVEN to advise you that we have completed the installation. It will include details of how the network has been configured.
• AmendOrderNotification: COMPLETED_BILLING to advise you the order is complete and we are processing the billing. It will include the charges except for WYAH charges.
• AmendOrderNotification: CLOSED_COMPLETED to advise you the order is complete. It will contain all charges including WYAHcharges.

In this example you have created an order to connect a Primary offer, the order progresses to completion using the standard order fulfilment process flow.

> Order Requires Consent

In this example, you have an order that is in the state and substate In Process/Consent Required.

We keep you updated as we work through the consent process by sending:

• AmendOrderNotification: CONSENT_REQUESTED to advise you that we have requested consent.
• AmendOrderNotification: CONSENT_GAINED to advise you that consent has been gained.
• AmendOrderNotification: NETWORK_DESIGN to advise you that we are designing the solution.

> Order Consent Declined

In this example, you have an order that is in the state and substate In Process/Consent Required.

We keep you updated as we work through the consent process by sending:

• AmendOrderNotification: CONSENT_REQUESTED to advise you that we have requested consent.
• AmendOrderNotification: CONSENT_DECLINED to advise you that consent has been declined.

> Order Requires Network Design

In this example, you have an order that is in the state and substate In Process/Acknowledged Accepted.

We keep you updated with the network design process by sending:

• AmendOrderNotification: NETWORK_DESIGN to advise you that we are designing the solution.
• AmendOrderNotification: NETWORK_BUILD to advise you that your order requires network build tasks.
• AmendOrderNotification: HELD_SCHEDULE_SCOPING to advise you that you need to schedule the scoping and install appointments with your customer.

> Order Requires Investigation and a Quote

Use case examples showing how we notify you that your order requires investigation and send you a quote are provided by:

• BIC116: Supplier Notifies of Order Cost Variation

> Order Appointments Rescheduled

Use case examples showing how we notify you that we have updated an appointment are provided by:

• BIC106-BIC110: Supplier Reschedules Order Appointment

> Advise You Appointments Require Rescheduling

Use case examples showing how we ask you to reschedule an appointment are provided by:

• BIC109: Customer Reschedules Order Appointment

> Advise You of Intent Cancel Order

Use case examples showing how we notify you that we intend to cancel an order belonging to you are provided by:

• BIC104: Supplier Cancels Order

> Ask You a Question

Use case examples showing how we ask you to update order details Correspond to a question are provided by:

• BIC105 - Customer Amends Order
• BIC108: Supplier Notifies Customer Order Information Required

This section provides a list of the User Story References that we have met in this business process, as defined by the Ultra-Fast Broadband BSS / OSS Business Interaction Framework.

The document is available from:

Refer to the TCF website for documentation.

Pre-conditions

The BIC003: Query Order Feasibility response returned the FEASIBILITY_CODE 998 or 999.

If your order requires a site visit you have reserved the appointment(s) using BIC005: Reserve Appointment.

Post-conditions

You receive our response with confirming that your order has been submitted and the state and substatus are Acknowledged/Received.

Refer to the Exception Codes table for error details

Create Order Requests

Disconnect Secondary Offer

A location can only have a secondary offer if there is an existing primary offer.

If the primary offer is disconnected, we will send you an order notification to advise that we intend to disconnect the secondary offer. If you do not reject our notification and create a Change Offer order to promote the secondary offer, we will process the disconnection.

Note: the notification must be rejected and the Change Offer order actioned within 5 calendar days or the secondary offer will be disconnected.

The use case example showing how to Answer a Disconnect Secondary notification is provided by:

• BIC105 - Customer Amends Order

Replace Orders

On receipt of a replacement order, we will send a disconnect notification to the Losing Service Provider(s) (LSP) and they must respond within 5 days.

The replacement will not proceed if the LSP:

• does not explicitly accept the intent to disconnect. Or,
• rejects the disconnection with a valid reason.

In either of these cases, the Gaining Service Provider (GSP) will be advised that we intend to cancel their order and they may accept the cancellation or raise an escalation with us.

The use cases examples showing how to Answer a Disconnect Abandonment notification are provided by:

• BIC105 - Customer Amends Order

The Exception Codes table lists the exceptions that may be returned by this service.

For a full list of exception codes and their meanings see B2B Exception Codes.

The following use cases support this business process.

Click on the links to view the XML samples.

> Connect Primary

Create Order Request is executed to order a Product Offer for the location using Order Type Connect Primary and OrderItem action new.

> Connect Additional ONT

Create Order Request is executed to order a Product Offer for the location using Order Type Connect Additional ONT and OrderItem action new.

> Connect Secondary

Create Order Request is executed to order a Product Offer for the location using Order Type Connect Secondary and OrderItem action new.

> Connect and Replace

Create Order Request is executed to order a Product Offer for the location using Order Type Connect and Replace, and OrderItem action new.

Note: the order moved to Held Pending Disconnect and a disconnection notification is sent to the LSP.

> Move Primary

Create Order Request is executed to order a Product Offer for the location using Order Type Move Primary, OrderItem action new and relinquish.

> Move Additional ONT

Create Order Request is executed to order a Product Offer for the location using Order Type Move Additional ONT, OrderItem action new and relinquish.

> Move and Replace

Create Order Request is executed to order a Product Offer for the location using Order Type Move and Replace, OrderItem action new and relinquish.

Note: the order moved to Held Pending Disconnect and a disconnection notification is sent to the LSP.

> Change Offer

Create Order Request is executed to order a Product Offer for the location using Order Type Change Offer, OrderItem action new and relinquish.

> Change Offer - Promote to Primary

Create Order Request is executed to order a promote a Product Offer for the location using Order Type Change Offer, OrderItem action new and relinquish.

> Modify Attribute

Create Order Request is executed to order a Product Offer for the location using Order Type Modify Attribute and OrderItem action modify.

> Modify Attribute with CSE

Create Order Request is executed to order a Product Offer for the location using Order Type Modify Attribute, OrderItem action modify and OrderItem action new.

> Disconnect Primary

Create Order Request is executed to order a Product Offer for the location using Order Type Disconnect Primary and OrderItem action relinquish.

> Disconnect Secondary

Create Order Request is executed to order a Product Offer for the location using Order Type Disconnect Secondary and OrderItem action relinquish.

> Transfer Primary

Create Order Request is executed to order a Product Offer for the location using Order Type Transfer Primary and OrderItem action new.

The following Use Cases provide examples of orders that require manual activity by Chorus.

-- Connect Primary - Order Requires Network Design

Create Order Request is executed to order a Product Offer at the location using Order Type Connect Primary and OrderItem action new.

The AmendOrderNotification: RFS_CONFIRMED is omitted and the order state and substate are changed to In Progress/Network Design.

-- Connect Primary - Order Requires Consent

Create Order Request is executed to order a Product Offer at the location using Order Type Connect Primary and OrderItem action new.

The Amend Order Notification: RFS_CONFIRMED is omitted and the order state and substate are changed to In Progress/Consent Required.

The following table describes the use case exceptions that support this business process.

Click on the scenario link to view the XML sample.

This section provides a list of the User Story References that we have met in this business process, as defined by the Ultra-Fast Broadband BSS / OSS Business Interaction Framework.

The document is available from:

Refer to the TCF website for documentation. 

Request Success Criteria

The order elements contain Order header information. The following table describes the Order elements.

The following table describes the BillingInformation element.

The following table describes the values provided by the Charge element.

The following table describes the values provided by the ChargeType element.

Order - type

The following table describes the values provided by the type element.

Order - RetainCopper

The following table describes the values provided by the retainCopper element.

Order - Document

The following table describes the OrderRole element.

Order - OrderRole - name

The following table describes the values provided by the name element.

Order - OrderRole - Party

The following table describes the values provided by the Party element.

Order - retainCopper

The following table describes the values provided by the retainCopper element.

The following table describes the OrderEmailNotification element.

Order - OrderEmailNotification - email

The following table describes the values provided by the emailAddress element.

Order - OrderEmailNotification - requestNotify

The following table describes the values provided by the requestNotify element.

The OrderItem elements contain details of the Order items. The following table describes the OrderItem elements.

Order - OrderItem - action

The following table describes the values provided by the action element.

Order - OrderItem - state and substate

Orders are managed using status and sub-status. The status changes as the order progresses and when scoping and installation work is carried out. Not all statuses apply to all orders.

The following table describes the values provided by the state and associated substate elements.

Note: An order is placed in the Held stage when we are waiting for an action to be completed by you.

Order - OrderItem - ExistingProviderDetail

The ExistingProviderDetail elements contain details of the existing provider (RSP) and product being replaced. The following table describes the values provided by the ExistingProviderDetail element.

The following table describes the Timing elements.

Date and time values use the xsd:dateTime format: YYYY-MM-DDTHH:MM:SS+[UTC offset, e.g. 12:00].

Order - OrderItem - Timing - name

RFS dates and times are sourced from BIC004: Query Appointment Availability.

The following table describes the values provided by the name element.

The following table describes the ProductOffering element.

Order - OrderItem - ProductOffering - ProductCharacteristic

The following table describes the values provided by the ProductCharacteristic element.

The following table describes the Product elements.

The appointment details will be returned for orders that have site visit booked. The following table describes the SiteVisit elements.

Order - OrderItem - SiteVisit - bookable

The following table describes the values provided by the bookable element.

Order - OrderItem - SiteVisit - type

The following table describes the values provided by the type element.

The following table describes the AppointmentSlot elements.

Order - OrderItem - SiteVisit - AppointmentSlot - dateTime

The following table describes the values provided by the dateTime element.

The Place elements provide the location and equipment access information. The following table describes the Place element.

Order - OrderItem - Place - Access

The following table describes the values provided by the Access element.

Order - OrderItem - Place - EquipmentLocation

The following table describes the values provided by the EquipmentLocation element.

The PlaceRole elements provide contact details for the location. The following table describes the PlaceRole element.

Order - OrderItem - Place - PlaceRole - Party

The following table describes the values provided by the Party element.

The Place Role elements are used to add role types for the order contacts. The following table describes the name element.

Note: Market Segment codes and Consent requirement values are provided by Query Product Offer availability .

The Contact Medium element is used to add contact details for each of contact types you defined using the PlaceRole - name element.

The following table provides details of the ContactMedium element.

Order - OrderItem - Place - PlaceRole - ContactMedium - preference

The following table describes the values provided by the preference element.

Service Name

CreateOrderRequest

Service Inputs

The following fields are mandatory for requesting this service:

• OrderRole
• Order id
• Order type
• billingAccount
• customerReferenceId
• retainCopper
• OrderEmailNotification
• OrderItem id
• OrderItem action
• Place
• PlaceRole

Thefollowingtableshowsthepossibleorderscenarios,thevaluesofOrder-typeandOrderItem-action fields, and the additional mandatory input criteria / fields.

Note: the ProductCharacteristics names and values must comply with the values and rules defined in the Product Offer/Specification Catalogue. If you are updating an existing product use the values provided by Query Site Information.

Message Handling Specifications

Service Name

CreateOrderResponse

Service Outputs

If valid input was provided, your order will be created and the response will contain the order details. It will be in the state and substate of Acknowledged/Received.

Note: non-catalogue values, e.g. existing ONT id, are validated before the order substate is moved to Accepted.

Message Handling Specifications

The following table describes the Place element

The following table describes the CoreLogicAddress elements.

The following table describes the BIF Structured Address elements.

The Address Part elements are used to return additional address information for BIF Structured Address queries.

The following table describes the AddressPart elements.

Address - Address Part - type

The following table describes the values provided by the type element.

Address - Address Part - type - Unit Type

Address - Address Part - type - Region Name

The following table describes the values provided by the Region Name element.

Address - Address Part - type - Road Name Suffix

The following table describes the values provided by the Road Name Suffix element

Address - Address Part - type - Address Type

The following table describes the values provided by the Address Type element.

The address key elements are used to search against TerraLink Unique Identifiers (TUI) or ICMS Unique Identifiers (PLSAM).

Address - AddressKey - type

The following table describes the values provided by the type element.

Note: for CoreLogic searches the AddressKey elements will always return the TUI values in the response.

An exact match search can be used to avoid addresses with a common house_high, house_low, flat_low and house_low_suffix being returned. For example, you can search for a location with a house of 23 and the response will not include 23A, 23B, 23B, 1/23.

This function does not apply the wild card rules, it will only search against the information you provide and will not return a result unless there is a single exact match to your criteria.

We do not recommend using this type of searching, as it increases the risk of selecting an incorrect address or having incomplete information available when choosing a service delivery address.

The following table describes the exactMatch elements.

exactMatch values

The following table describes the values provided by the exactMatch element

Query place searches are not case sensitive and are executed by matching search criteria against our Address Location Manager database, using either:

The order:

1. Road Name

2. Suburb

3. City/Town***

4. Level Number

5. Location descriptor.

Or, one of the address identifiers:

Place id TUI ID PLSAM.

***The query will search query both City and TerritorialAuthority name, as they may have the same value or, in some cases, an address record will not have an associated town name.

Pattern Matching (streetAlphaNumeric)

Pattern matching is used to search against values entered in the BIF Structured Address streetAlphaNumeric field. The following tables describe how pattern matching works.

Alternative Road and Alias Suburb Searches

We will always return our primary street/road name and suburb name, regardless of whether the primary or alternative names have been provided in the search.

This means that the address returned in the response may appear to be different from the one requested the search criteria.

Example:

The search criteria:

1 Smith, Ohawe.

Returns:

Place id: 102002584

1 Kingsford Smith Drive, Hawera.

The attached document demonstrates the 30 road and suburb search combinations, for which we return 1 Kingsford Smith Drive, Hawera.

Alternative Road and Alias Suburb Search Results [PDF, 65kB]

Exact Match Searches

The following table shows the elements used for exact match searches. The web service will perform a first level search if an exact match is not found it will perform a second level search.

Service Name

QueryPlaceRequest

Service Inputs

The following criteria can be used when requesting this service

Message Handling Specifications

Service Name

QueryPlaceResponse

Service Outputs

If valid search criteria was provided, the response will contain the Place id, any AddressKey details used in the request, and one of the following:

• A list of addresses which match or closely match the search criteria.
• Where the address has sub addresses, e.g. an MDU, the list will include the main and sub addresses.
• An exact address match.
• No matches (represented by an empty list being returned).

Multiple results will be limited to the first 200 closest matching records. They will be ordered using the following main steps:

1. Alphabetically by street name(ascending)

2. Numerically by:

• House_low
• House_high

Pre-conditions

• A valid Supplier location ID is specified as part of the request.

Post-conditions

Site information for the specified location is provided to the Customer.

• All ProductInstances pertaining to an ONT
• Existing ONT(s) including ONT identifiers
• Product id
• Family Type
• Offer Type
• A flag indicating whether the Customer making the request owns the Product Instance Configured ATA and / or UNI ports along with associated port numbers
• Pending in-flight orders against an ONT.

Refer to the Exception Codes table for error details.

The following rules apply to the information we will include in the Query Site Information response.

1. If the order has reached the state "Acknowledged" and the substate "Received" but has not been Completed or Cancelled, the order will be included in the response irrespective of who owns or controls the order.
2. If the order is a "Move" order, this query will not return the "Move From" value.
3. If the order is a "Transfer" order, this query will not return the "losing RSP" details.

Move Order Example

If an existing product is at location A and there is an in-flight order (Move Primary; from location A to location B), the query will return the following for:

• Location A, product and ONT details but not relinquishing order
• Location B, product, ONT details and order details.

Transfer Order Example

If an existing product is at location A and there is an in-flight order (Transfer Primary; from product 1 to product 2), the query will return the following:

• Location A, product 1, ONT details and any order details.

• The Exception Codes table lists the exceptions that may be returned by this service.

For a full list of exception codes and their meanings see B2B Exception Codes.

The following table describes the use cases that support this business process.

The following table describes the use case exceptions that support this business process.

Click on the scenario link to view the XML sample.

This section provides a list of the User Story References that we have met in this business process, as defined by the Ultra-Fast Broadband BSS / OSS Business Interaction Framework.

The document is available from:

Refer to the TCF website for documentation.

Request Success Criteria

Response Success Criteria