1

(36 replies, posted in Reporting)

seahawk wrote:

On all three client sites the above SMTP Mailer setup is working.

On one site I get the following error:

Creation of dynamic property email::$phpmailerCharSet is deprecated in file: /home/mysite/public_html/accounts/reporting/includes/class.mail.inc at line 131

I have tried to redo the installation with still the same error. It is sending the email even with the error. Do not know why this is the only site with this error.

This is related to php version installed, and can be easily fixed by adding declaration of property phpmailerCharSet in email class declaration.

FYI, just released FA v 2.4.18 contains a couple of bugfixes to mailer class included in FA .
J.

Long descriptions were never editable on Invoice. Long description is retrieved from inventory database, when invoice is printed (or mail generated),and is not stored as part of document. Unfortunately this has also side effect, that change in inventory item long description is visible in every later printed invoices  (if long descriptions feature is active).
This is because long description feature was introduced in minor release, so database structure could not be changed.

So, If you want issue invoice with changed description the workaround is:
. issue invoice
. change long description in Inventory Item record
. print/mail invoice
. change back description in Inventory item to previous default.

J.

3

(36 replies, posted in Reporting)

Good point. Fixed in additional commit.
Thank you.
J.

4

(36 replies, posted in Reporting)

Seems this problem is Win php version related. This patch should fix two separate issues (the other one is bug reported in mantis 5711).
Thank you for reporting the problem.
J.

5

(36 replies, posted in Reporting)

As I can see, this fragment is not part of attachment, but for any reason pdf content was sent as email body, and marked as test/plain content type.
How the email was generated in FA?
J.

Hi,
Seems github has changed server id hosting FA mirror. Repos has been synchronised.
Thank you for pointing the problem
J.

7

(9 replies, posted in Translations)

Hi Ap.Muthu,

We are open for every new extension package which would make FA users live easier. I would like to add the packages to repo, but frankly in current form th_TH translation is well below any acceptable standard. Adding package with five translations from google will make more confusion than help for any new user.  I'm also not sure what is value in declared Thai COA. I cannot find any specific differences with basic universal en_US COA bundled with any FA release, beside adding Thai Baht currency. Is it localized in any other aspect?

Tamil and Vietnamese lang packs has been updated in repo, many thanks.
J.

8

(3 replies, posted in Translations)

Hi,
We do not use transifex, this is paid comercial service, and we do not have resources to use it effectively. Frankly, for our needs any text editor and average target language knowledge is enough.
Anyway, FA is open project, so if you wish to contriubute you are welcome to send your translation. on contriutions@frontaccounting.com.
Keep in mind there are two separate *.po files to translate, main for the application and separate for installer.
J.
PS As far as I know there is no Vietnamese translation in official FA repos for now, so I'm not sure where you seen Google translation. Anyway you are welcome to provide one for FA vietnamese community:)

9

(57 replies, posted in Installation)

I'm happy all works right.

Default fiscal year you can change at Company Setup page. Before that you should define all fiscal years you want to use at Fiscal Years. Keep in find, you can only post GL transactions in open years, so do not close year until you are ready with all the postings.

J.

10

(57 replies, posted in Installation)

