It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Reporting → Balance sheet not formated according to IFRS and IAS
I agree with pete. Although hameed means well. Many of his suggestions will cause more problems than they solve.
If you ever have a question about how something should be calculated or how a report should be formatted, then I suggest you just do it the same way as quickbooks.
Every accountant is familiar with quickbooks and you will be best to pattern after them when it comes to standardized accounting principles and reports.
Pete, don't worry. The changes are optional. You can continue working as you use to do. But infotechaccountants have helped a lot during the test of manufacturing and reporting. Infotechaccountants have really lifted the process quite a bit.
And as I said, This is only implemented with a backward compatibility. This is a major requirement for me.
/Joe
Joe,
also we can not use frontaccounting anymore from version 2.1.3 for the same reason pete and bruzergear already announced.
your last reply states that is optional, what do you mean?
is there an option to "turn it of" or revert back to the 2.1.2 setting?
Jack
Joe,
I took a look in the database, to check what happens behind the screen.
Here i saw that the database really has changed.
in version 2.1.2 we had a 0 or a 1 for chart class --> balance_sheet
in version 2.1.4 this has become a 1 to 6.
I have done an update from version 2.1.2 to 2.1.4 and now in frontaccounting itself, I see that the accounts which where previous a 1 are now assets (still 1 in the database). And the accounts which where previous a 0 are now empty in FA (still 0 in the database).
How can these account types be empty!
This is a real showstopper, the software is now completely unusable for our clients and our own company.
Hello Guys, you don't have to set these values to 1 - 6. If you don't touch them the reports will run in the old fashioned way.
If you have changed the values to the new 1-6 values, and you still want the reports to be like the old ones, you can set the variable
$use_oldstyle_convert = 0;
in config.php, line 78 to 1:
Then the reports are run as before!!
The new values 1-6 was changed because we now have better possibilities to make special reports with key values and analytics in the future.
And it is easy to determine if the created class belongs to a balance sheet.
If the built-in value is of type 'Assets', 'Liabilities' or 'Equities' this is of type balance sheet (right?)
All other values belongs to a PL sheet.
So please don't be freightened. Everything still works correctly.
/Joe
Joe,
this is not backwards compatible.
Backwards compatible means that the user, can use his old data in the new structure.
I did an update from 2.1.2 to 2.1.4 and i can't find the Balance yes or no.
Well you deduce it from the current class type but that's not an option.
I have placed the old style back to 1 but still I see class type instead of balance sheet.
The problem here is that 1 person claims that this should be done, and 2 persons already pointed you out that it is NOT an option.
Still everything is changed to "the new style" and it is NOT functional for us.
As I already said this is a real showstopper.
The biggest point of all is, that previously with the balance sheet, you could fill in anything you want, and specify it to your personal / country needs.
That way you could also set it up to work following IFRS or IAS standards!!!
Now you took it all one level back, and made this IFRS / IAS the standard, without the option to set your own!
We really went one big step back, from totally user configurable to preset settings.
Please change it back, this way we can't use it anymore.
If the built-in value is of type 'Assets', 'Liabilities' or 'Equities' this is of type balance sheet (right?)
/Joe
Here the major part of Europe use only Balance and Profit and loss as a classification, we do NOT use Assets Liabilities or Equities.
The current implementation of classes is unusable in our part of the world.
Hello again,
I am sorry that you dislike the new approach.
I must tell you, that I have been involved in Accounting Software Development during at least 25 years in Europe and around the world. Every Accountant knows that Assets, Liabilities and Equities belongs to a balance sheet. This is a one time setup, so why so much fuss for so little?
Believe me, the new class types is an improment for future development, as told before.
/Joe
Hi Joe,
I'm sorry to say but you make a very bad decision here: not to listen to several members of your community and to change something based on ONE member's interpretation of the software. This is heading straight to alienating a large part of your current community.
So here is where we (SOFTECHMATRIX) stand on the issue:
We have made big investments into FrontAccounting. We have developed a professional full-color brochure for FA that we give to our support-partners, being companies in the Netherlands that support FA for their clients with our knowledge and expertise. We have commisioned a professional translation into Dutch wich has cost several thousand Euros and we have a current project underway (also commercially commisioned) to develop modules for interoperability with Dutch IRS and Dutch banking. All these developments will be given to the community over time. Among our partners are accountants so we do have the information as how the software should work here.
As you may have noticed we are very actively testing and debugging FA and hope to support the development that way. This is also an investment for us as the person who does the testing (Jack, also here on the forum) is employed by our company so we are paying him to do this.
Bottomline is that this new implementation makes FA unusable in the Netherlands and at least Belgium as well. In the previous version this was not the case and the proposed system with 'assets, liabilities, etc.' was already in place as a configuration. If something in that 'configuration' was missing then why not add options to configure it instead of removing functionality from the software.
As it stands now all out investment in FA goes down the drain if you keep it the way it is now. In this implementation FA will NOT work for our region. Don't tell me that I'm wrong here, I have very extensive bookkeeping knowledge of my own but I'm also backed by the accounting firms that are partners with us. So you better believe me if I say FA won't work this way here in the Netherlands.
If this is not changed we can not work with FA as it is so we will have to decide what direction we will take. At the moment I see almost no other option then to fork FA and maintain our own distribution. This will obviously also mean, in that case, that we will end our active participation here as we will need our resources for maintaining out fork.
This will all be too bad as we also have financial backing for your project in the pipeline. Again, that will have to go to our own version if we need to do a fork.
The changes are optional. You can continue working as you use to do.
The problem comes down to you not making good on this promise. This change is not optional because I can not switch it off and work the way I used to. Also, your backwards compatibility is moot because it only handles the current state of the system but not allows to maintain it in the same way as before. It does honor current settings on an account but I can not add an account that still works in the same way.
Please get back to me on this because we need to figure this out. I'm willing to discuss this in detail with you (by any means) to get to a better solution.
Hans Peter (Owner and Main Director SOFTECHMATRIX)
Well, still, I can not understand all this objection. The only difference from before is:
The checkbox 'Balance Sheet' with an internal value of 0 and 1 was here before to mark if this account class was of type 'Balance Sheet'.
This checkbox has now been replaced by a built-in selector of 'Assets', 'Liabilities', 'Equities', 'Income', 'COGS' and 'Expense'.
If you want this class to be of 'Balance Sheet' you set the selector to either 'Assets', 'Liabilities' or 'Equity'.
By this new built-in selector we have the ability to make better analysis reports in the future. Remember that we don't know in the earlier 'Balance Sheet' checkbox if it is of type 'Assets', 'Liabilities' or 'Equity'. 'Equity' is by the way optional. You can make splendid reports without this. And you can put the equity as an account type inside the 'Liability' class. Look at the demo site: .
We are not changing this back, and believe me, this has nothing to do with a single member of the community. Some Audit companies from European countries have adviced us to go towards this direction.
So having enlightened the difference and you still feel that this doesn't fit into your organisation, well then feel free to fork FA into your own way. Just remember the license type, GPLv3, and let it be open to the public.
/Joe
Joe,
You still don't get the real gravity of this decision. You turned a software package that could be used wordlwide into something that only works in those parts of the world that use the Assets-Liabilities-Equity model.
Even though I understand that this might open up possibilities to handle THAT model better than before, it is still A STEP BACK IN FUNCIONALITY. And it is, therefore, a bad design decision.
So let's make this clear: I don't object the reason for doing this, I object to the implementation of it. You realy should hold 'backward compatibility' closer to your heart. Like now, you are actualy destroying a large financial investment that we made into this project and force us to go into a direction we don't want to go in the first place. We rather collaborate with you to make a stronger product together.
Well, still, I can not understand all this objection. The only difference from before is:
The checkbox 'Balance Sheet' with an internal value of 0 and 1 was here before to mark if this account class was of type 'Balance Sheet'.
This checkbox has now been replaced by a built-in selector of 'Assets', 'Liabilities', 'Equities', 'Income', 'COGS' and 'Expense'.
If you want this class to be of 'Balance Sheet' you set the selector to either 'Assets', 'Liabilities' or 'Equity'.
By this new built-in selector we have the ability to make better analysis reports in the future. Remember that we don't know in the earlier 'Balance Sheet' checkbox if it is of type 'Assets', 'Liabilities' or 'Equity'. 'Equity' is by the way optional. You can make splendid reports without this. And you can put the equity as an account type inside the 'Liability' class. Look at the demo site: .
It seems that you don't WANT to understand our (and others) objections. This implementation forces an accounting model that we can't use. And as you say here this will allow you to make better analysis reports, again forgetting that those analysis are based on this forced accounting model that, again, we can not use.
Also, you still forget that in our current setup (for example) there are accounts that have a value '0' for their type, while this value can no longer be set for newly added accounts. The result is that two different accounting models are going to be mixed by your so called 'backward compatibility'. I'm afraid to think about the implications of this when your 'upcoming' reporting additions are being added to FA.
We are not changing this back, and believe me, this has nothing to do with a single member of the community. Some Audit companies from European countries have adviced us to go towards this direction.
Changing back is one thing, building GOOD backward compatibility is another. And not one audit company from around here would advice that model (assets, equity and what not) because accounting simply doesn't work that way here in the Netherlands.
So having enlightened the difference and you still feel that this doesn't fit into your organisation, well then feel free to fork FA into your own way. Just remember the license type, GPLv3, and let it be open to the public.
I was realy hoping that we could work together to solve this problem. Maybe by collaborating on developing backward-compatible functionality. The best (and tmo only correct) option would be if both systems are supported within FA. I have a fairly simple coding solution to have both options available so if you like I'll be happy to discuss this with you (for your information, I'm a professionally trained software engineer with close to 30 years of experience).
And if we need to fork that obviously it will be Open Source as we are an Open Source support company. However, I am one of those who think forking is bad for Open Source because it dilutes developer resources for any one project. FrontAccounting is still a fairly small project with a small amount of active community members. I think you would agree if, say half of those members would go away and join the fork this would be not so good for FA.
So my invitation still stands: let's tackle this backward compatibility to get the best of both worlds.
Hans Peter.
In addition to my previous post:
I did some quick research for you and found that the IFRS-model is used in the European Union but only for PUBLICLY TRADED COMPANIES that operate internationaly. ALL other companies use national accounting rules which differ per country. And in all fairness, I don't see any publicly traded, internationally operating company adopting FA for it's accounting.
Also, it seems that adoption of the IFRS-model is still very controversial and subject to international debate. It is still FAR from being a real international standard.
So you might have to rethink the value of the advice that brought you to this decision as it is not based on common accepted knowledge.
I will try to explain the difference once again.
In the new class type system you can select 'Assets', 'Liabilities', 'Equities', 'Income', 'COGS', 'Expense'. But you dont have to use all of them.
If you want to use it as before, you can for instance only use 'Assets', 'Liabilities','Income' and 'Expense' as is presented on the demo site.
Instead of marking the class with 'Balance Sheet' as before, you now select either 'Assets' or 'Liabilities'. It should be fairly easy to figure out which. And instead of unmarking the 'Balance Sheet' you select either 'Income' or 'Expense'. Again it should be fairly easy to set.
That's all there is to it.
By setting up the Account Types (Groups) you tell FA in which order inside a class you want to present the reports. This is similar as before.
This new implementation has nothing to do with any standards.
You can retrieve the same reports as before. If not, tell me which reports are not able to retrieve as before. And I will try to show you how.
/Joe
Joe,
You still don't understand the real problem here and I'll try to explain it to you:
We deliver support to companies that, in turn, deliver support to end-users for FA (among other software). So to have an end-user to adopt FA as their package of choice we have to make clear that it adheres to Dutch accounting rules. If we have to explain that the software uses some other model (it doesn't matter how or how deep this goes) but you just have to use this 'work-around thinking' to have your system working the way it should for Dutch accounting rules, then the end-user will NOT go to use FA.
Also, our current users will scream hellfire because of the fact that the software suddenly starts working in another way and, more importantly, needs another way of thinking about it.
For most companies bookkeeping is complex enough allready. If they need to start thinking in another way to be able to use the software, it is going to fail.
However, what puzzles me most at this point is your reluctance to discuss other options here. There ARE possibilities to have it both ways so why not look that way.
Normally I am not reluctant. It is only because there really are no severe differences to how it worked before.
So what you suggest is:
If a variable is set (in config.php) then the old checkbox with balance sheet is re-established. And if this variable is set FA runs as it did before, right?
Would you also want the old sign convertion (in the PL sheet, the income and expense was converted. We better do so to get it really backwards compatible)?
/Joe
Hans,
We are always open for discussion about future directions of FA development. We always want to find solutions satisfactory for most FA users, and we are open for real arguments. Sorry, but the argument that the old way of classification of GL accounts is better than the new one because it comply with way of thinking of most accountants in your country is NO argument. We do not introduce the new classification to satisfy some guy from yet another country, but just because the new classification is more fine grained than the old one giving us more flexibility in the future.
I can agree that the moment of introducing the changes was not the best one. The bugfix releases should not demand manual changes in GL setup after the source upgrade, but the changes would appear in 2.2 release anyway. Rest of your arguments are very alike the ones infotechaccountants has used opting for IAS compatibility.
Anyway we really appreciate your declaration of development support to find the best solution satisfactory for all. You are welcome to present your ideas how to achieve this goal.
Janusz
By changing a few lines in /gl/manage/gl_account_classes.php and by setting the variable $use_oldstyle_convert in config.php, line 78 to 1, everything now run in fully backward compabitility mode. You will only see the 'Balance Sheet' checkbox if you run in this mode.
The CVS Main trunk is now updated. If you download this file manuelly, please also download a few other files, according to ChANGELOG.txt, to get fully updated with a couple of bugfixes.
This correction will also work in the upcoming release 2.2.
And remember to set this variable, $use_oldstyle_convert to 1 in config.php, in upcoming releases.
/Joe
Hey Joe and Janusz,
Thanks for this great move to implement full backward compatibility. We will document the differences between de old and new system for our support-partners. With this option in place we can simply suggest both options and see what the end-users want to use. Any results from this will be posted back to you to give a valid basis for future development.
Just to give you the current status of the IFRS-model adoption here in the Netherlands: as I mentioned before there is a European requirement for publicly traded companies to implement their bookkeeping according to IFRS-model. However, the accounting branche here in the Netherlands is VERY conservative, and the Dutch IRS is following in their standpoints. Because of this it is also very hard to bring new accounting software (like FA) into this market. FA is very special in this way that it is one of the very few Open Source accounting packages that is capable of setting up bookkeeping according to Dutch national rules. This backward compatibility keeps FA into our accounting market. Great move guys.
Because of the conservatism and resulting mismatch between Dutch and European accounting rules there has been made an addition to financial laws in the netherlands, stating that a company IS ALLOWED to use the IFRS-model for their books but the Dutch IRS is not endorsing it in any way as far as we know.
So there is a possibility that in the future Dutch accounting eventually will switch to the IFRS-model. I will do some research into this possible adoption and keep you posted on this.
Again, kudos where they are due.
OK here's my 2 bob's worth on the issue
1) The class changes made by the guys make good accounting sense. The vast majority of countries use the categories defined. This change has NOTHING to do with IFRS or IAS - it's just ordinary double entry accounting to have accounts classifed as Assets = OE + Liab etc. and has been around for 600 years.
2) Where national rules are different, Joe and itronics tried again and again to explain how to manage this situation. It would require you to edit you (and your clients) chart of accounts, but the system could still work fine. I realise this could be disruptive, but it hardly spells the end of the software.
3) I agree with most people here: IFRS/IAS provide NO basis for making a changes to FA. I hope the guys don't get asked to do anything with that justification.
4) (Personal note): I find 'we are planning to send you money' (but of course, haven't actually done it yet) threats to the developers impolite. An apology would be nice.
FrontAccounting forum → Reporting → Balance sheet not formated according to IFRS and IAS
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.