1 Reply by softechmatrix

(43 replies, posted in Reporting)

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.

Go to forum: Reporting

2 Reply by softechmatrix

(43 replies, posted in Reporting)

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.

Go to forum: Reporting

3 Reply by softechmatrix

(43 replies, posted in Reporting)

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.

Go to forum: Reporting

4 Reply by softechmatrix

(43 replies, posted in Reporting)

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.

joe wrote:

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.

joe wrote:

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.

joe wrote:

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.

Go to forum: Reporting

5 Reply by softechmatrix

(43 replies, posted in Reporting)

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.

joe wrote:

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)

Go to forum: Reporting

6 Reply by softechmatrix

(4 replies, posted in Dimensions)

OK, some more info: I checked the ledger entries and it seems that the dimensions get recorded as they should. The problem seems to occur during reporting. When I don't filter the report then I get the correct information. But as soon as I set a dimension filter I get only the report header and the page is blank after that.

At least this means that all entries I make are recorded correctly smile

Go to forum: Dimensions

7 Reply by softechmatrix

(4 replies, posted in Dimensions)

Joe, thanks for your reply. I know that dimensions are very powerfull, that is why I want to use them. But the problem is that the behaviour that you describe is not happening here. I have the following scenario:

1. I have created a dimension list with product names
2. I have a ledger account for each product group
3. Products are linked to their specific ledger-account for the product group where we want to accumuate the ledger entries for that product
4. Each product is linked with it's product dimension
5. I invoice a product, this creates ledger entries for the correct product group account in the ledger
6. I asume, as you state above, that the dimension that is linked to the product is also generated into the ledger-entry
7. I should therefor see the dimension for the product reflected in the ledger entry but this is NOT the case

I want to filter my ledger entries (and other reports) by product dimension. I could for example create a profit & loss statement for one specific product this way but unfortunately this is not happening (for now)

Maybe you can give me some pointers as where to look to get this working. My assumption is that I can set a dimension on a product or service, invoice this product or service, have ledger entries generated with the correct dimension and then filter the ledger entries (for a specific report) for that dimension.

Where do I go wrong?

Go to forum: Dimensions

8 Topic by softechmatrix

(4 replies, posted in Dimensions)

