Search options (Page 40 of 200)

You can create a service item called Discount. Use each as uom. Create an item tax type with total tax exempt and put this on the item.
Then you can enter a Discount item with negative amount per item.
That's it.

Joe

Now I recall the flag. It is in the user preferences. Left pane. Save Report Selection days. If you set this to 30 days, the report selections are saved for 30 days.
Maybe this can be used.

Joe

Thanks for pointing this out.
We are no longer supporting release 2.3, but for those still using it they could just set the value $use_costed_values to 1 instead of 0 in config.php.

For backwards compatibility in 2.4 we will just change the value $use_costed_values to 1 in config.default.php, so all new users will automatically get this option.

Should they prefer the old method for some reason, they can set this value to 0.

Thanks @boxygen for helping with this.

/Joe

Are you updated with the latest repo build. I vannot reproduce this error, either on screen or in rep601.php report.
Everything is ok.

However we are planning an upgrade to 2.4.2, due to a couple of bugs.

/Joe

Ok, sorry my mistake. Then it is per default set to 1 in the sys_pref class. That is to say that the $SysPref->use_date_picker is set to 1 per default.

/Joe

In 2.4 all the global defined variables in config.php is assembled into the global $SysPrefs variable, so the name of the global variables is now $SysPrefs->use_date_picker. Then we only need to declare the $SysPrefs variable as global.
However if you are using the old $use_date_picker in an extension and you declare this as global in your routines is should work adequate.
For simplicity we have surrounded the new global members by macros, like user_use_date_picker();

There should be no occurrencies of the old $use_date_picker in the core, besides the one in config.php.

/Joe

Yes, but if you want to select a period less than a month this will not work. For those who absolutely want this to work on a monthly base, then it could be done this way.

Joe

Janusz will have a look at this. Sounds like a good idea.

Joe

I think I will commit these files now. I have tested them without any problems.

/Joe

Yes, you are right. The internal variable was not zeroed out before use in the Suppliers. Thanks for detecting this.

It will be committed asap to 2.4 stable repo.

In the meantime you can download the /includes/dashboard.inc and replace it in your setup.

/Joe

The implemented algorithm is the fastest way of doing it. In C/C++ these check are internally converted to assembly instructions of one line.

Still, I am waiting for test result before committing it to 2.4. And as told, it is possible to use the files in 2.3.X also as the code are the same in both releases and files. Only you will have to replace the files yourself.

/Joe