It seems that my POS module has decided that it doesn't want to print Sales Receipts anymore ! Sales 'appear' to process and the integrated CC system still prints out cc receipts - but no Sales Receipts. If I select Reprint, POS will print the last Sales Recipt from the previous days batch which makes me wonder if this is not a printing problem but a database issue. We've been reduced to hand written receipts. Any assistance would be greatly appreciated.
hi Mike, I belive the receipt printing for sales is already selected Go to SO Manager, Database/Registers/Receipt Formats. I suggest you to reattach the receipt.
Also are you have not customized any receipt format or you have changed any format.
I have attached and reattached the standard Receipt format several times without success. I've tried both the format supplied by the credit card company(which was attached when the Receipts stopped printing) as well as the MS default that came with RMS. The only change I made was to a setting in the Epson Printer driver that tells it to cut the paper after printing the first page. I have reset this to the driver's default setting. When we opened a fresh batch on Friday morning Sales Receipts would not print - but the cc slips still did. There were/are no error messages.
Some more info... I've also noticed that the x and zz reports don't print either (the RMS x report default is attached too). Basically the POS module will not print anything. I know the transactions are hitting the database because I can recall and void them with a Shift key. Interestingly when I open the current batch in the Ops Manager module there are no transactions. Is this normal if they didn't print? I can reprint a Sales Receipt from a prior closed batch from Ops Manager - which tells me the format must be attached and working. I have run the RMS Installer "Repair" wizard - no change.
I'm plann> hi Mike, I belive the receipt printing for sales is already selected
Thanks for your feedback Akber. I have been able to resolve this issue and get Sales Receipts printing again. It took all of my expereince as an Oracle dba a alot of testing to isolate the issue which turned out to be a missing field value that associates the receipt format with the printer. I was misled by the fact that credit card signature receipts still printed - just no Sales Receipt. It remains a mystery as to how this setting was lost, but replacing it restored printing functionality.
This expererience unscores the value of good Error messaging. Perhaps we in the Oracle community have been spoiled but I prefer to think that RMS could do with an upgrade in this area. It would have been much less painful to track down the problem if the POS module had informed me that Sales Receipt link was broken or unavailable when the Sales receipt failed to print.
I can fairly say I learned a lot; there?s nothing quite like a ?system down? scenario to sharpen one?s focus and activate the little grey learning cells. At the end of the day this was a deceptively simple fix; its context was the real challenge. A day earlier I had finished integrating a credit card plug-in that was itself fraught with misadventure most notably a pin pad with firmware for another time zone that would work intermittently and an API key containing the letter ?O?! Needless to say my brainware was ready for a vacation when I got the ?frustrated business partner? call. I was primed for yet another credit card integration woe. Ugh. As I mentioned in my original posting, the issue did not appear to be related to printing because the system was still printing a credit card signing page and I was able to print duplicate receipts from previous batches dated before the credit card integration. It wasn?t until later that I learned (by scanning other postings in this forum) that printed receipts are stored as bitmaps and therefore do require the register receipt format. I began troubleshooting by rounding up the usual suspects (rebooting, printer drivers, Installation routine ? Repair, Services restart, ECP printer setting in the BIOS, those sorts of things). Once I was sure nothing basic was corrupted I disconnected the hooks from the credit card plug in and turned off the service. I then reset the receipt format to the default RMS template ? or at least I thought I did ? in and effort reverse the changes that I had made installing the credit card plug-in. No luck. I appeared to be heading down a blind alley so I decided to take a different tack. One of my initial thoughts was that there may be a corrupted record in the database. I recalled glossing over a T-SQL script from the credit card set plug-in installation that added a table to the database. I ran the check database utility and browsed through the table records with SQL Server?s Management Studio viewer. Nothing appeared to be wrong so I backed it up and restored a daily backup from a couple days before the integration - still no sales receipt. At this point I decided to do some testing on my laptop. I had installed RMS on it originally so I could get familiar with the software and be able to support staff at the store over the phone. I had also not installed the credit card plug-in so I could be assured that testing would be ?plug-in? free. As you might expect, the Sales Receipts printed perfectly. I then restored the most recent database backup and it still printed perfectly. I was finally getting somewhere. Now I knew beyond a shadow of a doubt there was no database issue and I was even more convinced that the plug-in was the ?evil-doer? (I was wrong!). My daughter likes to play Sesame Street online and I had just read The Tipping Point by Malcolm Gladwell who was impressed by the creators of Sesame Street for their insight into how to connect with children and teach them problem solving skills. I found myself humming ?one of these things is not like the others? while I was comparing each RMS setting on my laptop with each setting on the Production system. They all matched but one ? Ops manager\Database\Registers\Properties\ReceiptPrinter1\Options ? Journal Receipts from this Printer. I called the help desk at the credit card company and the tech confirmed that I had to reset this field to the sales receipt format that they had provided; this was not in their documentation. Problem solved! It remains unclear to me how the original setting I had applied during RMS setup was lost. I had glossed over it several times during my troubleshooting because I assumed it was an optional value that I hadn?t set during the original RMS setup. I went back and tested swapping receipt formats; this field remained unchanged. I still don?t know the how or when this field value was lost. The ugly point about this is that this setting - and only this setting on this particular menu - needs to be changed when the receipt format is changed ? so why is it in a frame labeled ?Option? given a convoluted name and buried on a hardware selections menu remote from the Receipt Format menu? (In programming parlance when something is an Option ? like a signature in a method - that means it isn?t required! Perhaps my background was now working against me.) My finger was starting to wag uncontrollably! Another one of those timeless lessons from Sesame Street that appears to have been somewhat lost on the architect/s who designed the RMS interface: ?put the blue shapes over here and the red ones over there?. I work on very large ERP applications in my software business and I?ve always found that users much prefer software that has a thin menu architecture that keeps closely related items in close proximity to one another; it?s far more ?learner friendly? and manageable when it comes to troubleshooting. In point of fact the POS module is great; it?s simple and with a few Shift Keys users can access everything they need. The Ops Manager module could do with some improvements in this area in my humble opinion. In terms of lessons learned I would advise others to implement a complete backup installation on a separate PC - sort of a reverse test environment. This provides a very fast and simple fail-over solution. Our small retail business doesn?t warrant having a database server on site so I have now setup our shop register on two interchangeable laptops running SQL Server. The touch screen, receipt printer, dongle and other peripherals are connected to a high end docking station on the retail floor that either laptop can plug into. Each night the database is backed up both to a remote server and a 5 GB removable PC slot hard drive that also leaves the site. This drive can be popped into the backup lappy at any time to sync the databases. Using laptops also allows us to store them in a secure room overnight for extra insurance. Hope this helps others. Cheers. MikeP
BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.