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
You are happy people with so simple tax system, but I have to say this is really rare case. We do not want to complicate invoice interface with additional tax selector, as anyway in most fiscal systems it will be unusable. You have at least two options: define items which will implement GL lines with right taxes, or enter tax line manually as separate item. Or customize php scripts to have this made locally.
Janusz
Hello Mike,
Yes, this is good idea to place all the info on the development wiki. Currently we are more than busy with latest fixes before final 2.3 release, but after it is released we will have more time for cash/accrual VAT implementation. Good news is in the same time I'm involved in implementation of VAT related changes for Polish fiscal rules. As the rules are at least similar throughout EU some of them surely will go to core FA, and will be helpful during other local european VAT implementations.
It is up to you whether you will describe the matter directly on Wiki, or using GoogleDocs. To have write access to the wiki you simply need to log in via forum or wiki interface. I'm not sure about write access rules to specific wiki pages, so if you encounter any problems give me a note.
Thank you for helping us to make FA more friendly for european users 
.
Janusz
Yes, this seems to be small bug. Will be fixed in CVS.
Janusz
Yes, item codes can contain dashes.
When you import only items you have to use only stock_master and ite_codes, but import items quuantities involves also other tables (at least stock_moves). Look into related *_db.inc files to find more info.
Janusz
This is how the system works and it seems to be quite obvious: when you use items defined in inventory, every item has related tax group assigned, so the system knows how to calculate taxes. But If you entry arbitrary GL items you have to enter them correctly with apprioprate tax related GL lines based on your accounting knowledge.
Take into account common situation when more than one tax is applicable depending on goods/services category e.g. we have tax rate for luxury and normal goods. How the hell system can guess which one you want to use on GL items?
Therefore if you want to have taxes to be calculated fully automatically, do not use GL lines, but define in 'Items' special item for e.g. freight costs, and use it as additional item line in supplier invoice.
Janusz
Nice to know . Good luck.
Janusz
I'm not sure what can be a problem here. Can you send me database table dump for which you encounter enormous delays?
Janusz
In previous FA versions tax was not displayed in purchase documents at all, now it is. I have no time to check what was changed on demo site (everybody has access to the demo settings), but believe me: if tax system in FA is set right, the tax is calculated and displayed in purchase documents correctly (or at least it works fine on my setup). Wiki explains how to set tax system in FA.
Janusz
I have no reason to hide . I'm too lazy to check whether the tax display was added in 2.3RC1 or later, but please look into next.frontaccounting.eu demo - tax is displayed during purchase invoice entry in last 2.3RC3.
Regarding rbnzl question I'm not sure what is the problem you want to cure. If you have multiply service items which are posted on the same GL accounts (including taxes) and you do not want to entry multiply barely used service items, you can set one generic service item with editable description. This way you can use it for any services posted in the same way, while the descriptions on entered purchase invoice will inform you about real service registered.
Janusz
Regarding recurring purchase transaction it will not be added in 2.3. Maybe in next (2.4) release.
Janusz
You had some error during FA installation, otherwise installed_extensions.php would be created by installer as required. Look into Setup/System Diagnostics page to find whether you have some problems with directory access rights.
Janusz
Access to menu option is controlled via access roles setup. First you have to select some security area for the new menu option. If you want the option to be available for all users you can use SA_OPEN. Use the code you have selected as forth parameter in add_rapp_function/add_lapp_function call in respective class. Also put $page_security='SA_xxxx' at the top of your new option page.
If you have selected standard security area code other than SA_OPEN you have to enable related area in your role setup.
Adding non-standard security area code is more complex. You can download some FA extension to have example of this.
Janusz
Starting from PO supplier invoice cannot be entered unless you receive any items against PO via Oustanding Purchase Order Maintenance page, so surely in scenario above you have missed one step between B and C, but main misunderstanding is here:
I had already put in here the main account (80% of the delivery will be booked there).
If you want to use item related accounts you have to set Purchase Account option to 'Use Item COGS/Inventory Account' . Otherwise the purchase invoice will be posted according to supplier (not item based) setting.
Janusz
Reading such generic claim I have no idea what can be reason of the problem. Check our demo site. If you can run it normally in your browser you have done some mistake during FA install. Check also System Diagnostics page under Setup tab.
Janusz
Ernie, please try refer to real menu option names otherwise we will not understand each other. Nevermind.
I was entering via supplier invoice, and then I added purchase orders.
This way you have entered purchase order not related to the invoice.
The GL account is taken from the supplier account, because everything is booked to this account, anyway what is entered at the item.
When you set Purchase Account selector in Supplier record on really first option (Use Item inventory/cogs account) you will have what you need. This way you can select both behaviours: GL accounts used during purchase can be related to item or to supplier.
Janusz
I think the german and polish law is less or more the same in this regard. Namely the same same regulations are in case of sales invoice (delivery note is not fiscal document, so at least in smaller companies this is nt a problem).
In FrontAccounting every invoice has at least one underlying delivery note, so you can always print real delivery date on invoice providing transaction date on DN is the real delivery date. When DN has no such strict requirements (as in Poland) you can always entry real delivery date on DN entry.
Janusz
Yes, you can be right, but anyway final version 2.3 is to be released in December with complete de_DE translation.
Janusz
I can't reproduce the problem - company is created as required providing user/password db account has granted access to create new databases.
If you can't create database from php level you can still create database manually and then use it during company creation.
Janusz
Which version do you have ? (version 2.223 was never released ).
Version 2.3RC3 seems to have complete de_DE translation.
Janusz
I can't reproduce the problem. Testing both old way of purchase (via PO, GRN, Purchase Invoice) and the new Direct Invoice the items purcase is posted to item specific GL inventory accounts.
The other problem is, if you enter the second supplier invoice, automatically the GL accounts from the last entry are shown and taken for the booking, there are not shown the accounts which are recorded at the items.
I'm not sure I understand you right. Where you see those old postings - in GL items section of Supplier Invoices screen?
Janusz
When invoice is issued agains single delivery this change is easy but requires changes in php sources. But what about single invoice covering multiply deliveries sent on various dates?
Janusz
Quotation is functionally equal to proforma.
Janusz
I'm not sure I understand your question right, but bank accounts are available in journal when you are logged in as admin. Joe knows the details better, so I hope he can advice you more if you are still in doubt.
Janusz
This means application cannot connect to database server, probably due to incorrect authentication data in config_db.php. Check the password/logn/host/database name again.
Janusz
Yes, you are absolutely right. Move them all into connect_db.inc.
Janusz
FrontAccounting forum → Posts by itronics
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.