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
The change to 8 decimal places would affect new transactions only as the computations were done for the old ones using the limited decimal places that existed earlier.
If you keep IDR as the base currency and use USD for specific needs, the standard FA settings would suffice.
@joe: Does this warrant a check? Rounding off errors cannot be that big....
It appears that your session vale for the collation is specifically utf8mb4_unicode_ci which is different from the others.
You can test it in a local XAMPP first and see if the issue persists.
I have no issue with the standard en_US-demo.sql on XAMPP. You too can try the standard en_US demo CoA as a plain vanilla install (not an upgrade) and see if the issue persists. If it goes away, then compare your db schemas to see what gives.
If all else fails, PM me a link to your DB backup sans pwds/txns and the specific build of FA you are using and I will test it out in a sandbox. That way we can check if it is a php script issue or a MySQL db issue.
State the versions of PHP, MySQL, Apache, OS platform.
Check the output of:
SHOW VARIABLES LIKE "%collation%";Clear the company/#/js_cache/*/*.js files, logout, clear browser cache and login again after closing all browser instances.
HSN can be for group of items
If we want the "LIKE" parameter to be case-insensitive then the database collation should be utf8_general_ci. Otherwise if the db and connection collations are different, we will need to set the comparables in the LIKE statement to be "LOWER(field1) LIKE CONCAT("%",@cmpstr,"%")" in places like function get_customers_search() in sales/includes/db/customers_db.inc or cast / convert the collations on a per sql basis.
The real workaround:
After the last db_query() in the function set_global_connection() in includes/db/connect_db_mysqli.inc, add the following:
db_query("SET @@collation_connection = @@collation_database");The above will help avoid "Illegal mix of collations" error by synching the connection collation to that of the database and make for case-insensitive searching. It will also benefit those in a single db environment on a shared hosting platform with possibly different collations for each application - YMMV.
It is possible that the collation of the customer name may have been of a different collation as well - check your CoA and db schema!
@joe: can we commit this - after all the db collation should dictate such usage.
FA uses Quote -> Order -> Delivery -> Invoice with payments allocatable only to invoices with provisions for advance payments as workarounds.
The Order has the "date of delivery" field which can be different from the date of booking order / invoice.
If the following is done for all invoices, then it can simulate what you want but the real voiding must have something in the memo to distinguish from dummy voiding:
Quote => Order => Dummy Delivery => Real Invoice => Void Dummy Delivery => Make Real Delivery => Attach Real Delivery to Real Invoice or fulfill as new Real invoice after voiding old Real Invoice and suffer tracking issues.
Alternatively make a dummy invoice for the dummy delivery in a dummy company and then populate the real delivery and real invoice by selectively exporting them from the dummy company to the real company.
Try the same in the files:
gl/view/gl_deposit_view.php
gl/view/gl_payment_view.phpIf you have alternative systems for managing the Milk parameters data then you can export the suppliers invoices into an FA acceptable format with the parameter data in the Item description / memo field.
1. Take a backup in FA.
2. Enter 1 typical purchase invoice.
3. Take another backup in FA.
4. Compare the backups in WinMerge or any diff tool.
5. Create a template of MySQL insert statements to simulate the above transaction.
6. Create an Excel sheet of your Milk procurement data with their parameters and use the above template to generate the MySQL insert statements and run them in any MySQL client like phpMyAdmin / SQLyog.
Alternatively test out the import transactions 2.4.x module in a sandbox to see if it meets your needs.
As already stated, MySQL has DATE_SUB(DATE_ADD(date_field, INTERVAL 1 YEAR), INTERVAL 1 DAY) which will always take the right Feb 28th or 29th as needed.
Similarly, for a month, it would be DATE_SUB(DATE_ADD(date_field, INTERVAL 1 MONTH), INTERVAL 1 DAY).
If you can pin point the sqls in FA where this causes an error we will be able to fix it. In most instances, the start and end date of the fiscal year are taken from the table's fields so it should not cause any issue.
As EAN 8 is not available in the standard FA 2.3 and 2.4 as of now, my FAMods repos have been updated with the code backported from the TCPDF repo.
Attached is the file to replace in FA 2.3 and 2.4 (same file).
Barcode printing is available in the tcpdf library that FA uses for it's reporting. Checkout the TCPDF examples and write your reports for the barcode label size, type and layout needed.
Sample usage in a reporting/rep###.php file is:
// ..
// ..
// define barcode style
$style = array(
'position' => 'L', // If blank string, barcode starts on left edge of page
'stretch' => false,
'fitwidth' => true,
'cellfitalign' => '',
'border' => true,
'padding' => 'auto',
'fgcolor' => array(0,0,0),
'bgcolor' => false, //array(255,255,255),
'text' => true,
'font' => 'helvetica',
'fontsize' => 8,
'stretchtext' => 4
);
// EAN 8
$y = $rep->GetY();
// write1DBarcode($code, $type, $x='', $y='', $w='', $h='', $xres=0.4, $style='', $align='')
$rep->write1DBarcode('1234567', 'EAN8', 5, $y-8.5, 75, 22, 1.2, $style, 'N');
// ..
// ..@ssass24: Have you updated your Price Bands Extension (Post #12, #16) for the last version of FA 2.3.x and the latest FA v2.4.2?
If so and you would like to share it, you may send it to me and/or fork the extensions repos on GitHub and submit pull requests:
https://github.com/apmuthu/frontaccounting/tree/master/extensions/Extensions
https://github.com/apmuthu/FA24extensions
Also need to address classes in the reporting/includes/tcpdf.php and other pdf classes.
Firstly, you do not need these 4 columns at all. Just make an excel sheet with these values in columns and generate all possible Item names and then import them all in one go.
The corresponding FA 2.4 commit is here.
Whilst @PaulShipley's solution does the job (and degrades gracefully), the constructors can be replaced straightaway unless they are called specifically in the code as we now officially support only PHP 5+.
From the PHP Manual:
Warning:
Old style constructors are DEPRECATED in PHP 7.0, and will be removed in a future version. You should always use __construct() in new code.
Try a Journal Voucher: Debit Bank, Credit Interest Received Income
Unique EAN-8 Barcode ID generator for FA 2.3.x is enabled in this commit.
Do a diagnostic check of all your tables and re-index them. Also set the auto increment value of each such table to 1 - it should then set the actual value by itself. Make sure your Chart of Accounts sql schema compares exactly with the sql/en_US-new.sql file.
Most welcome.
https://frontaccounting.com/fawiki/index.php?n=Main.Usage
Study how the Tamil Translation was added:
https://frontaccounting.com/punbb/viewtopic.php?id=5242
Browser display issues with Khymer unicode:
http://www.sbbic.org/2014/05/01/fix-khmer-unicode-doesnt-display-correctly-firefox/
https://bugs.chromium.org/p/chromium/issues/detail?id=225717
You can login to http://www.transifex.com and find that the Khymer language (km_KH) translations have been enabled at:
https://www.transifex.com/gnuacademy/frontaccounting24/language/km_KH/
Translate and let us know so we can include it.
Make a module to populate a new table that has the same primary key as the items table and make your enum fields in it with static select boxes in the forms that populate them.
FA Forum login credentials work for the Wiki.
There is a Sticky Announcement: https://frontaccounting.com/punbb/viewtopic.php?id=922 but not as explicit as your statement.
@joe: remove old stickies and put in one with @poncho1234's suggestion there.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.