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

Is there some technical or legal impediment to Sage from providing and maintaining an interface to the latest version of Crystal Reports?

Frankly, the 'obsolete' and '10 year' stuff sounds pretty "dog ate my homework" from here.

And it doesn't have to be Crystal Reports.

http://www.nichesoftware.co.nz/content/why-crystal-reports-sucks

but it should be simpler to set up than writing a printer driver.

I currently have all our forms (invoices purchase orders etc) set-up in one common folder on the server and everyone draws from them.  Everything is printed to "Adobe distiller"  acrobat professional to turn everything to PDF format.    

So this will no longer work at all even with the new CR?

I can not set up to  printer to the distiller?  

I know I am rambling but I am still trying to come to grips with the enormous change and enormous amount of work that has been forced on us by his company!!

I believe the actual printing, to Adobe Distiller will work the same with the 'Sage 50' forms, or without Crystal Reports forms.  You can use modified Sage 50 forms in a common folder.

Provided the Sage 50 forms can do what you need, you can share them in one networked folder.   We've had to do this with a mix of 32 and 64 bit machines, and a terminal server, to make sure everyone was printing the same invoice.  

If there is more to it than that, i.e. Crystal Reports passes information to Distiller to number the forms and file them or route them accordingly, then that's going to be more of a hurdle.

Sage has only stated that they are removing the Crystal Reports printing capability.   Presumably this goes beyond just 'not installing' it , and would mean that they're ripping out the code that interfaces to it.  (the parts that tell the Crystal Reports Print Engine (CRPE32.DLL) which form to 'run'. )  

There will be an option to "print to CSV' that will continue to export the same data that the current Crystal Reports forms use when you print them.  So, it'll still be technically possible to print them from some sort of desktop-shortcut-batch-file-script type of thing.

Sage has flat out stated that they will not be adding functionality to the current Forms Editor.  Perhaps some third-party developer will make a nice order entry and printing system available, hopefully without the gonky interface bugs that were riveted onto the software in 2008.  

Randy and Vannorman

We at Business Innovations Technology have a utility that will print Crystal Reports. But is not plug and play software, needs to be installed and configured properly, especially in a network enviroment

Does your utility provide printing directly from the Invoice / Order data entry screens, in one step?

Hi,

We actually have created Excel-based sales invoice. It allow you to open/print a sales invoice in Excel.

I don't know if it can help.

Randy

The utility only prints reports that would normally found under the MicroSoft Documents.

So any reports that directly query the database will print using the utiltiy

Invoices ---this is my understanding-- still can be printed and setup under the usual place but instead a Crystal Reports selection it will have "Other Reports". The CSV files will still be generated

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.  

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.

Hasn anyone solved this?  I am a crystal report developer and i have a system that would work for this, working on creating it as a printer file so it would flow directly from sage 50.  would anyone be interested in this?

Sorry i mean print driver

The Sage approach is to allow an export of the data that the old Crystal Reports forms used to use.  

When printing the Sage forms, the data export doesn't happen, andinvoice has not been posted  It's not yet possible to query the database for other information relating to the invoice, so the only data available is what is being sent to the print driver.  (even though the Project data is available, it's not possible to know which Projects are allocated to the invoice.

There are already some third party products that use other triggers to work around the lack of any print integration.  (i.e. they watch for a data file to be created, or watch the Sage 50 database for any updates to the tables that store invoices (XLGL appears to do this).

I have a working solution for this. You setup a NUL print driver and use that as the default for the forms, then I have a C# program that monitors for changes to the CSV files and auto-prints the Crystal Reports. I'm able to custom-select the report based on the customer type, print any type of form, etc. It works quite well.

I had thought that the Crystal Reports CSV files did not get updated when the Sage 50 type forms were selected - that's how it acted up to the 2014.2 release.  

For the 'Sage 50' forms, there were a half dozen printing fields added for 2015 as a sop for pulling the Crystal Reports integration in the 2014.3 release, but then there was a new bug introduced in printing January 1, 1901 in blank ship date fields.  This was fixed in the 2015.2 release, and now there is a bug in the form selection.  Thanks for trying, Sage.

Kudos to all the independent developers working to keep a reasonable level of form printing capability available.

There is an option in the form setup to continue generating the CSV files.

Randy,

Justin is correct.  The option to export csv files is at the bottom of the Setup, Reports & Forms left-hand part of the screen (Form Data Export I think, going from memory).  It's been there since the release of 2014.3 but there is/was a significant bug in it, in that it will turn itself off "somehow" on network systems.

I do not know if that bug has been fixed.  Sage has not told me they found it and fixed it, it doesn't look like it was addressed in the 2015.2 release notes, and my clients have not told me it is still a problem. (though they all know about it and how to workaround it, and my program gives the user the option to set it for them if it is not set, but they have to reopen Sage 50 for their instance to see it).

The setting mentioned above is not a user-defined setting (as are all other Reports & Forms settings), it is a company-wide setting.  Set it once by any user capable of setting it and it is supposed to be set for all users but all users must then open the file after that to see the flag has been set.  If they have the file open when another user sets it, that instance of the program will not know it is set because it is only read at the opening of the file.