web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics GP (Archived)

RM HATB--ORTRXAMT vs. CURTRXAM

(0) ShareShare
ReportReport
Posted on by

Hello:

Some people who create T-SQL code for building the RM HATB report use CURTRXAM, while some use ORTRXAMT.

Whose correct, and why?

John

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    Lisa at AonC.com Profile Picture
    933 Super User 2025 Season 2 on at

    [quote user="john.ellis2015"]

    Some people who create T-SQL code for building the RM HATB report use CURTRXAM, while some use ORTRXAMT.

    Whose correct, and why?

    [/quote]

    ...Depends what you are looking for ORTRXAMT is the Originating Transaction Amount.   CURTRXAM is the Current Transaction Amount (that is not date-sensitive).

    Ways you can use these: 

    Starting with ORTRXAMT, deduct the relevant Applied Amounts to get to the net transaction amount remaining  based on your HATB date.

    CURTRXAM is not related to the HATB date but can be useful for knowing if the document is still outstanding.

    (A good check that everything is working with your code is to use a HATB date in the future and verify that the Originating Transaction Amount less the Applied Amounts equals the Current Transaction Amount.  Another check is that the current Receivables Summary Inquiry matches the Current Transaction Amount total.)

  • Community Member Profile Picture
    on at

    But, what if no amounts have been applied?  Then, you have to use ORTRXAMT.

    I see, however, so many people dead-set on using CURTRXAM and ignoring what I just said on ORTRXAMT.  What in the world for?

    This is why I should have gone into journalism or politics, instead of technology or business, in general.  I don't understand the science of business, yet I can ask the "hard-hitting" questions that you hear doled out on such shows as "60 Minutes", ABC's Sunday morning news show, "Fox News Sunday", and "Meet the Press".  

    :)

    John

  • Suggested answer
    Lisa at AonC.com Profile Picture
    933 Super User 2025 Season 2 on at

    >>But, what if no amounts have been applied?  Then, you have to use ORTRXAMT.

    [Correction:  In my original message I called ORTRXAMT, originating transaction amount.  It is OriginAL transaction amount.]

    If no amounts have been applied then ORTRXAMT = CURTRXAM.

    When calculating HATB -- the recreation of the aging at a set date -- I don't think CURTRXAM ever has a place in calculating the historical unapplied amount of an invoice. 

    Are you possibly referring to different uses of the amount fields based on document types (for example, invoice vs. payment)?

  • Community Member Profile Picture
    on at

    Not really.  I'm just trying to understand why 99% of those programmers utilize CUTRXAM instead of ORTRXAMT, even when I'm not so sure that's the correct thing to do, per my earlier observation.

  • Lisa at AonC.com Profile Picture
    933 Super User 2025 Season 2 on at

    Perhaps you are looking at something related to ATB, not HATB?

  • Community Member Profile Picture
    on at

    No.

  • Lisa at AonC.com Profile Picture
    933 Super User 2025 Season 2 on at

    Please attach the script or a link to the SQL script that you are questioning.

  • Community Member Profile Picture
    on at

    I don't want to embarrass the person who wrote this script.  So, instead of sharing that person's link, the following is the script from that link:

    select

    CM.CUSTNMBR Customer_ID, CM.CUSTNAME Customer_Name,

    CM.PYMTRMID Customer_Terms, CM.CUSTCLAS Customer_Class,

    CM.PRCLEVEL Price_Level,

    sum(case

    when RM.RMDTYPAL < 7 then RM.CURTRXAM

    else RM.CURTRXAM * -1

    end) Total_Due,

    sum(case

    when DATEDIFF(d, RM.DUEDATE, getdate()) < 31

        and RM.RMDTYPAL < 7 then RM.CURTRXAM

    when DATEDIFF(d, RM.DOCDATE, getdate()) < 31

        and RM.RMDTYPAL > 6 then RM.CURTRXAM *-1

    else 0

    end) [Current],

    sum(case

    when DATEDIFF(d, RM.DUEDATE, getdate()) between 31 and 60

        and RM.RMDTYPAL < 7 then RM.CURTRXAM

    when DATEDIFF(d, RM.DOCDATE, getdate()) between 31 and 60

        and RM.RMDTYPAL > 6 then RM.CURTRXAM * -1

    else 0

    end) [31_to_60_Days],

    sum(case

    when DATEDIFF(d, RM.DUEDATE, getdate()) between 61 and 90

        and RM.RMDTYPAL < 7 then RM.CURTRXAM

    when DATEDIFF(d, RM.DOCDATE, getdate()) between 61 and 90

        and RM.RMDTYPAL > 6 then RM.CURTRXAM * -1

    else 0

    end) [61_to_90_Days],

    sum(case

    when DATEDIFF(d, RM.DUEDATE, getdate()) > 90

        and RM.RMDTYPAL < 7 then RM.CURTRXAM

    when DATEDIFF(d, RM.DOCDATE, getdate()) > 90

        and RM.RMDTYPAL > 6 then RM.CURTRXAM *-1

    else 0

    end) [91_and_Over],

    CS.LASTPYDT Last_Payment_Date,

    CS.LPYMTAMT Last_Payment_Amount

    from RM20101 RM

    inner join RM00101 CM

        on RM.CUSTNMBR = CM.CUSTNMBR

    inner join RM00103 CS

        on RM.CUSTNMBR = CS.CUSTNMBR

    where RM.VOIDSTTS = 0 and RM.CURTRXAM <> 0

    group by CM.CUSTNMBR, CM.CUSTNAME, CM.PYMTRMID, CM.CUSTCLAS,

            CM.PRCLEVEL, CS.LASTPYDT,CS.LPYMTAMT

  • Suggested answer
    Victoria Yudin Profile Picture
    22,769 on at

    John,

    Unless someone has copied my code and put it somewhere else, this looks like code from my blog here: victoriayudin.com/.../sql-view-for-current-receivables-aging-in-dynamics-gp

    I am by no means embarrassed. If there is an issue with any code I have posted, I would like to know it so I can correct it.

    Please note that both the title of the blog post and the name of the view have the word CURRENT. This code will only ever show you the current aging. Current in this case means including everything that has been entered into Dynamics GP, even with future dates. This code is not meant to be a Historical aging (HATB) and will never work for that purpose.

    As Lisa absolutely correctly answered for your original question, the CURTRXAM is what you want to use for a Current aging (what she is calling ATB).

    For a HATB you would never use the CURTRXAM, you would take each original transaction amount and deduct any transactions applied to it through the aging date.

  • Community Member Profile Picture
    on at

    Thanks, to you both, for helping me!  I really appreciate it!

    Can I take Victoria's script, "re-code" it with an aging date of my choosing, and essentially have it function as an HATB?

    John

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

#1
mtabor Profile Picture

mtabor 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans