Report Design
 Crystal Reports Forum : Crystal Reports for Visual Studio 2005 and Newer : Report Design
Message Icon Topic: Organizing Report Post Reply Post New Topic
Author Message
PSpeare
Newbie
Newbie


Joined: 02 Sep 2007
Location: Canada
Online Status: Offline
Posts: 4
Quote PSpeare Replybullet Topic: Organizing Report
    Posted: 02 Sep 2007 at 11:50pm
Hello,

I'm rather new to using Crystal, and have found this forum helpful in answering some of my questions.  However, for some reason, I'm suffering a thought blockage in this one problem I'm currently working on, and would be grateful for any ideas or plans of approach that anyone might have.

Currently, I'm creating a monthly report using C#, and need something along the lines of:

---------------------------
Accounts with Amount Payable
[section includes columns Date, Account Number, Client Name, Associated Affiliates, Amt Payable, Prior Interest]

Accounts with Amount Refundable
[section includes columns Date, Account Number, Client Name, Associated Affiliates, Amt Refunded, Prior Interest]
---------------------------

Basically, it's one report with two sections - one section listing all the accounts with a postive amount payable and the other listing all accounts that have a negative amount payable.  The date is passed in by the user via a C# coded interface.

For some reason, my brain doesn't seem to want to wrap itself around this, so I'm currently encountering two main problems:

- What would be the best way to set it up?  I've considered creating two stored procedures, which in turn lead to two subreports, which in turn would be both inserted into one main report.  But doing so would require me passing in the date parameter into the main report and then into the subreports which would then be passed into the stored procs.  Is that even possible?  Or is this a not very good way to go about it.  For some reason, I get the feeling that there must be another way, but I just can't put my finger on it

- My second problem lies in the proper retrieval of the data and how to correctly display it in the report.  Each client listed (be it payable or refunded) has a number of associated affiliates (in a one to many relationship).  However, in the report, these affiliates need to be listed in a concatenated string for each client record.  I've toyed with it at the stored procedure level, and can't seem to come up with a proper solution.  Is there anything I can do at the report level?

Any help or insight on this would be greatly appreciated.  Thanks in advance!
IP IP Logged
jkwrpc
Senior Member
Senior Member


Joined: 19 Jun 2007
Location: United States
Online Status: Offline
Posts: 432
Quote jkwrpc Replybullet Posted: 03 Sep 2007 at 8:17am
Like writing code there are many ways to different ways to approach the design of your report.
 
If you have read my posts you will find that while I use subreports, I will do just about anything to avoid them. Most of my dislike relates to performance issues, and I admit its probably more imagined than real. 
 
Against that thought it appears the only difference between the two reports in one data field, amont payable vs amount refunded. So far as I can see everything else is the same.
 
Is there a reason you cannot use grouping and simply add the field to a a single query;  say add amount refunded to  the other query.
 
You would then have all  the client information on a a single line and then be able to use summaries fields more efficiently. Your user(s) may like not having to read one area of the report for a client payables then another area for refunds.
 
If this would work it would reduce your stored procs issues, etc.
 
Just a thought.....
 
 
Regards,
 
John W.
IP IP Logged
PSpeare
Newbie
Newbie


Joined: 02 Sep 2007
Location: Canada
Online Status: Offline
Posts: 4
Quote PSpeare Replybullet Posted: 03 Sep 2007 at 10:16am
Thanks for your suggestion, John!  That definitely does help to give another perspective on it. 

I'd prefer to avoid sub-reports too, and minimizing the number of stored procs is definitely something I'm in favour of.  However, a couple of quick clarification questions from someone who isn't as familiar with CR: if grouping is applied to the amt. pay/refund field, wouldn't it group each unique amount value together, which is similar to not grouping it at all since the amounts pay/refunded can be all over the board?  Or is it just me misinterpreting your response?

Unfortunately, the Systems Use Case document for this project dictates that the user wants the report to appear as I've noted (both payable and refunded on the same report but in separated sections), so deviation from it will definitely be frowned upon.
IP IP Logged
BrianBischof
Admin Group
Admin Group
Avatar

Joined: 09 Nov 2006
Online Status: Offline
Posts: 2458
Quote BrianBischof Replybullet Posted: 03 Sep 2007 at 1:57pm
I like how John takes the approach of using groups over subreports whenever possible. Personally, I just use subreports and never thought about it too much. I need to reconsider this approach and see if there are some good 'rules of thumb' of when groups can be used to replace  subreports. (this would be an excellent sidebar section in the subreport chapter....)

Anyway, back to the question at hand.... I think John is saying that you should group only on the account type (payable vs refund) and then put the detail data within that group. This way, all the payables are listed first and then all the refunds are listed second.

I'm not sure about your requirement to make them separate sections, but if necessary you can always create two sections and use conditional formatting to enable/disable the appropriate section based upon the current account type. But most likely, once you get the groups working okay then the format of the report will look fine as well. And you can always put formatting in the group footer or header to differentiate between the two categories.

