Availability Check
\n\n[Query Address Search](#operation/queryAddressSearch)\n\nTo check the availability of a given location. The buyer should send a request containing either a postcode or a UPRN.\n\nThe seller is then going to respond with detailed information about the queried location. If the buyer queried using a UPRN, the response will contain only one location. On a postcode request, the seller might respond with multiple locations that match the given postcode.\n\nThe location details include among other fields: \n* UPRN\n* [RFS (Ready For Service) status](#rfsStatuses)\n* Cabinet Release Date\n* [LOC (Limit Of Construction) Codes](#locCodes)\n* Whether the order will be a preorder\n\nLOC reasons are flags which indicate known issues with this property. If there are multiple flags for a location they will be separated by spaces.\n\nAn order can be accepted for any RFS_1, RFS_2, RFS_3 or RFS_4 property. \n\nFurthermore, the seller can query products for a given location using the location’s UPRN.\n\n[Query Products for Location](#operation/queryProductsForLocation)\n\nThe seller will then respond with a list of one or multiple available products (if any) along with information about the need for an appointment (yes/no/maybe). The response will be one of the below listed types:\n\nAppointment
\n\nThe buyer can query appointment availability, reserve an appointment and include the reservation key in the order request.\n\nIf this is not done, the order will go into a waiting state and not progress, the buyer will need to reserve an appointment and then amend the order to include the appointment reservation key before the order can complete.\n\nQuery Availability
\n\n[Query Appointment Availability](#operation/queryAppointmentAvailability)\n\nThe buyer can check the appointment availability by providing a UPRN and a product to the seller. \n\nThen the seller may respond with an ‘Accepted’ response along with the available appointment slots.\n\nOr if for some reason an appointment is not possible to book, the seller will respond with a ‘Rejected’ response and with the reason why there is no appointment availability for the given data.\n\nReserve
\n\n[Reserve Appointment](#operation/reserveAppointment)\n\nIn order to reserve an appointment, the buyer should provide the UPRN, product and the appointment slot that they desire to the seller.\n\nThe seller can then reply with a successful response if such appointment can be booked along with the appointment details and a reservation key.\n\nOr with a rejected response if there was any issue with booking the appointment along with the reason why such thing is not possible.\n\nOrder Submission
\n\nThe order is created using an orderRequest message containing an `Pre Orders
\n\nCityFibre will accept pre orders for locations where the cabinet release date is in the future, where DR status is DR3 or below and RFS status is NOT_RFS_2 \n\nThe buyer can query appointments and reserve appointments beyond the cabinet release date. \n\nOrders placed as pre order will return a delay after KCI 2 \n\n| 210 | Pre-Order Awaiting Cabinet Release |\n|-------|------------------------------------|\n\nShould the cabinet release date slip, orders will be automatically reappointed and a new date provided post the new cabinet live date.\n\nRegrades
\nThe Buyer can move between the FFN products through an automated journey meaning there is no manual effort required as well as no down time for the end customer when moving between product.\n\nThe Buyer can specify an order is a Regrade using the newOrderType field, on an RFS_4 property. \n\nThe seller (CityFibre) will handle the cease of the existing service, KCI updates will be sent to the Buyer as well as an unsolicited cease request.\n\nRegrade orders can be cancelled using Cancel an Order. Orders can also be amended (Line profile or Requested Date) on a regrade order.\n\nProduct Change – No Access Change
\n\n| Product Regrading From | Product Regrading To |\n|---|---|\n| Residential FTTH Local Access 160Mpbs | Residential FTTH Local Access (1Gbps) |\n| Residential FTTH Local Access (1Gbps) | Residential FTTH Local Access 160Mpbs |\n| Residential FTTH National Access 160Mbps | Residential FTTH National Access (1Gbps) |\n| Residential FTTH National Access (1Gbps) | Residential FTTH National Access 160Mbps |\n\nProduct and Access Change
\n\n| Product Regrading From | Product Regrading To |\n|------------------------------------------|------------------------------------------|\n| Residential FTTH Local Access 160Mpbs | Residential FTTH National Access (1Gbps) |\n| Residential FTTH Local Access (1Gbps) | Residential FTTH National Access 160Mpbs |\n| Residential FTTH National Access 160Mbps | Residential FTTH Local Access (1Gbps) |\n| Residential FTTH National Access (1Gbps) | Residential FTTH Local Access 160Mbps |\n| Residential FTTH Local Access 160Mpbs | Residential FTTH National Access 160Mbps |\n| Residential FTTH Local Access (1Gbps) | Residential FTTH National Access (1Gbps) |\n| Residential FTTH National Access 160Mbps | Residential FTTH National Access 160Mbps |\n| Residential FTTH National Access (1Gbps) | Residential FTTH Local Access (1Gbps) |\n\n\n ![\"regrade_flow\"](\"/regrade_flow.png\")
\n
\n\n1. Buyer checks availability\n * Property RFS Status is returned from Sellers Availability Check\n * Property is not RFS_4 follow standard Order Journey detailed above\n * Property is RFS_4 and has a cease, follow LP WLTO\n * Property is RFS_4 and has no cease, follow regrade flow\n\n2. Buyer submits order.\n * On creating an order, the buyer will pass the UPRN of the existing service along with the relevant order details including the product and profile. In addition, for a regrade the buyer will need to send a requested date with the new order instead of an appointment date.\n * Orders placed on the current day will be processed at midnight of the following day.\n * Order delayed if:\n * Buyer does not include Requested Date - Expires in 30 days\n * Order rejected if:\n * Buyer order reference is missing or duplicate\n * Buyer order reference exceeds the maximum length (36 characters)\n * UPRN is missing or not numeric\n * Product is the same as active service\n * Product is non-FTTH product\n * Product not permitted for this account or location\n * Gross errors in service configuration (invalid attributes or values)\n\n3. KCI.1 Order Acknowledged issued to Buyer\n\n4. KCI.2 Order Committed issued to Buyer\n\n5. Seller sends unsolicited cease to buyer\n\n6. Amendments are checked and either everything is accepted or rejected\n * Reject any amendment to product or UPRN\n * Accept amendments to site info\n * Accept amendments to Requested Date\n * Accept amendments to service configuration (e.g. ENNI, SVLAN/CVLAN, line profile, PPPoE Agent-Remote-Id): check for gross errors\n * Cancellation of auxiliary services: OK\n\n7. Cease is completed at midnight of the requested date. (Usually this happens at 00:00 and is complete by 2am).\n\n8. Provision ONT\n\n9. Seller sends KCI.3\n\n\nAmending
\n\nThe buyer may request to amend an order if it is still in early stages.\n\n[Amend Order](#operation/amendOrder)\n\nThe seller can then accept or reject the amendment of the order\n\nFurthermore, notifyOfOrderStatus requests will reflect the amendment request\n\nCancellation
\n\nIt is possible for the buyer to request that an order be cancelled before it is completed. Orders may also be cancelled by the seller if it is no longer possible to progress an order.\n\nBuyer Cancellation
\n\nThe buyer may request to cancel the order if it is still in early stages.\n\n[Cancel Order](#operation/cancelOrder)\n\nThe seller will then reply with the status of the cancellation\n\nThis will also reflect the notifyOfOrderStatus requests\n\nSeller Cancellation
\n\nThe seller may cancel the order if it is no longer possible to proceed. The buyer will retrieve a notifyOfOrderStatus.\n\n## Modify\n\nOnce a service has gone live, changing the line profile or requesting a change of ENNI/VLAN is done by means of an orderRequest `Modify ENNI
\n\nWhen an order is placed, the seller defines an ENNI for the order and provides the buyer with a list of available ENNIs via the notifyOfOrderStatus request.\n\nThen the buyer can modify the ENNI by sending back one of the codes returned in the `Modify Line Profile
\n\nIn addition to changing the line profile, sellers also have the ability to modify the line profile of their active service. This can be achieved through the use of the orderRequest call. The process of modifying a line profile follows a similar flow to that of a new install order.\n\nFor the Buyer to initiate the modification of a line profile they can send the line profile in `\n ![\"ftth_installation_process\"](\"/ftth_installation_process.png\")
\n
\n\n1. Order contains: Product; URPN; Site info (contact info, access restrictions, hazards); appointment reservation key; optional service configuration; optional auxiliary services\n\n2. Reject order if:\n * Buyer order reference is missing or duplicate\n * Buyer order reference exceeds the maximum length (36 characters)\n * UPRN is missing or not numeric\n * Product is non-FTTH product\n * Product not permitted for this account or location\n * Auxiliary services not recognised, or not permitted with this product, or not permitted for this account\n * Gross errors in service configuration (invalid attributes or values)\n * Property type not FTTH\n * Property RFS_Status_GIS__c is not RFS_1 (or NOT_RFS_2 for preorder) - if there is an appointment this will have been checked\n * Appointment reservation key (if provided) is for wrong UPRN or wrong product or has expired\n\n3. If the order contains an appointment key: check it is for the correct UPRN, reserve it and add service ID to it. If reservation key has expired, scrub the appointment from the order\n * If the property requires an Extended Install (LOC flags \"WSD\" or \"SUR\") then the KCI2 notification will include delay code 203 Survey underway, and a case is opened.\n\n4. Check cabinet release date. If there is an appointment, and the CRD is later than the appointment, then cancel the appointment and notify of slip. If the cabinet is not yet ready for service, KCI2 includes delay code 210 \"Waiting cabinet ready\" and go back to Wait Cabinet Ready.\n\n5. Check amendments and either accept everything or reject\n * Reject any amendment to product or UPRN - All amendments to site info are acceptable\n * Amendments to appointment: check new appointment is for correct UPRN, if so accept it (Note: does XML allow removal of appointment without creation of new one?)\n * Amendments to service configuration (e.g. ENNI, SVLAN/CVLAN, line profile, PPPoE Agent-Remote-Id): check for gross errors\n * Amendments to auxiliary services: check new auxiliary services are valid for this product/account\n * Cancellation of auxiliary services: OK\n\n6. \n a. Buyer cancel received: set Service state to Cancelled. Cancel the appointment reservation (if any). Terminate.\n\n b. Seller cancel: if the property is no longer serviceable, e.g. has gone to NOT_RFS_3. (Or should this raise a case instead?)\n\n7. Perform network provisioning for selected ENNI/SVLAN/CVLAN. (If it fails we could raise a case, or just go into exception for now)\n\n8. If the order does not have an appointment, send notify \"delayed - waiting appointment\" and go to Waiting appointment, otherwise proceed to issue job pack. If appointment date has passed, mark 'failed' and wait for reappointment\n\n9. Wait for buyer to amend the order to add a new appointment or cancel. Timeout if no appointment received within 30 days.\n\n10. Process amendments:\n * Reject any amendment to product or UPRN\n * All amendments to site info are acceptable\n * Amendments to appointment: check new appointment is for correct UPRN, if so accept it\n * Amendments to service configuration: check for gross errors.\n * Amendments to auxiliary services: check new auxiliary services are valid for this product/account\n * Cancellation of auxiliary services: OK\n\n11. Issue the job pack to the installation partner\n\n12. Waiting for response from installation partner. (We may also receive interim updates/notes during this time; ) 3 possible flows\n * If response is \"success\" go to Completed (WF0)\n * Depending on warning code go back to waiting for new appointment\n * Depending on warning code then open case, put in delay\n * If cancellation is received, then cancel the job with installation partner\n\n13. Process amendments\n * Reject any amendment to product or UPRN\n * Amendments to site info: relay to installation partner (i.e. update installation job)\n * If change to appointment: cancel the job with installation partner, return to waiting for appointment (Note: does XML allow removal of appointment without creation of new one?)\n * Amendments/cancellations to auxiliary services: either reject, or update the job pack with installation partner\n\n14. Update network provisioning (ENNI/SVAN/CVLAN/PPPoE/Line Profile) while waiting for installation\n\n15. Perform ONT provisioning while waiting for installation\n\n16. Waiting for case. Case closed successfully, go to waiting for new appointment; case cancelled, cancel order. Or we can receive cancel from buyer. \n\n17. Notify completion; include warning if result no CPE or speedcheck failed.\n\n## Gaining Provider Led Switches (GPLS)\n\nThis process is for when an end customer wants to move from one Buyer (Losing Provider) to another Buyer (Gaining Provider) on the Sellers network. In this scenario the end customer has contacted the Gaining Provider first to initiate a Gaining Provider Led Switch process.\n\nAs a key principle for Gaining Provider Led Switch Orders, any amendments to install and cease dates will be aligned to ensure a smooth transition for the end customer.\n\n\nPlacing Gaining Provider Led Switch Orders
\n\nWhen placing an order on a property with an RFS Status of RFS_4, the Buyer must specify whether this is a Gaining Provider Led Switch Order, using newOrderType field with a value of “Switch”, this will ensure the correct journey is applied to the order, with the subsequent lead times. This does not apply for properties that have a RFS Status of RFS_1, RFS_2 or RFS_3.\n\nIf the newOrderType is not specified on an RFS_4 order, and the Buyer owns the existing service at the property, then the order will be treated as a Regrade order.\n\nGaining Provider Led Switch orders will default to a non-appointed provision, unless Install Options requiring an engineer installation are requested, or an ONT swap is required.\n\nLead times (Customer Requested Dates and Install Appointments)
\n\nGaining Provider Led Switch orders have a next business day lead time that covers the NOT+ (Notice of Termination Plus) required lead time for requested date, or two business days for appointment date if managed install.\n\nCustomer Requested Dates should be sent with a Date only, if a specific time is also sent, this will be aligned to midnight of the same day.\n\nGaining Provider Led Switch Order Process
\n\n\n ![\"WLTO](\"/Gaining)
\n
\n\n\n1. End Customer / Gaining Provider checks availability of product(s)\n\n * The Gaining Provider can query products for a given location using the location’s UPRN.\n\n * The seller will then respond with a list of the available products (if any) along with information about the need for an appointment (yes/no/maybe).\n\n2. Customer Requests Appointment Date if Managed Install is Required\n\n * The Gaining Provider can check the appointment availability by providing a UPRN and a product to the seller.\n\n * Then the seller may respond with an \"Accepted\" response along with the available appointment slots. If an appointment is not possible to book, the seller will respond with a \"Rejected\" response and with the reason why there is no appointment availability for the given data.\n\n3. Customer Reserves Desired Appointment\n\n * To reserve an appointment, the Gaining Provider should provide the UPRN, product and the appointment slot that they desire to the seller.\n\n * The seller will reply with a successful response if such appointment can be booked along with the appointment details and a reservation key. Or with a rejected response if there was any issue with booking the appointment along with the reason for the rejection.\n\n4. Gaining Provider submits the Order Request\n\n * The order must be submitted with a newOrderType of \"Switch\" and either an Appointment Reservation Key for a Managed Install or a Customer Requested Date. Please ensure the correct lead times are applied, to ensure the order is not rejected.\n\n5. Seller sends KCI Order \"Pending\" to Gaining Provider\n\n6. Seller validates Order\n\n * If the order request cannot be fulfilled the Seller will send a KCI \"Rejected\"\n\n * Seller validates Reserved Appointment if one is provided\n\n7. Plan & Manage Switch Request\n\n * Seller creates \"New Install Order\" for Gaining Provider\n\n * Seller creates the \"Cease Order\" on behalf of Losing Provider if there is no in-flight Cease Order.\n\n * Seller links the Cease Order from the Losing Provider and the New Install Order from the Gaining Provider\n\n * Where Seller identifies an In-flight Cease Order it will be aligned to New Install Order Requested Date\n\n8. Seller creates Cease Order on behalf of Losing Provider\n\n * Seller sends KCI \"Unsolicited Cease Request\" to Losing Provider\n\n * Seller sends KCI Cease \"Pending\" to Losing Provider\n\n * Seller sends KCI1 Cease \"Acknowledged\" to Losing Provider\n\n * Seller sends KCI2 Cease \"Committed\" to Losing Provider\n\n9. Seller sends KCI1 Order \"Acknowledged\" to Gaining Provider\n\n10. Seller sends KCI2 Order \"Committed\" to Gaining Provider\n\n11. Wait for \"Switch\" Date\n\n * This will either be the Customer Requested Date or the Appointment Date for a Managed Install Order\n\n12. Cease Losing Provider Service\n\n13. Send KCI3 Cease \"Completed\" to Losing Provider\n\n14. Provision Gaining Provider Service\n\n15. If managed Install, wait for confirmation of installation for Managed Install journey\n\n16. Send KCI3 Order \"Completed” to Gaining Provider\n\nCease of Existing Services
\n\nThe Seller will handle the cease of the existing service, on behalf of the Losing Provider, for Switch orders. KCI updates will be sent to both Gaining Provider for the New Install Order and the Losing Provider for the Unsolicited Cease Order. Where a Cease Order is already in flight, the requested date will be aligned to the Gaining Provider New Install Order requested date.\n\nWhen an Unsolicited Cease is sent to a Losing Provider, it will state that it is the result of a Switch.\n\nIf the Gaining Provider cancels the Switch Order, then the Unsolicited Cease will be automatically cancelled. Where there was already a Cease Order in flight this will not be cancelled.\n\nAmendments to Gaining Provider Led Switch Orders
\n\nAmendments to Customer Requested Date, Appointment Date and Service Configuration can be submitted by the Gaining Provider and will be accepted and actioned up to the PONR of the business day before the install.\n\nAs a key principle for Gaining Provider Led Switches, any amendments to install and cease dates will be aligned to ensure a smooth transition for the end customer.\n\n1. Gaining Provider submits Amend Order Request\n2. Seller Responds with Amendment Pending\n3. Validate Amend Request\n4. If the amend request cannot be fulfilled the Seller will send KCI \"Amendment Rejected\" to Gaining Provider\n5. Seller Processes the Amend Request\n6. Seller sends KCI \"Amendment Accepted\" to Gaining Provider\n7. If the Switch Date has been amended the Seller will send KCI \"Amendment Accepted\" to Losing Provider with the new date\n\n## Working Line Takeovers (WLTO)\n\nThis process covers when an end customer is moving home, and the property they are moving into already has an active service provisioned. In this scenario the end customer has contacted the Gaining Provider to request a new service.\n\nPlacing a Working Line Takeover Order
\n\nWhen placing an order on an RFS_4 property, the Buyer must specify whether this is a WLTO using newOrderType field, this will ensure the correct journey is applied to the order, with the subsequent lead times. This does not apply for RFS_1, RFS_2 or RFS_3.\n\nIf the newOrderType is not specified on an RFS_4 order, and the Buyer owns the existing service at the property, then it will be assumed as a Regrade order.\n\nWorking Line Takeover orders will default to a non-appointed provision, unless Install Options requiring an engineer installation are requested, or an ONT swap is required.\n\nLead times (Customer Requested Dates and Install Appointments)
\n\nWorking Line Takeover orders have a 10 business day lead time that covers the NOT+ (Notice of Termination Plus) required lead time for requested date, or appointment date if managed install. \n\nWorking Line Takeover orders where the Gaining Provider is also the Losing provider, and owns the existing service = 2 days\n\nCustomer Requested Dates should be sent with a Date only, if a specific time is also sent, this will be aligned to midnight of the same day.\n\nWLTO Order Process
\n\n\n ![\"WLTO](\"/Working)
\n
\n\n1. End Customer / Gaining Provider checks availability of product(s)\n\n * The Gaining Provider can query products for a given location using the location’s UPRN.\n\n * The seller will then respond with a list of the available products (if any) along with information about the need for an appointment (yes/no/maybe).\n\n2. Customer Requests Appointment Date if Managed Install is Required\n\n * The Gaining Provider can check the appointment availability by providing a UPRN and a product to the seller.\n\n * Then the seller may respond with an \"Accepted\" response along with the available appointment slots. If an appointment is not possible to book, the seller will respond with a \"Rejected\" response and with the reason why there is no appointment availability for the given data.\n\n3. Customer Reserves Desired Appointment\n\n * To reserve an appointment, the Gaining Provider should provide the UPRN, product and the appointment slot that they desire to the seller.\n\n * The seller will reply with a successful response if such appointment can be booked along with the appointment details and a reservation key. Or with a rejected response if there was any issue with booking the appointment along with the reason for the rejection.\n\n4. Gaining Provider submits the Order Request\n\n * The order will be submitted with a newOrderType of \"WLTO\" and either an Appointment Reservation Key for a Managed Install or a Customer Requested Date. Please ensure the correct lead times are applied, to ensure the order is not rejected.\n\n5. Send KCI Order \"Pending\" to Gaining Provider\n\n6. Validate Order\n\n * If the order request cannot be fulfilled the Seller will send a KCI \"Rejected\"\n\n * Seller validates Reserved Appointment if one is provided\n\n7. Plan & Manage Switch Request\n\n * Seller creates \"WLTO Order\" for Gaining Provider\n\n * Seller creates the \"Cease Order\" on behalf of Losing Provider if there is no in-flight Cease Order.\n\n * Seller links the Cease Order from the Losing Provider and the WLTO Order from the Gaining Provider\n\n * Where Seller identifies an In-flight Cease Order it will be aligned to WLTO Order Requested Date\n\n8. Seller creates Cease Order on behalf of Losing Provider\n\n * Seller sends KCI \"Unsolicited Cease Request\" to Losing Provider\n\n * Seller sends KCI Cease \"Pending\" to Losing Provider\n\n * Seller sends KCI1 Cease \"Acknowledged\" to Losing Provider\n\n * Seller sends KCI2 Cease \"Committed\" to Losing Provider\n\n9. Seller sends KCI1 Order \"Acknowledged\" to Gaining Provider\n\n10. Seller sends KCI2 Order \"Committed\" to Gaining Provider\n\n11. Wait for \"Cease Order\" Date\n\n * This will either be the Customer Requested Date or the Appointment for the managed install date of the “WLTO Order”, or the Requested Date of the Cease Order where the Losing Provider has taken control.\n\n12. Cease Losing Provider Service\n\n13. Send KCI3 “Cease Order” Complete to the Losing Provider\n\n14. Provision Gaining Provider Service\n\n15. If managed Install, wait for confirmation of installation for Managed Install journey\n\n16. Send KCI3 Order \"Completed” to Gaining Provide\n\nCease of Existing Services
\n\nThe Seller will handle the cease of the existing service, on behalf of the Losing Provider, for WLTO Orders. KCI updates will be sent to both Gaining Provider for the WLTO Order and the Losing Provider for the Unsolicited Cease Order. Where a Cease Order is already in flight, this will be linked to the WLTO Order, and where the WLTO Order Requested Date is before the Cease Order Requested Date, the WLTO Requested Date will be aligned to the Cease Order Requested Date.\n\nWhen an [Unsolicited Cease](#unsolicited-cease) is sent to a Losing Provider, it will state that this is the result of a WLTO Order.\n\nWhere the Gaining Provider cancels the WLTO Order, then the Unsolicited Cease Order will be automatically cancelled. Where there was already a Cease Order in flight this will not be cancelled.\n\nUnsolicited Cease
\n\nFor an Unsolicited Cease related to a Working Line Takeover Order, a Cancel Other code can be used by the Losing Provider\n\n‘9190 SP REQUESTED CANCEL OTHER - END USER NOT MOVING’.\n\nAmendments to Working Line Takeovers Orders
\n\nAmendments to Customer Requested Date, Appointment Date and Service Configuration can be submitted by the Gaining Provider and will be actioned up to the PONR of the business day before the install.\n\nAs a key principle for Working Line Takeover Orders, where any amendments to install and cease dates are requested, the Install date must be on or after the Cease Date. A Losing Provider can take control of the Cease Date by amending the requested date of the Unsolicited Cease Order. Once the Losing Provider has taken control of the WLTO Order, the Gaining provider can still amend the Service Configuration and the Requested Date. Only amendments to Requested Date where the date requested is after the Losing Providers Requested Cease Date will be accepted.\n\nAmendments to Working Line Takeovers Orders by the Gaining Provider Process
\n\n\n ![\"Amendments](\"/WLTO)
\n
\n\nN.B. This process only represents changes to the Requested Date or Appointment Date where the WLTO Order has a Managed Install. Service Configuration related Amendments will be accepted up to the PONR.\n\n1. Gaining Provider submits Amend Order Request\n\n2. Validate Amend Request\n\n * If the amend request cannot be fulfilled the Seller will send KCI \"Amendment Rejected\" to Gaining Provider\n\n3. Seller Responds with “Amend Requested Date / Amend Appointment Date” Pending\n\n4. Where the Losing Provider “Has Control” of the WLTO Order Date\n\n * If the Amended Requested Date is after the Requested Cease Date the Amended Requested Date / Appointment Date is Accepted “Amend Requested Date / Appointment Date Accepted”\n\n * If the Amended Requested Date is before the Requested Cease Date the Amended Requested Date is Rejected “Amend Requested Date Rejected”\n\n5. If the Losing Provider does not “Have Control”\n\n * Amend the Requested Date of the Cease Order to the Gaining Provider Amended Requested Date\n\n * Seller notifies the Losing Provider Requested Date Amended “GCP Amended Requested Date”\n\n * Seller notifies the Gaining Provider “Amend Requested Date / Appointment Date Accepted”\n\n6. If Managed Install and amended Appointment Date is after the PONR, Amend Request is rejected “Amend Appointment Date Rejected”\n\nAmendments to Working Line Takeovers Orders by the Losing Provider Process
\n\n\n \n
\n\n1. Losing Provider submits Amend Cease Order Request\n\n2. Seller validates the Amend Request\n\n * If the amend request cannot be fulfilled the Seller will send KCI \"Amendment Rejected\" to Losing Provider\n\n3. Seller Responds with “Amend Requested Date” Pending\n\n4. If the Amended Requested Date is before the WLTO Requested Date the Amended Requested Date is Accepted “Amend Requested Date / Appointment Date Accepted”\n\n5. Where the Amended Requested Date is after the Requested WLTO Date\n\n * If the WLTO Order is not Managed Install, the Amended Requested Date is Accepted “LCP Amended Requested Date”\n\n * If the WLTO Order is Managed Install and after PONR, the Amended Requested Date is Rejected “Amend Requested Date Rejected” to Losing Provider\n\n * If the WLTO Order is Managed Install and after PONR, delay WLTO Order and send Delay Reappoint notification “LCP Amended Requested Date” to Gaining Provider\n\n * Manage Reappointment with Gaining Provider\n\n6. Update Losing Provider Amended Requested Date\n\n7. Notify Amend Requested Date Accepted\n\n8. Losing Provider now “Has Control” for the WLTO Order Date\n\n## One Touch Switch\nIn support of the One Touch Switch launch in October, the seller will make the below changes.\n\n* Removal of 10 day lead time on non-appointed switches\n\n* Ability for losing provider to cancel an unsolicited switch on a cease\n\nAdditional information about the ONT installed at the property will be returned in [QueryInstallation](#operation/queryInstallationDetails), this will include the ONT Identifier (serial number) and the ONT port.\n\n## Remote Activation\n\nRFS_3 properties are eligible for non-appointed remote activations. If the Buyer does not wish to include any auxiliary products (i.e. CPE Install), then a non-appointed activation can be ordered, for next working day onwards.\n\nIf the RFS_3 property requires an ONT Swap or CPE Install, then this will require an appointment, and the standard lead times will be applied. \n\n## ONT Swaps\n\nIf the product being ordered requires a higher bandwidth than the current ONT supports, then an engineer appointment may be required to change the ONT installed at the property.\n\nWhen querying for products at a property with an installed ONT(RFS_3 or RFS_4) we will perform a check of the ONT type that is currently installed against the products that are available to check if the products that are being returned will support the installed ONT type.\n\nYou can view whether an appointment is required by performing a [Query Products for Location](#operation/queryProductsForLocation) request. In the response you will be able to see whether an appointmentRequired is yes/maybe/no.\n\n* If the installed ONT type does not support the product you are querying then an appointment will be required and you will receive yes in the query products for location response.\n* If the installed ONT type does support the product you are querying then an appointment will not be required and you will receive maybe in the query products for location response.\n\nIf an order is placed against a property with an installed ONT and the product does not support the installed ONT type then the order will require an appointment otherwise it will be rejected.\n\n## Auto Compensation\n