Author |
Message |
PSpeare
Newbie
Joined: 02 Sep 2007
Location: Canada
Online Status: Offline
Posts: 4
|
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 Logged |
|
jkwrpc
Senior Member
Joined: 19 Jun 2007
Location: United States
Online Status: Offline
Posts: 432
|
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 Logged |
|
PSpeare
Newbie
Joined: 02 Sep 2007
Location: Canada
Online Status: Offline
Posts: 4
|
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 Logged |
|
BrianBischof
Admin Group
Joined: 09 Nov 2006
Online Status: Offline
Posts: 2458
|
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 Logged |
|
PSpeare
Newbie
Joined: 02 Sep 2007
Location: Canada
Online Status: Offline
Posts: 4
|
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 Logged |
|
jkwrpc
Senior Member
Joined: 19 Jun 2007
Location: United States
Online Status: Offline
Posts: 432
|
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 Logged |
|
hilfy
Admin Group
Joined: 20 Nov 2006
Online Status: Offline
Posts: 3702
|
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 Logged |
|
PSpeare
Newbie
Joined: 02 Sep 2007
Location: Canada
Online Status: Offline
Posts: 4
|
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 Logged |
|
jkwrpc
Senior Member
Joined: 19 Jun 2007
Location: United States
Online Status: Offline
Posts: 432
|
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 Logged |
|
|