Category: Axys


grayscale photo of computer laptop near white notebook and ceramic mug on table

In previous articles, I have written about the ability to take an Advent Report Writer report and make changes to it in the underlying REPLANG code. Though the program is actually called Report Writer Pro, I won’t be referring to it by that name since the “Pro” part seems a bit much.

In this article, I will take you through the basics of this process and also share some code I wrote recently to deal with a troublesome Report Writer exception. Please note, there are many modifications that can easily be done within the Report Writer interface, but this article is not about that.

You should have a good reason for attempting to modify Report Writer reports outside of the app.  For me, two fundamental issues drive this decision.  The modification either cannot be handled due to limitations of Report Writer or it is simply much more expedient to hack and slash REPLANG than it is to work within the confines of the Report Writer environment.

Okay.  Let’s assume that like me you think you have a good reason to do this. There are a few things you should know before you modify a report created by Report Writer outside of Report Writer. First of all, any report created in the Report Writer has a RPW extension, but the underlying format is REPLANG.  In most cases, any report with a REP extension was not created by Report Writer – except of course for reports like the ones we are talking about creating.

Second, your report containing code not created by Report Writer can no longer be modified by Report Writer in the future, so make a backup of the RPW file before any changes, and save the file you modify as a REP file.  That way if you need to make a change to the report later – that Report Writer would be better suited to make – you can.  In that scenario, once you have updated the report you can reapply your manual updates to the newer RPW file and then save it as REP report again.

The reason that your new REP report cannot be modified in Report Writer is not only due to the fact that the extension isn’t an RPW, but more specifically that a checksum created by Report Writer when it was last modified by the software will no longer match.  The logic behind why this is done is understandable.  Report Writer only works with certain predefined templates and does some really impressive things, but it is not designed to interpret code changes that were not created by Report Writer.

Lastly, if you haven’t waded into REPLANG code created by Report Writer it will take some getting used to.  By nature of the fact that RPW files are created to be extensible the REPLANG code is more abstract. In other words, the code generated by Report Writer appears far less direct with regard to its purpose than code that an individual might write for a singular and well-defined purpose.  If you are not familiar with REPLANG coding, I wouldn’t recommend trying to modify REPLANG reports created by Report Writer.

Some examples of the types of things I find myself doing when I modify Report Writer reports from REPLANG directly follow:

  1. I need to do a calculation that I find difficult or impossible within the Report Writer interface.  If you have any experience using Report Writer to create user-defined formulas, this really isn’t that hard to imagine.
  2. Adding a piece of data that isn’t readily available from the Report Writer.
  3. For expediency sake, I know how to do something in REPLANG in a minute, but doing it in Report Writer might take an unreasonably long time.

Dealing with Report Writer Exceptions

Recently, while working on some reporting extracts for a client, I attempted to take what appeared to be a relatively simple Report Writer report and change the format to a CSV file.  Doing so is a basic function of the product and only requires a few mouse clicks.  It is something I tend to do on a regular basis and it usually works well.  However, this time Report Writer went haywire.

Instead of taking the twenty-two thousand line report and making another similar sized report as I expected, it created a ridiculously long report (hundreds of thousands of lines of code) that Report Writer could not test or run.  Even a twenty-two thousand line report sounds big and it is.  By comparison, the longest standard report(persave.rep), which updates performance files,  is under four thousand lines. Most of the standard reports are significantly less than a thousand lines of code.

It is not the first time I have seen this problem, but this time I decided to do something more proactive to deal with this issue in the future.   The report that I was attempting to change is fairly simple.  There are no summary records.  So, the output is just a table of detail records and that helps to simplify the coding requirements of what I want to do.  To deal with this issue in the past, I have simply renamed the RPW to a REP file and modified 10 to 20 lines specific to placing the output on the screen and reformatted them to be CSV friendly.

There are alternative ways to do this. You could create the Excel file output manually by exporting the report output to Excel once the report has been generated and saving it, or by writing a script to generate an Excel file, but in this particular instance I preferred to create a more flexible CSV report.  We could also do a standard search and replace function within a text editor, but having seen this issue more than a few times I wanted to create a utility I could use going forward.

So I quickly wrote the code in the section below to change the original report, which was sending output to the report view screen, to send all the output directly to a file.  I find it very easy to code things like this using Visual Basic (VB) or Visual Basic for Applications (VBA). Since most users also have access to VBA via Microsoft Office, it is a programming option you can find and use on almost any PC. As such, I frequently use VBA when I am doing spontaneous and simple coding tasks or projects that don’t require a more complex development environment. I am not a huge fan of verbose comments, but I thought they might be useful here.

Sub MAIN()

