Security Ticket Lookup with embedded numbers like S32 3PL 1AG not found

Options
gazza73
gazza73 Accredited Partner Posts: 803 Accredited Partner Accredited Partner
IN PP2016 (perhaps others), the NEW SECURITY -->  Ticket Lookup feature fails to find securities that have names containing NUMBERS.

There are a number of these.

Articles like this one, suggest that you can push on with transactions with the desired code regardless, but why does PP20xx  appear to restrict lookups to purely alphabetic letter codes like:  RKN  and TLS for instance.

see:

https://community.reckon.com/reckon/topics/how-to-carry-out-demergering-of-a-company

This observation arose from discussions on a number of PP20xx experiences with Leif Pederson and Gary Pope a couple of weeks ago, but I can't find any mention of there being some sort of 'anticipated/assumed' syntax structure to ASX stock codes being alphanumeric versus pure alphabetic.

This observations holds true, irrespective of recent issues of currency downloads  last NOV, r US share downloads in May, or recent repeat of AUS share downloads last Thursday.

So it remains a curiosity about what the syntax rules really are.  Perhaps it is some ASX convention that has crept in over the years - I'm unsure,  but it can throw you, when debugging the way to insert a NEW SECURITY (of AUS).




Gary

Comments

  • st_6872571
    st_6872571 Member Posts: 79
    edited June 2018
    Options
    I've noticed this before and just worked through it as the downloading of prices worked anyway (disregarding the current issue of the prices not downloading).
  • gazza73
    gazza73 Accredited Partner Posts: 803 Accredited Partner Accredited Partner
    edited December 2016
    Options
    Thanks Andrew.  

    Yes, I'm seeing that when researching all this, and looking at all the data that comes from sources like:  http://www.asxhistoricaldata.com/
    that all sorts of combinations of ASX codes these days.   Trying to help someone with a S32 issue, recently,prompted me to look outside the square a litle, to see if other codes were not looking up.  

    It was useful to discover this, because it was right at that time that the access (resolving)  to the right IPs was failing, and hard to separate the issue of 'lookups' versus getting the data AFTER a valid lookup. Seems now to be two separate issues.  From a software engineering viewpoint, trying to isolate an issue when two variables are not as expected, can really slow down the debugging process.

    Thanks for the heads up on this!

    Cheers

    Gary