This is a very big dissapointment; when I link dimensions to artikels, clients, etc. they are not used when frontaccounting generates ledger entries from an invoice (what I've seen so far) and probaly other transactions as well. This means I can not use dimension reporting on ledger reports to see what profit and/or loss is being generated by invoiced items or to see a annual cost report for any particular dimension.

Is this being worked on, can we do it ourselfs (maybe a pointer to where to begin) or is this not wanted or absent for some other reason.

Go to forum: Dimensions

9 Reply by softechmatrix

(3 replies, posted in Dimensions)

OK, thanks

Go to forum: Dimensions

10 Topic by softechmatrix

(3 replies, posted in Dimensions)

It is very clear to me that I can use dimensions as costcenters or other similar things. However, it is not clear what the two dates are used for. Can anyone clarify this part.

Go to forum: Dimensions

11 Reply by softechmatrix

(10 replies, posted in Reporting)

Thanks for the info. But still the fact remains that the class.pdf.inc references certain font definitions that are not available in the distribution. If you add a language definition with UTF-8 as locale this creates an error so this should be addressed one way or another:

- keep the current class.pdf.inc and include the fonts that are referenced there into the distribution... or

- don't distribute the font definitions and change class.pdf.inc so it uses the bundled helvetica in each setting

Both are easy to do tmo.

Go to forum: Reporting

12 Reply by softechmatrix

(10 replies, posted in Reporting)

Of course changing dejavu into helvetica in class.pdf.inc wil also make things work as the helvetica definition is available in the fontdir.

I still have to test with all reporting options to see if the dejavusans font is to my liking, otherwise I might switch it to helvetica or another one perhaps.

Go to forum: Reporting

13 Reply by softechmatrix

(10 replies, posted in Reporting)

The Frontaccounting distribution seems to be missing specific font definitions for TCPDF. In the class.pdp.inc file there are references for fonts dejavu and freesans but they are not included in the fontdir. I installed a language file with UTF-8 locale and this means that Frontaccounting wants to use the dejavu-font.

I donwloaded the TCPDF-distribution and installed the specific fonts from it into the fontdir under frontaccounting. NOTE: I have changed 'dejavu' into 'dejavusans' in class.pdf.inc to make it work as there is no dejavu font in the TCPDF-distribution, only dejavusans and some others.

Please consider correcting this for the current and/or next distribution.

Go to forum: Reporting

14 Reply by softechmatrix

(1 replies, posted in Items and Inventory)

We have found the problem: this happens when no base-pricelist has been set in the system settings.

Not sure if this is a bug or a feature though big_smile

Go to forum: Items and Inventory

15 Topic by softechmatrix

(10 replies, posted in Reporting)

After upgrade from 2.0.1 to 2.1.2 I get this error:

TCPDF error: Could not include font definition file: dejavu.php

I'm currently unable to print any report, every one gives this error.

Go to forum: Reporting

16 Reply by softechmatrix

(6 replies, posted in Banking and General Ledger)

Two things so far:

1. It seems that this is not what I hoped for, but that's ok. However, I did try to book a payment directly into the GL and split it into separate lines for tax and cost (no problem so far), but the tax-amount won't show up in the tax-report. So this negates the vallue of the tax-report for quick tax-reporting.

2. It still eludes me what the 'tax-type' is actually doing. Can someone give me an example of an entry that uses this and the results (and where I can fine/see the results).

tia.

Go to forum: Banking and General Ledger

17 Reply by softechmatrix

(6 replies, posted in Banking and General Ledger)

Thanks for your quick reply, but can you elaborate a little more on this:

What is calculated exactly and what is the result? I tried to find out what happens but nothing was showing. Will this create additional information/items that is visible in a tax-report? Because that is what I'm hoping for so I can book simple costs as a quick payment (without purchase-order and invoice) and have it's tax showing up in the tax-report.

So can you tell me, preferably step by step what workflow is used and what the results are.

Go to forum: Banking and General Ledger

18 Topic by softechmatrix

(6 replies, posted in Banking and General Ledger)

Simple question: when I define a GL-account, I can link a tax-type to the account. What is this actually doing, or where is it being used?

Go to forum: Banking and General Ledger

19 Topic by softechmatrix

(0 replies, posted in Wish List)

Just installed RC2 for testing. It's great to see 'direct invoice' and 'direct order' for sales, but it is needed for purchases as well. I'll explain (just in case this is not clear):

When I enter expenses there are two ways to go about it. I can enter it as a bank transaction and put the Tax as a separate line, but this way the taxes don't show up on the Tax-reports. The other way, and only way to have the tax show up on the report, is to enter the expenses as purchases, but then I need to make a purchase-order and a receive-order before I can enter the expense as an invoice.

One way or the other, this needs serious consideration. I need the expense taxes to show up on the tax-report.

Go to forum: Wish List

20 Topic by softechmatrix

(4 replies, posted in Report Bugs here)

FrontAccounting let me set the character for decimal separator and thousand separator. I have set those to a comma for decimal separator and a dot for thousand separator (European setting). Now all numbers are shown correctly but when I enter a decimal value like '123,45' I get an error. The current workaround for me is to enter decimals with a dot instead of a comma. After putting in numbers in this form they are shown correctly.

Hopefully this can be corrected in a future version :-)

Hans Peter.

Go to forum: Report Bugs here

21 Reply by softechmatrix

(13 replies, posted in Translations)

Jan wrote:

Hans Peter,

I am on 60%

Jan

Great, that's quite a bit more than I have right now. However, do you have any indication on when you will have it completed as I kinda need the translation within another month or so (as I'm switching my own company to FrontAccounting over the next months). If you can't have it finished in that timeframe then I might still do it myself.

Hans Peter.

Go to forum: Translations

22 Reply by softechmatrix

(13 replies, posted in Translations)

Hi Jan,

How far are you with the translation, as I'm also working on a Dutch translation.

Regards, Hans Peter.

Go to forum: Translations