Look Sidewards - Reports DataPro / Standard Protocols

[Jan Schenkel]

--- Richard Gaskin <ambassador at fourthworld.com> wrote:
> Jan Schenkel wrote:
> 
> > The main issue here, however, is getting data onto
> > paper. We cannot expect our customers to buy Word
> or
> > Excel just to be able to print a report from an
> > invoicing application written in RunRev.
> ..
> > Yes, we can do all this within RunRev, building
> > report-stacks with cards that have everything
> > hand-tweaked. Which is why I'm looking forward
> very
> > much to the report generator that's upcoming.
> 
> The invitation from yesterday still stands:
> 
>    If you just need to get a report out the door
> while
>    someone else writes a generalized printllib,
>    describe what you need and maybe we can all
> benefit
>    from looking at how a specific printing task
> would
>    be solved using Rev 1.1 out of the box.
> 
> 
> -- 
>  Richard Gaskin 
>

Hi Richard,

Since you offered so nicely :-)

One of the most common reports in an accountancy
program is the general accounts balance.
In the Belgian standardised Minimal General Account
System, the general accounts have number ranging from
100000 to 799999 (six digits).

What we need to print is:
1) the account number
2) the account name
3) current period's total debit bookings
4) current period's total credit bookings
5) current period's balance (column 4 - 3)
6) current financial year's total debit bookings
7) current financial year's total credit bookings
8) current financial year's balance (column 7 - 6)

Subtotals would be required on digits 1 through 5.
Headers on every page, containing the company data.
Summary page with the parameters that were set in the
selection screen.

All the data comes from a *SQL database and is ready
in a revdb_cursor.

What I can see as an answer is:

1) clone an empty stack ;

2) set size to A4-landscape :
2.1) 27.3 x 21 centimeters ;
2.2) ~ 774 x 595 picles ;

3) make the headers :
3.1) clone the fields ;
3.2) populate with company data ;

4) go to the first element in the cursor ;

5) loop through the detail lines :
5.1) see if a subtotal needs to be printed, 
-> if so clone fields for subtotal line, populate with
subtotals, reset subtotal counters
-> check if another subtotal needs to be printed for a
'higher' level
5.2) clone 8 fields per detail line ;
5.3) populate fields with data from cursor ;
5.4) revdb_movenext ;
5.5) if the distance between the bottom of the field
and the bottom of the card is too small to squeeze in
an extra line,, create new card and print header,
reset detail_counter_for_page

6) when we've reached the end of the cursor, clone a
bigger field, and put the parameters in there.

The resulting stack could be used both for viewing
on-screen, and for printing to paper.

Now for more technical depth, I'd say we could
implement the headers as a group with background
property, so that whenever we create a new card it's
there.
Cloning the other fields in the correct position is
feasible, if we keep track of the next 'top' to place
the fields at.
Printing subtotals means check from inside to outside
(digits 5 through 1) which has changed, and if it has
changed, clone the necessary fields for a subtotal
line; add the height of this line so we know the new
'top' for the next line.

This still needs work on number formatting and such,
but it's a basic framework on how a printinglib can be
accomplished.
I'm willing to admit that there are a few weaknesses
in the reasoning (eg new-page determination), and that
this could be accomplished by writing line after line
to a text field and using revPrintField.
But hard-coding such reports seldom guarantees
portability, and automated data grouping and subtotal
calculation takes away a lot of the headaches and
mistakes in such data processing.

Hmm, I guess I'll stop rambling here and let other
people post their suggestions/remarks :-)

Jan Schenkel.


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com