Showing posts with label invoice. Show all posts
Showing posts with label invoice. Show all posts

Friday, March 30, 2012

Print on back side of 1st page only

I have a SRS report that we are using as an invoice. I want to print out terms on the backside of the 1st page. Is this possible? Any ideas on how to go about doing this? I think the best way to go about doing this is to print the whole report double sided, and leave every 'even numbered' page blank expcept page 2, where the terms would print. I'm just not sure how to go about doing this in SRS.

Any help would be appreciated.

Randy

To start out with, can you be sure that content for each of the subsequent pages (page 3 and up, I mean) will be less than a page in length, with explicit page breaks between each, or does the content have to "flow" through pages 3, 4, etc without explicit page breaks? Does the content for page 1, similarly, have a known length, or can you force it to have a known length?

This is a cool problem <s>.

>L<

|||

The report is an invoice report. Page 1 will contain some header information (logo, address, customer, etc) and then will begin to list invoice lines. More than likely these invoice lines will carry over into multiple pages depending on how many items the customer ordered. In this case, page 1 would need to print with all of my header information and as much invoice line information as will fit, then page 2 would need to print terms, then page 3 should continue where page 1 left off. Page 4 would then need to be printed blank (since we are printing double sided) and page 5 would continue where page 3 left off, etc, etc. The challenge is telling SQL, "OK, now that we are on page 2, print this instead" and then, "now that we are on page 3, continue printing."

Thanks for any help you can provide.

Randy

Example:

Page 1 - Header, and body section

Page 2 - Terms

Page 3 - Body section from page 1 continued (if needed)

Page 4 - Blank

Page 5 - Body section from page 3 continued (if needed)

Page 6 - Blank

Page 7 - Body section from page 5 continued (if needed)

Page 8 - Blank

etc, etc

|||

>> No explicit page breaks

That's what I was afraid of -- makes things a little more complex, but I think it can be done... sorry for the delay in response...

OK, this is really cool. And I tried it a bunch of other ways, some of which might work and be less wierd -- but this really does work perfectly and doesn't disturb the "preview" layout at all -- it will only affect the print and PDF layout (and presumably other renderers that go to fixed page dimensions).

Here's how it works: It depends on something that usually annoys the heck out of us: the behavior of "wide" report designs in terms of page breaks for fixed page layouts such as print and PDF.

This is what you do:

1) First, figure out how you are going to separate the content of the first page from other pages and design your report with *two* tables, one for first page and one for the other pages. The first table obviously has your header while the second does not.

I did this by creating a SELECT statement that included a row number using SQL Server capabilities, because you can't filter or break by the the reporting RowNumber() function. You can do this in other environments as well -- in another thread somewhere here I show a worked example for doing it in SQL 2000 -- and you could also just use two datasets, one for each table. But in SQL 2005 it's really easy to do this:

Code Snippet


SELECT Row_Number() OVER (ORDER BY Whatever) As MyRowNum,*
FROM YourData ORDER BY Whatever

2) Now you make sure you only have the right details for each table. In my example, it worked out to have these two filters. If you split your data by some other method into one dataset for each of the tables , you don't need to do this:

Code Snippet


=Fields!MyRowNum.Value <= =15 ' first table

=Fields!MyRowNum.Value > =15 ' second table

3) Design your two tables so that they fit within the normal printable page limits -- if your paper size is, for example, 8.5 * 11, you should make sure that the tables are no wider than will print properly in this normally.

4) Here's the trick: You need to make the layout (page size -- *not* interactive page size) wider than will print properly for your page set up.

Horizontally across from table #1 , you put a rectangle (or whatever) holding your Terms details for the invoice.

Horizontally across from table #2, you don't need to put anything.

The layout ends up looking something like this:

Real layout (say, 7.5") a bit of space for comfort addtl layout, forcing the break

Header information, part of Table number one, plus the details that fit on page 1

Your terms go here Table number two with the rest of your details

The extra layout you put in should not be any more than 8" wide (in the example where the page is 8.5" wide) and preferably it should be a bit less.

The result is exactly what you want and what we usually do not want but get by accident, when we design page layouts that don't fit in a fixed page size:

the terms are pushed to page 2 and each appearance of table #2, starting with page 3, gets followed by an extra blank page...

Whaddya think?

>L<

Print Multiple Documents with VS2005 Local Report

