I just looked at the patient statements and there is a huge issue with the address moving down the page.
The address information used to be at the top of the page. Now it is at the bottom and it moves!
This is not good.
I just wanted to say this out loud in case someone else is thinking the same thing.
The way it was in 4.x.x was better.
@juggernautsei,
It would be a good idea, if the address field is placed at the top of the page.
If not we need to traverse down each time to search the address.
To make it simple, we just gave a try by replacing the address code to top of the page and it worked as expected.
Thanks,
ViSolve
What version openemr? How is this suddenly broken in 5.0.1 if that is what we are talking about?
I think there’s a bug for multiple page bills in 5.0.1 which may have existed in earlier editions 
So, is this an issue in 5.0.2 as well?
@sjpadgett Yes, it is in 5.0.2 also. Some time back in 5.0.0 the address was moved to the bottom of the page which would have been fine if it did not move from the bottom of the first page.
Stmt_Lindabv_4 (1).pdf (20.7 KB)
So, like Visolve suggested. I moved it back so the biller could mail the invoices without having to create a separate page with the mailing address on it or creating mailing labels that waist time and money.
@juggernautsei Okay so the real issue is page formatting and not necessarily location of the address. I assume as long as the address is positioned so folding will result in address appearing in envelope view area, we’re good. So moving the address is a stop gap because there was a reason it was moved in 5.0.0. Also, 5.0.2 has several changes to invoice header, billing address and service address.
Not trying to be difficult Sherwin but i’d much prefer we get this right once and for all with two possible options to do so: 1.Short term, fix existing page formatting, 2. Write a statement editor(bet we could do it with LBF help) or even a drag and drop. Option 2 would be a great project for one of our newer developers seeking experience i.e. @danielehrlich projects team.
I don’t have time to do this but, I will ensure any fix in 5.0.2 will get back ported to 5.0.1.
btw: Great to see @visolveemr back helping on the forum. A huge contribution, thanks
having the address at the top would be the best imho
Yep, I get it. We need options for various invoice templates because there are so many requirements depending or users work flow. I’ve looked at your use case Stephen and see why you need it at top. It’s a difficult ask and hard to accommodate all use cases unless we modify to allow several template selections options in billing ie posting, or add global to fix statement template.
I’m hoping someone will take this on but if not, i’ll try to get it done.
I’ve thought about an idea for quite a while now. Word documents are just XML. Open Document files are just XML. I would love to see a template built in Word or LibreOffice or Apache Office and then we just parse the template, inject the variables and offer a true docx or odt file. Makes templating so much easier because the heavy lifting is handled by a real word processor
ok, thanks for checking that out @sjpadgett that was a custom statement but we also use default openemr statements and if anyone’s tried to fold the bottom addressed statement and put it in an envelope…
Hi, sure and come to think of it we already have an engine to do just that which I modified for portal and we use in Document Templates. Just need to add the new tags for billing.
@sjpadgett
I agree there needs to be a more permanent fix to this issue with the statements. I like @robert.down idea of leveraging existing tech to give more flexibility to the statements.
Reverse engineering how the statements are created is not a strong suit of mine. I have traversed it a some but don’t have the time resources to dig in and really uncover it completely. That is always the case when working on some else’s dime.
Thank you to everyone that has taken your precious time to look at this.
I am confident we will get this working better.
Actually, Robert had a great idea to use our existing template engines. Don’t know why it didn’t come to mind as i’m always thinking about Portal Patient Document templates and ways to integrate in to encounters.
I may be able to do this without spending a whole lot of time on it so, if someone would build the docx/odt invoice template, i’ll parser out the statement code into insert tags then call the xml tempate engine.
Anyone?
I’m not familiar with how this code is currently setup, but my strong suspicion is that all the business logic and view logic look somewhat like a tossed salad.
@sjpadgett think we could work together on breaking out the business logic into a module with proper service classes? This opens up the possibilities of having different outputs (html for the portal, docx for a file, etc)
@robert.down Okay, i’m in and maybe something will come to help in my claims re engineering . I’ll start off by breaking down the existing statement code into methods usable for tags at least. @stephenwaite new billing classes will be handy.
Still would be handy to have a default invoice template.
@robert.down fyi, i’m building a service TemplateTagsService that will include all the combined tags for both portal and document templates plus new tags for billing. From there we can do controllers for statements, receipts(payments) and portal documents.
Once I have tag service i’ll put up PR. Maybe later today.
@visolveemr Can you post what you did so that anyone that finds this thread can have a working solution until @robert.down and @sjpadgett do their thing.
@juggernautsei,
We have made changes as specified in the sample file format(mentioned in file statement.inc.php).
If anyone wish to use patient statement, as specified in below pdf can make use of the code.
Stmt_Kavi.pdf (13.3 KB)
statement.inc.php (45.1 KB)
Thanks,
ViSolve
