Till Issues
We have just spent the last hour sorting out till balancing errors and adjusting many pages of client accounts due to operator errors from not following procedures. A few things arise from this:
- When you print out the til balance 'Refund-Credits' still appear on the sheet - they should not (Refund-EFT and Refund-Cash should). It adds to confusion when staff are checking it
- The Rounding error is still present on the balance sheet - I think it is set to round to the nearest (up or down) 5c - if it is it is not calculating correctly
- Errors frequently arise from staff not entering EFTPOS amounts correctly in the machine and then trying to correct their errors. I do not know programming but would it be a major task to link the EFTPOS machine directly to the payment module or would this vary too much depending on the machine you use?
Thanks,
Nick
RE: Till Issues
Not sure what you mean by "refund - Credits" and shouldn't be on till report. I assume you mean refund - credit card ? If so why shouldn't these be on till summary ?
Also not sure what you mean by rounding error. The rounding only occurs on cash payments and is setup in administration->organisation to mathematical rounding to nearest 5c. The till balance will show the total of the cash round in the cash totals which is correct as the this will give you the real cash that is in the till. I haven't heard of an error in these totals so if you have found one you may have to be more precise as to the nature of the error then we can have a look at it ..
I think it would be a great enhancement to integrate eftpos devices into the application. I imagine it would be quite different requirements and coding for different equipment. Anyone out there have experience in this ?
Cheers Tony
-----Original Message----- From: users-bounces@lists.openvpms.org [mailto:users-bounces@lists.openvpms.org]On Behalf Of paradisevets@internode.on.net Sent: Friday, 19 December 2008 19:50 To: users@lists.openvpms.org Subject: [OpenVPMS Users] Till Issues
We have just spent the last hour sorting out till balancing errors and adjusting many pages of client accounts due to operator errors from not following procedures. A few things arise from this:
- When you print out the til balance 'Refund-Credits' still appear on the sheet - they should not (Refund-EFT and Refund-Cash should). It adds to confusion when staff are checking it - The Rounding error is still present on the balance sheet - I think it is set to round to the nearest (up or down) 5c - if it is it is not calculating correctly - Errors frequently arise from staff not entering EFTPOS amounts correctly in the machine and then trying to correct their errors. I do not know programming but would it be a major task to link the EFTPOS machine directly to the payment module or would this vary too much depending on the machine you use?
Thanks,
Nick _______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/mailman/listinfo/users
_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/mailman/listinfo/users
RE: Till Issues
Direct EFT integration... we would be willing to co-fund such a project... For the right price :)
Matt C
On Sat, 20 Dec 2008 13:15:02 +1100, "Tony De Keizer"
wrote: > Hi Nick, > > Not sure what you mean by "refund - Credits" and shouldn't be on till > report. I assume you mean refund - credit card ? > If so why shouldn't these be on till summary ? > > Also not sure what you mean by rounding error. The rounding only occurs > on cash payments and is setup in administration->organisation to > mathematical rounding to nearest 5c. The till balance will show the total > of the cash round in the cash totals which is correct as the this will give > you the real cash that is in the till. I haven't heard of an error in > these totals so if you have found one you may have to be more precise as > to the nature of the error then we can have a look at it .. > > I think it would be a great enhancement to integrate eftpos devices into > the application. I imagine it would be quite different requirements and > coding for different equipment. Anyone out there have experience in this > ? > > Cheers > Tony > > -----Original Message----- > From: users-bounces@lists.openvpms.org > [mailto:users-bounces@lists.openvpms.org]On Behalf Of > paradisevets@internode.on.net > Sent: Friday, 19 December 2008 19:50 > To: users@lists.openvpms.org > Subject: [OpenVPMS Users] Till Issues > > > We have just spent the last hour sorting out till balancing errors and > adjusting many pages of client accounts due to operator errors from not > following procedures. A few things arise from this: > > - When you print out the til balance 'Refund-Credits' still appear on the > sheet - they should not (Refund-EFT and Refund-Cash should). It adds to > confusion when staff are checking it > - The Rounding error is still present on the balance sheet - I think it is > set to round to the nearest (up or down) 5c - if it is it is not > calculating correctly > - Errors frequently arise from staff not entering EFTPOS amounts correctly > in the machine and then trying to correct their errors. I do not know > programming but would it be a major task to link the EFTPOS machine > directly to the payment module or would this vary too much depending on > the machine you use? > > Thanks, > > Nick > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > http://lists.openvpms.org/mailman/listinfo/users > > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > http://lists.openvpms.org/mailman/listinfo/users >_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/mailman/listinfo/users
[OpenVPMS Developers] EFT integration
There is a java API named JavaPOS (http://www.javapos.com/) which appears to have some support with EFTPOS terminal providers (e.g some Ingenico terminals).
All other APIs I've found have licensing schemes not compatible with OpenVPMS.
What types of EFTPOS terminals are being used in practices?
-Tim
mpcosta wrote: > Hi Nick and Tony, > > Direct EFT integration... we would be willing to co-fund such a project... > For the right price :) > > Matt C > >_______________________________________________ OpenVPMS Developers Mailing List developers@lists.openvpms.org http://lists.openvpms.org/mailman/listinfo/developers
EFT POS
We use a Cadmus system (Counter Top – CP03 & PM03 ) thru Bendigo Bank (http://www.cadmus.com.au/products.html)
A breif look at their site suggests they have their own integration solutions... probably licensed. Blurgh...
Matt C
Re: EFT POS
Do banks let you provide your own hardware?
If the hardware supports the OPOS standard it may be possible to use a java -> OPOS wrapper. According to http://www.javapos.com/bridge.html , Wincor Nixdorf made one freely available, although I haven't yet found it. It was released back in 2000.
-Tim
_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/mailman/listinfo/users
Re: EFT POS
Matt C
On Fri, 09 Jan 2009 15:08:18 +1100, Tim Anderson
wrote: > mpcosta@boroniavet.com.au wrote: >> We use a Cadmus system (Counter Top – CP03 & PM03 ) thru Bendigo >> Bank (http://www.cadmus.com.au/products.html) >> A breif look at their site suggests they have their own integration >> solutions... probably licensed. Blurgh... >> >> Matt C > Do banks let you provide your own hardware? > > If the hardware supports the OPOS standard it may be possible to use a > java -> OPOS wrapper. > According to http://www.javapos.com/bridge.html , Wincor Nixdorf made > one freely available, although I haven't yet found it. > It was released back in 2000. > > -Tim > > > > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > http://lists.openvpms.org/mailman/listinfo/users >_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/mailman/listinfo/users
Till Issues
In Retail, the standard for integration to retail devices like handheld scanner, thermal printer and pinpad is through UPOS (OPOS and JPOS are the older standard). This standard is managed by ARTS, the Association for Retail Technology Standard. It's the industry's IT standards group. http://www.nrf-arts.org/UnifiedPOS/default.htm.
Your biggest issue so that not all UPOS drivers are written the same. Depending on the manufacturer (just like video cards), you'll be able to get different ranges of abilities. I know in the US, you can almost get anything (down to.... if the paper in the printer is empty or if the reader is due for a replacement). In Canada, the pin pad is a black box due to financial regulations. You can only get a status code back.
Till Issues
Dear Nick,
We have often had issues with the automatic rounding. As reported here it only happens with cash payments. However if the person taking the payment first adds the new payment as cash, then changes to credit card or eftpos, the amount does not change back to the unrounded amount. Let your staff know that if they have started the transaction for cash they need to delete this and start again. What we do is stay on the invoicing screen until the client has provided the method of payment. That way the staff member goes straight to the correct method, and no rounding errors are introduced. This method also helps with those clients that decide to add another product at the last moment. This method allows another error to occur - ie previous balances have to be manually added to the total....
RE: Till Issues
I have tested this on both version 1.2 which I believe you may be using and the newer 1.3 version and I cannot get this to happen.
I had a customer with a balance of 125.96. I went to payments and added a new payment and hit add immediately to create a cash payment. The amount to pay came up as 125.95. I then deleted this payment type and selected credit card payment type and it came up automatically with $125.96 in the amount field. There was no need to cancel the whole payment just delete the specific payment type and add a new one in the same dialogue ?
In regards seeing balances this has been rectified in version 1.3 where the payment dialogue now displays useful information such as previous and current invoice balances, overdue amounts and totals. In 1.2 people where relying on the summary panel total which was visible while you were in the payment dialogue but was not updated with any changes made during the current check-out workflow until after the workflow was completed.
Cheers Tony
-----Original Message----- From: users-bounces@lists.openvpms.org [mailto:users-bounces@lists.openvpms.org]On Behalf Of clinic@kilsythvet.com.au Sent: Thursday, 29 January 2009 10:55 To: users@lists.openvpms.org Subject: [OpenVPMS Users] Till Issues
Dear Nick,
We have often had issues with the automatic rounding. As reported here it only happens with cash payments. However if the person taking the payment first adds the new payment as cash, then changes to credit card or eftpos, the amount does not change back to the unrounded amount. Let your staff know that if they have started the transaction for cash they need to delete this and start again. What we do is stay on the invoicing screen until the client has provided the method of payment. That way the staff member goes straight to the correct method, and no rounding errors are introduced. This method also helps with those clients that decide to add another product at the last moment. This method allows another error to occur - ie previous balances have to be manually added to the total.... _______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/mailman/listinfo/users
_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/mailman/listinfo/users
RE: Till Issues
I also tried this at work today and could not get the error either?
Matt C
On Thu, 29 Jan 2009 16:26:42 +1100, "Tony De Keizer"
wrote: > Hi, > > I have tested this on both version 1.2 which I believe you may be using and > the newer 1.3 version and I cannot get this to happen. > > I had a customer with a balance of 125.96. I went to payments and added a > new payment and hit add immediately to create a cash payment. The amount > to pay came up as 125.95. I then deleted this payment type and selected > credit card payment type and it came up automatically with $125.96 in the > amount field. There was no need to cancel the whole payment just delete > the specific payment type and add a new one in the same dialogue ? > > In regards seeing balances this has been rectified in version 1.3 where the > payment dialogue now displays useful information such as previous and > current invoice balances, overdue amounts and totals. In 1.2 people where > relying on the summary panel total which was visible while you were in the > payment dialogue but was not updated with any changes made during the > current check-out workflow until after the workflow was completed. > > Cheers > Tony > > -----Original Message----- > From: users-bounces@lists.openvpms.org > [mailto:users-bounces@lists.openvpms.org]On Behalf Of > clinic@kilsythvet.com.au > Sent: Thursday, 29 January 2009 10:55 > To: users@lists.openvpms.org > Subject: [OpenVPMS Users] Till Issues > > > Dear Nick, > > We have often had issues with the automatic rounding. As reported here it > only happens with cash payments. However if the person taking the payment > first adds the new payment as cash, then changes to credit card or > eftpos, the amount does not change back to the unrounded amount. Let > your staff know that if they have started the transaction for cash > they need to delete this and start again. What we do is stay on the > invoicing screen until the client has provided the method of payment. That > way the staff member goes straight to the correct method, and no rounding > errors are introduced. This method also helps with those clients that > decide to add another product at the last moment. This method allows > another error to occur - ie previous balances have to be manually added to > the total.... > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > http://lists.openvpms.org/mailman/listinfo/users > > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > http://lists.openvpms.org/mailman/listinfo/users >_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/mailman/listinfo/users