Ok. To check the claims reported here I just have installed latest FA version from scratch on Linux box with preinstalled MySQL and Apache2 (I do not use windows nor iOS, so can't check it in those environments).
. downloaded current 2.4.14 tarball from our official site on SourceForge;
. unpacked sources in www server root subdirectory;
. created empty test database and dedicated db user  on MySQL server;
. opened main page of installation in browser;
. checked/fixed all the preliminary conditions listed on main installer page;
. performed step by step installation in installation wizard passing credentials to created database.

All works as expected. After that I have tested repo access installing FrontHrm module as example. Again, module has been installed properly and all installed and works as expected.  Now, I'm not sure how can I help. So, maybe some generic advices...

. If you are installing FA via some third party installer eg from cpanel or whatever - please, don't. Try again installing the application from the current tarball  available on Sourceforge (2.4.18 as of today), then check if it works properly. If you cannot ommit third party installer - please send claims to your server maintainer or installer authors.
.  Default repo settings works properly from the box. If you do have problems with installation of extension modules - this is most likely related to bad pemissions on  ./company, ./tmp, ./modules or main installation folder.
. Regarding problems with FrontHrm module, I have updated repo content to the last version available on Nostrinos github page.
Please install module via 'Install/activate Extensions' page, set access to the module on 'Access setup' page, then log out and log in again.
The module works as expected. Please send any bugfixes or feature request related to this module stright to Nostrinos via his github bugtracker. We do not maintain the module (beyond FA repo integration), so all thanks and/or claims please send to the author.

J.

Thanks for your comments.

Regarding the fonts used in FA I have to agree.  The themes for FrontAccounting were designed long time ago, for much lower resolution displays than current FHD standard. We will fix this soon. (In before, the application is designed for table displays, not smartphones, so - even if we received some suggestion to change this - we will stay with assuming table monitor as target display).

Regarding Hrm module by Nostrinos, I have just updated the version available from default FA extensions repo. Please test if you have any problems with this version. Frankly, in now way I could reproduce your problems with the module. Both previous as current version installed on fresh new FA installation works as expected. Yes, I could point many constrains in usage of this module in real business workflow, but bottom line is it just works. For any feature improvement please contact HRM module author.

J.

@sairmalhi

Well, I cannot reproduce this error too. The parameters passed to add_item_code() are correct, and the 'fix' (if I correctly understand your sugestion) boiling out to removing any argument from the call to add_item_code() is not acceptable.

More over, the add_item() function from /inventory/includes/items_db.inc is used only in inventory database edition, and is not referenced in any of sales modules document pages. There is no way the change in add_item() would fix problem appearing eg in sales_order_entry.php, so I guess this is pure coincidence, and - if the problem has gone - you had to fix it somewhere else.

J.

13

(5 replies, posted in Accounts Payable)

The bugs were just fixed here .
I have made some basic tests, but please confirm all works right now.
J.

After additional patch bugs seems to be finally fixed.
Thanks for cooperation on fixing the problems.
J.

Further fixes to this issue are in FA repo.

J.

Hi,
Yes, I can confirm there are further changes needed to fix all the issues. This will take me some time, I need to rewrite rep115 code, which is highly unreadable. When I'm ready, I will push the changes to repo,  and will send notice here with test request, or just contact you by pm.
J.

Right, additional fixes has been added. Hope totals works properly now.
Thanks.
J.

You have to check average cost of the problematic item (Items&Inventory | Standard Costs)
and/or  current inventory status (Items&Inventory | Inventory Item Movements) and fix invalid negative value either changing standard cost or entering inventory GRN.
J.

I'm not sure  I understand, let's focus on rep101.
Prepayment order should not be included in this report, only lines for sales invoice (250) and customer payment (250). So, if you have any sum in grand total (600) this should be equal to beginning balance for this customer.
Grand Total is sum over all GL history, including opening balance for selected customer.
Is this the case?
J.

Discussed fixes have been pushed to source repo here and here.

Thank you very much for pointing the problem out
J.

Yes, I think so, if this would make prepayments handling easier, why not.
We can add  another column  on Invoice Prepaid Orders page, displaying customer payments allocated but not invoiced yet (ie content displayed later on Final/Prepayment Invoice form field).

J.

advocaat.pollet wrote:

So, you can't see witch rows have (partial) payments ...  ALL prepayment-orders are presented, even when no payment(s) are booked ...
How can you know witch rows have to be invoiced ?

In 'Invoice Prepaid Orders' fully invoiced orders do not have link for invoicing. You can consider such an order as closed/ fully processed.
On the other hand all not fully processed orders have link to invoicing, and this is ok, because two cases are supported here:
. when you have any customer payments allocated to prepayment order, but not yet invoiced - you can issue prepayment invoice for this payment;
. if you have no customer payment allocated to this order, you can still issue final invoice, changing payment terms for still unpaid part of order, changing payment terms to e.g. delayed payment.
Those two situations are clear when you click on invoicing link: the final invoice have empty 'Payments received' info field (see also invoicing page title which mention both Prepayment and Final invoices).

advocaat.pollet wrote:

AND in every case (reports 101, 102, 108 and 115), when an invoice is made against the partial prepayment, not the amount of the invoice, but the amount of the whole order gets debeted in the balance !
This is very wrong !

Yes, I have confirmed this bug in comment above - to be fixed asap.

advocaat.pollet wrote:

Wrong 'Charges' also in /sales/inquiry/customer_inquiry.php? (Heading)

Agree, also to be fixed somehow (e.g Debit column).
J.

Sales order is never included in Customer Balances and other reports, as orders are not part of a balance.
What is included in customer balances is Sales invoice, namely 'Prepayment invoice' issued against customer prepayment. When you have registered customer payment allocated to (prepayment) Sales order, please use 'Invoice Prepaid Orders' option in Sales menu to generate prepayment invoice.

But still, at least 'Customer Balances' report needs a bugfix, due to invalid value displayed in 'Charges' column for prepayment invoices. This will be fixed asap.
J.

Ok, hopefully this is fixed now in master branch.
Thank you for reporting this problem.
J.

No, unfortunately we haven't separate person edit interface, which would be handy. But the person data (in crm_persons table) should be deleted automatically when all connections (records in crm_contacts) are deleted. But I have just tested and it is not.
This seems to be a bug, I will investigate it further.
J.