One more regression defect with spares notification. System was sending notifications for workshop/unit sales orders. Now suppressed.
One more regression defect with spares notification. System was sending notifications for workshop/unit sales orders. Now suppressed.
Recent changes to spares order notifications would send emails when parts initially go on backorder. Although the email stated parts were on backorder it wasn't obvious in the email and it would be easy for customers to incorrectly assume their order was infact ready due to poor layout of the email. Overhauled email notification so email subject and body content make it clear what is going on. Also modernised emails to look alot nicer with proper tables/styles etc.
Includes database changes, you'll need to log all terminals out during upgrade
Includes database changes, you'll need to log all terminals out during upgrade
This version includes a significant new feature : detailed workshop scheduling. Scheduling provides a proper calander like system for workshop service management tailored specifically for workshop servicing.
Goto workshop -> utilities -> Schedule Availability. Here you add rules that define the schedule. Rules apply from top down. So lunch break from 12:00 to 13:00 overrides business hours rule before it, so between 12:00 and 13:00 it is non available time.
goto Workshop -> utilities -> Staff. Change setting 'Mechanic with regularly scheduled work' to access feature. Also here you can create customised avialability rules for the tech : these overlay ontop of default ones from above.
Access scheduler from Workshop -> scheduler. Some tips on how to use:
Fixed bugs with Whites Power Sports integration. Was working on our test systems but nowhere else. Should be fixed now
Tweaks to PC-EFTPOS. By default if PCEFTPOS sends a query back to c9 asking "Customer Copy?", c9 by default will now automatically answer Yes. Intent here is that we do not want to unnecessarily pause and risking failing txn finalisation with non essential post txn processes such as receipt printing. At this point the txn has gone through but PC-EFTPOS is withholding telling c9 this. Had an instance where operator walked away from the terminal and the txn in c9 cancelled due to timeout. This change will only impact a couple of setups/ banks where this question is sent back via the terminal.
Release 4.619 introduced a bug which broke ability to run manual backup by breaking the backup progress screen: screen would pause with no activity/progress. (Online backup was fine). The nature of the bug meant it may of affected other screens too (none I am aware of though).
Also finally got Husky F12 availability check to work again! Turns out it was working fine on non Windows systems (Linux/Mac which myself and James use to build/test) but wouldn't work on Windows. Should now be working again on all.
Includes database changes, you'll need to log all terminals out during upgrade
VicRoads integration continues to prove to be challenging. They'll happily show rego info on a bike on website but they actively try to stop likes of c9 from being able to perform exactly the same query fulfilling exactly the same end-user intent (save hassle of having to hunt down VIN numbers etc as bikes are checked in for a service for the first time) nor do they provide an accessible means to establish a technical partnership with them. We've sort of got it working again (it works mostly but will sometimes fail), but for how long we cannot reasonably say. This is all best effort type stuff and expect it to stop working again very soon.
C9 statement run can be configured for a print run for debtors without an email address as printed statements and for debtors with email addresses for emailing.
To do this you run the statement print process twice. Once for email and once for physical print.
Messenger reliability improvements
This version includes some experimental changes to help improve reliability of messenger related functions : SMS/Email delivery, backup syncing, scheduled tasks like automated SMS reminders plus a heap of other chores.
Looking at messenger problems we see consistently that issues are occurring when messenger is trying to reach C9's database but is unable to and is stuck, waiting for data that will never come. Root cause of these is typically hardware/network and OS setup. i.e. most common cause is timing of computers going into sleep mode disabling network card while c9 is mid database read, and to a lesser extent network links intermittently dropping out.
Solution involves implementing brute force timeouts on database waits. Messenger should now be able to better detect an unresponsive network and heal from this.
Other changes