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 (Page 79 of 97)
Topics by itronics User defined search
Posts found: 1,951 to 1,975 of 2,419
Well, I'm still not sure if those scenarios are examples of proper way of doing business, or how the money flows between friends 
. First case (if not identical to second) seems to be customer mistake, which can be fixed with next payment.
As far as I understand idea of prompt payment, giving this kind of discount make sense if the payment is received _before_ goods are delivered to customer. This is how some companies with only virtual inventory do their business via internet. The aim is to minimize time of delivery and stock costs. In most cases customer know whether he want to pay in advance at the ordering time, but in _any_ case some deadline have to be set for prompt payment (as subject to discount), to avoid unneeded conflicts. So if not at ordering stage, the deadline should be set at invoicing time. Otherwise you have to pay taxes calculated for total invoice value, also for discount amounts you have never received.
Janusz
AFAIK Portugal is currently the only country which has this accounting software requirement. We will look into this anyway.
Janusz
Currently additional discount for invoices paid in advance can be recorded during customer/supplier payment stage. This seems to be somewhat unhandy, as the right operation order in case of customer invoice paid in advance is usually as follows:
. During sales ordering customer decides whether he want to pay in advance, or prefers delayed payment
. Customer receives sales order copy or proforma invoice with stated additional discount available in case of advance payment.
. Customer payment is registered in system
. Final customer invoice is issued with prompt payment discount included.
Therefore we want to move prompt payment discount input from customer/supplier payment screen to order entry page, to be used during invoicing. This way we can also make proper use with Prompt Payment Discount Percent customer parameter, which currently is not used in invoice calculations, but only informative.
Any comments are welcome.
Janusz
Yes, the Modern Factor demo setup seems to be too restrictive at this point and should be fixed. Nevertheless you can test nearly full FA functionality selecting 'Training Co' company at login.
Janusz
Allocation is simply binding some part of payment with related invoice.
Hello,
This is very straightforward process, however you have to make some simple but necessary preliminary steps:
1) Learn php
3) Became familiar with FrontAccounting structure.
3) Learn Java
4) Recognize what Liferay guys meant talking about open source integration.
At this point right solution should be obvious, so...
5a) Implement some midleware software,
or,
5b) Customize FA to be integrated with Liferay,
or if you will find all this as worthless effort,
5c) Have a couple of beers.
Another option is to skip directly to step 5c saving some person/months, and use FA as it is, or spent saved time improving it.
Janusz
Company created in automatic process is exactly the same as created from setup using en_US-new.sql file, so this is why I have asked about this. Nevermind. I hope it was some temporary problem.
Janusz
Do you mean unstable version? All works right on fa2 demo regarding Journal Entry edition available via Journal Entry Inquiry.
Janusz
The version 2.1.3 is bugfix stable release as any other minor releases. This version does not have any problem related to this thread. I have just tested installation from scratch - no errors both during install nor Direct Invoice entry, so - as I said - I don't know the reason. Maybe this is something related to your Win MySQL installation or version (I use only Linux), but FA is always thoroughly tested before release also on Windows by Joe.
AFAIR the problem fixed was that user was allowed to delete some data from sample database content, which should not be deleted, which in turn lead to this databse error. You can find thread related to this issue somewhere on the forum, but as I said this was finally fixed in FA 2.1.3.
I installed the default and then created my own company from the setup page option - as explained in the forum. I used the en_US-new sql script to create my company. Could it be that there is a problem with the sql script?
I'm not sure I understand you right. What was the reason to create new company after installation, when all was working fine? After installation you have en_US-new.sql just installed, so for single company setup based on en_US file nothing more is needed.
Janusz
I don't know, but it seems to be Win Mysql verion related problem.Maybe you will find some solution here.
Janusz
When direct invoice is entered related sales order is created in background. This is idea of direct invoice. The error message is displayed when for some reason database structure is corrupted. Some time ago we had issue like this in FA source, but the message was displayed after failed upgrade from FA 2.0 to .1.x. Now it is fixed, so I don't know.
If you initially see only one supplier, regardless of number of suppliers defined you have supplier selector working in 'search' mode. To see all of them press space and input * in displayed input field. Or uncheck related option in company preferences.
Janusz
Yes, every company uses separated set of tables. All companies created are completely independent. Keep in mind that some (potentially dangerous) options are available only for admin of first created company (the super admin). This includes installing modules and languages, creating new companies and performing system upgrade.
Janusz
In Download Documentation section you will find ERD and database scheme for FA 2.1. All the changes introduced in development version (currently 2.2) you will find in sql folder (alter2.2.sql and alter2.2.php files).
Development process is made simultaneously in two CVS branches: stable (main) and unstable (development). If your main goal is to track bugs in FA, or make smaller improvements not involving database structure changes the better choice is to use stable source as released on SF.net. But if your changes are more time consuming and/or need some database changes you should work on your local unstable CVS branch copy. This way you will have easier merging of your code with next FA release. All bugfixes from main CVS trunk are merged to unstable branch after every minor FA release (2.1.x).
Regarding IDE, personally I also prefer simple editors, but I think this is matter of habits. For debugging I can advice xdebug php extension and firebug plugin for Firefox.
The best practice is to announce planned development to other guy e.g. here on the forum, to avoid hard to merge overlapping code changes.
You are welcome .
Janusz
You cannot simply replace one chart of accounts with another, because the COA is not stand alone feature, but is real foundation for any other features in FA. Most tables like suppliers, customers, items, transactions etc. has relations to GL accounts, so first you have to choose right COA, then fill database with other data.
Janusz
When you print document reports like invoices, the language used depends on currency off your customer/supplier. Translated messages are used only for customer using your home currency, otherwise the report is printed in English.
Janusz
FrontAccounting is entirely written in PHP, and there is plenty of good reasons why it is not written in Java. But if you want you can rewrite it to Java. It would be splendid exercise for your knowledge of PHP, Java and typing skill as well .
Janusz
The problem with error during database restore was related to MySQL version. Probably you have backed up FA on one system and restored on the other system with different MySQL version. Changing 'ENGINE' to 'TYPE' in respective queires should help.
Janusz
This is no way that FrontAccounting does not work on Linux. In my case Linux is development and production environment as well. Some people tell that Linux need user's expert knowledge to be used but this is the same urban legend like existence of user friendly Windows 
.
You should copy FA source files to some directory in apache document root folder (depends on distribution e.g. /var/www for Debian), direct your browser to install directory and follow install instructions. That's all.
Janusz
Thanks Pete .
The change seems to be not very controversial, but maybe current tax defaults scheme is crucial for somebody, so I think we can wait a while for some response.
Do you want to take over this fix?
Janusz
Recently during fixing bug found by Pete we have found current tax system in FA a little unclear and prone to erroneous manual accounting. To avoid this we want to improve it by small simplification of tax settings as follows.
Currently tax rates defined at Setup/Taxes have assigned default tax rate, which can be changed later on tax group level. We consider this additional flexibility as confusing and in fact unneeded. Therefore in FA 2.2 we are about to remove the tax rate setting on tax group level and always use the rate defined for given tax type instead.
The planned change seems to be harmless on most installations (often default rate values are used in tax group definitions without change), but anyway we are open for strong arguments against planned change as always.
Janusz
Well, I thought proxmox is another one administration panel like cPanel or lxadmin. Anyway I'm happy you have solved the problem .
Janusz
We do not release FA especially crafted as proxmox application. As far as I understand your problem, the best answer you can obtain from your hosting provider. Anyway this have nothing to do with FA configuration, and probably cannot be solved remotely without admin acess.
Janusz
No idea. Please set $go_debg=1 in config.php to switch error messages on.
Janusz
Thanks, Andre. I hope you will be satisfied using FrontAccounting.
Janusz
Hello Andre
Ok. I accept your point that it is not correct behaviour. But in no way I can agree with following statement:
Users over time start remembering codes so this leaves the application vunerable for abuse.VERY DANGEROUS!
It is sensitive to nonstandard user operation which can result in entry errors, but not for abuse. Or my understanding of term 'abuse' differs from yours. Nevermind.
All I wanted to said is that this problem does not appear during natural using of the user interface. Last but not least if you have some thousand of items in inventory you should check 'Search Item List' option in company setup, and you have the problem solved.
As for now I have not enough resources to rewrite complex combo related code, to fulfill your requirements. If you think this is really important issue please report it on our mantis bugtracker for later consideration.
Janusz
Posts found: 1,951 to 1,975 of 2,419
