Hi Vannorman,

The old Crystal Report components that enable the printing and viewing of Crystal Report forms and reports will be removed.  Those components are from an obsolete version of Crystal Reports (8.5) that hasn’t been supported by Sage for more than 10 years and, that Sage can no longer legally provide to customers.

For options other than Sage 50 form designer, please take a look at the following KB article.

What are my options if I need additional functionality not available in Sage 50 forms? - KB32636

Hi Keith,

I took a look at the article KB32636 and have a question: I have Sage 50 2013.4 and I am wondering if it's possible to upgrade to Sage 50 2014.3? I can't quite tell from looking around Sage's website if this is a possible upgrade and I'd like to check out the feature that allows one to export reports and forms to .csv files (as outlined in the article KB32636.)

Thanks,

Kristine

It may have been unclear in the article, the 2014.3 update hasn't been widely released yet.  There may be a beta version available to Certified Consultants.

The 2014.3 release doesn't add functionality, it removes it.  Basically it's supposed to work the same as prior versions, including the one you have, up to generating the CSV files.  

If you want to test how the new release will work, without killing a lot of trees, select a Crystal Report form and print it to a PDF or to a printer that's shut off, then delete the print job, and work from the CSV files that are created.

The new release will stop after generating the CSV files, where the current versions call a DLL that runs the Crystal Report that reads the CSV files.  

So, after the update is installed, if you have a current, licensed version of Crystal Reports, you will have to print to CSV, then throw Crystal Reports into gear and get it to print each invoice, one at a time.  Probably batch printing of Crystal Reports invoices will have to be done with a custom program.

for an invoice, it looks like a handful of CSV files are created in Documents\Simply Accounting\forms\CAN2014

Randy

to maintain a seemless interface, do you know if Sage is planning on replacing the DLL with the ability specify a batch file to run ?

so that I can specify invoice.bat to run when printing invoices

and invoice.bat starts up crystal reports, msaccess, etc

Hi Randy,

I don't have any version of Crystal Reports, unfortunately, and I tried printing to file in Sage 50's Printer Setup, and Sage 50 seems to ignore that I checked the "Print to File" box and just prints to whatever printer I have selected, whether that be to an actual printer or the PDF printer driver. I thought that if I generated a postscript, .ps, maybe I could peek in there to see what I could grab. (A .ps file is just a text file, afterall, and in this case it would be a capture of invoice data being sent to the printer.)

Distiller won't help as all it does is take a .ps and basically finish off generating the pdf. Having used Acrobat since version 1, I know this oh too well... originally, that is how pdfs were generated... it was ALWAYS a muti-step process... you couldn't even pass certain image formats through Distiller, like .eps, until they were first converted to tiffs in your parent document. All a pdf really is, is the electronic/digital capture of whatever was to be printed - if you can print it, you can pdf it, I always say. And hence, pdf is not a 'working' format but rather a 'finishing' format. Perfect for Sage users to generate digital copies of their invoices and reports, for example.

The trick is, is to capture what happens between hitting the print button and the actual printing. Sage doesn't seem to want to let a user access that, either.

