Advice for invoice design
- Fabio Pagano
- Posts: 355
- Joined: Mon Apr 16, 2007 12:38 pm
- Location: Bari (Italy)
Advice for invoice design
I am new to StimulReport (i'm evaluating since march): now i need to design an invoice.
In my program i do all calculations, so there is no need to use report "sum" function or other specific functions: all data are already elaborated, they just have to be printed.
As you know, invoice has (typically) an head, a body and a foot. In my case, the user decides what fields must be printed in the head and what in the foot: i cannot decide what are the fields that must be printed in the head and what in the foot. For example, some users want the "Bank name" printed in head and other users want it printed in foot. Of course, the body fields are always the same (luckily).
My "hypothetical" solution is to pass two datatables: "master" (containg all "head" and "foot" fields) and "details" (containg all body fields).
These two tables have a master-detail relationship.
Assuming this structure, how can i design the report so that the "head" and "foot" data are taken from "master" table and "detail" data are taken from "detail table"?
And, beside this, do you have any design suggestion? I'll begin now to design as i told, but i am searching for some "experienced" advice to understand if i'm doing right with this dataset structure or there is a better way.
Thanks.
In my program i do all calculations, so there is no need to use report "sum" function or other specific functions: all data are already elaborated, they just have to be printed.
As you know, invoice has (typically) an head, a body and a foot. In my case, the user decides what fields must be printed in the head and what in the foot: i cannot decide what are the fields that must be printed in the head and what in the foot. For example, some users want the "Bank name" printed in head and other users want it printed in foot. Of course, the body fields are always the same (luckily).
My "hypothetical" solution is to pass two datatables: "master" (containg all "head" and "foot" fields) and "details" (containg all body fields).
These two tables have a master-detail relationship.
Assuming this structure, how can i design the report so that the "head" and "foot" data are taken from "master" table and "detail" data are taken from "detail table"?
And, beside this, do you have any design suggestion? I'll begin now to design as i told, but i am searching for some "experienced" advice to understand if i'm doing right with this dataset structure or there is a better way.
Thanks.
- Fabio Pagano
- Posts: 355
- Joined: Mon Apr 16, 2007 12:38 pm
- Location: Bari (Italy)
Advice for invoice design
I'm doing some pseudo-test: having a structure master-detail i've designed one databand referring to the master table, under it a databand for the detail table and under it another databand referring to the master table.
This is the design result
- DataBand with datasource from "Master"
- DataBand with datasource from "Detail"
- DataBand with datasource from "Master"
This way, i have obtained what i wanted: print a "master" field in foot.
As seen in flash tutorial
http://www.stimulsoft.com/livedemos/Rep ... eport.html
in detail databand i have setted the relation and the master component.
Anyway, other suggestions are welcome (summarizing my initial question: "how did you design the invoice report?").
Thanks.
This is the design result
- DataBand with datasource from "Master"
- DataBand with datasource from "Detail"
- DataBand with datasource from "Master"
This way, i have obtained what i wanted: print a "master" field in foot.
As seen in flash tutorial
http://www.stimulsoft.com/livedemos/Rep ... eport.html
in detail databand i have setted the relation and the master component.
Anyway, other suggestions are welcome (summarizing my initial question: "how did you design the invoice report?").
Thanks.
Advice for invoice design
Form your description, I would gess the every field in the header or footer must be printed only once, so this is no real master-detail case. You need two datasources: Header/Footer fields and data Fields.
3 databands is defenitly worng. You need one page header, one page footer and one databand. The databand will be fillied with your Detail data.
The fields data goes to header and footer.
As for design: I could created all header and footer fields in both header and footer and would use the beforeprint event to set the field enabled or disabled with a variable.
E.g. the bank:
You got one variable: ShowBandInHeader of type bool. Before printing the report you somehow get the value of this and pass it to stimulreport.
Now in the header you got a text field with the Bank name and a before print event: TextFieldBankHeader.Enabled = ShowBandInHeader. You do the same for the footer with the negation of the field.
I hop that helps somehow.
Marco
3 databands is defenitly worng. You need one page header, one page footer and one databand. The databand will be fillied with your Detail data.
The fields data goes to header and footer.
As for design: I could created all header and footer fields in both header and footer and would use the beforeprint event to set the field enabled or disabled with a variable.
E.g. the bank:
You got one variable: ShowBandInHeader of type bool. Before printing the report you somehow get the value of this and pass it to stimulreport.
Now in the header you got a text field with the Bank name and a before print event: TextFieldBankHeader.Enabled = ShowBandInHeader. You do the same for the footer with the negation of the field.
I hop that helps somehow.
Marco
- Fabio Pagano
- Posts: 355
- Joined: Mon Apr 16, 2007 12:38 pm
- Location: Bari (Italy)
Advice for invoice design
Good advice, thank you. I'm doing so and things works fine.EDV wrote:3 databands is defenitly worng. You need one page header, one page footer and one databand. The databand will be fillied with your Detail data.
The fields data goes to header and footer.
Fields will be designed by end user where he wants (header or footer), so this is not a problem: if he designes the "Bank description" in header it will go in header, if he designes the "Bank description" in footer it will go in footer. I've tried and i've been able to make it work.EDV wrote:As for design: you could create all header and footer fields in both header and footer and would use the beforeprint event to set the field enabled or disabled with a variable.
Thank you very much Marco.
Advice for invoice design
In the 2007.2 official release version we've added a new group of reports to the Demo example application named "Invoice".
Please take a look at this reports too.
Thank you.
Please take a look at this reports too.
Thank you.
Advice for invoice design
Also printing/not printing of the fields may be achieved via the following trick:
You place all text components in the following way:
text1
text2
text3
Also you should set the following properties for these components:
text1.CanShrink = true;
text2.ShiftMode = Decreasing Size
text3.ShiftMode = Decreasing Size
Value for the text1 you can transfer via variable, so if the value of the variable is null or "", then the Height of the text1 will be set in zero, the text2 will be printed instead of text1 and text3 instead of the text2.
Also via variables you may manage values to be printed from the DataSources, e.g.:
{IIF(MyVariable=="ValueFromColumn1",MyDataSource.MyColumn1,MyDataSource.MyColumn2)}
I think this information will be useful too.
Thank you.
You place all text components in the following way:
text1
text2
text3
Also you should set the following properties for these components:
text1.CanShrink = true;
text2.ShiftMode = Decreasing Size
text3.ShiftMode = Decreasing Size
Value for the text1 you can transfer via variable, so if the value of the variable is null or "", then the Height of the text1 will be set in zero, the text2 will be printed instead of text1 and text3 instead of the text2.
Also via variables you may manage values to be printed from the DataSources, e.g.:
{IIF(MyVariable=="ValueFromColumn1",MyDataSource.MyColumn1,MyDataSource.MyColumn2)}
I think this information will be useful too.
Thank you.