× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



A solution I found that was exciting for a few shops was to create an Intranet website then develop reports targeted for each group. It is reasonably easy to do and is well received. I have also, in a few instances, created the information in graph form as that was the easiest way for the user to keep perspective of the various decision points.

Spreadsheets tend to worry me because self-proclaimed "experts" find it too easy to massage unflattering data into more pleasing results. At least, that was the unpleasant result in one location.





On 1/29/2013 3:38 PM, Buck Calabro wrote:
On 1/29/2013 1:02 PM, Jeff Crosby wrote:
So how ARE you creating the file for Excel?

Scott Klement's HSSF wrapper.

What file extension? .csv? .xls? XML?

.xls

Are you doing any kind of cell formatting/alignment? What about column
headings?

Yes and yes.

Are you converting spool files or DB files to Excel? Or both?

Are you bursting these "reports" such that each sales rep (for example)
gets his or her own pages only? Or do you create separate reports for each?

I personally avoid simple scrapers like the plague. It seems simple and
easy to convert an existing spooled file to a spreadsheet, but then you
have exactly the issues you bring up. The printed report is 500 pages
long, goes to 9 different regional office managers and the last (total)
page goes to the president's office. With the printed report, the
operator manually separates the sections, puts them in the proper
interoffice mail bins and Robert is your mother's brother. Simply
converting this to a spreadsheet means some other sort of manual
handling to create new spreadsheets for each manager and the president
and email them off.

I haven't crossed that bridge just yet; I'm still convincing people they
don't really want to see a 30 page detailed listing which they manually
scan looking for error messages. Instead, I'm giving them a single
spreadsheet containing only the records in error. So I'm taking the
opportunity to do it differently, rather than electrify the manual process.

If I had to send a separate spreadsheet to different department heads I
think I'd have a 'distribution file' containing the program name, report
name, 'level break' ID, and recipient ID. There aren't really that many
level breaks: perhaps department code, regional office ID, building
number, business unit and so on. Use an integer for that code and there
are many millions of possibilities. Write a subprocedure to convert
table + column names to level break ids and it's not that hard to return
the recipient for a given level break. Needs some fleshing out, but
that seems a decent start.
--buck

On Tue, Jan 29, 2013 at 12:29 PM, John Yeung wrote:

On Tue, Jan 29, 2013 at 11:31 AM, Terry Nonamaker wrote:
I would still stick to part of my original input
....that she should probably redesign the report
....because it's going to be a mess the way it is

Yeah, when you have to start asking "how wide can a report be?" it's a
strong indication that you should probably be asking "will the user(s)
accept something other than a printed report?"

Most users I know of would actually prefer NOT to get a printed report.

The shop where I work is probably toward the old-school end of the
technology scale, and even here we hardly ever create any new printed
reports. Most new reports are in Excel, and we're also gradually
migrating old reports to Excel.

It's not hard to do. If we can do it here, it can be done anywhere.

John

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.