Thanks @kvvaradha.
This has been fixed and committed to stable repo.
The fixed file can be downloaded here.
Joe
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 joe
Thanks @kvvaradha.
This has been fixed and committed to stable repo.
The fixed file can be downloaded here.
Joe
@Braath Waate.
You are right. It was my fault that this was a missing parameter. Thanks.
@kvvaradha.
It was you that suggested the correct fix, but I accidently missed this function call on a line. Sorry for that.
Fixed and committed to stable repo. The /sales/includes/ui/sales_order_ui.inc can be downloaded here.
/Joe
Thanks @kvvaradha.
I will check later.
Joe
This has been fixed in core and committed to stable repo.
The fixed file can be downloaded here.
Thanks for finding this!
/Joe
The repo should work again. Sorry for the Miss.
Joe
Hello Guys,
We had to transfer the Website to a new Webhost due to outrageous price increase.
This transfer is now done. Hopefully without too much problems.
I can understand that there might be some missing posts. In that case forgive us and try to enter them again.
In a couple of months we will try to release a 2.5 Alpha. Included will be a Human Resource Planning (HRM or Payroll) that has been developed by @notrinos. It will have a few changes to adapt to the core of FA.
There will also be some improvements on the themes. We will implement a poll, with the various new themes presented by some developers.
/Joe
Yes, I can reproduce this. Will talk to Janusz about this.
/Joe
@JimmyC
The file /sales/includes/db/sales_invoice_db.inc has now been fixed and committed to stable.
A Fixed file can be downloaded here
Joe
@JimmyC
Thanks JimmyC. I have found the bug now. There is a zero amount tax record with an amount of 50 that are inserted in the trans_tax-details table.
The tax amount of this is 0 and is inserted as a 0 amount of tax with an unknown account. This record should never create a gl_trans.
I will fix that in a while.
/Joe
@jimmyC
I have been doing some investigation about this empty account line.
This line is created if floatcmp reports a balance. Look in gl_db_trans.inc, line 95.
There should also be an error line in your tmp/errors.log file for the date. Please have a look and report.
But the reason that the account code is empty is that there is no System and GL account for 'exchange_diff_act'.
If you go into Setup/System and GL setup and look up this account, there might be a value here, but if it doesn't show the right account change the account to show the right act, then save the setup.
Then please try another Direct Invoice. Now it should work.
/Joe
the later GL transactions seems to include an empty account line (are there any missing accounts in your chart of accounts.
FA should never post anything to an empty account.
The line could be some rounded values, but the value is 0 so this looks strange.
I have no idea. In my testing everything went ok in the GL lines and it should do so.
Please check that all your default accounts in the System and GL setup are ok. Do this check in the phpMyAdmin.
/Joe
Hello again.
I found the place to fix the bug and this has been committed to stable repo.
/Joe
Hello again @JimmyC.
I see the problem now. When the Document date is earlier than todays date, then the duedate becomes todays date. This is only for Cash Payments.
I have problem finding where to fix this error. Janusz wrote these routines. I will ask him to fix this. Thanks for reporting this.
/Joe
@JimmyC.
I cannot reproduce your examples in version 2.4.6. However there was a presentation bug in Sales Order View.
In the Direct Invoice, the Sales Order is automatically created with the reference 'auto'. The value in the due_date field was the later invoice due_date. So in the dispatch view, you will see the label 'Due Date' instead of 'Requested Delivery'.
Therefore I have changed the 'Sales Order View' to present the 'Due Date' value if the reference is 'auto'.
This should eliminate the misunderstanding.
I am open for other users testing this to see if I have missed another bug.
The view_sales_order.php has been committed to stable repo.
/Joe
This has been committed to stable repo. Thank you @notrinos for providing this.
Remember to change the settings in config.php also.
/Joe
@Braath Waate.
Is this safe to implement in the core now?
Joe
Hello Guys,
I am aware of the problems. However using the built-in mail function has normally been working ok during the years.
Using phpmailer requires an existing account for using it.
Suggestions are welcome.
Joe
@PaulShipley
This was a PHP 7.X error. Thanks for finding this and showing the resolution.
Committed to repo. The fixed file can be downloaded here.
Joe
Which PHP-version is used?
Joe
This has been fixed and committed to stable repo. The AUTO_INCREMENT removal will wait until later due to backwards compatibility.
Joe
No, hardly not. Will remove it and commit later.
Joe
Hello Guys,
I would say that this is rather region specific so I suggest following a global setting like the one selected by Janusz.
We simply put the setting in config.php. That is my opinion.
Joe
This has been fixed and committed to stable repo. Thanks @kvvaradha and @apmuthu.
A fixed file can be downloaded here and replaced.
Joe
Oops! Thanks @kvvaradha for detecting this. Well it did no harm and the conversion is done immediately after the open balance call.
But it should not be here ![]()
Committed to stable repo.
/Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.