Skip to forum content
FrontAccounting forum
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
Active topics Unanswered topics
Search options
I upgraded from 2.4.14 to 2.4.16 and just wanted to run my monthly statement reports to my dealers.
So I selected customer and email: yes.
Then I got the message "customer xxx has no overdue debits. No email is sent".
WHY? I checked an older version of rep108.php and it hasn't got this check... and I even can't find in the GITHub change logs anything about this.
if (($CustomerRecord["Balance"]) != ($CustomerRecord["Balance"] - $CustomerRecord["Due"]))
$rep->End($email, _("Statement") . " " . _("as of") . " " . sql2date($date) . " " . _("from") . " " . get_company_pref('coy_name'));
else
display_notification(sprintf(_("Customer %s has no overdue debits. No e-mail is sent."), $myrow["DebtorName"]));
This makes no sense. Even if a customer has NO overdue debits he still needs to be sent a statement... I could just print it into a PDF, which still works and then manually create an email... but why would I need to do this...?
For now I have overwritten the new rep108 with the older one to keep the functionality.
@joe: thanks for getting to the root cause of this bug.
Did you also check that the cost are correctly calculated, since they had been also wrong.
Thanks Joe!
Updated and works fine.
@Braath Waate: sorry for my late reaction and thanks for posting this.
Please excuse my ignorance - I'm not very experienced with git - with what do I parse this script to change the source file?
/cheers Andreas
Using 2.4.8 and also tried in 2.4.6:
1. create new sales order
2. Click on "Email this order"
3. Email will be correctly send with PDF attachment
But the name of the attachment is just ".pdf" - many clients can't open the file.
I remember that it was in the past a proper name... what am I missing?
When emailing quotes or invoices the PDF files have their random IDs...
apmuthu wrote:Please make sure you have tested with the Git Master which has the post release fixes too. The file includes/ui/allocation_cart.inc was updated on these dates:
2020-03-18 (after FA 2.4.8 was released)
2020-01-11
2019-12-26 (after FA 2.4.7 was released)
2017-11-10 (before AF 2.4.6 was released)
FA 2.4.8 was released on 2020-02-05
FA 2.4.7 was released on 2019-06-25
FA 2.4.6 was released on 2018-12-18
I appreciate your answer, although I'm not a developer so please excuse my ignorance to GIT... I would expect that fixes in a presvious release are getting added into the next release. Especially if we talk about base functions like receiving goods?
Braath Waate wrote:All I can say is that your web page processing is messed up in an interesting way. "Clear all GL field entries" is the title of the button "Process Receive Items" and would not normally display unless the cursor hovered over the button.
It would interesting to "View Page Source" in your browser to see what was actually loaded and that might give you a clue as to what is happening. Maybe the server is sending some garbage preventing the browser from running the page.
Sorry mate, not sure what you are talking about... there is nothing wrong with my server... using FA now for 8 years.
Same problem comes up for other users.
Hi team
I was using 2.4.6 before and did not upgrade to 2.4.7, but later to 2.4.8. I tried now to receive an outstanding purchase order and it does not work anymore.
I just get the info "Clear all GL field entries". Another user reported the same for 2.4.7 and it's true, I tested with 2.4.7 as well, same problem.
So this means I will have to downgrade back to 2.4.6 (with all the problems we had there).
Could someone of the developers have look into this PLEASE?? I wonder why noone else did report this before? It seems to be a quite normal procedure to receive stock...
Also stock adjustement does not work properly!! Minus adjustments are handled as PLUS adjustements!
These are major bugs and I wonder what going on in the developers area...
Hope you guys can find the grip on this. I have really enjoyed working with FrontAccounting till now.
Since 2.4.8 any negative adjustments are booked as positive adjustments!
Was working fine in 2.4.7.
Seems as if one of these fixes broke something:
** Inventory Adjustment: fixed error in adjustment entry when inventory notifications are switched on.
** Inventory Adjustment: negative adjustment should always use current average item cost.
Downgraded temporarily to 2.4.7 to get end of business year stock adjustments done.
Would be great if this could be fixed soon.
https://www.dropbox.com/s/3iprw57lmi1xra4/Screenshot_2020-04-05%20Item%20Adjustments%20Note.png?dl=0
https://www.dropbox.com/s/tjv09kctyzhpt7k/Screenshot_2020-04-05%20View%20Inventory%20Adjustment.png?dl=0
Thanks for the given hints. I have chosen to change the code in doctext.inc. Forcing $Addr1 always only to use the debtor name and address. In that way I still can use a proper branch name, which I need for the delivery address to be correct.
(Ref FA 2.4.6) We have customers with multiple shops as delivery addresses. The customer's company is the one which needs to be invoiced to, independent to which branch delivered. But FA does always print on the invoices the branch name (which is different to the company name) and address. When I go to "view invoice" is does state the correct "charge to" company, but this information is not used when printing the invoice?
How can I force to get on an invoice with the main customer company name as "charge to"?
Thanks. I have upgraded to 2.3.26 without problems.
I have installed a separate version of 2.4.2 with all latest patches and a default company.
I have create my own company (db set 1) and uploaded the database backup from 2.3.26 (same company prefix).
I have started the DB upgrade - but does not finish... how long can it take to upgrade a DB when it's size is about 11MB?
I might need to change timeout values for PHP or MySQL accordingly?
Upgrade log reports:
[07-Sep-2017 04:19:44 Europe/Berlin] [Info] Upgrade started for company 1.
[07-Sep-2017 04:19:51 Europe/Berlin] [Info] Security backup in file ../company/1/backup/frontac_1_20170907_0419.sql done.
[07-Sep-2017 04:20:58 Europe/Berlin] [Info] Switching database to utf8 encoding from latin1
After that the screen just returns to a blank screen. It takes about 60-90 seconds. I have set PHP timeout to 300 sec.
When I try it again it will report many already existing or missing fields due to partly converted DB:
Last log entry before it stops is: 308:Unknown column 'counter' in '1_budget_trans'
What I don't understand is the statement "switching DB to utf8 from latin1" as the DB is already in utf8.
Remark: I run these tests currently on a local machine with XAMPP PHP 5.6 and Maria SQL Server 10.1
I have copied all 2.42 source files over my existing installation (on a copied system) and can log in as admin. I get the warning
"System is blocked after source upgrade until database is updated on System/Software Upgrade page".
So I went to Setup -> Software Upgrade.
After clicking, the browser just sits there and spins till after about 2 minutes later I get:
"Request Timeout
This request takes too long to process, it is timed out by the server. If it should not be timed out, please contact administrator of this web site to increase 'Connection Timeout'. "
Any ideas?
All currencies are created and maintained with correct exchange rates - otherwise I wouldn't be able to enter any transactions.
The problem is that I have exchange rates USD/NZ and EUR/NZ. When I enter now a purchase payment for an USD supplier from an EUR account, both exchange rate tables are used to acquire the proposed exchange rate, rather than the field, which is also existing in the form - any values I enter in the field are ignored for calculation.
So what happens to the value in form then?
(type="text" name="_ex_rate" size="8" maxlength="8" value="1.186675"> NZD = 1 USD)
Hi, our home currency is NZD, but we also pay USD suppliers from an EUR account (EUR account is in FA). I enter the correct exchange rate into the field "Exchange Rate", but the USD value does not match afterwards with what I have on my transfer receipt. Apparently the already existing exchange rates in the database are used, which are the official ones. Just try to enter as exchange rate "1", as long as there are other exchange rates available the result will not match.
So either I haven't understood the concept behind this option or this is a real bug...
Cheers
Andreas
Posts found: 15