And re your question about listing all the affiates in a concatenated string, there are two options for this (both a bit tricky). Since you know how to use stored procedures, I would do it by putting the logic in the stored procedure. I forget the exact term, but SQL lets you loop through each record in a table and you can concatenate the fields into a single string that is passed returned from the SP. The term is something simple like using resultsets or recordsets or something (my SQL reference books are at work). Anyway, this would be best (although a bit slow). For the pure CR technique, the way to do this is to use subreports that use shared variables to build a concatenated string of the affiliates and then print this shared variable from the main report. This is a bit messier and is only recommended for those who don't know how to code SQL stored procedures. For you, I recommend the SQL approach.
Please support the forum! Tell others by linking to it on your blog or website:<a href="http://www.crystalreportsbook.com/forum/">Crystal Reports Forum</a>
IP IP Logged
PSpeare
Newbie
Newbie


Joined: 02 Sep 2007
Location: Canada
Online Status: Offline
Posts: 4
Quote PSpeare Replybullet Posted: 03 Sep 2007 at 8:19pm
Thanks so much, Brian.

The catch is that there is no field that indicates whether an account is payable or refunded.  The status of the account is determined by the amount listed in the amount payable field, so the accounts change month to month.  However, John's and your point did light a light bulb for me in terms of giving me a direction to try.  I'm going to attempt to do some fancy SQL coding and perhaps see if I can create a temporary table in which I can create an 'payable/refund' type field before selecting the data for the report itself (at which point I can try implementing some grouping).

And I'll definitely look into the SQL loop for concatenating.

Thanks again for the suggestions!
IP IP Logged
jkwrpc
Senior Member
Senior Member


Joined: 19 Jun 2007
Location: United States
Online Status: Offline
Posts: 432
Quote jkwrpc Replybullet Posted: 04 Sep 2007 at 9:16am

Just a couple of more thoughts as you work through the design issues. You must have some way  of sorting out what is a amount payable and amount refunded. I am not clear what this is but am certain you know the logic.  You need to key in on this logic.

The second thought is to remember that you can do a lot of things in the sql commands. this seems to be the path you are looking into.  I try to drive as much of the data processing, as I can, to the database sever.  I really like it if the data if all the calculations, grouping, etc are done before it gets to the report.
 
For Brian, my general rule, one that has many execptions, including the users requirements, is to use a subreport to show unrelated data, in a main report.  I find for related data. that by using SQL and the doing the calcs, grouping, string work, etc., and  then incorporting the grouping features in CR itself as well as conditional logic, I can generally give the user a good report with good output performance...and no subreports. 
 
But still I have used subreports. I recently had one customer who designed a report that had 5 subreports in addition to the main report body. When you consider that it takes 6 passes in CR to generate the report for each account, and there were hundreds of accounts, the overall report takes a long time to generate.
 
Best wishes for a design solutions, let us know what you end up with so we to can learn. 
 
 
John W.
 
IP IP Logged
hilfy
Admin Group
Admin Group
Avatar

Joined: 20 Nov 2006
Online Status: Offline
Posts: 3701
Quote hilfy Replybullet Posted: 04 Sep 2007 at 4:19pm
It looks like you could create a formula on your amount field:
 
If {table.amount} >= 0 then 'Payable' else 'Refundable'
 
You would then group on this formula to split your data by type of amount.
 
-Dell
IP IP Logged
PSpeare
Newbie
Newbie


Joined: 02 Sep 2007
Location: Canada
Online Status: Offline
Posts: 4
Quote PSpeare Replybullet Posted: 04 Sep 2007 at 9:02pm
Thanks, Dell!

This is very similar to what I ended up doing.  In fact, I incorporated everyone's thoughts into the solution, which is brainstorming at its best.

What I did was do most of the work within the DB side (as John noted).

First off, I created a temporary table that held the concatenated fields of the affiliates.  I joined this temporary table with the other tables with the required fields.  I then created another temporary table with an extra fields called 'accountType'.  I selected the necessary data from the joined tables (with a WHERE clause of amountPayable > 0) and put them into this newest table with the 'accountType' listed as 'payable'.  Then I did another SELECT from the joined tables with a WHERE clause of amountPayable < 0 and inserted these records into the newest temp table, making sure to insert 'refund' into the 'accountType' field.  Lastly, I did a SELECT of these newest table before dropping it.

The data then got put into the report, and I did a simple group on the 'accountType' field.  It worked out very nicely.

Thanks so much for all your ideas.  I couldn't have done it without you.  :)
IP IP Logged
jkwrpc
Senior Member
Senior Member


Joined: 19 Jun 2007
Location: United States
Online Status: Offline
Posts: 432
Quote jkwrpc Replybullet Posted: 05 Sep 2007 at 7:04am
Thanks for the update, it sounds like you have come up with a great solution. Your use of temporary tables has reminded me of another SQL tool I need to make better use of.
 
 I hope as others read this thread they will come to a fuller appreciation of using SQL and grouping to improve their overall report design and  performance.   As an added benefit, I also believe it improves the ability to maintain and troubleshoot a report over the long term.
 
One persons opinion I know...
 
So Brian you going to rethink when to use subreports for the next edition. :)
 
Thanks again,
 
John W.
 
 
 
 
 
 
IP IP Logged
Post Reply Post New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum



This page was generated in 0.031 seconds.