Hello all.
I have a document (that could be for example an invoice) that was done with
VS2005 Local Report. This document is exported to PDF in the application
(with response.OutputStream.Write).
Now I want to be able to print multiple documents (for example invoices), by
generating a PDF with all the documents selected by the user.
I can generate as many local reports as i want to with the desired data. But
how can i export them to a single PDF file?
I will appreciate any comments.I am trying to do this also -- except printing, does anyone have any
suggestions? I can call the report over and over again, but then I get a
print dialog for each iteration of the report.
Thanks!
"Orlando" wrote:
> Hello all.
> I have a document (that could be for example an invoice) that was done with
> VS2005 Local Report. This document is exported to PDF in the application
> (with response.OutputStream.Write).
> Now I want to be able to print multiple documents (for example invoices), by
> generating a PDF with all the documents selected by the user.
> I can generate as many local reports as i want to with the desired data. But
> how can i export them to a single PDF file?
> I will appreciate any comments.|||Just to say that I solved this problem by redesigning my local reports to
support multiple documents.
I couldn't find another way to do this.
"Joel" wrote:
> I am trying to do this also -- except printing, does anyone have any
> suggestions? I can call the report over and over again, but then I get a
> print dialog for each iteration of the report.
> Thanks!
> "Orlando" wrote:
> > Hello all.
> >
> > I have a document (that could be for example an invoice) that was done with
> > VS2005 Local Report. This document is exported to PDF in the application
> > (with response.OutputStream.Write).
> >
> > Now I want to be able to print multiple documents (for example invoices), by
> > generating a PDF with all the documents selected by the user.
> >
> > I can generate as many local reports as i want to with the desired data. But
> > how can i export them to a single PDF file?
> >
> > I will appreciate any comments.

Monday, March 12, 2012

primary key

hey all,
i have an invoice table where the customerID/invoiceNo uniquely identify a
record, also i have just a tableID (if I'm not mistaken, is a good practice
to do). which one should be my primary key?
thanks,
rodcharIf tableID is an auto-incrementing integer field, then I'd use that one.
You can build an index on CustomerID, InvoiceNo for the lookups.
Personally, I would make the InvoiceNo unique as well, unless there's a
reason the system requires the uniqueness to be both customerID and
InvoiceNo.
-Steve-
"rodchar" <rodchar@.discussions.microsoft.com> wrote in message
news:2B8D7EAE-1AF3-4622-A219-63E72EEEF228@.microsoft.com...
> hey all,
> i have an invoice table where the customerID/invoiceNo uniquely identify a
> record, also i have just a tableID (if I'm not mistaken, is a good
> practice
> to do). which one should be my primary key?
> thanks,
> rodchar|||"rodchar" <rodchar@.discussions.microsoft.com> wrote in message
news:2B8D7EAE-1AF3-4622-A219-63E72EEEF228@.microsoft.com...
> hey all,
> i have an invoice table where the customerID/invoiceNo uniquely identify a
> record, also i have just a tableID (if I'm not mistaken, is a good
> practice
> to do). which one should be my primary key?
> thanks,
> rodchar
Whatever makes most sense to you. Both columns are candidate keys if they
are unique and not nullable therefore it would make sense to declare unique
constraints on both of them (either NOT NULL UNIQUE or PRIMARY KEY). In SQL
Server the practical differences between a PRIMARY KEY and one that is NOT
NULL UNIQUE are purely to do with default behaviours: PKs are used as the
default for foreign key references; they are clustered by default and PK
columns default to NOT NULL rather than NULL. All of these defaults can be
explicitly overridden so most of the time it doesn't make any difference
which key is PK rather than NOT NULL UNIQUE. If a surrogate key is used as a
foreign key reference then that is frequently the one declared as PRIMARY
KEY but that doesn't have to be so.
ER modelling tools may handle PRIMARY KEYs in a special way (using a
different notation in diargrams for example) so you may want to take that
into account when you choose.
Notice that throughout I've written PRIMARY KEY in caps. That's because
SQL's PRIMARY KEY is not the same thing as a "primary key" in the relational
model and design theory. Standard SQL uses the PRIMARY KEY purely as a way
of designating the default reference for a foreign key constraint.
David Portas
SQL Server MVP
--|||"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:wbudnVf6Cc9-Es_eRVnyjw@.giganews.com...

