Implement a new Payment type

Message from benjamin.charlton@kalingaparkvetsurgery.com.au benjamin.charlton@kalingaparkvetsurgery.com.au

I was wondering how everyone felt about permanently adding a new Payment type
for Direct Deposits to the core Openvpms system, when considering how to
process these payments made by bank transfer nothing really fit,  I try and
make sure that our eft/cc totals balance exactly against the daily totals, as
does the cash.  Using a account credit didnt really track the payment as
well as i believe it could with a new payment type just for that purpose.  

If people are happy to have this added I think I can help add it.  For the
end user it will mean adjusting 

* Till Balance Reports
* Deposit Reports

Although the existing deposit report will work ok, its just that it doesnt
specify a total for Direct Deposits it will list them in the detail pages.

As a part of adding this I would also ask the community what it thought about
reordering the payments types on the deposit report.

The Current order is :

1) Cheque
2) Credit
3) EFT
4) Cash (detail not currently printed)
5) All other payment Types (this is where Direct Deposits currently gets
reported)

My suggesting would be to all most revers it.  Make the report

1) Cash (not printed)
2) EFT
3) Credit
4) Direct Deposit
5) All Other Payment Types (a page per type would be printed or none if
there werent any)
6) Cheque

The reason is that this means on the last deposit summary page the cheque
list will be printed, with tweaking this page can then be used as a bank
deposit slip to do the cash deposit.

Any thoughts

_______________________________________________
OpenVPMS User Mailing List
users@lists.openvpms.org
To unsubscribe or change your subscription visit:
http://lists.openvpms.org/listinfo/users
Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Implement a new Payment type

 

Where did my original post go....anyway Tony

Thats a really nifty approach!!!  

Can I ask though...how can I get CentreLink to pay my clients bills!!! :) 

(I am guessing your talking about Finacial Supplement payments) But still!

 

I can see how using an administrative Till would be helpful, to avoid the Till Clearing issues.  

This is a much better implementation than I suggested, it is infinitely more flexible.  

Ben

Re: Implement a new Payment type

Hi Ben/Tony,

Bank Deposit Report - I would like the total for the period for all payment types to be listed on this report. It is on the computer screen. I don't mind what way it is listed.

Currently we process DD thru a diff till - can be a pain when you forget to change it back so a new payment type in the main till would be good.

Centrelink can pay bills thru Centrepay - you just need to join. No joining fee but 99c transaction fee each payment they make to you.

Not sure what may have been missed with the missing post.

Cheers,

Bernie 

TONY's post - copied back from mailing list

---------- Forwarded message ----------

From: tony[at]openvpms[dot]org

To: users@lists.openvpms.org

Cc: 

Date: Sat, 12 May 2012 00:03:24 +0000 (UTC)

Subject: Re: [OpenVPMS Users] Implement a new Payment type

Hi Ben,



I am in the process of implementing this for a site and we are about to go

into testing. 



What I have done is add a new payment type "Other"

(act.customerAccountPaymentOther) which actually has an amount and a lookup

(lookup.customPaymentType).   The lookup allows the site to determine what

additional payment typce categories they wish to add. i.e Direct Deposit,

BPay, Centrelink etc



The current Till Blance report displays these as Payment - Other with the

description being the lookup Name.  Just need to modify report to have a

Total Other balance.



The current Deposit report displays thes eon their own page called Other. 



Now typically what practices do is process these types of payments into a

separate administratve till as they typiclally done in back office

transactions and they do not get confused with the standard "over the

counter" payment transactions and dont need to be managed by the reception

staff when clearing the till.  Often a different Deposit Account is used as

well mainly so reconciliations can be done on a different cycle then standard

deposits.  Obviously this is up to the individual practice.



I look forward to your commenst on this approach.



Cheers Tony

Re: Implement a new Payment type

Ben, thanks for raising this topic!

Tony, we've lost your post above somehow but I read it in the user email digest. I think what you suggested for the new site that you are currently working on is exactly what we wish to have. In the past, I'm receipting Direct Deposit payment using a separate administrative till under EFT but obviously it is harder for me to reconcile the money using the current Deposit Report because those DD transactions will be added to the EFT total.

I like your suggested method because it will give individual clinic the flexiblity to create additional payment types under "Other" as well.

One application I can think of immediately is to separate American Express transactions (or other charge cards) from Credit Card total for example.  These transactions are typically deposited separately from visa/mastercard money by Amex Australia a couple of working days after the actual transaction took place (anyone knows what other charge cards do?). It would be beneficial if OpenVPMS can separate Amex transactions from Visa/Mastercard credit card totals because Amex would have deducted their merchant fee by the time the money is deposited in the clinic's bank account, making it harder to reconcile total credit card/EFTPOS money.

Currently I remove all Amex transactions manually from the Deposit Report and record them separately for book keeping purpose.

So Tony, intructions on how to modify our OpenVPMS to incoporate the "Other" payment method with additional payment type categories will be much appreciated!

Thank you!

Kind regards,

Anthony (ActiVet)

