I am just waiting for somebody else will test this, please. Then I will commit the changes. So please try @peacecop kalmer's solution.

/Joe

This topic has been fixed and committed to stable repo. Thanks @notrinos for reporting this.

/Joe

Hello again,

I see that we already have a money_format that has been used for OS Win in /includes/current_user.inc on line 369:

// function money_format doesn't exist in OS Win.
if (!function_exists('money_format'))
{
    function money_format($format, $number) 
    {
        return price_format($number);
    } 
}    

All windows users have been using this routine for years without problems. Maybe we should include the function here suggested by @PaulSipley instead. I see that this function is listed in PHP.NET as an alternative to money_format. There is also another slightly better version we can use.

What do you think?

/Joe

We could use the NumberFormatter instead, but it is handling it differently. I wonder how important this is?
We could simply skip the currency formatter, I guess. What do you guys think? Right now it is not used seriously. We could use the number_format2, like we do normally.

/Joe

Hello guys,

I am not sure. I like the grayed versions in the core as is. This means that the report exists, but I am not allowed to see it. In my opinion this is not a problem. I know my place in the organization, so I don't mind.

I understand the question, but not sure if we should change this.

/Joe

I understand the need for this report for some sompanies, but please don't change the original report in the core. This is because this has something to do with the jurisdictions.
If you need to create this branch/customer balance report, please create in in the company reporting folder.

/Joe

Willdo. Committed to stable repo.

Joe

I have asked Janusz to look into this item. Hopefully he will respond asap.

Joe.

309

(21 replies, posted in Reporting)

This has been fixed and committed to stable repo.

A fixed file can be downloaded on Mantis.

Thanks for  reporting this smile

Joe

Will consider this.

Joe

This has now been fixed and committed to stable repo.

The fixed file can be downloaded here.

/Joe

Thank you guys for solving this. Will fix and commit the changes tonight.

Joe

Committed to stable repo.

/Joe

Thanksn@apmuthu

I will fix this asap.

Joe

315

(8 replies, posted in Items and Inventory)

Hello again, @tom.horton.
This is amazing. I tried to paste 60 characters into the description field. Only 50 characters were accepted. I am using Windows 10, Chrome browser, php 7.4.9, FA 2.4.9 and having no problems.
Would you tell us your environment, tom. Would be interesting to know.

/Joe

316

(8 replies, posted in Items and Inventory)

This is strange. The text box for the Item Description has a max length of 50 characters and this is exactly the size of the field in the DB. Entering more than 50 characters in this field is not possible.
Could this be from an import module that doesn't check for max length?

/Joe

@kvvaradha

Ideas are welcome. Thanks.

Joe

Yes, we will rearrange the fields a bit in 2.5. Until then, you can use the existing fields to elaborate the information.
I made an Invoice a while ago with the sort-code, IBAN, BIC fields, by rearranging the info in the various field in the Bank Account

Joe.

Fixed and committed to stable repo. Thanks.

/Joe

Hello @notrinos. Thanks for detecting this.

Fixed and committed to stable repo.

/Joe

Hello @notrinos and all interested parties.

This was NOT a bug in rep 704, but in /includes/types.inc, function payment_person_name. The string returned from here was mistakenly a link and that didn't work in reports. Fixed now in function payment_person_name, and rep704.php has been restored. A similar bug was also in rep601, bank statements, also fixed now.

Committed to stable repo.

/Joe

I will ask Janusz to look into this.

/Joe

I will ask Janusz to take a look at thisl

/Joe

Fixed and committed to stable repo.

/Joe

Committed to stable repo.

/Joe