It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by apmuthu
FrontAccounting v1.1.0?
Where did you get it from?
Try using some filter to reduce the rows.
Alternatively try to generate the PDF first and then use some program / service to convert it to Excel 2007 format.
@joe: Should we not generate the xlsx (Excel 2007) format if there are more than 65535 rows?
It may be your PHP version.
Replace the line 211:
foreach ($waapp->modules as $module)with
$wapp_modules = $waapp->modules;
foreach ($waapp_modules as $module)Use the cumulative values and print at the end of the report in the appropriate reporting/repXXX.php file.
Which version of FA are you using? Try - payment within 1 day.
Output is chosen as PDF or Excel type. If PDF is visible in browser, just print from there. Printers need to be available on your system or LAN with appropriate drivers installed. If you choose to setup your printer in the Print Profile in FA, then it will get automatically printed.
Please see the versions in my online repo:
3. en_US-new.sql - English US Standard 4 digit CoA.
The differences between 1 and 3 above are that VARCHAR(60) in the English CoA is VARCHAR(120) in the Arabic CoA for the following fields to accommodate multibyte characters:
bank_accounts.bank_account_name
chart_class.class_name
chart_master.account_name
chart_types.nameUse the en_US-new.sql to start with. Gradually introduce the ar_EG-8digits CoA in stages, starting first with the normal translations and then work your way thru' to the 8 digit account codes. See when and where it breaks. Alternatively try to check the difference in the schemas between the two CoAs.
Since the TB_PREF is already alaised in the FROM part, it is not necessary anywhere else.
When the backup file size becomes big, the php.ini's settings and script timeout values may begin to matter. What was the size of your last backup - with and without compression? Check to see if this is on the threshold of the php.ini and apache conf settings.
Try to make a fresh installation and create the closing balance and create a new fiscal year and set it to be the active one and then close the earlier fiscal and then delete the earlier fiscal and then see if the trial balance for the current one tallies. It is imperative for the IDs of the fiscal years to be in chronological order.
Alternatively start with the current fiscal year and insert a journal voucher for the opening balance and then check if the trial balance tallies before beginning to enter the transactions for the current fiscal year.
Which version of FA are you using?
Did you add the said fields to the appropriate tables?
If it is FA v2.3.25+, then see the wiki article on adding data into generic text fields like Description or memo/text fields and then parse them from there. This way upgradation of DB issues will not arise.
Another Wiki article deals with adding columns to tables.
Thanks @joe, @boxygen.
Committed to my repo after synching the whitespaces first so that the actual changes alone can be visible clearly.
Another possibility (Comment 87) is to have 'REP_WINDOW' replaced with '_blank' avoiding the need to comment it out.
Each time you have a popup of a PDF, just save it as a file and then open each in your PDF Viewing Application in separate windows and compare them.
Thanks for the insight @joe.
The WriteOff has both a positive and negative entry pair for quantity: $credit_line->qty_dispatched in the database. Restored code.
In FA 2.3.x, lines 202-206 in sales/includes/db/sales_credit_db.inc:
add_stock_move_customer(ST_CUSTCREDIT, $credit_line->stock_id,
key($credit_note->trans_no), $credit_note->Location,
$credit_note->document_date, $reference, -$credit_line->qty_dispatched,
$curr_std_cost, 0, $price,
$credit_line->discount_percent);are duplicately executed for $credit_type WriteOff as it is present in lines 209-213 as well.
Committed in my repo's FAMods.
@joe: can update in upstream.
In FA 2.4, there appears to be no WriteOff distinction for the $credit_type and it stands committed.
This issue has been test committed out in FA 2.4 unstable repo. Please provide feedback with PHP 5.3 and MySQL 5.1.
@joe: please update the FA 2.3 repo as well if it works since we do not want the stable version to have glaring bugs such as this.
It is possible that the Company 0 is not the default company.
It is possible that the company prefix of '0_' may be in non default company as well.
Default company is based on $def_coy variable's value in config_db.php(attached example) file.
The example attached has the default company as 0 and the 0th element of the $db_connections array has it's tb_pref element as "0_" but this may not always be the case.
You can create a new company only from the default company (generally 0) in any installation. Make sure you obtain the entire sql backup from your PHP 7 upgraded server (preferably pre-upgrade state) and the stanza pertaining to the company in the config_db.php file there as that would be useful to restore in the PHP 5 server instance.
I assume you are using FA v2.3.25 as the Assets tab is missing.
You want to make a Bank Payment Entry and have the reference entered into a separate form field in the Journal Entry Page. How would you know which Bank payment entry's reference you want in the Journal Entry? If it is part of the same transaction, read it from the appropriate table's field directly without having it redundantly stored.
You can also have the additional reference as part of the appropriate Memo form field.
You can use the Tags feature to link various transactions as a group.
Translate the Arabic CoA into English and compare with the equivalent en_US one.
Your steps are okay.
Try the en_US-demo.sql and see if the error appears.
Which version of FA are you using on what versions of PHP/MySQL and what platform?
What menu navigation steps did you use to achieve your output?
Whether Bank Payment or Customer Payment / Allocation was used?
Attached you output for forum self-sufficiency.
The Training Company (Demo Data)'s Customer Balance Report 101 is what you should have unless you customised your report and/or are using an older version of FA.
Whilst the Joomla project in it's latest avatar is being built for PHP7, the stable FA (v2.3.25+) is built for PHP 5.3.x and works with thru till PHP 5.6 without issues. Some users have tweaked FA to work with PHP 7 and later versions of MySQL (v5.7+) as well. Some tweaks to the Chart of Accounts will be necessary for MySQL 5.7 onwards unless the strict mode for dates is disabled.
Please note that using the appropriate version of PHP for which the application is designed will have the least issues in it's install / operation. The latest and greatest version of PHP / MySQL may not be appropriate in most cases of legacy software. Stable and proven versions and code you can understand and tweak yourself is one way forward that many will profess to.
Till this is done, try to get hold of one set of transactions' sql inserts / updates and make an sql for creating a new supplier invoice/goods_receipt/payment from the differences in the sql backups before and after it and use that in any mysql client when operating in exclusive mode during that time.
In the latter case of separate db / setups, the consolidation will have to be manual for the Head Office accounting.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.
