4,676

(11 replies, posted in Accounts Receivable)

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

4,677

(1 replies, posted in Wish List)

Good Idea,
I'll put in on the poll page.

/Joe

4,678

(26 replies, posted in Setup)

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

4,679

(26 replies, posted in Setup)

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

4,680

(5 replies, posted in Report Bugs here)

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

4,681

(5 replies, posted in Report Bugs here)

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

4,683

(13 replies, posted in Translations)

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

4,684

(7 replies, posted in Banking and General Ledger)

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

4,685

(13 replies, posted in FA Modifications)

Regarding # 9. Yes and this is related to one of the wishes in the polls on the poll page. I think we can do it this easy.
Ah, regarding the Cash Only. In case we do not want to give the customer 1 day for cash only, we should set it to 0. N/A is either column that is not in use.

/Joe

NO you can not get your 1.16 data into a 2.0.1 version that way.
This is mysteriously. There must be something with the database user/password. You can check in the file config_db.inc for the correct data to give to the update_db.php. Please try and check this. I have never heard this error before if the data is correct.

/Joe

4,687

(13 replies, posted in FA Modifications)

I forgot. Your # 7 was a good idea. Will include that in release 2.0.2. We do it as an extra selector box, Inventory Column, or so with 'Yes' and 'No' default to 'No'.

/Joe

There should be a script in the root folder, called update_db.php. Run this script twice. The first time you should include the file alter.sql from the /sql folder. The second time you should include the file alter2.sql from the /sql folder. After that everything should run.
You are simply running the 1.16 database on the 2.0.1 release and there are several changes to the database structure.
There should be instructions in the update.html about that. Probably not very easy to find sad

/Joe

4,689

(13 replies, posted in FA Modifications)

You change/add Payment Terms in Setup, Payment terms. After that you can select the payment terms in Sales / Add and manage Customers. You can also set the Payment terms for a supplier in Purchase.

/Joe

4,690

(13 replies, posted in FA Modifications)

6. What is the reason for printing the P/L in another currency than the domestic currency?
8. Due-date is customer specific. It is calculated based on the payment terms.

/Joe

You should press the button in the Sequence # column to get an editable line. After processing the line it is entered to the upper list and removed from the lower list.

/Joe

And just think of the dimensions as a subaccount in this matter. But the dimension are much more powerful. Using dimensions you can get balance sheets/income statements for a local dimension or for a group of dimension 1 (if you use 2 dimensions on a transaction line).
So you can keep your internal accounting by department - cost centres. I mean for a total department or a costcentre inside the department. So you see this approach is much more flexible.

/Joe

Yes and no. You can just let the account code be 101111 Cash Sanur Mr.X. Your reports will be sufficient enough anyhow. Use the groups wisely. You can have as many groups as you like for this, but try to make it easy to understand.
The account_code2 is on another separate level.
And if you need detailed, yes use the dimensions.

/Joe

FrontAccounting is built up from Account classes, account groups (or types) and accounts. So a single account belongs to a group and a group belongs to a class. This way it is easy to build balance sheets and income sheets. How you build the accounts is up to you.
Certain countries use this:

1000 Cash
1010 Cash Jakarta
1011 Cash Bali
10111 Cash Sanur
and so on.

Without building these as subaccounts, which is not necessary when you use a modern SQL tool like MySQL. Instead companies use dimentions to get detailed (internal) accounting for projects, cost centres and departments aso.
Some tax authorities in certain countries insist on having a special code for calculating taxes in their own way. The account_code2 is used in these cases but it is a total free field, and if your tax authorities do not demand this, you can either ignore it or use it for your own need.

/Joe

You are free to build your account just like you wish. There are a total of max 11 characters in the account code field. You can build with or without a point in the account. Just remember to set the chart_of_accounts to be alphanumeric in config.php if you with to use non-digits in your account code.
If you need a detailed accounting, consider using the dimensions instead. Look in the dimension forum for more info.

/Joe

I'm not sure if I understand your question? If you mean which type of accounts, the answer is that we only have the provided ones that can be downloaded in the download section. You can select a fresh chart, like en_US-new.sql that comes with the core installation and create one that suits your need. Delete not needed accounts and create your own. Then you can make a backup of this and download it and use it in future companies. In that case, make sure the table prefix is set to 0_ before all the tables.

/Joe

4,697

(1 replies, posted in Installation)

The item categories are sorted by category id. You can change the order by adding an ORDER BY in /inventory/manage/item_categories.php.

/Joe

4,698

(2 replies, posted in Setup)

Hello, just create the items as services, then there is no stock control.

/Joe

4,699

(4 replies, posted in Modules Add-on's)

Your solution is perfect.

/Joe

4,700

(4 replies, posted in Modules Add-on's)

We are aware of this problem. We had to escape all the input database fields in FrontAccounting to eliminate spammer injections. Spammers could add html code into the fields and thereby inject the script.

/Joe