This was a problem in the version 1.xx. Please upgrade to 2.0.3.
/Joe
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 joe
This was a problem in the version 1.xx. Please upgrade to 2.0.3.
/Joe
No, I cannot reproduce this. Can you give me an exact entry sequense. We have not heard of this before.
/Joe
Hello guys,
I'm glad that you have done some research on this. I have no experience in chinese languages. When I prepared the chart of accounts, I used utf-8 from pspad I guess.
Maybe you can change the characters in the chart of accounts to be the right encoding. I have, however, the original charts in the correct characters. So maybe I should use another editor for preparing the charts.
And finally, if any of you can give instructions here to us, so new users can benefit from this, please.
We got the Arabic languages to work smoothly, so we should also solve this ![]()
/Joe
BTW, please install the cid0 font for Reporting. It reduces PDF filesize enormously.
Bug fixed. CVS repository updated. Look in the ChANGELOG.txt for involved files.
/Joe
This sounds strange. Which version are you running? Did you do a direct invoice or did you go all the way with sales order, delivery and invoice?
/Joe
demouser - password
/Joe
Yes you are right. If this was the last module you deleted, you get this error. We are currently having trouble updating the CVS repository, but as soon as this is solved the CVS will be updated.
In the meantime you can delete the expression 0 => inside the empty array in /modules/installed_modules.php.
Then you are running again.
/Joe
You can try either of two things.
On line 37 in repgen_select.php
change require_once("repgen_const.inc") to require_once($path_to_root . "/modules/repgen_const.inc") or require_once("./repgen_const.inc")
The same method for line 38. Tell me if it works.
/Joe
I'm not sure if I understand your question in full. If you want to include the debt into FA, you could create a service item and invoice your customer with this service item and set the price to the amount. Of cource you will not send him this invoice. This is only for internal use. But this will include a GL posting.
I guess that you should not be able to include a debt into FA without GL postings.
/Joe
Hello,
Remember that we do this on a non commercial base. It is all open source, that is why you should help us reporting these things.
You can download a fresh CVS copy of alter.sql from the CVS repository and see if it helps.
/Joe
Try to set the $go_debug flag in config.php to 1, to trap ev. messages. If it doesn't help, look in the apache_error.log to see if any errors/messages are here.
/joe
You can use the following:
Create a Cash Customer and set him to cash (0 days) in Payment Terms. Creata also a Cash Branch. Use a Bank/Cash account as the AR account.
When creating the Direct Invoice, you can use som fields at the bottom to specify the buyer (address fields, I guess).
In this specific case the payment is done immediately and the invoice is allocated when processing the invoice.
This is much easier.
/Joe
The -credit this- immediately allocation problem is now solved. Also eventually exchange variances as the other payment/credit notes allocation.
The CVS repository is updated. File /sales/includes/db/sales_credit_db.inc.
/Joe
Yes, in Windows vista, you can set the sql-mode to an empty string in my.ini (inside the MySQL folder). The filename in Linux is my.cnf. Restart the MySQL server and you are done!
However, I have decided to change about 5 to 6 files for 'sloppy' sql and thereby minimize the risk for running into this. I have been through all of FA and not found that many errors in the strict sql. I gues about 5 or 6 files. The biggest 'problem' is the data that is already in the database.
So the best advice is to set the sql-mode in the my.xxx file to empty and go with that.
/Joe
Hello marvo,
Seems like we have found the problem. Date values and non string values can not have empty strings.
I'll install the version 5.0.51 of MySQL and try to trap eventually more errors.
The repository will be updated when this has been done.
I see that you reported another error in a different thred.
Please, marvo, if you have the time. Help with further testing.
/Joe
Please help us one step further. Instead of $SQLDueDate = date2sql($due_date);, please change into the following:
if ($duedate != "0000-00-00")
$SQLDueDate = date2sql($due_date);
else
$SqlDueDate = $due_date;
so it looks something like this
if ($due_date != "0000-00-00")
$SQLDueDate = date2sql($due_date);
else
$SQLDueDate = $due_date;and see if this helps.
/Joe
Marvo, the payment uses the same table, and therefore is sending an empty value. Will you do me a favor, helping me test this? I think this might be a MySQL version specific issue.
In file /sales/includes/db/cust_trans_db.inc, line 79, in function write_customer_trans. The parameter $due_date=null. Will you change that to $due_date="" (empty string) and save and see if this helps? It would be very appriciated if you will help us with this.
/Joe
Good Idea,
I'll put in on the poll page.
/Joe
There seem to be valid email addresses in both sender and receiver. I cannot say what the problem is. Some hosts need the sender email be part of the website. Otherwise I can see no problem. Normally this works right out of the box. Maybe there are others who can help here?
/Joe
I guess you need to set an email address in the branch. There was a problem in 1.16 only having an email on the customer. Also make sure there is a sender email in the Company Setup.
You do not need to set any SMTP setting. FA uses PHP internal mail function.
/Joe
The problem with the exchange variation has now been solved. The CVS repository is updated. Look in the CHANGELOG.txt file which files are affected. The variations on the various allocations are added to the Payment GL transactions. This way it is easy to see where they come from, and they also have a Sales/Purchase invoice reference in the memo field.
/Joe
Yes, you are right. And fortunately we have these default accounts in the company table, exchange_diff_act and purchase_exchange_diff_act. We have never been using these. We could use the first as the gain and the second as loss.
FA has never implemented these routines and I have been aware of it. And you are right, the best place to resolve the gain/loss of exchange rates is when the allocation is fully done. Then we are able to calculate the currency rate when the invoice was created and the rate from the payment date when we allocate. The difference could then be posted in the GL. Involving AR/AP account and gain/loss exchange account. Then it should even out in the long run, right?
We can add the two default accont listboxes in the System and General GL Setup. And we don't need to change the database structure. What do you say?
/Joe
BTW. Maybe it is enough with one account, called Exchange Variation for both the gain/loss.
I tried to reproduce this error, but couldn't. It seems to work as intended, but I have no answer to why your example doesn't work.
/Joe
Hello MorkvonOrk,
Fantastic work. Thanks a lot. Btw. I think you should rename it to nl_BE, according to the standard. Look in the sheet Download - Language definitions.
I hope you get the gettext problem solved. Mostly there are no problems, but when there are, it seems to be hard to find it.
/Joe
The 'Calculated return' doesn't come out of nowhere. It is the difference between the assets and liabilities. When closing a year, the assets and the liabilities should balance. But during the year it is normal to present a balance sheet as 'balanced', thus the 'Calculated return'. At the same time the 'Calculated return' is the difference between the income and expenses. You know that all the account transactions during a year should balance to 0. Debit = Credit. During the years the Retained Earnings is accumulated with this 'Calculated return' by making a final balance voucher, as explained in this thread. You use an expense account to balance the year, often the last one.
Please talk to an accountant about that, because it is easier to see this, when an expert show you how.
/Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.