RW: Using the rw_TableLineString() and rw_TableLineCurrency() Report Writer functions

David Meego - Click for blog homepageWhen Microsoft Dynamics GP 9.0 was released, it included six new global functions specifically added to make life easier for ISVs (Independent Software Vendors).

These six placeholder functions were added so that Dexterity developers could trigger against them and use the functions to get their custom data on to reports without needing to create alternate reports.

Before these functions existed, a developer could create a Report Writer function in their dictionary which could return the additional data required. However, as the RW function was only in the third party dictionary, it could only be used if the report was also in the same third party dictionary… as an alternate report.

With the addition of these six placeholder functions, a developer could now trigger on the functions in the core Dynamics dictionary and their code could now return the data to any report in any product as core Dynamics RW functions are available to use in a calculated field from the Report Writer for any product dictionary.

The details of these functions is covered in the following KB Article. The KB article covers how developers can use the functions in their code:

Note: The article is currently unavailable, so I am attaching an archived version to the bottom of this post.

The added report writer user defined functions (in the system series) are listed below:

  • rw_ReportStart()
  • rw_ReportEnd()
  • rw_TableHeaderString()
  • rw_TableHeaderCurrency()
  • rw_TableLineString()
  • rw_TableLineCurrency()

This article covers an issue which using the rw_TableLineString() and rw_TableLineCurrency() report writer functions from the Report Writer.

The parameter list for these two functions is the same with the data being returned being either a String or Currency value respectively:

in integer dict_id; 		{Dictionary ID}
in string report_name; 		{Report Name}
in string sNumber; 			{control field 1}
in integer sType; 			{control field 2}
in currency cSequenceOne; 	{control field 3}
in currency cSequenceTwo; 	{control field 4}
in integer iControl; 		{which piece of data to get}

The four control fields are designed to match the 4 key fields on the SOP_LINE_WORK (Sales Transaction Amounts Work) table; SOP Number, SOP Type, Line Item Sequence, Component Sequence.

However, the developer (who shall renamed nameless, he knows who he is and it is not me 🙂 ) who originally created the functions made a mistake with the data types of the last two fields. The Line Item Sequence and Component Sequence fields are actually Long Integers and the functions are expecting Currency datatype.

If you attempt to pass the fields directly from the table, the Report Writer will generate an error when the report prints. So you will need to create a couple of calculated fields to change the datatype to currency and use them instead.

See the images below for settings to use for the calculated fields:



On the plus side, the currency datatype provides more flexibility to be used to pass any numeric data if you want to use the parameters in different ways.

See the next articles which will use this technique.

Hope this helps.


KB Article: kb_mbs888884_usefulfunctionsforreports

06-Jun-2019: Added links to related articles.

This article was originally posted on

7 thoughts on “RW: Using the rw_TableLineString() and rw_TableLineCurrency() Report Writer functions

  1. I have done some testing on these functions, it appears the name of the functions are misleading as they infer that the “header” functions can only be used in headers, and the “line” functions can only be used in lines, but they appear to rather be generic placeholder functions with multiple variable lists that can be called in Dexterity code in any part in any report, which means they are much more powerful than their names suggest. Is this true?


    • Hi Bruce

      The names of the six functions is just a suggestion of where they can be used.

      What is really the important factor is the number and datatype of the available parameters.

      The cool thing is that since 2009 GP Power Tools (aka SDT) uses these functions to allow for the creation of custom user defined report writer functions.

      See tomorrow’s post for more info.


  2. Hi David ,

    Trail Balance report blank issue!

    The trial balance report is blank when any users run the report. The report is properly populated when the same report is ran as SA user .
    I have never faced this type of issue,need some direction .

    I made sure the user is given access to the gets opened but not populated for all user.but with sa user the report is populated. what are the other possibilities ?.

    checked alternative window to check whether the report is modified ,its not modified.

    i wonder what might be the issue. need some help! sir


    • Please note that blog comments are not an appropriate platform for support.

      I would try another user with POWERUSER role. If that works we know it is GP application security causing the issue.

      I would try another user granted SQL sysadmin status. If that works then it is SQL security causing the issue.

      If SQL, try running Grant.sql script.

      If Dynamics, check security settings.

      If still not working, capture logs and look for an error from SQL.

      GP Power Tools will help you fix security errors, sql permissions and capture logs.


      Liked by 1 person

Please post feedback or comments

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.