Friday, 27 May 2016

When is a KCI3 not a KCI3

Sorry this is technical, but it is just so BT that it is scary.

This is one of the final niggles with the renumber+export process, one we can work around somehow and is mostly just an annoyance.

When the renumber order completes, we want to send another order to BT to set incoming barring on the newly assigned number. This is a number that will not be used and already has outgoing barring or direct connect on it. This is a final tidy of the line to be a "naked DSL" line.

So, the renumber order completes, and BT send us what they call an KCI3, which is to tell us the order is completed. There are a lot of clues in the XML including:-
  • LineStatus: Completed
  • CompletedDate: 2016-05-27T11:43:00
  • Message: Order Completed
KCI stands for "Keep Customer Informed", by the way. We feel very well "informed" with this message that maybe, just maybe, the order is now "Completed". Wouldn't you?

But it turns out that no, the order is not in fact complete. When we send the next order we are told "A pre-existing open order has been found on this line"!

Apparently there is still a "robotic process" which can take 24 hours, and we will get a KCI3 when it finishes. To my surprise we do, indeed, get one!

Same clues in the message:-
  • LineStatus: Completed
  • CompletedDate: 2016-05-13T11:38:14
  • Message: Order Completed
The eagle eyed amongst you will have noticed a new "CompletedDate", one that is 14 days ago?!?!

The new "CompletedDate" looked familiar. We checked our original order, and we sent:-
  • RequiredByDate: 2016-05-13T11:38:14Z
This is actually when we created the order, as we want it ASAP, and BT adjust to the minimum lead time (10 working days). But wow! what a co-incidence! Except it is stranger still as the really eagle eyed will spot that 2016-05-13T11:38:14Z is not 2016-05-13T11:38:14. At this time of year they are an hour different. 11:38:14Z is in fact 12:38:14.

So it is almost like they plonked the UTC time of the CRD in to the CompletedDate as local (summer) time, in this robotic process, for an order that actually completed 14 days later.

I'd love to see that really special programming BT, and the comments that go with it. I wonder if, as a BT shareholder, I have any right to ask to take a look? I doubt it. Perhaps I should go to one of the shareholder meetings one day.

I'd also love to have a definitive way to tell the real KCI3 from the fake KCI3 so I can know when it is safe to send my next order.

The good news is that our "take over line and port number" system is apparently working right up to this point, and this is a minor last tidy up order which we can probably find a way around or do manually until BT fix it.

P.S. BT presumably use one of these big commercial XML B2B systems to do all of this. In A&A we use an XML library I knocked up. However, for us to do what BT are doing here would be really hard - we don't process date/times as text, they go in to a time_t right away, so we'd actually have to mess about taking 3600 off the date/time when in the summer to fill in the XML like this, it would be hard work.

5 comments:

  1. My guess: this means they can 'prove' that they completed everything when required! (For you, it means you can probably look for a date in the past of all previously received CompletedDates for that order and you know it's the real completed notification. But holy crap, how ridiculous.)

    ReplyDelete
  2. without either the terminating 'Z' or a timezone offset, the completed date is not valid according to the XML xs:datTime type. It is mandatory to specify one or the other.

    ReplyDelete
    Replies
    1. My understanding was that with no timezone data it is "local time". Do you have a reference for that?

      Delete
  3. As a bit of an aside, once you've got the line into a state of being "naked DSL", does it still have a dial tone on it to stop the pair being pinched?

    ReplyDelete
    Replies
    1. No, it has a message saying not to pinch it :-)

      Delete