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 102 of 246)
Topics by apmuthu User defined search
Posts found: 2,526 to 2,550 of 6,149
The sql/alter2.4*.php files are there to migrate the data into the new fields/tables and the FA web user interface is the correct way to upgrade an FA install.
To compare the standard chart differences and sql statements needed to synch the database from FA v2.3 to FA v2.4 we can use the online tool at http://www.infoom.se/compare-mysql-online/ by pasting the FA 2.4.2+ sql/en_US-new.sql's contents in the upper textbox and that of the FA 2.3.x counterpart in the lower textbox and click "Compare".
Attached is the current state.
On further investigation, your fix is in order. See attachment. The inactive item_tax_type is seen with a strikethrough (CSS styled).
@joe: can commit it.
Looks like there must be atleast 1 entry in the "item_tax_types_list()" - there is no filter to remove the inactive ones. This is the "item_tax_types_list" and not merely the" tax_types_list".
I still see the inactive tax type.
The inactive field is missing in the SELECT field list in the functions tax_types_list() (line 1171) and tax_groups_list( (line 1205) too apart from your above item_tax_types_list() (line 1237) and templates_list() (line 1369) and workorders_list() (line 1399).
For any of the combo boxes, is it possible to add new elements on the fly?
@joe: is this fix necessary?
SESSION may have not been refreshed. Logout and close all instances of the browser and then try again.
Check your CHARSET settings in your Navicat for the DB used.
Hex 0x3830354e = Dec 942683470
Check for CRLF ("\r\n") characters in the strings. Excel has cell delimiters that can go awry.
The Wiki page on Exchange Rates now sports troubleshooting issues thereat. The files used in the FA webroot are attached herewith.
The import transactions can be used possibly for importing Purchase Orders in CSV) too. These Purchase Orders can then be turned into Invoices as needed in the FA UI.
The Auto Fill form can be implemented as a popup with a multiple select list checkbox set as well but the system will not accept if the order quantity is 0 or absent. A comma separated item code list if input into the item code field (form field size to be addressed) it should expand it accordingly but what if invalid item_codes were input?
Stands corrected now in the official repo.
Good catch @notrinos. This is what happens when a blind copy/paste occurs. My repo has the right code.
The PRIMARY KEY of the 0_bom table in both FA 2.3 and FA 2.4 is part of the list below:
PRIMARY KEY (`parent`,`component`,`workcentre_added`,`loc_code`),
KEY `component` (`component`),
KEY `id` (`id`),
KEY `loc_code` (`loc_code`),
KEY `parent` (`parent`,`loc_code`),
KEY `workcentre_added` (`workcentre_added`)
It can be re-arranged like this to save an index that would then have become redundant:
PRIMARY KEY (`parent`,`loc_code`,`component`,`workcentre_added`),
KEY `component` (`component`),
KEY `id` (`id`),
KEY `loc_code` (`loc_code`),
KEY `workcentre_added` (`workcentre_added`)
Also why have the erstwhile VARCHAR fields like loc_code and some other fields now become CHAR in FA 2.4?
The official repo mirror on GitHub now stands committed for the supp_trans table fix as well.
All Chart maintainers are requested to submit suitable changes / devs may update the charts in the official pkg repo.
Everything works as expected. See attachment with files in transaction sequence.
If you add parameters make sure they are referenced correctly in the code where they are used.
@dz: you have now added to the confusion.
Please be consistent with the order of the fields in the primary key as it should match the standard Charts and those that get upgraded using the sql/alter2.4.sql file.
This problem does not arise in FA 2.3.x.
The equivalent in FA 2.3 is placed just before the end_form(); statement like:
hidden('popup', @$_REQUEST['popup']);
In FA 2.4 we have Fixed Assets too as Items and the possibility of @... returning a NULL / false instead of a 0 in current strict syntax of later PHP versions prompted the solution for this commit.
Isn't it better to be a little permissive when a change from strstr to stristr isn't any great penalty?
And also a check to see if it is the first word in the sql?
Also if it is not going to be fixed in the core it will reside in my FA24Mods.
Thanks for the policy info.
Existing installs of FA 2.4 can also correct the supp_trans table also and retain the key field order too (as in the commit and in the sql/aletr2.4.sql with:
ALTER TABLE `0_debtor_trans`
DROP PRIMARY KEY,
ADD PRIMARY KEY(`type`,`trans_no`,`debtor_no`);
ALTER TABLE `0_supp_trans`
DROP PRIMARY KEY,
ADD PRIMARY KEY(`type`,`trans_no`,`supplier_id`);
Actually, @itronics order of the key fields is better as it also is in the same order of fields in the table but the sql/alter2.4.sql and the commit are otherwise. The extension Charts too will have to be updated atleast for the supp_trans table.
The above stands fixed in my repo.
This does not affect FA 2.3.x as the counterparty "feature" supporting code is present in FA 2.4.x only.
The sql/alter2.4.sql file is already updated in FA 2.4 for both debtor_trans and supp_trans tables.
All the extension Charts need to be updated.
The supp_trans table too needs to be updated accordingly with supplier_id in the place of debtor_no.
That is something a knowledgeable end user should tinker with for FA 2.4.x and submit their findings / fixes. The other check print module for the US should work if you overwrite the files with the ones in my repo where a recent commit was made.
The stristr is okay to fix instead of the regex except that it will not address checking if it is the first word in the sql.
The idea is that it should be the beginning of the string and not inbetween like CREATE TABLE xxx SELECT * from ....
@joe: fix redundant returns.
The Canada Cheque Print is available in my repo and the files match the ones in the official pkg repo when installed online.
After installing the rep_cheque_print module, activate it for the target company, whilst logged in to the default company. Now when you login to the target company, you will see the reports as expected and attached here.
My fix works.
@joe: can commit it. Diff attached.
You will need to study the default themes and make yours by starting out with a clone of one of them that suits the technology you want / are familiar with. You can post your findings here and document it in the Wiki. That is how the Wiki is what it is today - everyone who's scratched their itch have embellished it with their lessons learned so that others may take it from there..
Posts found: 2,526 to 2,550 of 6,149
