bradymiller wrote on Thursday, October 30, 2008:
hey,
Nope, the online CVS demo and Developer Appliance install from scratch every time. They take advantage of the Virtual Machine function of being able to revert to a previous “snapshot”. So, the CVS demo basically resets to a blank slate every morning, and then installs the most recent version of OpenEMR from CVS. So, it’s doesn’t test any of the upgrade scripts(phpGACL, sql, etc.).
-Brady
rpl121 wrote on Sunday, November 02, 2008:
Thanks, Rod, for that advice. I created another directory called /var/www/openemr_dev and did a fresh CVS installation. I made the changes in globals.php so that it recognized that as the proper working directory. I am able to use the same working openemr database with either version of OpenEMR.
I’va had a chance to try the pdf and X12 insurance claim generation, the billing reports, invoices, payment application, receivables ageing etc. Now that I’ve found my way through the menus, it’s time to do some serious playing around with it.
Ronald Leemhuis MD
fred0 wrote on Sunday, November 02, 2008:
Rod,
Things I’ve seen so far in just a few minutes:
The Front Office Receipts report doesn’t seem to do anything. I’ve tested with a co-pay and a checkout function and neither transaction seems to appear.
This may be the way it’s always been, but the tax rate entry in lists requires the tax expressed as a decimal multiplier instead of a whole number percentage (.0825 instead of 8.25). This is fine, just confusing. Only realized it when I went to checkout and my tax was higher than the charge itself.
The pop-ups for checkout, pre-pay, import/export, etc stop working after 1 use in Apple’s Safari.
Also, I know just from some recent hassles with our practice and sql-ledger that we will require more reporting tools than currently provided. I’ll need to poke at it some more and think about it, but I will try to compile a list.
omo66 wrote on Monday, November 03, 2008:
I tested it. it is working great so far.
Here what I did. I did not want to mess with the production server, so I created a back up copy as follow:
1-I upgraded 2.9 to include the backup restore link (added all files from CVS)
2- create back up tar (emr_backup.tar) ~ 18 MB
3- used the script inside contribute to restore into an experimental server with Fedora 9 installed.
All database installed automatically (openemr, pgpgacl) with real data.
Then I download from CVS all updated files for Accounting (see above) and replaced all files.
It worked right away no issues so far…
Great job Rod…Perfect…I will keep testing then consider upgrading my production sever.
Is this a complete replacement for SQL-Ledger?
omo66 wrote on Monday, November 03, 2008:
found one bug.
A/R
V 2.91 upgrade from 2.90
Select encounters.
then Click : to Clinical View
The out come is only a blank space.
Normally you should see all encounters listed.
sunsetsystems wrote on Monday, November 03, 2008:
Fred: I don’t think any of those issues are related to the recent changes, but let me know if you find differently.
Omar: Thanks for the bug report. I checked in a fix to interface/patient_file/history/encounters.php.
Cheers,
mike-h30 wrote on Monday, November 03, 2008:
I am having a difficult time at getting a copy of the CVS version of OpenEMR in order to help test the new accounting feature that Rod developed. I have "CVS" installed on my system and a CVS client called "Cervisia". I have looked at the CVS documentation but have not been able to get the files via the command line or my CVS client. Rather then continuing to spin my wheels on this I wanted to do the following instead.
1. Start with a working copy of OpenEMR-2.9.0
2. Download each of the modified files for the new accounting feature that Rod specifies via the cvs web client.
3. Run the two SQL scripts:
sql/2_9_0-to-2_9_1_upgrade.sql
sql/database.sql
4. Copy the modified files into my working copy of OpenEMR-2.9.0.
includes/config.php
interface/billing/billing_process.php
interface/billing/billing_report.php
interface/billing/indigent_patients_report.php
interface/billing/sl_eob_invoice.php
interface/billing/sl_eob_search.php
interface/billing/sl_receipts_report.php
interface/forms/fee_sheet/new.php
interface/forms/fee_sheet/view.php
interface/patient_file/deleter.php
interface/patient_file/front_payment.php
interface/patient_file/pos_checkout.php
interface/patient_file/summary/demographics.php
interface/patient_file/summary/pnotes.php
interface/reports/collections_report.php
interface/reports/receipts_by_method_report.php
interface/reports/sales_by_item.php
library/Claim.class.php
library/billing.inc
library/invoice_summary.inc.php
library/patient.inc
library/sl_eob.inc.php
library/classes/WSClaim.class.php
library/classes/WSProvider.class.php
Will this be ok versus trying to checkout a copy of the cvs version of OpenEMR?
-Mike
omo66 wrote on Tuesday, November 04, 2008:
The new fix in interface/patient_file/history/encounters.php. was tested.
It is better, however, only one encounter is displayed when the Billing view is clicked. Normally all encounters as displayed.
Thanks
omo66 wrote on Tuesday, November 04, 2008:
more clarifications:
All new encounters created after upgrade are displayed (when clicking to billing view)
All old encounters created before upgrade were ignored.
sunsetsystems wrote on Tuesday, November 04, 2008:
Aha. That is to be expected, since no conversion of data from SQL-Ledger has been done.
I have just checked in a conversion script. See my next message for more about that.
sunsetsystems wrote on Tuesday, November 04, 2008:
There is now a conversion script checked in to CVS, for converting A/R data from SQL-Ledger to the internal OpenEMR format. It is called sl_convert.php.
You can run this from your web browser after upgrading (similarly to the setup.php or acl_upgrade.php script) and before doing any more billing activity. The program will refuse to run if any new payments or adjustments have been entered. If you want to run it anyway and are willing to zap those payments and adjustments, then clear out the ar_session and ar_activity tables.
If your SQL-Ledger database is large, the script could run for a while. In that case it may be necessary to increase the run time limits in php.ini.
Again, there may be bugs… keep me posted!
sunsetsystems wrote on Tuesday, November 04, 2008:
I don’t think that will work as other changes have also been posted to CVS since 2.9.0.
I will probably have some time to create a snapshot in the next few days, or perhaps someone else can put one somewhere.
sunsetsystems wrote on Tuesday, November 04, 2008:
I forgot to mention, there are also updates to the following that you will need:
interface/billing/sl_eob_invoice.php
library/invoice_summary.inc.php
library/sl_eob.inc.php
omo66 wrote on Wednesday, November 05, 2008:
Thanks for making SQL Ledger updater.
Rod I did not have Sql-Ledger on my 2.9 (upgraded 2.91). The data was real imported from production server.
I still don’t see old encounters= (visits) when clicking on Billing view.
Thanks
are these files only for ledger updater?
interface/billing/sl_eob_invoice.php
library/invoice_summary.inc.php
library/sl_eob.inc.php
I am looking at other potential bug:
Billing–>EOB–> print ( sql query data errors)
sunsetsystems wrote on Wednesday, November 05, 2008:
I just checked in some more bug fixes:
sl_convert.php
interface/reports/collections_report.php
library/invoice_summary.inc.php
library/patient.inc
Omar: those files you identify are for other things also, not just sl_convert.php.
omo66 wrote on Thursday, November 06, 2008:
All fixes applied and working fine.
New bug:
Billing–>EOB–> Print selected (kept boxes blank)—> list of items showed up–>I selected one check box on the right—> print selected --> ( sql query data errors) see below:
ERROR: query failed: SELECT f.id, f.date, f.pid, f.encounter, f.stmt_count, f.last_stmt_date, p.fname, p.mname, p.lname, p.street, p.city, p.state, p.postal_code FROM form_encounter AS f, patient_data AS p WHERE ( f.id = 10 OR f.id = 25 OR f.id = 12 OR f.id = 23 OR f.id = 22 OR f.id = 15 ) AND p.pid = f.pidORDER BY p.lname, p.fname, f.pid, f.date, f.encounter
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘BY p.lname, p.fname, f.pid, f.date, f.encounter’ at line 1
sunsetsystems wrote on Thursday, November 06, 2008:
I see the problem. Line 70 of sl_eob_search.php is:
"p.pid = f.pid" .
Change it to:
"p.pid = f.pid " .
That is, insert a space before the ending quote. Let me know if that fixes it.
omo66 wrote on Thursday, November 06, 2008:
The sql error is gone.
I clicked on print selected.–> A pop-up window showed this message box with OK button:
( Now printing 7 statements and updating encounters.)
but it did not print. and did not prompt for printer selection.