My wish would be to grab the .ps file and see if I could parse out the invoice data I need... I suspect the answer will be no, because that data will only include the data used in the invoice in the first place. Ideally, I'd like to go back an earlier step and add other data into my invoice from what I've input as custom fields. THAT, however, seems to be overly complicated :( Sage 50 is just a database so I fail to understand why custom fields input within Sage cannot be accessed in Sage's form designer. I find that so odd I can only think it intentional on Sage's part. There must be some legal issue or something, preventing them from doing this?

To me, as I transition into accounting, this is indicative of how the accounting field never seems to be able to respond effectively to the needs of a given industry. Rather, accounting seems to impose itself onto an industry. While to a certain extent that is necessary in order that accounting principles/rules/laws be followed, accounting seems to think that that is where the buck stops, if you will. Again, I fail to see the harm in accessing custom fields in the form designer, as that would allow our invoices to be organized by AFE number (Authority for Expenditures) in the oil and gas industry. This is critical to what we do and as a result I do double time for invoicing. I actually take the invoice pdf generated from Sage 50, copy from it the text in the invoice pdf, and paste it into Excel and work with THAT information. Rather labour intensive since that copy-paste step is not neat... no columns/tabs are copied, or anything, just one smoosh of text into Excel (I get the same result when I export to Excel from within the pdf.)

Anyways, I'm writing a book here! LOL!

Re to maintain a seemless interface, do you know if Sage is planning on replacing the DLL with the ability specify a batch file to run ?

The trick is, is to capture what happens between hitting the print button and the actual printing. Sage doesn't seem to want to let a user access that, either.

That was my suggestion, too - add a configurable parameter so that a batch, a script, an EXE, or SOMETHING could be run automatically.

I only know what they explained in the tech document, if they had intentions of keeping the process of printing customized third party forms to be automatic, it could have been done by providing some sort of configurable command line. 

I would imagine that more or less all the current printing to a Crystal Reports form does, is to call the printing DLL and pass it the filename of the report form to run, and the location of the CSV files. 

 find that so odd I can only think it intentional on Sage's part

It's how software is built and marketed - once something is developed and tested, it costs almost nothing to put it in every product.  Small software companies usually produce one or two 'editions' of their software - perhaps a 'lite' or 'community' version that's free, and a more advanced 'Pro' product that you have to pay a license fee to use.  

It almost surely costs more to pull all the 'Pro' features out of the product and test to make sure it still works properly, than it would to leave them in.  But if they left them in the 'lite' edition, few would pay for the 'Pro', and they wouldn't have a viable business.

If you buy a tax software product intended for the consumer market, for instance, it won't have capabilities for printing letters for clients and doing billing by form.  The features are intentionally removed for that market, partly as an incentive to move users of the software to a more appropriate product.  It's a strategy that makes sense in that market where the software is outdated for everyone, every year.

But...

If anyone from Sage thinks that hacking functionality *out* of Sage 50 is going to influence me *towards* switching to one of their *other* refurbished 1980's technology offerings, they can call me and we can discuss the likelihood of that happening. 

I have been away from this forum for a bit, but I totally agree with the question as to why SAGE cannot (or will not) open up their platform and allow us access to their data tables so that those of us who have added or converted certain fields could incorporate them into our invoices or purchase orders etc.  If that was allowable I could totally use their form designer for the forms I need to print out of SAGE.  We also have no intention of being pressed into upgrading.

I need to get Crystal Reports invoices working for a client. Has anyone found a work-around yet? I haven't found anything online so my current plan is to build a windows app that will monitor for changes to the CSV files and then auto-print the invoice with a separate Crystal engine. Basically Sage 50 will print to a null (dummy) printer, generate the CSV files and then trigger a custom app to print the Crystal Report.

Something like that should work.  

I'm not certain what logic could have been behind the lack of any sort of an optional command line that could be configured.  According to the documentation, all the new 'print to CSV' does, is create the CSV files.  

From there, you have to initiate the printing process, so a utility that watches the directory for changes should be able to kick off a print job.  It would have to check all the CSV files to see which ones have changed, in order to figure out which form to print, I suppose.

Unless your client is in New Brunswick, the easiest fix / work around is to go back to the previous 2014.2 release.  There are no new features in the 2014.3 release.

I thought of building a Windows print driver that would send most of the data to be captured and formatted the way I want it.   But for a lack of skill and ambition, I would do it.  

Something like that should work.  

I'm not certain what logic could have been behind the lack of any sort of an optional command line that could be configured.  According to the documentation, all the new 'print to CSV' does, is create the CSV files.  

From there, you have to initiate the printing process, so a utility that watches the directory for changes should be able to kick off a print job.  It would have to check all the CSV files to see which ones have changed, in order to figure out which form to print, I suppose.

Unless your client is in New Brunswick, the easiest fix / work around is to go back to the previous 2014.2 release.  There are no new features in the 2014.3 release.

I thought of building a Windows print driver that would send most of the data to be captured and formatted the way I want it.   But for a lack of skill and ambition, I would do it.  

I'm currently only interested in printing invoices, but I may need to look at statements in the future. It must be possible to detect between invoices and statements as the two files I currently use for invoices don't contain sufficient data for printing a statement.

I already have a program that allows the user to quickly switch between different invoices formats and printers (since they are running multiple companies out of one Sage 50 company). I plan to just modify it to include a setting for the path to modify. Printing the CR should be easy enough.

If anyone else is interested, let me know and I'll share my program.