Yes - printing cheques only.
Use the Memo field to put in cheque Number, bank name, etc in the payment allocation entry.
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
Yes - printing cheques only.
Use the Memo field to put in cheque Number, bank name, etc in the payment allocation entry.
Which version of FA are you using. There was a commit to rectify a similar (or same) issue a few months ago.
Which version of the paypal extension are you using?
There was some feature reduction in a later version.
There could be some error in the file sales/includes/db/payment_db.inc since only 11 arguments are initialised in the code fragment from line 29-31:
$args = func_get_args(); while (count($args) < 12) $args[] = 0;
$args = (object)array_combine(array('trans_no', 'customer_id', 'branch_id', 'bank_account',
'date_', 'ref', 'amount', 'discount', 'memo_','rate','charge', 'bank_amount'), $args);
Try changing the first line above:
$args = func_get_args(); while (count($args) < 12) $args[] = 0;
to
$args = func_get_args(); while (count($args) <= 12) $args[] = 0;
and report the results.
Do you have the dejavu.php file in your FA webroot?
If not, get it from the frontaccounting.com downloads section.
Read the related section in the wiki.
dejavu.php missing - TCPDF Font Failure
Download dejavu.php
Extract contents to reporting/fonts folder
This is the default unicode font when none are defined
Can change this font at around line 161 in reporting/includes/class.pdf.inc
Use Windows Scheduler and print the TXT files from the folder using normal Windows Batch commands. Why do you need PHP here?
The following links may be useful:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/batch.mspx?mfr=true
http://en.wikibooks.org/wiki/Windows_Batch_Scripting
http://ss64.com/nt/
http://www.robvanderwoude.com/batchcommands.php
@genebarker: Thanks indeed.
The writeup will be useful for FA Evangelism.
Wonder why you have not upgraded to FA 2.3.24 yet (from your screenshot).
Your computation of GST (in the notes) assumes 70% for Item 1 instead of 7%. FA calculates it correctly.
The label for the column "Qty yet to Credit" should be "Rate".
@joe: Please change this.
Which versions of FA and extension are you using?
Use FireFox Browser and not MSIE.
Check the error.log to locate the line number that causes the fault.
FA 2.4 is heading towards PHP 5.4 and UTF-8 fully. Use "UTF-8 without BOM" in your IDE.
Is default '' illegal for text fields?
See if there have been changes in the latest FA 2.4 build.
I see you have forked the official FA Unstable as well - that is the way to go - not a fork of my frontac24.
You need to install the module from within the default company and then activate it for the target company and possibly enable permissions for the user to access it's functionality before you can start using it. Search the forums and read the wiki for more info.
Study the various extensions available and roll your own. The extensions files are available in my unofficial github repo.
Copy the rep304.php into company/#/reporting/rep304 and edit it there - # is your company number. It will override the original report file of the same name.
Changes in config file values to reflect in FA may need a logout and login again if session variables are depended upon.
Your workaround could be useful for others till the dev fixes it. Thanks.
The selections in one screen are the ones which get processed. Selections in the second screen must be done separately. You can try to increase the number of entries on each screen as stated in this thread, if you want all in one go.
You will have to increase the number of variables in php's php.ini - see another post for it.
Using Courier New or Terminal font (slashed zero) may be suitable.
This is so that you have all links available after the transaction and you can choose what you want.
Platform - Linux/Windows.
FA version?
Files and Folder permissions for webserver user.
The php closing tag issue generally comes up on PHP 5.4 onwards.
The include_once should have no effect and is needed to enforce authority to download only if logged in.
If the generated file is good, then the browser transfer may be the issue. Check the apache error logs for any clues.
What you ask will break the normal workflow of FA. Better make a module (extension) with a new table that keeps track of these fields but you will have to take into account what happens when such entries are edited. There is another thread with info on editing Journal Vouchers and their consequences for the database tables and next_reference field.
There is huge scope for misuse of FA for money laundering and embezzlement besides hiding transactions amidst legitimate ones making forensics that much more difficult if what you say is allowed since there is no info on the final resting place for the monies to all the intermediate parties concerned.
If the autoupdate is enabled, then what you state is acceptable as a current exchange rate would have been acquired. If not, only an older exchange rate would be available and may be used for the current transaction as would obtain if it is withing a few days of no significant change.
If the date_ >= $date is used, then the Order by Desc should be Order by Asc. Should there be a dictate to use the old exchange rate if autoupdate is disabled with an option to update for that specific time alone as well otherwise?
Today is Tamil New Year's Day. Let us hope Tamil makes it to the list of FA languages officially (it is there in my unofficial GitHub Repo though).
Attached is a snapshot of the last 1001 registrations in the FA Forums.
Thanks for the policy decision - any rationale?
Would it then not clutter the standard listing of the transaction summary listing? Some vouchers could have huge GL postings like Opening balances and P & L Transfers.
The function get_exchange_rate_from_to() calls the following functions in the same file includes/banking.inc:
1. get_exchange_rate_to_home_currency($from_curr_code, $date_)
2. get_exchange_rate_from_home_currency($currency_code, $date_)
The first one is the arithmetic inverse of the second one.
All currency exchange rates in FA are relative to the home currency.
The sql used in the second function (lines 91, 92) is:
SELECT rate_buy, max(date_) as date_ FROM ".TB_PREF."exchange_rates WHERE curr_code = ".db_escape($currency_code)."
AND date_ <= '$date' GROUP BY rate_buy ORDER BY date_ Desc LIMIT 1
The date_ <= $date is key to the record being pulled out.
Should it not be for all future transactions by making it date_ >= $date ?
After all, when we get an exchange rate from a provider (YAHOO, ECB, BLOOMBERG, GOOGLE, etc) it should be for all future transactions till the next one is obtained and not for all past transactions.
@joe: your take?
If SGD is the home currency, get the exchange rate of the alternate currency say USD here. The exchange rate of the home currency will always be "1". The Supplier / Customer Currency needs to be used for the Supplier / Customer Invoice respectively.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.