Assisting you with this is outside the scope of the FA forum and you will need to either do it yourself or seek professional assistance.
The specific function that does this job is the last one in reporting/includes/reporting.inc file in the FA v2.4 Mercurial repo.
]]>Invoice memo field - same as Invoice comments ?
]]>
In reports, I would like to have page numbering x of y pages instead of only page x
would also like to add Attn : contact_name auto derived from branch_person / contact_name and editable during invoice input by having a text box
A discount textboxt at direct invoice before shipping
On checking out the PDF generation classes and the bridge functions between the older FPDI and the new TCPDF, we find that the Header3() method in excel_report.inc and pdf_report.inc (that uses the Total Number of Pages in PDF data is not used in any of the reports.
Other features of the Info() method in these files too don't go beyond using the first 4 arguments in the report files whereas, the $companylogoenable, $footerenable and $footertext arguments provide for additional functionality that obviates the need for repetitive coding in the reports. The excel_report.inc defines 7 arguments in the Info() method whereas it's counterpart in the pdf_report.inc additionally defines the three arguments listed earlier.
These may well be some of FrontAccounting's best kept secrets!
Attached is one way to address Alann's first request.
The second issue notes: The contact_name issue is in flux at the moment since all such info are being collimated into the crm_persons table and some reports still reference the old one though the standard forms now avoid it. It will require custom coding and maintaining it as fixes to the core code arrives will need to be taken care of unless assimilated into the core. The Invoice memo form field is the best alternative for now.
The third request fix: A discount Text box during Invoice Input can be implemented by invoicing a dummy service item (Discounts Offered) of editable description and stating amount (negative) at use time. Otherwise, provide the discount at payment allocation time.
The current stable version 2.3 will only get critical fixes backported as the devs policy which is justified, as resources are best spent on newer versions.
]]>