' This routine takes a REPORT WRITER report which sends output to the
' screen and creates a report that sends output to a file. The routine
' was created to address an exception where the normal function to make
' a change in a RPW file created an obscenely large Report Writer file
' that couldn't be tested or run.

' written in VBA by Kevin Shea (aka AdventGuru) & published 06/26/2019

' Disclaimer: This routine works fine for the specific instance it was
' created for, but could need additional modifications for different
' circumstances.

'Initialize variables
Dim InputFileHandler As Integer
Dim OutputFileHandler As Integer
Dim Filename$
Dim Record$
Dim IgnoreRecords As Boolean
Dim ReportLocation$
Dim OutputFolder$

ReportLocation$ = "f:\axys3\rep\"
OutputFolder$ = "f:\axys3\exp\"

' Axys users will probably need to change the two locations above to
' match their actual folder locations of Axys.

' APX users, depending on the APX server name, the preceding statements
' might need to change to ReportLocation$="\\apxappserver\APX$\rep\"
' and OutputFolder$ = \\apxappserver\APX$\exp\"

InputFileHandler = FreeFile 'fetch an unused file handler
IgnoreRecords = False
Filename$ = InputBox("Report file name?")

Open ReportLocation$ + Filename$ For Input As #InputFileHandler

OutputFileHandler = FreeFile 'fetch an unused file handler

Open ReportLocation$ + Left$(Filename$, Len(Filename$) - 4) + ".out" For Output As #OutputFileHandler

Do While Not EOF(InputFileHandler)

  Line Input #InputFileHandler, Record$ 'read a record from the report

  If Left$(Record$, 4) = "head" Then IgnoreRecords = Not (IgnoreRecords)

  ' REPLANG marks the beginning of the header definition with the
  ' statement "head" and ends the header definition with the same
  ' statement. We don't want to write the header to our output file,
  ' so we are going to ignore all of the code between the two head
  ' lines of code.

  If IgnoreRecords = False Then

    If InStr(Record$, ".") > 0 Then

      ' The "." in REPLANG is the syntax usually associated with
      ' sending output to the screen most, but not all, "." lines
      ' end with "\n", which marks the end of the output line. By
      ' making the "." a requirement of this logic we will only
      ' process REPLANG statements that create output.

      For i = 1 To Len(Record$)

        'ignore any code lines that are less than two characters
        If i > 1 Then

          ' We may not need to be this specific, but I want to err
          ' on the side of caution. We will only process lines that
          ' start with a period. This prevents us from processing
          ' other lines that may have periods in the remarks or other
          ' areas of the REPLANG report.

          If Trim$(Left$(Record$, i - 1)) = "" And Mid$(Record$, i, 1) = "." Then

            'Somewhat self-explantory...
            Record$ = Replace(Record$, "~", ",")
            Record$ = Replace(Record$, "#,", ",#")
            Record$ = Replace(Record$, " ,", ",")
            Record$ = Replace(Record$, "?", "")

            Print #OutputFileHandler, Record$ 'write the record we modified

            Exit For
            'Exit logic early if we are done processing the record.

          End If

        End If

      Next i

    Else

      ' This bit of code inserts the code that writes all records
      ' that weren't modified, but contains some minor code insertion
      ' (outfile) make the output go to a file. The proper place to
      ' insert the outfile statement is before any accounts are
      ' processed, which is immediately before the load cli statement.
      ' Writing to a file requires that we close (fclose) the file
      ' or the result will not get written properly. The right place
      ' to insert the fclose statement is when all of the processing
      ' has been completed, which is immediately after the next cli
      ' statement.

      If Left$(record, 8) = "load cli" Then Print #OutputFileHandler, "outfile "+OutputFolder$+"outfile.csv n"
      Print #OutputFileHandler, Record$
      If record = "next cli" Then Print #OutputFileHandler, "fclose"
 
    End If

  End If

Loop

Close #OutputFileHandler
Close #InputFileHandler

End Sub

As to why Report Writer erroneously attempts and fails to create such a long report, it likely has something to do with user-defined calculations and parsing of strings. However, for the purpose of this article we are not trying to fix that issue. It may just be a limitation of the Report Writer.


About the Author: Kevin Shea is the Founder and Principal Kevin Shea Impact 2010Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide. For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

Bull_20140121-winter-SamiraBouaou-2329-676x450A relatively predictable bull market doesn’t pose significant challenges to investment managers short of making the best possible investments.  Assuming one has embraced a decent platform and mission-critical systems are in order, investment managers don’t need to think too hard about reporting or much else during a boom.  Investment management firms are money-making machines, and in a bull market, most tend to do that well.

