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
All data elements go into the appropriate db field in MySQL.
The doctext.inc file should have it's path created before being copied over and edited as needed in the web folder.
If you need professional assistance post your offer in the Job Offers board.
Setup => Access Setup => Roles => select host
Attached is a set of screenshots for a forex purchase invoice and the corresponding forex converted payment along with their views and GL entries.
At the time of making the Supplier Invoice entry in USD, there is no conversion needed even if the company currency is in SAR except for the GL entries that would get converted in the Purchases account - check the GL entries for the transaction after Purchase Invoice entry.
Again, when making payment in USD from a cheque drawn on a USD denominated bank account, no conversion is needed except for the GL entries on the purchases / stock inventory accounts - check them as well.
You should have an Exchange Variances Account assigned in Setup => System and General Setup that will be used for Balance Sheet, P&L Account and costing / settlement purposes.
Alternatively, if you entered the exchange rate manually, try to logout and login again and then make the Supplier Invoices and the Payments to Suppliers. This is assuming you are plagued with some browser cache - set the browser options to clear cache on exit.
Read the Wiki.
Sales => Customer Transactions => Sales Invoices (Type) => Edit Icon.
Since both Supplier Currency and Purchase Invoice entry are in USD, there is no conversion needed. Make sure you have entered it in USD Amounts too in both cases. Hopefully, if you pay the Supplier from your USD Bank Account, then too there will not be any exchange rate conversion. Only in the Balance Sheet and P&L Account will it reflect in Saudi Riyal after conversion. Make sure your exchange rate is entered preferably a day earlier (may be there might be some glitch there - but no one has complained so far).
Just downloading the charts and overwriting the counterparts in the sql folder is good only for new companies created with them. The old companies created with the erroneous charts must be synched in schema and appropriately migrated to the new one. Just make one company with the en_US-new.sql and compare the schema with your older companies and synch the latter.
PHP 5.4.x should work.
Are you on Windows or Linux?
Study the Apache and FA error logs and enable debug in your config file and see where the problem lies. Check out FA troubleshooting in the FA Wiki.
Enable OpenSSL in your php.ini and restart your webserver.
Do not use the Yahoo exchange rate provider as they have discontinued free service.
All future transactions will be at the exchange rate you have entered.
Your supplier / customer should have their settlement currency entered and your bank account for that currency available.
The Slim Framework page has examples.
Nice work.
PHP 5.1.6 (XAMPP 1.7.3 on windows) and 5.3.3 (Debian Squeeze) do not need to remove the comment though.
That chart is probably old and not updated correctly. Take an updated one from the FA24extensions repo depending on if you are using the English or Arabic one.
Read the wiki, search the forum and experience the code - live and learn.
Post your job and bounty offer on the Job Offers board.
1. Inventory report is as on the time of printing - yes, continuous.
2. Enable Barcode in the Preferences. - Yes.
3. "add a call" ??? - each item sold in multiple units should be entered as separate items or use the sales kit / assembly feature.
4. Salesman facility only.
5. Expiry Date / Batch number not in native FA as of now. Some users have built their own extensions and some sell them - search the board.
The FA project is an open source one where everyone can learn and be a developer. The project has nothing to sell and everyone works at their own cost in time. Support employees / FA users to become developers and contribute your fixes / feature sets.
The Retained Earnings Account and the Profit and Loss Account must exist in your chart_master table with the correct chart_type - see the sql/en_US-new.sql file for parallels and adjust your Chart accordingly.
Setup => System and General GL Setup must have the Retained Earnings and the Profit/Loss Year accounts set properly.
Not in the official repo. Some commercial implementations are available and the SlimREST_API can be used to design one.
The official pkg when installed probably did not install fully as the file/folder permissions may have been wrong.
What is your platform and versions of PHP/MySQL/Apache?
Have you updated your FA 2.4.3 with the fixes thereafter?
Update your repgen module from the FA24extensions repo.
@joe: Thanks for the commit.
Not aware of this "feature" in FA as of now.
Addendum to your commit:
In rep102.php, $sign is computed and then used in the sql so it is okay.
In rep107.php $sign is assigned 1 and used and hence it can be fully eliminated unless there are some CAST issues.
In rep113.php, $sign is assigned -1 and used and may be removed likewise and the sign made inline.
In rep109.php, rep111.php and rep209.php just as in rep110.php here, $sign is not assigned anywhere in the script and hence can be removed as done herein.
This is a quirk of some set of PHP 5.6.x versions as listed here and here - specifically the PHP 5.6 bug.
https://frontaccounting.com/punbb/viewtopic.php?id=1294
https://frontaccounting.com/punbb/viewtopic.php?id=4202
https://frontaccounting.com/punbb/viewtopic.php?id=1112
No standard extension in the Official PKG repo as yet.
Replace line 161 in reporting/rep110.php:
$DisplayFreight = number_format2($sign*$myrow["ov_freight"],$dec);with:
$DisplayFreight = number_format2($myrow["ov_freight"],$dec);The $sign is not defined anywhere in the report and may be present through some include when a sales order is being printed. The $sign was not present in FA 2.3.x.
@joe: Should this be committed?
In general the wiki article referred to in my post still applies but needs to be modified to suit FA 2.4.3. It was considered to be a workaround as the DB schema was frozen in FA 2.3.x then and hence we needed it to accommodate several data elements in the single description field and then parse them out when needed.
Line 22 in the same file in FA 2.4.3:
item.units, item.mb_flagshould now be changed to:
item.units, item.mb_flag, item.long_descriptionto use the workaround.
In FA 2.4.3, it was sought to be made native but the devs had not found enough time and sponsors to get it done and it possibly remains as an extension in some private repos only. The correct way to implement this would be to create a separate extension that would use a new table in a 1:1 relationship with the existing stock_master table used.
EG, FR, GB, IN, SG, US, CA, AU English charts have been committed in synch upto this core commit with fixes till date.
@itronics: can update the relevant official pkg charts.
Read this post.
Flesh out the function price_in_words() and translate the lang/new_language_template/locale.inc file and copy it over as lang/es_AR/locale.inc.
$locale path is defined having the filename locale.inc in line 63 and used in line 64 of includes/lang/language.inc file.
The local default function price_in_words() is defined in includes/ui/ui_view.inc and relies on the function _number_to_words() also defined in the same file.
@joe: what is the standard way of providing the number to words in each language?
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.