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 apmuthu
FA v2.3.13 Mer 3109
File: reporting/rep301.php lines 148 to 158 place the individual detail entries for the Inventory Valuation Report. The decimal formatting is not respected as the deprecated
&$decis used.
Lines 310 - 312 of includes/current_user.inc:
function price_decimal_format($number, &$dec)
{
$dec = user_price_dec();clearly do not take in the $dec from the function parameter.
This results in the kind of multi-decimal output in the report snapshot attached.
Check the SQL schema diffs between before and after backup/restore
lang\new_language_template\LC_MESSAGES\empty.po
needs to be copied to
lang\C\LC_MESSAGES\C.po
Beware of case sensitivity and all paths are relative to the FA folder in the webroot.
This is probably specific to Win7 installs.
Copy over the empty.po as C.po.
Create a faillog.php file in the webroot.
It is most certainly a permissions issue on the folders.
Which versions of XAMPP / Uniform server are you using?
Refer Forum Post for both the changed file sets (v2.3.12 to v2.3.13 and from v2.3.13 to Mercurial 3109) and overwrite your existing files.
There are no db changes.
Just check the difference between your config.default.php and your config.php file for newer options and update config.php accordingly. Use WinMerge2 for the job if you're on Windows.
Since the release of FA v2.3.13, a few fixes have been made especially those that deal with module installation requiring sql updates. Attached is the Mercurial Build 3131.
Weight can be a unit of the item and it will be shown in the invoice if the price of the item is based on the Weight then it would appear in the Quantity column.
Create a new Currency called Coupon (CPN) and set the exchange rate!
An Access role for the Customer can be adjusted if necessary and a user created and assigned the said role. Placing an order but not being able to edit the order after it has been delivered / invoiced is the need that must be ascertained of role's functionality before trusting it.
Thanks Joe, it would have taken me quite a while fathoming the logic and code hierarchy to set this one right. The fix has come extremely fast!
There is no need for such code at all in general. The packing slip will suffice - only the difference in title exists.
Maybe a title such as "Packing Slip / Delivery Order" instead of just "Packing Slip" is what MacPhotoBiker desired.
Please refer the Wiki page.
Refer FA Bug 1902.
Only the Pie and Donut do not print correctly.
Server - Apache, PHP 5.3.3.7 on Debian 6.0.6
Client - WinXP
Browser - IE 8 / FF 16.0.2
Any Reporting Menu -> BS and GL -> Balance Sheet -> Graphics -> Select each Graphic in turn.
The attachment contains the graphics screenshots for each graphic choice for the same data.
Thanks carmelr, changed it in the Wiki as:
ALTER TABLE `0_sys_prefs` CHANGE `value` `value` TEXT NULL; The code was taken from SQLyog's standard history output.
If the errors have to do with PHP v5.3 in the PDF generation then Mercurial ChangeSet 3107 fixes it. This fix is after the release of v2.3.13.
Thanks Janusz. That was fast.
Hope all the strings are in empty.po - there are many references to the string "#" - lines 211 to 244. It is probably a substitute for "Sl.No." - Serial Number - in column headings in some or all the files listed.
The v2.4 alpha needs to get synched with the current default version.
I was addressing the temp fix by twitty1437.
The Packing Slip does fine.
Looking up the code for this issue enlightened me on the report code format that needs to be Wikied.
Line 3121 in reporting/includes/Workbook.php
if (ereg("^\"[^\"]{0,255}\"$", $this->_current_token)) {may need to be changed to preg_match for PHP 5.3 compatibility.
Can have an option in the report request form to print delivery note without prices.
Also may need to blank out the $DisplayDiscount as well.
Instead of value being 0.00, it can be blank and skip the computations it uses.
Could be a cache / session issue. Whenever any config setting / preference is changed it is advisable to clear out the cache and login into a new session.
Also, if any js setting changes (like date format, etc), empty out the company/X/js/*.js files where X is the company number.
There are 50 altered files from v2.3.12 to v2.3.13 which are attached in this post.
There are no database changes keeping with policy on minor release versions.
There are a few new and / or expanded options in config.default.php that may need to be added to the existing config.php for those upgrading. Backward compatibility has been ensured even if not done, but to leverage new / expanded functionality, it is advisable to include them.
This release is Mercurial Changeset 3106 of the current default branch.
Thanks Janusz, the OpenVZ template is now in synch with the FA codebase except for the db fix in Mantis Issue 1758.
Yes. A possible mailout from the Forum / Wiki to all users about a new release may quicken adoption of latest codebase. If the GitHub model is chosen, then we can avoid releases itself and have it downloadable therefrom - even the Mercurial does have snapshots download possible but is yet to be enabled in FA's Mercurial.
Please look into subsequent additions to Open Bug 1785 - I am having to manually update code each time - the negative values are not so much the issue. The optional avoidance of the faillog is nice besides the ability to take values after a delayed include.
Also please look into whether Fix in Open Bug 1858 can be accepted.
Analysing the SourceForge Download statistics yielded a nice insight into how many downloads occur within 2 days of a new release.
Approximately 300 downloads occur within 2 days of a new release at SourceForge.
* General Users download from SF.
* Developers take it from Mercurial.
* Bleeding edge non developer users take it from snapshots forum post.
* Hosting Panel users get only what their bundles offer (cPanel Fantastico, SimpleScripts, TurnkeyLinux, Webuzo, etc).
* Clients get their code from Consultants' archives
GeoIP based Country Stats indicate that
* USA 14%,
* Indonesia 12%,
* India 9%,
* Netherlands 6%
account for a sizeable share of 41% of downloads in 2012.
Other countries above 2% each are Pakistan, Malaysia and UK. Together, the 7 countries account for 49% of downloads in 2012.
This is certainly not representative of the usage distribution, but rather the segment that actively takes it from SF immediately when released. Weekends, holidays, individual pre-occupation and other geographical differences have not been taken into account.
On the complementary side, there is plenty of scope to usher in fresh adoption in low download countries - business potential!
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.