The following table describes the Place element

The filter parameter elements allow you to apply search criteria against Product Characteristics.

The following table describes the FilterParameter elements.

FilterParameter - FAMILY_TYPE

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

FilterParameter - MARKET_SEGMENT_CODE

The following table describes the values provided by the market segment code element.

Filter Parameter - OFFER_TYPE

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

The following table describes the ProductOfferingInteractionItemDetail elements

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

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

The following table describes the values provided by the demand point type element

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

The following table describes the values provided by the Zone _Type element.

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

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

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

The following table describes the values provided by the Service_Lead_Type element

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

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

The following table describes the values provided by the LFC_Area element

The following table describes the values provided by the design required element

The following table describes the values provided by the build required element.

The following table describes the values provided by the MDU_Build_Status element

The availability date of the fibre network is returned by the ProductOfferingInteractionItemDetail - Availability_Date element where the is “Under Build”.

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

The following table describes the ProductOffering elements.

The following table describes the ProductCharacteristics elements

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

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

Service Name

QueryProductOfferAvailabilityRequest

Service Inputs

The following criteria must be used when requesting this service:

This service also provides the option of restricting the search criteria by Product Characteristic using one or more of the following the FilterParameter elements:

• Family_Type
• Market_Segment_Code
• Offer_Type.

The filters behave as follows:

• If multiple filters are selected, the query searches using AND behaviour
• If a filter is not selected a wild card search is implied.

Note: the filter option only restricts the results returned to you, it does not affect the underlying availability of products we offer you.

Message Handling Specifications

Service Name

QueryProductOfferAvailabilityResponse

Service Outputs

If a valid Place id was provided, the response will contain the Place id and the relevant fields from the following list:

• MDU_Class
• Fibre_Available
• Demand_Point_Type
• Right_Of_Way
• Zone _Type
• Availability_Status
• Central_Office
• Point_Of_Interconnect
• Install_Type
• Install_Distance
• Service_Lead_Type
• Consent_Required
• Consent_Status
• Coverage_Area
• LFC_Area
• Design_Required
• Build_Required
• MDU_Build_Status
• Availability_Date
• ProductOffering
  • id
  • name
  • ProductCharacteristics.

Message Handling Specifications

Pre-conditions

We have identified a variation in the cost of your order. The order state will be either In Progress or Held.

Post-Conditions

You respond to our quote within the required timeframe. If you accept, your order will continue through the fulfilment process, otherwise you may reject the quote and change or cancel your order.

The following use cases support this business process.

Click on the links to view the XML samples.

> Advise of Cost Variation

In this example, we need to send a technician to gather more information about the location. We advise you by sending:

• AmendOrderNotification: INVESTIGATION_REQUIRED
• AmendOrderNotification: SVM_EVENT to show that a change has been made to an appointment
• AmendOrderNotification: GENERATE_QUOTE to advise you that we are generating a quote for your order
• AmendOrderNotification: QUOTE_ACCEPTANCE to advise you of the quote details.

You respond using the Amend Order Request type:

• ANSWER - to APPROVE our quote.

We advise you that the order requires scheduling by sending:

• AmendOrderNotification: HELD_SCHEDULE_SCOPING.

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

Your end customer has chosen to transfer to another service provider, who has created a transfer order.

The transfer order has been completed.

Post-Conditions

You receive our notification to confirm that the end customer has transferred.

The following table describes the use cases 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.

Pre-conditions

You have created an order using BIC101: Customer Creates Order. The order can be in any state.

Post-Conditions

You receive our response containing the order details.

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 table describes the use cases that support this business process.

Click on the scenario link to view the XML sample.

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

Click on the scenario link to view the XML sample.

Use Case Exceptions

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

You have created an order using BIC101:CustomerCreatesOrderandtheappointmentdates fortheorder are in the future.

You have retrieved a list of site visit appointment times or RFS dates using BIC004: Query Appointment Availability.

Post-Conditions

You receive our response confirming that the appointment has been rescheduled.

Refer to the Exception Codes table for error details.

• Wewillnot changeanappointmentthatincursaddtional charges,unless youacceptany charges.
• We will validate RFS date changes against the lead times for the products in the 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 table describes the use cases that support this business process.

Click on the scenario link to view the XML sample.

> Reschedule Site Visit Appointment

In this example, you have and order that is in the state and substatus: In Progress/Network Design. We advise you that your order is ready to be progressed by sending:

• AmendOrderNotification: HELD_SCHEDULE_SCOPE to request that you schedule the site visits.

You use:

• QueryAppointmentAvailability to retrieve a list of available appointments
• AmendOrderRequest: APPOINTMENT to request an appointment for each appointment type, e.g. Scope, Install, CSE, etc.

Note: you may choose to reschedule the Install appointment first, due to the inter-appointment leadtime validation rules.

> Reschedule RFS date

In this example, your customer has requested that you reschedule the RFS date for their order.

You use:

• QueryAppointmentAvailabilitytoretrievealistofavailableappointments
• AmendOrderRequest:APPOINTMENTto reschedule theRFSdate.

> Use Case Exceptions

Use case exception examples showing AmendOrderRequest: APPOINTMENT exceptions are provided by:

• BIC105 - Customer Amends Order

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

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