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 new "CompletedDate" looked familiar. We checked our original order, and we sent:-
- RequiredByDate: 2016-05-13T11:38:14Z
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.
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.
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.)
ReplyDeletewithout 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.
ReplyDeleteMy understanding was that with no timezone data it is "local time". Do you have a reference for that?
DeleteAs 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?
ReplyDeleteNo, it has a message saying not to pinch it :-)
Delete