It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Report Bugs here → Bug in Journal Inquiry View
Hello @joe,
Again with the power of Journal Entry to record transactions for Customers and Suppliers we have one more bug. I have tested it with customer but while fixing please check it for suppliers as well.
check the image here
The Journal Entry is for 20,000 but Journal Inquiry is showing up 60,000.
The Counter Party is shown as the First Customer while here there shouldn't be any one counter party because we can't put all three.
Are you using the latest snapshot of FA 2.4.2+ ?
Yes latest
What happens if each transaction is posted separately instead of combining all three payments received into one journal transaction - is it okay? If so, then there is GROUP BY / SUM error in the sql used. Post the urls that are affected.
@joe: Needs investigation and fixing.
It happens only when counterparty is used and it multiplies the number of times the counterpaties are added to voucher.
Hm.. will have a look later.
Joe
@dz are you using latest version of FA?
In FA2.4+ if you select Accounts REceiveable Code in Account Description in Journal Entry It creates another column automatically to enter CounterParty. This works same for Accounts Payable also.
@dz I am not getting any error if I select more than one customer/suppliers (each should be different) and it is reflecting in each parties ledger, balances, aging etc.
At some places the view is distorted just like in Journal Inquiry View but technically the transaction is OK.
You may call locally at my number to discuss further if you want that I am going to PM you.
Janusz is investigating this.
/Joe
We had small bug in database scheme, which I has just fixed in initial sql files. Impact of this big is moderate as such journal postings are made mainly during opening balance entry on fresh installations, so I think we do not have to implement any special measures to fix the problem in existing databases on next minor release.
Anyway, any existing FA database can be fixed easily with following command run in phpmyadmin:
ALTER TABLE `0_debtor_trans`
DROP PRIMARY KEY,
ADD PRIMARY KEY(`trans_no`,`type`,`debtor_no`);Thanks for pointing out the problem.
Janusz
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.
Ironically all the extensions does not suffer this bug. This change was overlooked in the main code only.
Janusz
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.
@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.
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.
why both Sourceforge repo and GitHub update PRIMARY KEY (`type`,`trans_no`,`debtor_no`) for table supp_trans ?
It must be PRIMARY KEY(`type`,`trans_no`,`supplier_id`)
am I wrong ?
Good catch @notrinos. This is what happens when a blind copy/paste occurs. My repo has the right code.
Stands corrected now in the official repo.
Consequent on this commit, all existing DBs may be updated with:
ALTER TABLE `0_debtor_trans`
CHANGE `debtor_no` `debtor_no` INT(11) UNSIGNED NOT NULL,
DROP PRIMARY KEY, ADD PRIMARY KEY (`trans_no`, `type`, `debtor_no`);
ALTER TABLE `0_supp_trans`
CHANGE `supplier_id` `supplier_id` INT(11) UNSIGNED NOT NULL,
DROP PRIMARY KEY, ADD PRIMARY KEY (`trans_no`, `type`, `supplier_id`); FrontAccounting forum → Report Bugs here → Bug in Journal Inquiry View
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.