> PKs are used as the
> default for foreign key references; they are clustered by default and PK
> columns default to NOT NULL rather than NULL. All of these defaults can be
> explicitly overridden
Hopefully it's obvious that if you override the default nullability on a PK
column by declaring it explicitly as NULL rather than NOT NULL then the
result is an error and the PK won't be created. :-)
David Portas
SQL Server MVP
--|||>> i have an invoice table where the (customer_id, iinvoice_nbr) uniquely identif
y a record [sic], also i have just a tableID (if I'm not mistaken, is a good pr
actice to do). which one should be my primary key? <<
I would have assumed that the invoice number would be the identifier
for an Invoice, and not the pair (customer_id, iinvoice_nbr). And I
assume that you have an audit trail and check digits on the invoice
numbers.
Let's get back to the basics of an RDBMS. Rows are not records; fields
are not columns; tables are not files; there is no sequential access or
ordering in an RDBMS so that table_id makes no sense. All attributes
have to map to something inthe reality of the data model -- where did
God put this table_id'
WHY do you think that "magical, universal table id" would be part of
the relational model' Can you quote anything from Dr. Codd or any
book on RDBMS to support this?|||"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1129496221.897333.45100@.f14g2000cwb.googlegroups.com...
> I would have assumed that the invoice number would be the identifier
> for an Invoice, and not the pair (customer_id, iinvoice_nbr). And I
> assume that you have an audit trail and check digits on the invoice
> numbers.
> Let's get back to the basics of an RDBMS. Rows are not records; fields
> are not columns; tables are not files; there is no sequential access or
> ordering in an RDBMS so that table_id makes no sense. All attributes
> have to map to something inthe reality of the data model -- where did
> God put this table_id'
> WHY do you think that "magical, universal table id" would be part of
> the relational model' Can you quote anything from Dr. Codd or any
> book on RDBMS to support this?
>
I also advise against the table_id here, however I think it's fine for
invoice_nbr to be an IDENTITY column and a candidate key.
In any case add a unique index on invoice_nbr and a unique index on
(customer_id,invoice_nbr). Which is your "primary key" is a matter of
preference. For performance the more important question is which index you
make your clustered index. You can either optimize for access by customer
or access by invoice_nbr, it's up to you.
David|||>> however I think it's fine for invoice_nbr to be an IDENTITY column and a
candidate key. <<
No. IDENTITYwill have gaps and has no check digits or other validation
methods. How do you get validation of the invoice numbers? How do you
get an audit trail, when you have machibne-generated, untraceable gaps?
Would you do this with upor checkbook?|||thanks for the great replies.
"rodchar" wrote:

> hey all,
> i have an invoice table where the customerID/invoiceNo uniquely identify a
> record, also i have just a tableID (if I'm not mistaken, is a good practic
e
> to do). which one should be my primary key?
> thanks,
> rodchar|||so, say for instance there are many customers. I would like each customer to
have their own sequence of invoice numbers. Please advise.
"Steve Zimmelman" wrote:

> If tableID is an auto-incrementing integer field, then I'd use that one.
> You can build an index on CustomerID, InvoiceNo for the lookups.
> Personally, I would make the InvoiceNo unique as well, unless there's a
> reason the system requires the uniqueness to be both customerID and
> InvoiceNo.
> -Steve-
> "rodchar" <rodchar@.discussions.microsoft.com> wrote in message
> news:2B8D7EAE-1AF3-4622-A219-63E72EEEF228@.microsoft.com...
>
>|||Personally, I have never used that concept. IMO, an invoice # should be as
unuique as the customer ID. That's the way I've always built all my sytems.
I don't think I've ever seen an accounting package that used duplicate
invoice numbers for different customers. I tend to think of invoice numbers
as transaction numbers. Unquie by their very nature. It's also less
complicated for the end-user to look up an invoice by just the invoice#.
Why should they have to select or enter the customer ID as well? Obviously
you should still have the customerID as part of the invoice record, I just
prefer not to combine the two for uniqueness.
HTH,
-Steve-
"rodchar" <rodchar@.discussions.microsoft.com> wrote in message
news:4CAB0A12-E8EA-498F-B39F-0BC7B68B9BD8@.microsoft.com...
> so, say for instance there are many customers. I would like each customer
> to
> have their own sequence of invoice numbers. Please advise.
>