When markets and returns are kind, client reporting doesn’t get much scrutiny.  This is a point exemplified by the fact that during these times some clients don’t even bother to open up their statements.  In more challenging times, client reporting gets a level of attention that has the potential to be bad for business.  And yes, I know – even during those times – there are still clients that don’t look at their statements.

Over the years, report designers like myself have created a number of dazzling client reports that can look … well … not so dazzling when returns approach zero, or worse, become negative.  In the design process, most of the time is spent looking at accounts that paint a pretty picture.  Those are the accounts that get used in sample reports, so it shouldn’t be surprising when investment managers see how ugly an account with poor performance can appear.

A survivor bias naturally minimizes any attention these accounts might receive, but in the meantime, those reporting on accounts with sub-zero performance need to make decisions like “Should we show the floor of the graph when the account is negative?” and other presentation details that most investors would rather not contemplate.

No one I have worked with says, “We want our bad performance to look good.”  They just don’t want it to look any worse than it actually is.  Though some of the changes we make to reports are purely cosmetic, most of the report enhancements we implement are designed with one thing in mind: presenting performance fairly.

Some specific examples of modifications we have made include:

  1. creating a truly representative custom index for each account
  2. producing comparative index returns and risk
  3. isolating managed asset class and sector returns to produce select time period performance
  4. providing comprehensive performance summary reports that help the clients of investment firms put occasional anomalies in perspective

 

Flashback to Q1 2016 

Coming off a relatively flat 2015, traditional investors were likely dismayed to see double-digit negative returns just two weeks into 2016.  Since many of these same investors were drafting their investment commentaries explaining the past quarter, calendar year 2015, and the outlook for 2016 (ahem), these market conditions likely spurred some very focused thought about existing client reports and how they might look next quarter based on January’s performance to date.

2016-Q1

As a result of this come-to-Jesus moment, my phone was ringing more than usual.  In January of 2016, I fielded a number of calls from firms in a few different countries and across the US.  In almost every case, decision-makers were ready to pull the trigger.  They wanted new reports and they wanted them done quickly.

Investors planning on replacing their platform with a higher-cost alternative that ultimately might address the shortcomings of existing client reports may have reconsidered those decisions for the immediate future due to concerns over time to implement, predictability and increased costs.  I have made the point in the past and I’ll make it again here: it is typically much easier to replace your reports than your portfolio accounting system.

In simple terms, it generally takes hours, days or weeks to create new reports for Axys and APX users regardless of the content.  In contrast, the time required to change your portfolio accounting system in order to leverage pre-existing reports or make new reports on a different platform is more likely three to six months.  In some cases, investors that switch to another portfolio accounting system with new reports in mind find that they still don’t have those reports a year later.

These fundamental truths along with market conditions no doubt led investors that use Advent Software products to seek out and retain the expertise of replang and SSRS report designers like me to create and implement a variety of new performance reports designed to address concerns about their existing performance reports.

In my own experience, one prospect provided me with the specifications for their new performance summary report and requested that the report be done in a week.  In another instance, I was tasked with facilitating a reclassification of securities, regeneration of performance history, and creation of a new performance report based on the reclassification before the end of January.  In each of these engagements, working as a team with responsive and motivated clients, we were able to start and complete large-scale, high-impact projects in an accelerated time frame.

As a seasoned professional services consultant, I do my best to address the needs of my retainer clients – that keep me in business – first and any new prospects second, so these non-retainer clients were fortunate that I was able and willing to commit to projects that required fast tracking on short notice.  Though I regularly take on new projects, the most interesting thing about that quarter’s new business was the timeline imposed.

There was definitely a sense of urgency associated with these reporting projects that usually isn’t there, and though consultants like me appreciate new business opportunities, investment managers cannot usually expect those results if they haven’t forged a relationship with a consultant ahead of time.

With an established, highly-motivated expert on retainer, you can call that person on impulse, have a high-level conversation in minutes with someone that is familiar with your systems, get a responsive quote for additional work if necessary, and potentially have a new report or automation created before you might be able to effectively start a dialog or get an adequate response from an alternative source.

When the financial markets take a turn for the worse, one might assume that folks like myself who make a living off of providing software products, custom reporting solutions and consulting services aimed at automating and integrating investment management systems would suffer a downturn in business.

While that is ultimately true, should the market ever become so difficult that my customers become distressed or go out of business, it is not true of “corrections” that occur in the market.  These events force the hand of investors – making them scramble to take stock of reporting, trading and any other systems that their businesses rely on with an aim to enhance, automate and improve.

The best run investment firms are constantly striving to improve their mission-critical systems and willing to retain the talent that empowers them to make changes to those systems whenever it becomes necessary or advantageous.

