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 itronics
Money...Yeah, you are right, there is not a lot of munificent people on this bad world, so most time we have to spent on paid jobs. We have also some other FA functionalities under construction, in final development stage so extending POS features have to wait for its time.
But if you (or any other one skilled in php development) want to accelerate changes in this matter you are strongly welcome to join development mailing list, and continue progress. All help is always appreciated.
Janusz
If some business does not use stock control then all items sold should have 'Service' type set, and problem with cost update does not appear at all. 'Allow Negative Stock' option is not for this type of business. If your assumption is that there should be never negative inventory to have right valuation,existence of this option make no sense.
As far as I understand the idea behind this option is to allow sales even when items sold were not purchased from supplier yet. There is nothing weird in such quick sales operations in some type of ad hoc businesses, although for reliability reasons not often used.
Therefore I think we have one of the two cases: invalid option allowing negative inventory (while we cannot guarantee consistent inventory data in this case) or not complete cost update algorithm which fails in case described above.
Janusz
I' not sure I understand right all the problem, but defnitely all the GL postings should be done right regardless of status of 'Allow Negative Invnentory' option, or the option should be removed and negative inventory definitely forbidden.
Isn't this problem related to make GL posting to inventory account directly on Supp Invoice and not on GRN receival?
Janusz
Well,. VAT group IS used for incoming invoices for every item included. I think you do not understand right how the tax system in FA works, but you can test it. Please observe how tax is calculated for items purchased from different suppliers for demo data. As example company use USD as home currency Junk Beer from Denmark is in Tax Exempt group, while Lucky Luck is domestic supplier. Therefore VAT is calculated for items form Lucky Luck, but not form Junk Beer.
Another thing is costs entered via GL lines on supplier invoice. Regardless of type of supplier, every individual GL line can have different nature. So even for tax exempt supplier the costs can have various tax rates related to every one GL line. If you do not want calculate it manually you should create quick journal entries for all tax schemes you wish to use.
The only constraint in purchasing is currently assumption that all suppliers us pricelists without VAT (this obviously does not mean they do not use tax, simply the tax is adde and not included). This constraint was here since the start of original system FA derives from, and unfortunately it wasn't removed so far. Originally the application was designed for b2b companies which usually use only prices stated without tax.
Finally I have to say that adding GL lines on purchase invoices was introduced to enable recording additional purchase costs. The best solution for 'non-core' purchases would be separated page with a little another ui structure, not needing selecting from predefined inventory list. FA still lack such a page, but adding manual change for tax rates in GL lines is in no way improvement. And in no case better solution than use of predefined quick journal entries.
Janusz
I noticed the quick entry. This still looks to fixed. I would really prefer to have a calculated VAT and a default purchase account. Simular to line item invoices, except then based on the supplier fields: VAT and Purchase Account.
Yes, quick entry is exactly for this kind of calculations. We cannot do it automatically on every GL line entered in purchase invoice just because different type of 'non-core' purchases can have various tax item rates. E.g. two different rates are used in most countries using VAT regulations.
Janusz
Finally the exact problem on Dave's database appeared as deleted default POS. This shouldn't happen, but due to bug in checking routine it was possible.
If this is the case - add default POS with cash sales on, and update every defined FA user record (Edit/Update). After this sales order form should have all fields available.
Janusz
You have an example how to do it in customer_branches.php.
Janusz
Yes, you should set 5430 as account group (type).
Janusz
You cant. You can only inactivate items not used anymore.
Janusz
BTW. Please do not reopen old closed threads if you have questions not related to the subject. Open new thread instead.
J
Look into System Diagnostics page and check whether you have properly configured system or not.
Janusz
In Access Setup switch off 'Journal entry to bank related accounts' under 'Banking & GL transactions' for every role you which shouldn't have access to this type of postings. The best is switch of it in all roles, as bank related postings should be done via bank/supp/cust payment/deposit and not journal entry.
Janusz
Yes. Changing price list updates prices on all items added to cart. The guess algorithm for prices does not calculate sum of individual prices as default price. I'm not sure it is best algorithm, but at least if you see non-zero price for sales kit you are sure this price is right.
Janusz
He is right, bank/cash related GL accounts should not be used in Journal Entry. Anyway they are available for admin also in journal for historical reasons. Normal non-admin user have no access to bank related accounts in journal.
Janusz
Hello,
When I click on the"Place invoice" button the system does not complete the invoice and I get a yellow triangle exclamation mark on the bar at the top of the windows.
This is the same problem another FA user has (londondaveuk). He also use Ubuntu karmic. What are exact versions of php, myql and http server displayed on your System Diagnostic page?
Janusz
This is document issued when seller receive back items previously sold by customer, or agree that customer anyway can not to pay for some part of delivery.
Janusz
Change collation in 0_check_account table with pmyadmin to the same as used in 0_bank_accounts table.
Janusz
This is a way to generate new delivery on the base of another invoice already entered in the past.
Janusz
"found that IE8 worked but whatever you did to IE7 in terms of settings did not."
Have you downloaded new version of inserts.js form CVS, or made the fix descried above manually? I cannot guarantee anything on IE7, but after the fix at least the problem you have reported seems to be gone.
"Now on to setting this up - I'll contribute back the COA's if that might be of use."
Ok, thank you Tim.
Janusz
You should unpack the tarball in your www server document directory, then simply open index.php in this directory with your browser, and follow installer wizard instructions.
Janusz
I have just solved the problem. Please remove ending comma at line 308 of /js/inserts.js. For some reason IE7 does not like it. I am preparing some smaller fixes to current FA version just now, so this fix will be updated in CVS later today.
Thank you very much for tracking this down. I really does not use MS windows at all, so I had to ask my son for help. Fortunatelly he still has XP installed for gaming 
.
Janusz
Hello Axe_man,
"Well, I certainly don't want to start one of those e-mail fights with you, that's for sure - it helps noone."
So we are on the same side, apologies if you had another impression 
.
For interest, I installed weberp before FA, and this works ok. This is weird, because FA is a fork (I think?) and I wanted to run the more up to date system.
FrontAccounting is rather complete rewrite of webERP than simply fork. As you certainly noticed FA has (between others) completely different user interface, more consistent and designed for fast kbd data entry. We try to ensure our application works on any lamp based system which has php>4.3.2 and mysql >3.23.58, but using bleeding edge php version is not tested well (we are working to make it better).
I have just tried ypur demo system as you suggested, and it behaves identically to my installations.
This is the good news .
Take this trivial example which I have just done on the demo system.
In Chart of Accounts maintenance I have just added an account 0001. The screen now shows a green line at the top telling me that the account has been added. The form still has the 0001 data in it, but the account code is now greyed out.
Now if I want to amend an account, say "1060 Checking Account" I call that up on the drop down, but there is then no way to amend that - at the bottom of the form I'm only given the choice of updating 0001 or deleting it. Now the manual showed an 'edit' button when a drop down item was selected to enable amendment, but that is not shown in the demo systemNow I may be being incredibly stupid (possible / likely) but I can't see how an amendment is then done to an existing account. This applies to other master data, such as customers etc. That's the nature of the problem.
Well, I'm really lost as I cannot reproduce your problem.When you want to entry new account you should select first selector option (New account ) as you have described. When you want to change any account, select it via the top selector, then you have all editable parameters for this account instantly available. The account code itself is grayed out (not available for edition) simply because it is used as key in another tables, so changing it could broke database consistency. If you really want to change the code you can delete account and recreate again with another code until this account is really used, otherwise you can deactivate the account to be not available in selector throughout FA ui. After the change you have to press update button, that's all.
It is how it should work, and it do for me (Debian, FireFox). As far as I understand you cannot change top selector, or after the change the edition form is not updated and still details for previous account (0001) are displayed. Is this a case? Have you javascript switched on in your browser?
Janusz
PS. I hope after initial problems you will find FA useful for your application. Keep in mind FrontAccounting is community-driven project, so if some feature is missing in core code, but can be implemented with advantages to wider audience - it is added directly, or at least we help develop extensions .
J.
" try to explain what is your problem"
I already made a post elsewhere giving details of one particular problem, but as yet noone responded. This was pretty basic, in that in this installation it is not possible to amend COA details - and this is just one example of the issues.
Well, I have read your post, but I had really not understand what you mean. Now I think you have tried to test FA against outdated manual, which can be confusing. Sorry for that, we should simply remove the manual at all from our site until it will be up to date.
Anyway you can look into FA demo available via link on our home page. If the demo works another way than your local installation - this is probably some installation or compatibility bug.
However, more importantly, I don't just try and then give up and burat into tears, and I find that remark demeaning and completely uncalled for. I have installed, re-installed, and checked several times befire I posted. I have checked table updates with phpadmin and put on logging, including sql logging. I've been in the software busines all my life so I can test in a structured manner. In fact, my business is designing and implementing enterprise capable (>1m entries per day) ledger systems for investment banks, so I also know which side a debit goes on. [Indeed, I was planning to contribute some specific COAs if FA had functioned]
Sounds interesting. There is still a lot to be done both in FA design and testing, so if you are still interested you are welcome.
I made it very clear in this post that I was not suggesting FA didn't work, only that something in _my_ installtion didn't work and it was not practically unusable as installed here. As it is just don't have the time to spend further trying to sort it out when something else may work out of the box. I was not in any way berating FA or its development team.
Ok, no problem. Please try compare your local FA behaviour with the demo, and when unsure do not hesitate ask again. We always try to help fix any problems with FrontAccounting, when we have a chance to reproduce them locally.
Janusz
If you need any help please stop cry, dry your eyes and try to explain what is your problem. For now the only thing I can understand from your post is that FA manual is not up to date. Yes, it is.
Janusz
Such weird effects are likely if you have updated your local translation file (po/mo) and have not restarted apache server.
Janusz
1. I have just customized rep107 to be in accordance with Polish legal rules. It includes adding VAT summary, per items VAT rates and amount in words. If you wish I can send it to you directly (not ready to be placed in download area yet).
2. You have 'Round to nearest cents' setting in company setup.
Janusz
FrontAccounting forum → Posts by itronics
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.