Search options (Page 1 of 97)

Extensions repo has been updated. Thank you very much, sorry for delay.
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.

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.

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

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:)

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.

@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.

After additional patch bugs seems to be finally fixed.
Thanks for cooperation on fixing the problems.
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.

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.

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

Thank you very much for pointing the problem out
J.

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).

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

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