Hello again.
I found the place to fix the bug and this has been committed to stable repo.
/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
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
@Braath Waate,
Are you suggesting a correction in the core? I have some problems following this thread.
Please be a little more specific if I should change something in the core. Thanks in advance.
/Joe
Hello,
Janusz wrote these routines. He is informed about this. He is busy at present, but will fix this asap.
Joe
Hello all, and especial @notrinos.
I have been looking at your work, @notrinos, and it looks very good. I think it should be implemented in the core for release 2.5.
I only have one suggestion. Instead of using the reporting folder I would rather like to make this folder inside the new dashboards folder. and also the includes folder. f.i.
a folder called: widgets and inside this folder all the widgets and the includes folder.
The reason for this is that the reporting folder is more addressed to the reporting system.
We could use all the widgets or some of them in the core. I haven looked at this in detail yet. This is a matter of taste.
I guess you have taken all the current widgets, right?
I will have a talk with Janusz, about merging the stable 2.4.6 into the unstable version and call it 2.5 Alpha, and then we can implement your dashboard variant, is that ok @notrinos.
Janusz has been working on your HRM, but I don't know how far he is, but I think this HRM should also be in the 2.5. I guess it need to be 'merged' with your new ideas as well.
Thank you all for your coorporations in this matter.
/Joe
This has been fixed and committed. Thanks @anoopmb.
We will see later if the function is needed or not.
/Joe
No, but we have been busy fixing an SQL Injection problem.
Give me some time to evaluate this. It seems good.
/Joe
Ok, but the 'STRICT_ALL_TABLES,NO_ZERO_IN_DATE' was implemented by Janusz to prevent SQL Injections. As I told we fixed a lot of sideeffect errors, but your error was another one.
I will ask Janusz to do something about this.
/Joe
@Braaht Waate.
Which version of PHP do you use? And did it fix the problem?
Janusz did a security update due to some report of SQL Injections. We have taken most sideeffect errors but you might have run into another one.
Joe
This has been fixed and committed to repo. Thanks @kvvaradha for detecting this.
A new file for replacement can be downloaded here.
Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.