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 152 of 201)
Topics by joe User defined search
Posts found: 3,776 to 3,800 of 5,003
Hello,
If this is the fact, then you would set it up as follow:
In Tax type, setup a fed tax 5%, value 5
Provincial tax 7.5%, value 7.88
Then combine them into a group, and you are done.
Maybe there are some Canadians that can help me further here?
/Joe
The groups are sorted by class_id, group id. And inside the group_id it is sorted per subgroup. When running the reports it is doing the right way.
This is the way it works. You can rearrange the group_id. The update routine will adjust the subgroups and accounts groups in the accounts table accordingly.
/Joe
Please look into our wiki,
under Working with FA, Items and Inventory, Purchase pricing. Here you can read all about conversion factors and cartons, boxes etc.
/Joe
You should also download the following file from CVS unstable
Otherwhise some of the reports will not print.
/Joe
This has now been fixed in CVS unstable. Affected file /includes/ui/ui_lists.inc.
You can download it here:
/Joe
Yes, I understand.
The Account Group table above is ordered correctly, but the combobox list is sorted in a strange way. It should have been sorted just as the Account Group table.
Janusz will have a second look at the function gl_account_types_list.
/Joe
You could send me a backup (sql script) from your test client. You can use the email address on the 'Contact Us' page for sending attachments to us.
/Joe
There must be something wrong with your setup. It is sorted correctly in my environment.
Did you remember to download the latest /includes/ui/ui_lists.inc from the CVS unstable?
You can download it here:
This types_list has been updated.
/Joe
Hello, I think your list should be sorted just as you typed it (with None in front). All these types are belonging to the same class type, right?
The sort order is class type, type id.
I will have a look at it.
/Joe
No, it is not possible to modyfy a payment at present.
You will have to void the transaction (Setup - Void a transaction), and re-enter it again.
/Joe
Janusz has how fixed the combox group order. I have tested further on the subject and fixed a couple of other minor errors. Now the types is working as intended.
Please update your CVS unstable. The files affected are:
/includes/ui/ui_lists.inc
/gl/includes/db/gl_db_account_types.inc
/gl/manage/gl_account_types.php
/Joe
This was related to the following expressing in php:
if ("00" == "0")
This will return true in php. I have now used strcmp instead for comparing the strings in the file /gl/manage/gl_account_types.php, but there is still a problem when setting the correct type in the listbox (for parent). I will have to discuss this with Janusz.
In the meantime you can pick up the latest revision in the CVS unstable.
/Joe
It is the zeros that are causing the problems. You can either change your groups one by one by editing them and select None for parent and save again. Or you can use phpMyAdmin and change all the 0 in parents to an empty string.
Or you can use this SQL for fixing this.
UPDATE `0_chart_types` SET parent='' WHERE parent='0' OR parent='-1';
After that, you can again use 0 as a parent if there is such a group.
This SQL is going to be part of alter2.3.sql when upgrading in a while.
/Joe
Please look at the underlying delivery (dispatch) note. It is referenced as 'auto'.
Here you will see the inventory and COGS GL postings.
/Joe
CVS unstable (2.3 CVS) is updated. Affected files:
/gl/includes/db/gl_db_account_types.inc
/gl/manage/gl_account_classes.php
/gl/manage/gl_account_types.php
/includes/ui/ui_lists.inc
Thanks for reporting this.
/Joe
Yes, will be fixed asap.
/Joe
Ok, Fixed. CVS Main updated. Affected file /reporting/rep209.php
You can download it here:
/Joe
Yes good idea.
CVS Main trunk updated. Affected files: /reporting/rep105.php, /reporting/rep301.php, /reporting/rep302.php and /reporting/rep303.php.
/Joe
Hello AM,
If you have the global variable in config.php, $print_invoice_no, set to 0, FA will print the reference number on all documents instead of the internal numbers.
If possible, FA will increase the reference number by 1. F.i. A15 will increase to A16. So if you look at the number in forms setup after you have created the document, it has increased by one.
/Joe
If you mean the sales person listing, it has been implemented a long time.
/Joe
Yes, maybe we should put this information on the customer or the branch. We have doctext and doctext2 at present and they are chosen depending on the customers currency.
If we put this information from a combobox (with available doctext) documents then you can copy existing and name them doctext3 ...
This way you can have all the language you want. Default when creating a customer or branch could be existing method.
We retrieve the correct doctextX when printing the document. A candidate for 2.3.
/Joe
You can enter that information in the memo field on the document.
/Joe
What about using the reference number for that? This can be either numeric or alpha-numeric.
/Joe
Due to complications it is not possible to void a PO receival, but you can delete tehm in the Supplier Invoice form. You got a warning and you must be logged in as admin.
/Joe
Look under fawiki, https://frontaccounting.com/fawiki, on how to fix that. The topic is Exchange Rates in Banking and General Ledger, Working with FA.
/Joe
Posts found: 3,776 to 3,800 of 5,003