Re: Alternatives to printed reports was: O spec help needed please

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