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 175 of 200)
Topics by joe User defined search
Posts found: 4,351 to 4,375 of 4,985
Well, frankly speaking, I don't know. Maybe the Check Print Utility could be extended to do this. Unfortunately I am extremely busy at present with the 2.1.3 release.
/Joe
BTW. Thanks for the tip about using the supplier for sales rep's and salaries to employees.
Hello,
When releasing a work order (advanced manufacture) the wo requirements from BOM is automatically created. When you are issuing, you are issuing extra items to the workorder. This might have caused the out of stock message.
/Joe
I asked you a while ago to change the two accounts (from an earlier COA) to 11000 and 10200. You can either change it with phpMyAdmin or with a text-editor directly in the sql script. Then everything is ok. I have changed it here, so we avoid these problems when destributing the 2.1.3.
/Joe
This database error was arising because when deleting the DEF location the deleting routine inside locations.php didn't check for BOM values and some other relating records in other tables. This has now been fixed and will be uploade to CVS Main trunk. Which, of course, will be included in 2.1.3.
Please, infotechaccountant, be good to us. Under no circumstances will we be developing in a bad practice. Both the main developers have over 30 years of serious developing experience. But, unfortunately, bugs comes and goes. And as said we try to fix them ASAP. I am just waiting for another bugfix before committing to CVS Main trunk.
/Joe
Ah, we overlapped our answers, vishow. I guess you saw my last extension.
/Joe
There is a global variable in config.php, $print_invoice_no, that is set as default 0. If this is set to 1, the internal invoice numbers are printed on the invoices. Therefore if the value is 0, the references are printed on invoices. And I agree with vishow, that we should change the selector in print out invoiced to reference number when the value for $print_invoice_no is set to 0. Will be fixed.
BTW the list will still be sorted by invoice_no descending, due to bad formatting elsewhere in reference. This way we make sure the sequence is right.
/Joe
Currently, when deleting locations, we check for locations in:
table stock_moves
table work_orders
table cust_branches
It seems that we have to extend the check.
You can insert the location DEF again, and then the report will work ok.
/Joe
I guess we will have to wait for t2webby's comments on this. He wrote the Check Printing module. If you have his email adress inside the readme.txt file in the check_print folder, you can ask him directly.
/Joe
The dimension on the customer follows all the item lines. But you could also set a dimension on the items itself (in the items form), should you prefer.
When the delivery has taken place it uses the same dimension as set on the customer. Here you can see that the purchase is also taken care of.
Please look at the delivery note in Customer Transactions. Press the GL icon and you will see that the dimension is set on the line too.
/Joe
Hi Spott. Good idea to translate FA into Estonian. I have just looked into your link to Launchpad. Seems to be an alternative to poEdit. Please continue and report back occasionally.
Well of course you will need xgettext or poEdit to compile the .po file into a .mo file, right?
/Joe
We have a lot of technical issues implemented in 2.2 already, but still there are a great deal to do. You can follow the changes already done in the CVS CHANGELOG.txt for unstable. So we can not just stop the 2.2 in the middle of the cycle. This doesn't make sense in a development matter.
You have to rely on us, that we are doing the development in a safe way and with as less fuss as possible for our users.
If you mean, that you can contribute with improved demo COA in a week, it is ok for us to delay the 2.1.3 a week.
Regarding the demo site, we have decided a long time ago to let the demouser be an accountant, to easily see most of the features in the program.
But we could create another user to be of level Inquiries and explain on the Website which one he/she should use. I don't know what is best here.
/Joe
I am not sure if you understood me right. The changes we have made to 2.1.2 in the last CVS in of course included in 2.1.3. But the change of class type will implement a minor correction of the class table structure and therefore has to be made in 2.2. So we will have to wait with this implementation. But the 2.1.3 will work with the new sublevel change.
If you want the new COA to be included in 2.1.3, I will have to get the one with demo data tomorrow, because this is the planning date for shipping of 2.1.3. It will take me some hours to make them ready for including, but it could be donw. I was planning to wait to 2.2 with this includes, but nevertheless we can do it in 2.1.3.
/Joe
Yes, you can use dimensions on both sales sales and purchase lines. You can decide when invoicing how to use either default dimension on customer or select another one.
You can experiment with the Training Co. on the various options.
/Joe
I am not at all expert in Chinese, but did you set the MySql to use utf-8?
/Joe
Hello,
Are you sure you need to run this as UTF-8? The footprints are quite large for PDF files when using UTF-8.
On our linux demo server, , we changed the encoding in Setup tab, Install/Update Languages., from UTF-8 to iso-8859-1, and everything went fine using this encoding. Also this is recommended. Try for yourself on the demo server. Use 'Preferences' to shift to es_AR language. Remember to set it back again. I am not sure if all understand Spanish . Of course they should.
/Joe
No, the new class type will not be in 2.1.3. It will be too much fuss inside a minor release. The merge will take all the fixed bugs and the new sublevel features into 2.2, so the class type and the sign converting can be continued in 2.2.
During developing of new minor/major release all the bugfixes etc. from the existing release will only be merged into the new minor/major release when shipping new subreleases, such as 2.1.2, 2.1.3 etc.
We expect the 2.2 RC to be released in a month or two. And it is followed by one or two RC or betas depending of bug testing.
/Joe
Ah, just a minor correction to the suggested fixed class types in 2.2. It should probably be:
1. Assets
2. Liabilities
3. Equities
4. Income
5. Cost of goods sold
6. Expenses
It is extended with Cost of goods sold. It will help analysing tools or own routines to extend the reporting. Ok?
It will be a minor manuel correction when updating existing companies, but this is a small price to pay for this new feature, right?
When we have released the next minor 2.1.3 in a couple of days, we will merge the changes in 2.1 into 2.2. Then we can continue with this work here.
/Joe
One way of doing this is to use the Customer Payment in Sales tab. Use the discount field for this $2,36 and the amount field for rest ($68,5-$2.36),
Ok it will use the Discount Taken account (which is an expense account), and the bank account is reduced by this discount amount and you have all 68,50 for allocation. Maybe this is a solution?
/Joe
I guess we could replace the class field, balance_sheet to include a Class Type instead. It could then be:
1. Assets
2. Liabilities
3. Owners Equities
4. Income
5. Expense (or costs)
Then we can discuss which class types should be presented converted. And take away the sign converter in the class form.
I will change this in 2.2. We know, of course, that 1,2 or 3 belongs to a balance-sheet.
Thanks for your nice words.
/Joe
No, it won't work by Bank Payment either. I think you mean that we should include an editable field between the Total Allocated and Left to Allocate, right? I will ask Janusz, if he could include this in release 2.2.
/Joe
Hello again. Yes it is easy to fix, but it is implemented in 2.2 unstable. On the classes you can set a sign convert in 2.2. And it should be converted in liabilities and income classes (to only have 'positive' values).
In f.i. the Scandinavian countries most people are satisfied with the presentation as it is now. The reason for not implementing it in 2.1 is that an extra field in the chart_class is needed. And we cannot change the database structure inside a minor release.
The problem is to find a way around this in current release. I don't know if a class is belonging to liability or income in the classes. I only know if it belongs to a balance_sheet.
There can be different setups.
/Joe
Why not create a Quick Entry for this? To use in the GL part.
/Joe
Hi Tom,
Have you tried to do the payment in GL, Bank Payment. Here you can have an extra entry line with bank charges. Right? The same way with Bank Deposits.
/Joe
Try this . On the demo you will not be able to do admin stuff. This is for safety reasons. To dive closer you should install a copy at your own server/station.
You can also look att the next unstable release 2.2 at .
And you can read news at sourceforge.net and on the website.
/Joe
The CVS Main repository has now been updated with new files. It should no show correct sublevels in the various reports. If there are no transactions in L3 types, it will not show up in BS and PL. Just ot save space.
/Joe
Posts found: 4,351 to 4,375 of 4,985