Kind regards,

Anthony (ActiVet)

Re: Implement a new Payment type

Hey Anthony, with regard to American Express. The first thing I did to my Till Balance report was to modify it so AMEX was summed seperately from Credit cards.  The same adjustment can easily be made to the deposit report to seperate amex out.

Of course if we the above suggestion was moved into the "Trunk" (core OpenVPMS build) you could simply use that system instead.  Although the customization means report customization will be important.

Ill attach the changed template I use that extracts AMEX and sums it seperately so you can see how I did it and update yours or just use mine.  I havent done it for our deposit summary yet, because we dont deposit daily and thus credit card and eft totals arent used on our deposit report, but you can easily use the adjustements I made to the till balance template to the deposit template to achieve what your doing above.

The key to this report is the variable

isAmericanExpress

 which i gave the expression 

new Boolean($F{item.description}.contains("American"))

Obviously if any other credit card types are used like i dont know American JCB or something odd this wont work, but for typical australian use it seems to work fine.

AttachmentSize
tillBalance.jrxml 41.28 KB

Re: Implement a new Payment type

Hi Ben,

Thank you for sharing your till balance report template! I'm no good with programming codes so I'm not brave enough to try modifying our deposit summary report yet. But I'll definitely look into that and let you know the outcome :)

Cheers,

Anthony (ActiVet)

Kind regards,

Anthony (ActiVet)

Re: Implement a new Payment type

Tony,

Is this the sort of thing thats worthwhile patching into a release and thus standardizing everyone's approach, or leaving in the realm of implementation.

Cheers Ben.

P.S Im happy to submit my patched files for inclusion.  

Also

Anyone have anything to say regarding the order in which each payment type is reported in the deposit report.

 

The Current order is :

1) Cheque
2) Credit
3) EFT
4) Cash (detail not currently printed)
5) All other payment Types (this is where Direct Deposits would currently get
reported)

My suggesting would be to all most revers it.  Make the report

1) Cash (not printed)
2) EFT
3) Credit
4) All Other Payment Types (a page per type would be printed or none if
there werent any)
5) Cheque

Re: Implement a new Payment type

Hi,

I know this is a very late reply and I have already posted about this somewhere else, but our receptionists have a few requests/suggestions:

With the payment types, could the default be NONE? This means the person taking the payment HAS TO select a type of payment, rather than it defaulting to Cash.

Can I make it so the person taking the payment MUST put their initials somewhere on the payment (ie in the reference part)? Ideally they wouldn't be able to finalise a payment without putting their initials somewhere on the payment.

How do I remove the 'cash out' on eftpos? We do not offer that, and would like to remove it from my till balance (replace the description 'Cash Out : 0' with EFTPOS)

Thanks,

Greta

 

Re: Implement a new Payment type

Yes, I agree. These are both good ideas.

Re: Implement a new Payment type

We use cash out... and if I had a preference I would have EFTPOS as a default (90% of our trasanctions)

I think these changes should be made on implementation, not hardcoded into the default installation.

Re: Implement a new Payment type

I absolutely agree Ben, that the changes should be made on implementation. I would just like to know if it is possible to change the archetype so there isn't a defaut payment type. I think EFTPOS is probably most clinics preferred type (except ours ;)), but if it is possible to change your own preference that would be great!

Re: Implement a new Payment type

I had a quick look at the archetypes involved Greta (on the back of your suggestion I decided to see If I could change ours to eftpos. within the Openvpms web front end it didnt look possible there. 

Its been a busy day, and I will look tonight, at both the source code as well as the archetypes

Ill post if I can get it changed !

Re: Implement a new Payment type

Look at me reviving on old thread! Did anybody work out how to change the default payment type to "none"? I would still like to do this if possible

Thanks,

Adrian

Re: Implement a new Payment type

In the process of making a payment to a customers account, our system presents with the options by a drop down box of Credit card, EFT, Cash, Cheque, Other etc.

I wish to delete Credit card from the options. How does one do this?

Re: Implement a new Payment type

You will need to edit the archetype:

actRelationship.customerAccountPaymentItem

and remove the target entry for CreditCards.

 

I have done that below - do not remove the 

act.customerAccountPaymentCredit

as that will cause existing entries to error.

 

If you appreciate the help given consider making a small donation to a project of your choice!

AttachmentSize
actRelationship.customerAccountPaymentItem.adl 4.13 KB
Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: Implement a new Payment type

Hi Ben

Thanks for your help. I have been into the archetype actRelationship.customerAccountPaymentItem but cannot see where to go from there. In addition, I cannot open the attachment, and I had already previously deleted the archetype act.customerAccountPaymentCredit prior to your response

 

Re: Implement a new Payment type

Sorry you should be able to right click my attachment and click SAVE TO FILE

It will save it as an ADL file which CAN be automatically imported into OpenVPMS

You can also select to OPEN it WITH  NOTEPAD on windows or any other text viewer of your choice.

You will most likely need to add back in the payment archetype you removed.

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au
Syndicate content