Duplicate transmittals due to multiple station codes being picked up by AOI

Comments

14 comments

  • Official comment
    Sher Kirk

    Good News and Bad News...

    The Station Code was added to the file name to resolve the issue under discussion here. However, now that we are testing Ticket Edits, it has become apparent that without the Ticket Status information in the file name, Edited ticket transmissions are being seen as duplicates and are being over-ridden. Example: If a cancel is transmitted, it is deleted in FTP because it appears to be a duplicate of the original ticket.

    This means: WE WILL HAVE TO ADD THE TICKET STATUS TO FILE NAMES AS WELL.

    I do not have a date that the change will be completed, as it was only requested this morning.I will let everyone know as soon as I have it. However, we recognize this change may result in more testing, and more configuration changes on the member side, with little time left to adjust. We do not want this change to result in another delay, but without the change, edits will be lost.

    I'll keep everyone posted as I get more information. Please check announcements for an update early next week.

    Comment actions Permalink
  • Natasha Hunter

    Thanks Julie, I will see what the team thinks and get back to you asap

    0
    Comment actions Permalink
  • Regan Brown

    I'll second this, as I consider it an overlook on the software developer's part.  There is no timestamp, no versioning, code indicator, or anything in the file names... so for anyone receiving locate notices for more than one member code, there will be overwrite issues.

    I don't know how it will help a member with multiple code notifications that happen on a ticket, but in our case [ as an LSP ] we have setup separate inbound emails (or FTP accounts) for each member we are responding for, so that we can receive more than one copy of the locate request.

    0
    Comment actions Permalink
  • Kurtis Poettcker

    If it helps at all, we are using a compound key of ticket number and station code. That keeps any duplicates separate in the system. In the XML file, they are tags StationCode and TicketNumber.

    0
    Comment actions Permalink
  • Regan Brown

    Hi Kurtis, I'm not sure how that would work in the case where a locate happens to be right on the border line of two codes?  If you receive your locate requests via. FTP, you would get two notifications: one for code UTILABC and one for UTILZXY.  When the files for those notifications are sent to your FTP folder, the second one sent would likely overwrite the first one, because the file names themselves are the exact same name. (ie. 2018450001.XML / 2018450001.GIF for both transmissions)

    0
    Comment actions Permalink
  • Kurtis Poettcker

    Sorry Regan, we are dealing with emails instead of ftp. We read and process the attachments which are named the same but attached to different messages. I've never seen the ftp setup, but I agree with you. If the files are being overwritten that is an oversight. 

    0
    Comment actions Permalink
  • Patterson, Julie

    has there been any update to the issues around duplicate transmittals due to multiple station codes being detected? those who receive their information via FTP utilizing the .XML and .GML. BC Hydro is running into the issue when the second copy of the ticket loads the  the .GML has a different format for the co-ordinates which is resulting in the ticket for the 2nd station code failing to load - this is my basic understanding of what the IT team has identified.

    0
    Comment actions Permalink
  • Patterson, Julie

    this issue has been resolved at BCH

    0
    Comment actions Permalink
  • Regan Brown

    I see that some of the files relative to a notification have been renamed to include the station code value; this is great, thank you, and should solve the file overwrite issue.

    However, it seems that they missed including the station code on the PDF filename and the GIF filename:


    Can they please make sure that all attachments for a locate notification follow the naming convention of ticketNumber_stationCode.extension ?

    0
    Comment actions Permalink
  • Natasha Hunter

    Hi Regan, they are working on having the same file name convention for the pdf but they won't be able to apply it to the GIF due to space issues

    0
    Comment actions Permalink
  • Regan Brown

    Hey Natasha,

    What is their reasoning for this? ... you mean spaces in the file name? or a problem with the length of the file name in total?  I can't understand how they're able to change the GML & XML files, but not the GIF.... the only thing different between the names is the file's extension.

    0
    Comment actions Permalink
  • Natasha Hunter

    this is the response I got:

     

    this file naming convention does NOT apply to GIF files because they are images and this means will take up much more storage space if we created an individual for every station code.

    0
    Comment actions Permalink
  • Patterson, Julie

    I see now that the station code is now applied to the .PDF but do not understand the reason for it. it is a copy of the ticket information at we receive .XML and .GML - all automated ticket processing is using either one of those.

    0
    Comment actions Permalink
  • Natasha Hunter

    Other members only use the pdf so it was applied to that as well

    0
    Comment actions Permalink

Please sign in to leave a comment.