Investors dodged a bullet in Q1 of 2016, but doing so in the future may require changes to your client reports. I am hopeful that 2019 will be another banner year for investors, but sooner or later something is bound to change.


About the Author: Kevin Shea is the Founder and Principal Kevin Shea Impact 2010Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide. For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

iStock_000000129907XSmallIn my experience working with investors across the nation both small and large, there is at least one recurring theme.  Their sophisticated workflows hinge on semi-automatic processes that rely in part or completely on people.  I suppose that is a good thing when operator oversight is a plus, but when I get involved most of these firms have realized that they literally want to push a button and have things done as simply, quickly and reliably as possible.

Ten years ago, one of my clients experienced organic growth so rapid that it drove their firm from one that managed hundreds of millions to billions in assets in less than two years. While investment managers are known to consistently take pains to build processes that allow their businesses to scale efficiently, explosive growth can strain or disrupt established workflows.

In this case, the effect of the growth was dramatic. It demanded that certain processes be automated. One of the most important processes was related to trading foreign stocks in local currencies.  The influx of trades from new business was overwhelming.  Back-office employees that were already working hard needed to work even longer hours to keep pace with the incoming business.

More specifically, the firm’s back office needed to manually enter both transactions to trade currencies and the associated equity trades. In the multi-currency version of Axys, purchases and sales of foreign stocks in local currency require three transactions: two to exchange the currency and one to buy or sell the security.  As a result, every purchase or sale required two additional transactions related to foreign currency exchange.  They were entering three manual transactions in the trade blotter for every trade they made – even partial fills of an outstanding order required these transactions.  The entries to the trade blotter were tedious, time-consuming, and a potential source of operator error; the firm knew they needed to automate them.


Money concept

Understanding the Required Workflows

As part of their process, the firm waited until they got the executed FX rates from an assortment of brokers before they could enter the corresponding trades and post them in their portfolio accounting system.  This backlog of trades created a slew of manual trade blotter work that ultimately had to be done after hours to make sure the firm was ready to trade the next day.

A homegrown Order Management System (OMS) populated the Axys trade blotters of the traders at the company with open trades. Those blotters were utilized to track open trades and never actually posted.  Once the execution info was reported, our automation needed to create the additional transactions that back-office staff was entering manually. The workflow also required that the trade blotters for individual traders be updated to reflect that the executed trades were no longer part of the open trades. In effect, our automation needed to rewrite the traders’ blotters as well as the trade blotter of the operations employee running the app and post the latter.


Building the Prototype/v1

In a relatively quick timeframe (40 hours), we built a working prototype using Visual Basic that:

  1. loaded the outstanding trades from each trader’s blotter into an Access database
  2. created a process where outstanding trades could be selected and associated with trade execution info to generate the required trade blotter entries
  3. imported executed trades to the trade blotter for review and posting
  4. updated the open positions in the trader’s blotters
  5. produced reports (via Crystal Reports) detailing trades pending and actual execution info

In short, the app pulled pending transactions from their homegrown OMS and allowed users to associate foreign currency execution rates and other specifics of trade execution with specific orders to produce the necessary Axys trade blotter transactions automatically.  Once the execution info was recorded, the user would exit the app, which in turn automatically updated the user’s trade blotter and the traders’ blotters.

Version 2

The next version of the app was under development for over six months and cost nearly 40k, but it met the needs of the firm. The core functionality of v1 with respect to workflow was preserved, but we added many features.  In terms of the initial cost, v2 was expensive, but over a period of nearly ten years it required almost no maintenance. The multi-currency trade automation solved an immediate and urgent need when it was originally developed, and continued to save the firm hours of back office processing work every week for nearly ten years, until it was finally decommissioned in 2015 as a byproduct of the firm’s transition to Moxy and Geneva.

Though the application wasn’t cheap to build or maintain initially, it paid for itself many times over during its tenure as an integral part of the daily workflow at firm that knows the value of automation.


About the Author: Kevin Shea is the Founder and Principal Kevin Shea Impact 2010Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide. For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

This article is a follow-up to two previous articles: one that addresses the future of Axys and another that helps Axys users figure out whether they are on the right version of Axys for their firm.

Almost two years ago, I speculated on what would begood-bad-uglycome of Axys and whether Advent Software would answer to a growing demand among the Axys user base for major product enhancements after several years of minimal but consistent maintenance updates.

Among other things, my blog detailed an expectation for the same old thing as we have seen in the past – a maintenance release – but I also hoped that we would see a major release.  Since the current version was 3.8.5, it made some sense that version 4.0 might be the next release.

