Skip to forum content
FrontAccounting forum
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 138 of 247)
Topics by apmuthu User defined search
Posts found: 3,426 to 3,450 of 6,167
Attached your image here.
Please see if the "error" is there for all items and if so whether the item_tax_types and item_tax_type_exemptions tables data are messing up.
Delete all rate=0 entries in 0_tax_types and 0_tax_group_items tables whilst all 3 records in the 0_tax_groups table can remain as is. You may want to switch the sales_gl_code and purchasing_gl_code to 2150 whilst removing the 2151 and 2152 account codes from the 0_chart_master and suitably fixing the "System and General GL Setup".
There should not be any gl-codes in the CoA for zero tax entries.....
1. Logout.
2. Clear browser cache.
3. Clear FA cache (company/#/js_cache/*.js).
4. Login and check.
Where and in which report file you used the mb_convert_encoding() function that solved the issue? We need to see if there is a really generic solution.
The browser automagically chooses the encoding and hence screen display on html will work normally.
There are 3 tax lookup tables in the FA database - tax_groups, tax_types, tax_group_items - have a look at their raw contents and see what is missing.
@joe: Done and committed in my FAMods - can port it to both cores.
Make sure you have removed redundant indexes and have some needed indexes in place. Also, some reports are cycled through in php on a per sql query basis instead of being acquired in a single sql query possibly as atomic requests use less memory.
Which reports slow you down? Has your MySQL been "tuned and defragmented" ?
View the tax table relationships in the EDR in the Wiki. You probably have not attached the tax to the tax group / tax instance.
Attached your file here as well.
Which table, which field? Is your table and field utf-8? When you read back from the field in FA do you see the normal apostrophe?
Ref: http://stackoverflow.com/questions/3574609/php-html-decoding-help-converting-a-039quote039-is-bbold-b
html_entity_decode('A 'quote' is <b>bold</b>', ENT_QUOTES);
should work.
mb_convert_encoding($string, "UTF-8", "HTML-ENTITIES");
replacing UTF-8 with your charset should work.
Read the wiki - there are pointers there and study the existing reports in reporting/repXXX.php files.
https://frontaccounting.com/fawiki/index.php?n=Main.BuildYourOwnFAReports
https://frontaccounting.com/fawiki/index.php?n=Main.AnatomyOfAHeader2TemplatedReport
https://frontaccounting.com/fawiki/index.php?n=Help.ReportsAndAnalysis
https://frontaccounting.com/punbb/viewtopic.php?id=5541
Mohd Pats, your company ( GoSoft ) is supporting a modified version of FA v2.3.19 for your client. We need to take this off board as any fixes to it here would only confuse the forum users. PM-ed you.
Forum users would however benefit from the following way FA has been used for a Vehicle Maintenance Company:
Customer Branch is treated as "Make / Model of Vehicle" where the details would have the Vehicle Registration number. Some unnecessary mandatory fields (Addresses) have their validation for presence turned off. The local terms (VAT => GST, etc) have been hardcoded into the scripts all over the place - this can be replaced with a single translated en_NZ.po and re-compiled en_NZ.mo file. Unnecessary modules and menu items hidden / not loaded.
So my FA 2.3 GitHub FAMods folder grows.... Soon it will be the defacto v2.3 of choice due to lack of backports into 2.3's official repo for whatever reason - for those who wish to remain at 2.3.
Line in reporting/includes/header2.inc:
$this->LineTo($right, $iline2 ,$right, $iline4);
is redundant and can be removed as it is already executed in the preceding loop.
@joe: please do the needful.
Solved. Changes to 8 php files and some minor db changes will fix it for good. The field width is not of any great significance here as the widths move the vertical bar along with the "Discount %" text.
I am unable to see what you want. The invoices print properly. See the original and some tweaks in the attachment.
The Wiki has been updated with MySQL table Defragmentation methods.
Over a period of time, FrontAccounting's MySQL tables accumulate a lot of deleted records. Purging the "marked for deletion" records will shrink the table space, re-index / defragment it and make it faster in operation.
This is important for those running FA having a lot of data and for those running several companies in one FA server. - especially so when a fiscal year is closed and then deleted.
When only 1 currency is used, a session flag variable can hide the currency filter in all report forms including extension reports.
A config variable / sys_prefs record to suppress the display of the Dimensions, Manufacturing and Inventory menus would be useful too.
Adding extra fields into FA tables is generally not advisable as it will surely break upgradeability. Some extensions have been known to extend FA tables and the FA extension framework actually allows for this.
That said, we can still live within the FA schema whilst simulating the presence of the extra field. A common grouse of an unfulfilled need in FA is that of Bin Locations within the warehouse. This "extra field" has been accommodated within an existing text field and illustrated in the Wiki.
Changing code too in FA will lead to a need to update again after any upgrade occurs especially for company specific reports. Maintaining your own GitHub like repo (or any Source version control) will mitigate it to some extent. Submitting the code changes back to the project makes it possible to have it incorporated into the core codebase avoiding the need for maintaining such repos.
PM me the details and I'll see if it is interesting and if I have the time for it - no NDAs, no responsibilities. For your regular FA scripting needs refer the FA Support page. Scouring the forum would show up many eager FA enthusiasts would work for $$$.
After deleting all fiscal years except the current one, we see all opening balances pertaining to only the current fiscal year appended to the gl_trans table. Attempting to query thus:
SELECT * FROM `gl_trans` WHERE ABS(amount) < .001 AND amount <> 0;
we find that there is one (chart_class.cid=2 => Liabilities) entry that has a very tiny amount balance, ie., 2.27373675443232e-13. There are over 100 entries whose absolute gl_trans.amount value is under 0.01. How do we eliminate these opening balance entries - where does the contra go if we delete these GL entries?
Place your request details here with a link to an image of your target output and what you are willing to pay. It is possible some forum user will give you the solution FOC as well. You were assisted before in a similar manner and have not yet provided any feedback or even thanked the solution provider.
The standard sql_trail reports the sql error message if any.
Using this commit in my GtHub repo, the following will appear prefixed to the message in the msg field.
For INSERT statements, the AUTO_INCREMENT field's last inserted id value prefixed with an I
For UPDATE / REPLACE statements, the number of affected rows prefixed with M
Wiki-ed.
@joe: want to include in the core or extend the table with another field for it in FA 2.4?
1. Open a "Bank" Account for the client.
2. Whenever the client is given an advance, treat it as if money was deposited into the above "Bank" Account.
3. During settlement, allocate from the said "Bank" Account.
1. Take backup 1
2. Do your operations that result in a wrong state
3. Take backup 2
4. Restore backup 1
5. Do your operations that make it to the desired state.
6. Take backup 3
7. diff "backup 2" "backup 3"
This will then need to be compared with the state at backup 2 after trying to make it right through FA standard operations.
This mod needs to be used with caution on a case by case basis as you do not want the mail recipients to get confused with mail appearing from some third party hosted FA which might point to a different domain than desired.
Anyway, thanks to your attention to detail for sharing the fruits of your perseverance , we have one more issue "solved".
@joe: may need a re-run for FA v2.4 RC1.
1. If you have more than one company in a single database and
2. for one of them you choose to have no table prefix, then,
3. when backing up that company, all tables in the database (including other companies tables in it) will get backed up and
4. sometimes resulting in a timeout!
This has been documented in the Wiki now and is thanks to lines 506-513 in admin/db/maintenance_db.inc.
The config.php and Data Locations in FA pages in the Wiki have been updated and provided herein for offline use.
Posts found: 3,426 to 3,450 of 6,167
