Looks like something else to document! Before generating statements, you have to configure the file custom/statement.inc.php. This includes specifying the command for printing in $STMT_PRINT_CMD. See the comments in that file for more information.
Some info I have discovered:
It appears to create a file one the server /tmp dir called openemr_statements.txt. This file has some macro code [Your Clinic Name] imbedded.
Several obvious issues with this.
1) The file is not accessible or presented to the end user for for printing or download.
2) The file is formatted for some, specific, undocumented use case, ie: some kind of mail merge application rather than for general use
3) There is no "batching" date/time stamps on the file so subsequent run step on each other.
I am looking at that file and it does not address the issues adequately. This is way more than a documentation thing.
1) The path to the file does not allow for batching, fixed string.
2) The print command assumes you are printing directly from the server, which is never the case with a hosted service and is not the way I would install even at the clinic.
3) The clinic address information should come from the billing facility record
Wow, we sure can’t expect a end user to be able to edit PHP code. It’s not even a config file.
Since this is in the custom directory I assume it was never part of the base product to do statement billing. Which make me wonder why it’s even an option in the Billing screen.
Documentation won’t fix this one, at least for me operation. I’ll be adding that to a my long list of things that are well implemented for Practice Management and need to be enhanced.
Dang typos:
Documentation won’t fix this one, at least not for MY operation. I’ll be adding that to a my long list of things that are NOT well implemented for Practice Management and need to be enhanced.
The print command doesn’t have to print. It can reference a script that does whatever you want with the statement images, including batching.
Yes, setting up statements will usually need some help from a techie. Until someone makes it more plug-and-play, you can at least document that much and tell the programmer where to look. If you think that’s bad, try getting freeb working in an older release! Much progress has been made, but more work on the basics remains to be done. Don’t forget where we came from.
No argument from me on the progress, even since I started using it at 2.7. The statement thing has just been nagging at the back of my thought process for a while.
In this case I’ll fix that before I waste anytime documenting it. It’s just not workable the way it is.
Of course, a quick wiki post of your explanation and and extract of the scripts comments would be in order.
I have been using a workaround for this issue.
- I created another directory under openemr called statements.
- Directed the statement output to this location.
- Modified the code in statement.inc.php to output named files with additional info
- Created a statements_list.php file to display the statement files.
- Add statements as a menu item.
It was a work around we were going to come back to. Our next action item was to write the statement files as pdf and store them under documents associated with the patient It has been a low priority item for us.
More generally, the way to get commit access (assuming you have an ongoing interest in that) is to send your stuff to an existing developer (such as me) for review. It’s likely that you’ll be asked to change a thing or two. After a bit of successful history with such submissions, we’ll get you set up.