1 Reply by maasj

(3 replies, posted in Report Bugs here)

Hi Joe,

joe wrote:

Due to a bug in sprintf replacing the if statement solves the problem:

Thanks for the new patch, it seems to work well for me!  And I don't think there's a bug in sprintf(), it's just a known problem that PHP (and other languages like Python) don't deliver proper math results by default when dealing with base 10 floating point numbers.  The real fix would be to use something like BC Math here which is slower (not enough to matter for this purpose) but delivers correct results all the time.  We ended up using BC Math for some of our custom FA reports because otherwise it's really flakey to do math on floats and then try to do an equality comparison with 0.0, for example.  Because the result of your floating point math will actually be something like 0.00000000000001239458345 if you printf() it with enough digits to see that.  Annoying!

-Jason

Go to forum: Report Bugs here

2 Topic by maasj

(3 replies, posted in Report Bugs here)

Hello,

Calling price_in_words() on the amount 1960.58 with user_price_dec set to 2 produces the string ''One Thousand Nine Hundred and Sixty and 57/100''  <-- Note ''57/100'' which should be ''58/100''.

Also, the amount 16418.29 produces ''Sixteen Thousand Four Hundred and Eighteen and 28/100''.  Again, note ''28/100'' instead of ''29/100''.

The following patch to ui_view.inc seems to fix the problem for me, but I'm not sure if it's the best fix.  Can you think of a better one?

--- ui_view-orig.inc    2012-02-07 13:24:33.398225655 -0500
+++ ui_view.inc    2012-02-07 13:24:36.218220917 -0500
@@ -774,7 +774,7 @@
     if ($dec > 0)
     {
         $divisor = pow(10, $dec);    
-        $frac = round2($amount - floor($amount), $dec) * $divisor;
+        $frac = (int) round2(($amount - floor($amount)) * $divisor, $dec);
         $frac = sprintf("%0{$dec}d", $frac);
         $and = _("and");
         $frac = " $and $frac/$divisor";

Go to forum: Report Bugs here

3 Topic by maasj

(1 replies, posted in Report Bugs here)

Hello,

FYI, in the $ones array "Eightteen" is misspelled and should be "Eighteen".

In the $tens array, "Eigthy" is misspelled and should be "Eighty".

Thank you very much!

Jason

Go to forum: Report Bugs here

4 Reply by maasj

(5 replies, posted in Wish List)

Hi Janusz,

itronics wrote:

It would be good to stay with old version, if possible. Even version currently integrated with FA has enormous size, but TCPDF 4.8 dangerously approaches  madness border - this is over 500k file! Over half a megabyte of code which is mostly not used in simple reports, but must be always included  hmm.
Just my 3p.
Janusz

Thanks for letting me know about the size concern!  Out of curiousity, what exactly is it about the size that is a problem?  Disk space used?  Performance concerns?  Amount of unknown code?  In most computing situations 0.5MB isn't considered a big deal these days.  It's not like we're aiming to get FrontAccounting embedded in every wristwatch, right?  smile

I'd like to have more flexibility for making nicer reports than the included ones, and tracking with a more recent TCPDF seemed like a good idea to me for several reasons:

- to have the last year's worth of bug fixes (it can be frustrating to encounter unexpected behavior and then wonder if it's a bug that's been fixed in a newer version, or if you just misunderstood how something is supposed to work)

- to have the last year's worth of features

- so the information on the TCPDF website would be more relevant to me and anyone else wanting to write more advanced reports

- to more easily communicate with the TCPDF developers and other users if the need should arise (you probably wouldn't be thrilled to be getting support requests from new FA users who were starting off with 1+ year old versions, right?  <grin>)

I'm almost done testing the integration of a newer version of TCPDF into FA.  What would be the best way to submit the code for your consideration?

Thanks for your help!

Jason

Go to forum: Wish List

5 Reply by maasj

(5 replies, posted in Wish List)

Hi Joe,

joe wrote:

The problem is lack of resources.

...snip...

You are, however, welcome to test if we can use a later version. Be aware of our own implementation inside tcpdf.php at the top.

...snip...

/Joe

Thanks so much for your fast and helpful response!  I'll do some testing to see if I need a newer version and whether I can integrate it into the FA 2.2 codebase.  I'll let you know what I find.  Thanks!

Jason

Go to forum: Wish List

6 Topic by maasj

(5 replies, posted in Wish List)

Hello,

I'd like to implement a number of new PDF reports for my employer using more features of TCPDF than are currently exposed via the FrontReport (& Cpdf) classes.  In order to do that I could either:

- write the reports using TCPDF methods directly, bypassing the FrontReport & Cpdf classes, or

- extend the FrontReport class to expose more TCPDF functionality

I'd like to go with the second option because I think it would be more beneficial to the whole FrontAccounting project and other users who may want to generate their own reports in the future.

But I'm not asking you to approve any changes I'd make yet.  First, I just wanted to touch base and see if you'd consider shipping a more recent version of TCPDF with FrontAccounting.  That could really help my work to make the FrontAccounting Reporting system better.  The version of TCPDF you're shipping in a recent copy of the FA 2.2 branch from CVS is TCPDF v4.0.027.  The authors of TCPDF seem to consider all 4.x number increments to be fairly major releases and there have been a bunch of those and lots of bug fixes and new features made since the version you're using.  They're up to v4.8.007.

So, would you be open to upgrading the version of TCPDF you include?  Is there anything I could do to help make that happen?

Thanks so much for considering it!

Jason

Go to forum: Wish List

7 Reply by maasj

(9 replies, posted in Reporting)

Hi Janusz,

Thanks so much for checking it out, verifying the problem, and fixing it so quickly!  I just backported your reports_classes.php patch to our 2.1.2 installation and it worked!  Good job!

Thank you,
Jason

Go to forum: Reporting

8 Reply by maasj

(9 replies, posted in Reporting)

Hi Joe,

We found the problem!  And I think that we may have found a bug in FrontAccounting in the process.  Note: I'm a system administrator here at DiscipleMakers who has been supporting Courtney's work in evaluating FrontAccounting.

The problem we found is that reports would not filter by Dimension unless the dimension's Reference field was set to a number.  And in particular a number that matches a dimension's ID in the underlying database.  So I think that either:

- the report generation system has a bug in that it mixes up the ID and the Reference when filtering on Dimensions

or

- there's a bug on creating dimensions in that the program doesn't indicate an error if you enter an alphabetic Reference or a numerical Reference which is out of sequence.

Does that make sense?

Let me explain a little more about what we'd like to do with FrontAccounting & dimensions.  We would like to use the Dimensions to represent people as if each person was a department in our company.  So it seemed natural to use the Reference field to represent their name.  So the Reference for Joe Smith's dimension would be "SmithJ".  FrontAccounting allows us to enter in a dimension Reference like that without a number and displays it properly in the list of dimensions.  But obviously filtering on that reference isn't possible when the SQL query tries to find a dimension ID which matches "SmithJ".

So is FA supposed to support alphabetic dimension References?  Also, it would be great if it was possible to sort dimensions by the Reference or Name field wherever a list of them appears in the program or on a report.  Does that seem feasible or is it supposed to be supported?

Thank you very much in advance for your help and please let me know if there's any other information I can provide that would be helpful!

Jason

Go to forum: Reporting