Batch Payment issues 4.1.1 (13)

jeepdc1 wrote on Wednesday, July 24, 2013:

I’m having a couple of issues with the batch payment section of OpenEMR.

  1. The filter to display non paid, primary complete, etc is not working. All transactions are allways shown.

  2. I’m unable to apply one patient payment to multiple patients (family member). When I click “finish payment” it appears to save but when I review the payment, the payment exists but nothing is applied. It will never apply payment for any transactions. This was working when I first installed.

I’m currently running OpenEMR 4.1.1 patch 13 on Centos 6.4 with php 5.3.3 and mysql 5.1.69-1.

Thank you for any assistance you can provide.


jeepdc

aethelwulffe wrote on Thursday, July 25, 2013:

Do you have anywhere you can display the contents of certain files? Also, are you sure that the upgrade scripts for the patch were run? did this start “all of the sudden” or after patch 13? Have you done an apache/mysql restart since any of this started?

We can go over what code you are using, and maybe get a structure dump of your relevant tables.

The includes of /interface/billing/billing_report.php:
require_once("…/globals.php");
require_once("…/…/library/acl.inc");
require_once("…/…/custom/code_types.inc.php");
require_once("$srcdir/patient.inc");
include_once("$srcdir/…/interface/reports/report.inc.php");//Criteria Section common php page
require_once("$srcdir/billrep.inc");
require_once(dirname(FILE) . “/…/…/library/classes/OFX.class.php”);
require_once(dirname(FILE) . “/…/…/library/classes/X12Partner.class.php”);
require_once("$srcdir/formatting.inc.php");
require_once("$srcdir/options.inc.php");
require_once(“adjustment_reason_codes.php”);

Report.inc.php and the billing report itself are the two most important here I think. We can compare your code, and test it against my test install if there are significant differences (my report and criteria selection are modified significantly). Different from the base code is one clue. Even if it is the same, if it does not work on my testbed, it has issues.

If you can post these files somewhere (the report and at least the report.inc.php) I can test them for you, if everything is OK, we can go elsewhere. This issue is not easy to diagnose without system access.

-Art

jeepdc1 wrote on Friday, July 26, 2013:

Thanks for your help. I did restart Apache but not mysql. I have not made any customization to the files you mentioned.

I’m trying to attached a compressed tarball with the files you need.

jeepdc1 wrote on Thursday, August 01, 2013:

Can anybody help me? The batch payment feature does not work at all. The payments are never applied to the encounters. A payment is recorded ,but never applied.
–jeepdc

jeepdc1 wrote on Thursday, August 01, 2013:

A record is created in the ar_session table but no records are created in the ar_activity table.

–jeepdc

yehster wrote on Thursday, August 01, 2013:

ZHH is the author of this code, they would know how best to help.

fsgl wrote on Thursday, August 01, 2013:

Hello, jeepdc.

While we wait for ZH Healthcare to respond, thought I might try to help.

The attachment is from the Demo which may be on patch 14.

Check the attachment to see if your posting covered all the items circled in red.

I find posting Medicare payments easier with Batch Payment but for personal payments, it is more efficient with the EOB Posting module. Just enter the check number, payment amount and date. The payment amount will decrease to zero if the posting had been done correctly. Remember to click the Patient radio button before saving.

jeepdc1 wrote on Friday, August 02, 2013:

Thanks for your comments guys. I thought the batch payments was the better method to enter payments but perhaps you are correct fsgl. However, I do have some payments that require the batch payment module. I’m finding the payment problem only occurs with some patients, not all.

fsgl wrote on Friday, August 02, 2013:

It sounds as if the Batch Payments module works for insurance and most patient remittances and that your posting protocol mirrors that of the above attachment.

What distinguishes the patients whose payments you are having difficulties posting?

Your posting routine should be the same no matter which patient you are posting for. Is this correct? If it is incorrect, describe how it is different and why you need to modify the posting procedure.

zhhealthcare wrote on Wednesday, August 14, 2013:

There seemed to be issues in the patch 13 as well as 14. The issue that we found is in library/log.inc file for these two patches. This file seems to be different from the latest version of the openemr 4.1.1 . This is an issue related to last insert id.
If you can upgrade to latest version of openemr, the payment postings should work as expected. Please let us know if this resolves your issue

bradymiller wrote on Thursday, August 15, 2013:

Hi ZH Healthcare,
Those patches do not even have a library/log.inc file in them. Guessing you have a local mod that changed this rather than the patch.
-brady
OpenEMR

kylenave wrote on Monday, July 27, 2015:

I’m having the same problem currently with v4.2.0.

This is a new install. I have patient demographics entered and I’m ready to get started processing real data. Encounters entered fine, check is stored in ar_Session but no ar_activity is created when I entered the payments against individual items.

Since there are no patches to apply I’m not sure where to go.

Any suggestions?

fsgl wrote on Monday, July 27, 2015:

In retrospect the OP should have been clicking the “Post Payments” instead the “Finish Payments” button after entering the data for each line.

“Finish Payments” serves to save the very last payment in the batch & then all lines of the batch are displayed for review before one exits the module.

4.2.0 can be patched to (3), but this is not a known 4.2.0 problem; therefore patching is not the solution.

kylenave wrote on Monday, July 27, 2015:

BTW - I was able to enter payments through the patient payment interface, just not the Batch insurance payment interface.

Thanks.

kylenave wrote on Monday, July 27, 2015:

Not sure what was going on… a reboot of the virtual machine seems to have fixed my problem.