At their conference in 2013, Advent formally announced a major release that would include a user interface (UI) overhaul and the addition of permissions.  Advent also indicated that Axys 14.1 would be released in Q2 of 2014.  This was good news to many Axys clients.  I was off by 10 versions, but happy nonetheless that a major new release was in the works!

While I commend the UI overhaul and see those changes as a necessity given today’s technology standards, permissions have never been that big a deal to me or the clients I work with.  As the go-to technical resource for many firms that use Axys, I found we could almost always work around this issue.  The announcement of a major release no doubt made users hopeful that Axys would get the long-awaited attention it required.

 

Understanding Advent’s new versions…

Advent has embraced a versioning system that makes 14.1 the next release after 3.8.5.  From 2014 forward, there are two scheduled point releases one in Q2 and another in Q4. Advent’s other products also share a similar versioning and release schedule.

 

2014

As April 2014 went by I needed to remind myself that there were three months in Q2, and the release could just as easily come out in June.  Like many users I waited and listened, but heard no great news about 14.1.  As it turned out, 14.1 was a beta with no more than a handful of users outside of Advent partner firms participating in testing.   14.2 was released on a limited basis.  Thanks to the new version numbers, some Axys 3.8.5 users were thinking, “Wow! The latest release is 14; we really have fallen behind.”

Relatively speaking, a very small group of users had begun using Axys v14.x.

2015

Axys 15.1 was also released on a limited basis.  Those Axys users that want to try out the latest Axys version now need to fill out a questionnaire detailing information that helps Advent determine whether the software in its current iteration will work satisfactorily enough for them to allow or discourage testing of the Axys in each particular user’s environment.


Ten Things You Should Know About Axys 15.x

  1. The UI is a ribbon bar similar in style to more recent versions of Office.
  2. Though the software and data still resides locally, Axys 14.x and beyond require an internet connection to authenticate users via Advent Direct.
  3. The file formats are the same as Axys 3.8.5; that is one piece of good news for integrators.
  4. The ancillary products that work with Axys remain the same for now. Report Writer Pro, DTCC, Dataport and Data Exchange. There has been no change to those products yet.
  5. Reports can now be produced from the Axys program rather than the reports program (rep32.exe) alone.
  6. The function of specifying lots when positions are sold off has changed. It is no longer a pop-up.  Now users must specify the close method in a comment line that immediately follows the transaction.
  7. An additional server running SQL CE is recommended for the parallel testing phase.
  8. Scheduled scripts need to be amended to include authentication credentials.
  9. It is not available to Axys users running the single user version, but support for single user installs is planned for v15.2.
  10. Advent recommends running Axys 15.1 in a test environment for at least a quarter.

Axys users should understand the need to do a phased and methodical release.  This need is predicated on how long Axys has been around and how many programs and interfaces connect with it.  As it was designed and marketed to be, Axys is still the hub of operations for many firms.  By and large, Axys users have had the product for several years and many have built and or purchased additional tools that integrate with Axys.

Advent wants users to start using 15.x, but only after they have thoroughly tested all of their processes.  The easiest way to accomplish that, as Advent recommends, may be running Axys 15.x in parallel with Axys 3.x for an entire quarter.  One of the best things Axys has going for it is the fact that it works so reliably.  With that in mind, the last thing Advent would want to do is destabilize the platform and call their clients’ favorite thing about Axys into question.  However, a greater sense of urgency with respect to facilitating Axys 15.x implementations and bringing more substantive enhancements to Axys would be refreshing to see.

In 2013, Advent made an informal and perhaps unspoken promise to continue to make substantial improvements to the Axys platform through announcing their upgrade plans and committing additional resources to make enhancements to Axys.  Though Axys users can clearly see the signs that Advent has made a significant additional technology investment in Axys, the majority of Axys users have not been able to take advantage of those improvements yet.

Future improvements aside, the primary reasons to stay the course with Axys remain the same as they have for quite some time:

  1. it is an established standard
  2. function over form
  3. simple to host and maintain
  4. relatively low-cost versus most emerging alternatives
  5. a platform you can build on

Firms that want to adopt the latest version of Axys in 2015 will need to work to make it happen.  I suspect that the best-case scenario for many firms would be for them to start testing with 15.x in 2015 and eventually go live in 2016 after year end processing has been completed.  Given the competitive nature of today’s portfolio management systems, the slow motion release of major Axys updates could lead to more firms leaving Axys (and possibly Advent) to pursue alternative solutions with enticing features they may be able to take advantage of on a more predictable timetable.



About the Author: Kevin Shea is the Founder and Principal Kevin Shea Impact 2010Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide.

For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.