Author Topic: Derived Fields - When and How to Use Paragraph Instead?  (Read 4077 times)

Chris Weitzel

  • Professional
  • ***
  • Posts: 30
Derived Fields - When and How to Use Paragraph Instead?
« on: December 02, 2015, 03:27:49 PM »
So I have this report writer (/RD) report with some derived fields.  They fields exist only on that report (not a dictionary item), they do math, and produce a value.  The math isn't complicated by any means, but it is nasty to look at on the derived field (30 characters at a time).

Suppose I were to do the math in a paragraph instead and call it from the derived field.

1. What naming convention would I use for the paragraph?  After all, it's only for that report.
2. Do I just pass all the fields I need for the math as parameters?  I don't think there's any other way to do it.
3. Should I do this a completely different way?

Chris

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
Re: Derived Fields - When and How to Use Paragraph Instead?
« Reply #1 on: December 03, 2015, 12:02:56 PM »
There are a couple of approaches to this.  If you have several calculated fields, I would suggest that you call a paragraph in the Process After Read and post your calculations from @RECORD either to @WORK fields or a @USERDATA(X) entry.  You would then use the corresponding field in your report.

Remember, in the Process After Read, you can set @RTN.FLAG = 1 to exclude a selected record from the report.  Sometimes it makes more sense to do that (e.g., if you want to exclude partial shipments, you would set @RTN.FLAG = 1 if there was a backorder quantity).

If you wish to use a separate paragraph for each field, you can pass parameters in the process call, or you can create a dictionary item that calls the paragraph.  Here's a sample I use.

I have a MV field that has monthly accumulators for several years, but there are times I only want the current year and/or previous year.  I created paragraph MY.SUM.MV:

LOCAL ATR,IDX,I1,IX,SUM
SUM = 0
ATR = OCONV(@PARAM,"G0,1")
I1 = OCONV(@PARAM,"G1,1")
IX = OCONV(@PARAM,"G2,1")
FOR IDX = I1 TO IX
   SUM = SUM + @RECORD<ATR,IDX>
NEXT IDX
@VALUE = SUM

I then created two dictionary items to sum the corresponding values in Attribute 101.  Here are the Derived Fields:

MY.CUR.YR -- (P("MY.SUM.MV,101,1,12"))
MY.PAST.YR -- (P("MY.SUM.MV,101,13,24"))

Note:  if I use both fields in a report, that paragraph gets called twice for each record in the report.  That's why I would recommend a single Process After Read to do all of your calculations.  You can often be more efficient with the programming.

As to naming conventions - those are usually site specific.  I would just be consistent.  Perhaps CALC.report.field.P for an individual field calculation, or report.AR for a Process After Read paragraph.

Chris Weitzel

  • Professional
  • ***
  • Posts: 30
Re: Derived Fields - When and How to Use Paragraph Instead?
« Reply #2 on: December 04, 2015, 08:05:03 AM »
Great information, Tom!  Thanks.

I've started my paragraph.  One of the calcs uses fields from @RECORD only.  The other uses derived fields that aren't really on @RECORD (of course).  Is there a way to tap those in my paragraph without having to "re-derive" them there?

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
Re: Derived Fields - When and How to Use Paragraph Instead?
« Reply #3 on: December 07, 2015, 08:37:42 AM »
(Sorry for the late reply - I was on vacation Friday - Santa had a Toy Drive to attend! :) )

The @USERDATA and @PARMS values are not changed with each report record processed, so you can use them to store additional data you need as well.  For example, if your report has @RECORD items from your Order Line file, you could use a paragraph to read the Order Header into one of these.  You could also store the Key to the alternate file, so you could avoid doing multiple reads of the same alternate record.

There are several Report Process slots you may use:

Use Process At Start to initialize variables for the report
Use Process After Read to analyze and adjust values in a record before they appear on the report
Use Process Before Break to make adjustments just before the Break Field
Use Process After Break afterwards, if needed

Note that the process flow is as follows:

1) Read the next @RECORD
2) If any break field is different, Process the Break
3) Process the Record

So, when you use the Process Before/After Break slots, remember that @RECORD has the first record of the next break value, and is not part of the current break!

You could also check out this thread I wrote in 2007 (Yikes, I'm old! :) ) for an example that uses these multiple slots.

http://www.precisonline.com/forum/index.php/topic,66.0.html

PS for Prelude Users - /FLI PARMS shows which @PARMS items are used by their system.  For example, @PARMS(1)<1> has the current Company Number (assuming you've called GET.CO to set up the system variables).

Chris Weitzel

  • Professional
  • ***
  • Posts: 30
Re: Derived Fields - When and How to Use Paragraph Instead?
« Reply #4 on: December 10, 2015, 06:49:30 AM »
No problem on the delay.  Santa's work always comes first.

Thanks for all your help.  I finished my project yesterday and everything worked marvelously!

Chris