Each Client wants a receipt formated for his own

  • Thread starter Thread starter Wael
  • Start date Start date
W

Wael

Dear All;

I have an access 2002 stock control application and each one of my clients
has his own formatted report. When I redesign the report to meet his
requirements I need to go back to the source mdb file and make the changes
then make an mde and deliver the application, and so on for each client.

Is there any way that I can keep my mde file as a standard application and
make the report for each client as separate report?

Any help will be appreciated.



Thanks in advance



Wael
 
What customization do your users want?

If it's a company logo, there's a couple of options:

a) Put an Image control on the report. Use the Format event of that section
(report header?) to set the Picture of this image control. For example, you
might require them to supply a file named logo.jpg in the same folder as
CurrentDb.Name.

b) Put the logo in a subreport. Use this subreport on all the relevant
reports, and there's only one place to change.

If it's the actual text for the report, you can put that in a memo field in
a table, and read it from there. There are several ways to approach this.
Examples (in increasing complexity):

a) a simple DLookup() to get the text.

b) Let them create a series of template paragraphs (stored in a memo field
in a table), each one date limited, and with sorting. You write a function
to retrieve the paragraphs that apply for the date of the report, in the
order required. You may also need to provide some way to handle 'merge'
fields (e.g. where you Replace() the text {Company} with the actual name of
the company.)

c) Programmatically append the output of (b) above to a table where you
store the actual text used in the report. Use this if the user wants to be
able to edit each report individually.
 
Thanks for the quick reply



The problem is that each client has his own preprinted papers with a
deferent field's size and position and some fields are not there and my
application will fill out these fields with data and it will not print on an
empty white paper like in this sample:

Sample1:

Date :

Receipt No:


Name :




Item No
Item Name
Qty
Price
Total































Sample2:

Receipt No:

Date :


Name :




Item No
Item Name
Brand
Qty
Price
Total
 
Yuck! It is actually possible to use Report_Open to set the Left and Width
of the text boxes (in twips where 1440 twips = 1 inch), but that's messy.

You might be better off explaining that pre-printed papers come from the
ancient past before computers, when the actual number of rows needed for any
particular receipt/invoice was unknown. It's far better to print the total
immediately below the last entry, rather than leave space where some forger
can add stuff.

Unless there's some really good reason for using pre-printed forms (e.g.
government requirement), it's just so out of touch.
 
If the report drives from one record of data you could switch approaches and
use Microsoft Word merging to generate the report. Example in my latest
application the user uses Microsoft word to generate donation receipts.
They customize them how they want and add merge fields where they want. In
the end just a new word file is put in a directory.

If you want to see an example of it in action see:
http://www.donationmanagementsoftware.com

I basically used Albert kallals word merge code with a few little changes
(so it works better with word 2007 and I might of put some code to strip out
other types of quotes from different languages from data fields).

However go with regular reporting if that works for you.

My two cents,
Mark Andrews
RPT Software
http://www.rptsoftware.com
 
Hi Wael,

Logistics really loves it preprinted forms, and after all they are the
customer and pay for it right?
What I do is storing all different formats in 1 application, and I have a
parameter table that decides which one to use. So when I install the app
with the customer I just have to set the right parameter to get the lay-out
the customer wants.

gr
NG
 
Thanks for the reply.



The problem is that what we want to print is a receipt / invoice and what I
am afraid of is changing the data when it is merged with word this could
cause a manipulation in invoice values and the management could not know
about that. So we simply want the printing to be fully automated and the
employees could not interact with the process.

Is there any way that the merge process could be automated and the user can
not interact with it or use our template to create a fake invoice?
 
In that case you need to build the report customization options right into
the access application (similar to what the other posts talked about). If
that's too difficult (to get the exact layout and flexibility you need),
then you could launch another database with just the one report with linked
tables to the backend db. You then supply this new database (with one
report) to everyone.

Word merging is usually meant for documents you want the user to modify (the
design of the template and possible after the merge occurs).

Your problem is you need a full fledged design tool to layout the report so
you know it will print correctly, such as Access reporting design or
Microsoft Word.

HTH,
Mark
RPT Software
http://www.rptsoftware.com
 
Another option would be to create the report in another mde file. This way,
each client could have their own reports mde file

Add some code in the main application to check to see if the reports.mde
file is present. If it is, then make sure it has all of the appropritate
tables linked to it.

Then, when the user indicates that they want to print an invoice, you could
use automation to:
1. open another instance of Access

Dim obj as Object
set obj = GetObject(currentproject.path & "\reports.mde")

2. open the reports.mde file using the GetObject( ) function

Dim app as Application
Set app = obj.application

3. and then use the OpenReport method to run the report

Dim strCriteria as string
strCriteria = "InvoiceID = " & me.cbo_Invoice
app.docmd.OpenReport "Invoice", acViewPreview, , strCriteria

4. Once the instance of Access is open, you could then set the app and
Object objects to nothing

set app = nothing
set obj = nothing

5. Finally, in the close event of the report, you could quit that instance
of Access.

You might also want to consider hiding the database window and other Access
menubars in the report mde.


HTH
Dale
 
Back
Top