Take your report as an excel sheet and then manipulate it there. If you customise your reports then place them in the company/#/reporting folder and they will override it for that company.

Yes, Firefox even latest one too is in the same state. All ALT-[Key] combinations just choose the tab menu shortcuts if available and if not, choose the first available matching shortcut for the Key and does not allow cycling through all available matching shortcuts for the same Key.

On logging into FA, we are at the Sales Tab. If we type ALT-P, we go to the next tab, Purchases instead of cycling through the menu items on the current tab:

Invoice Prepaid Orders
Customer Payments
Sales Persons

The solution is to keep the ALT key depressed while repeatedly pressing the menu option Key till the one needed gets highlighted and then release the keys to go to that page.

Read this post.

2,053

(6 replies, posted in Modules Add-on's)

@notrinos has done a wonderful job!
Any public repo or is it commercial?

2,054

(13 replies, posted in Accounts Receivable)

Packing Slip is the way out.

Barcode is just a keyboard interface. If you are already on the FA page for Invoice entry in the Item Code field, just scan in the Barcode and it will appear in the said field. Barcode reader Apps for the iPhone.

FA does that automatically when the year gets closed.

2,057

(114 replies, posted in Reporting)

Are you using the fixes after the release of FA 2.4.3?

The id_ID language uses the iso-8859-1 encoding as listed in the install wizard but is entered as UTF-8 in the .po files and this has now been rectified in my repos. Anyone using the new .mo files should update their lang/installed_languages.inc file as well.

install lang id_ID commit - install .mo file - 100% translated (17 strings left in official repo)
core id_ID lang extension commit - core extension .mo file - 433 strings untranslated still (444 in official repo)

2,059

(4 replies, posted in Translations)

You can add / modify / delete any line in the .po file and re-compile it into a .mo file and use it.

Have just updated the id_ID install language and core language strings in my repos. If you intend to use this, then change the UTF-8 encoding to iso-8859-1 encoding in your lang/installed_languages.inc file as well.

It is best to make mobile themes self sufficient instead of tinkering with the FA core. The FA core can abstract hardcoded constructs in it into the theme where pertinent. Some elements will need different widths / font sizes to accommodate strings in other languages.

Swiftkey for Android auto injects emoicons based on context which will not be suitable for FA.

A mobile/responsive theme is available in some forks which have morphed FA considerably making it difficult to keep updating it when the core changes.

Creating additional user roles can be documented in the wiki with intent and purpose explained.

@joe: The viewport can be added if it does not violate strict browser settings.

All debits are stored as negative numbers in the GL Trial Balance. Your cash balance should be negative (debit) too. When you close the year all P&L entries are summed up and the net Profit or Loss is moved to the balance sheet. If you are referring to the account closure that this happens in, then the contra entry will have to be added to zero out the P&L account and then migrate it (P&L) to the Balance Sheet as a debit.

Since one location sells to another - treat them as different shops - each can make a profit from selling to the other. Alternatively use average costing and let the discount given to each customer vary. The exact acquisition cost will then be factored in the average cost. Anything specific can be treated as a different item for the FA internals with the same description - item_code and stock_id - you can also use manufacturing / assembly and kits. In the inevitable instance, make yourself an extension.

If you wish to track the same item with vastly varying prices, then make it two differently coded items (stock_id). There is nothing wrong with the current algorithm's outcome as the item is still one of a kind.

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.

2,065

(3 replies, posted in Reporting)

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.

2,068

(6 replies, posted in Setup)

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).

2,070

(5 replies, posted in Setup)

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.

2,073

(6 replies, posted in Modules Add-on's)

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.

2,075

(5 replies, posted in Setup)

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.