1

(11 replies, posted in Wish List)

Sorry, there was no quick entries for supplier invoices.

2

(11 replies, posted in Wish List)

What happened to this great feature? I don't see it in the demo any longer

3

(31 replies, posted in Wish List)

Thank you vipsoft smile

vipsoft wrote:

Another point is that regardless of the license (GPL vs AGPL), you should already be mindful of the software coupling between your proprietary code and any open source code that you use.  Done properly should warrant no concerns over your proprietary code becoming tainted by the GPL, and being forced to turn over your closed source.

See: http://library.findlaw.com/2004/May/11/133415.html for one lawyer's perspective on the IP risk.

FrontAccounting is somewhat modular... I suppose developpers of modules could still develop under different licenses as long as the core remains intact, just like in the case of GPL licensed client software? As I see it, this AGPL/GPL issue only involves the core developped by FrontAccounting. AGPL would still allow commercial developpers to contribute with modules, while the core would still be protected.

The question really boils down to wether we want an open source project or not? We will probably loose some contribitors that eventually could end up being big freeriders. However, in the long run, I think we will see the benefits of having an open source project.

4

(31 replies, posted in Wish List)

I do not agree.

A lot of new projects are turning towards AGPL, because there has been a lot of issues in web projects that was provided under the GPL license.

AGPL simply give the same rights to people that provide open source web applications, as GPL gives to providers of client based software. On the client side the GPL license has been very succesfull.

I am mostly concerned about the project itself. If we are going to base a business model on frontaccounting, we need to make sure that it will still be here in 10 years.

What you guys want is not an open source project. FrontAccounting is not an opensource project if it is released under GPL v3.

Read more at:
http://news.cnet.com/8301-13505_3-9917947-16.html
http://forums.alfresco.com/en/viewtopic.php?f=20&t=11539

5

(31 replies, posted in Wish List)

Hi mr. kiang,

I understand your concerns. However, we have to remember that the source code is already available for download at sourceforge.net. This implies that both those who uses the software and those who supply it can get access to the source code. So in this sence hackers, competitors and malicious people already have access to the core of the system. If we considered this a problem, we should completely close the sourcecode for anyone who isn't "trusted". Usually the fact that the source is available is used as an argument, to why the system should be more secure. It is possible for other people to provide bugfixes, enhanced features etc.

I agree that there are a lot of cons in providing open source software if you use a traditional proprietary business model. But the great part in supplying ERP software is that an open source business model often works a lot better than an proprietary model. Being an ERP-software provider should often be a biproduct of supplying a good understanding of business processes, rather than being the primary product itself.

As I see it, the GPL v3 license has nothing to do with open source when it is used in web based projects. It is only intended for client based software. And when it comes to client based software, the GPL v3 works pretty much the same way as AGPL v3 works in web based projects.

I don't see why we should have a license at all, when it doesn't provide any protection to FrontAccounting. They might as well let go of the code and close down the project. Any big provider could use the source and never have to give anything back. This to me sounds like it would kill any open source project.

Lets say Micro$oft came and took the code of FA 2.1 and decided to supply it as a part of there new clouding product line. They would spend billions in promoting the software and most likely they will have great success in doing so. They will very likely also provide a lot of extra nice features. However, they will never have to give anything back to the community.

6

(31 replies, posted in Wish List)

rasmus_kristensen wrote:

First, I do not see why giving the rights to ask source code for people other than customers is a good idea. Any modifications we make to any open source product, we will publish anyway.

Should have been

First, I do not see why giving the rights to ask source code for people other than customers is not a good idea. Any modifications we make to any open source product, we will publish anyway.

7

(31 replies, posted in Wish List)

First, I do not see why giving the rights to ask source code for people other than customers is a good idea. Any modifications we make to any open source product, we will publish anyway.

Second, to really benefit from open source, it is great to use work from other projects. A lot of other new projects are licensed under AGPL v3 today. Not being up2date on the license simply means, that the project in the long run will not be able to benefit from all of these great projects.

One example is a theme that we developed using styles and images from group-office http://www.group-office.com/. This theme is very nice. However, FrontAccounting wont be able to benefit from it, because their license is not gpl3 compatible.

8

(2 replies, posted in Wish List)

Great smile

9

(2 replies, posted in Wish List)

It would be nice, if it was possible to edit the description on sales order lines, when entering the sales order. Also in the direct delivery and direct invoicing sessions.

As it is now, this is only possible when doing a dispatch.

This feature would be good for two kind of users:
- those selling services. Often you need to let the customer know what you used the invoiced hours for, and you will often use the direct delivery feature for this.
- those who doesn't use advanced inventory features, and therefore treats inventory items as service items (a lot of small companies run their business like this). When they receive supplier invoice, they simply post them directly as COGS. Even though this isn't a very nice way of running your business, this is still how a lot of small companies does it.


Rasmus

10

(11 replies, posted in Wish List)

This feature will help us and hopefully a lot others a lot.

Thank you very much smile
Rasmus

11

(11 replies, posted in Wish List)

I don't see how the above is possible, since you can't use bank accounts in your gl entries.

However, I have new suggestion that probably would be a lot more simple to implement.

We should simply have the same quick entry feature when entering manual gl entries on a supplier invouce, as when you we bank payments.

The core problem is that there is no way to do cost entries, where payment is not on the same day as the cost if you also want to control outstanding balances with suppliers that doesn't supply to your stock. And as you mentioned, there are also no way of controlling allocations. But if we had quick entries on the supplier invoice, we could use this to control all costs.

12

(11 replies, posted in Wish List)

You are correct that there shouldn't be two different dates on the same GL entry. Therefore it should generate two smile

So that the first one credits the total amount on the accounts payable account and the second one does the payment transaction on the payment date. In this way you make sure that the costs are booked correctly for VAT reporting and at the same time you can still do the reconciliation with your bank account.

Example: Rent of stock.
Supplier: Stocks4Thugs
Date of invoice: 15/3
Date of payment: 15/4

Total amount: 2500
Amount: 2000
VAT: 500

When entering the above information and using the quick entry to get the correct VAT postings it should do two things.

- 1st:
Create GL entry for 15/3

Debit VAT account: 500
Debit account for stock rent: 2000
Credit Accounts payable: 2500

- 2nd:
Create GL entry for 15/4

Debit Accounts payable: 2500
Credit Bank Account: 2500



It should do both GL entries at once, just with different dates. It would be nice if it somehow could register the transactions on the supplier Stocks4thugs (should be optional). No allocations are really needed in this case as I see it (as you can adjust the payment date), though it would be nice to have a report that gave you list of all upcoming payments.

Very often this type of costs will be operational, wherefore you want to be able to enter them fast, since there is no need to control the flow as much as when you do purchases. From the bank account the money will often either be withdrawn automatically or you enter the payment imediately after receipt with a payment date out in the future.

Rasmus

13

(11 replies, posted in Wish List)

As it is now, it is very difficult to control payments from supplier invoices where the date of the payment is different from the date of the actual cost.

Here is our wishes:

- It should be possible to attach a supplier to a payment quick entry
- It should be possible to set a date of the cost.
- On basis of the two above, it should create two GL entries. The first one with the GL postings that involves the postings of the actual costs that are then counter posted on the accounts payable account. The second one should be the payment, that debits accounts payable and credit the bank account on the date of the payment.

There is no way of controlling this as it is now, unless you use the purchase order. But unless you create an actual purchase order of an item, there is no automatic calculation of VAT. The new quick entry feature is very very nice. However, it often isn't possible to use it, because of the above.

Regards
Rasmus

14

(31 replies, posted in Wish List)

Hi Dave,

I totally agree on the not implementing unnescessary features. However, the system is an ERP system, that also does accounting (doesn't matter)...

We are also providing software as a service to our clients. However, we are also doing development on the system and will be doing so a lot more in the future. What we are going to do is to give back whatever enhancements we make to FrontAccounting. For stupid little features that doesn't really make sense to anyone else, except a company with very specific requirements, we will upload the source to our own "forge". This will not be a place where we will accept any contributions. Those must still be handled by FrontAccounting (that by the way does an excellent job). It will only be to fullfill the license.

If companies are simply allowed to take the system, modify it and not give anything back, the business model of FrontAccounting as I see it, is very weak. You are either in or you are out. Otherwise you should use some kind of propritary license instead.

The new license will allow us to use work from a lot more different open source projects, which will be great for one of the most promising open source ERP projects.

Regards
Rasmus

15

(31 replies, posted in Wish List)

with our new theme. They look a lot a like smile So you can almost call it an application suite. Even more so when OpenID gets implemented in both applications...

16

(31 replies, posted in Wish List)

What do you mean by Group-Office module?

17

(31 replies, posted in Wish List)

Great smile

18

(1 replies, posted in Wish List)

OpenID support would be a very very nice feature that will allow easy implementation into single signon environments that are very much appreciated by our customers smile

19

(31 replies, posted in Wish List)

I would like you to consider the option of releasing FrontAccounting under the AGPL license instead of the GPL. This license is more minded at hosted applications.

http://www.fsf.org/licensing/licenses/agpl-3.0.html

http://glast.pi.infn.it/mech/Joomla/Componenti/civicrm/CRMDOC/AGPL%20vs.%20GPL.html

Currently I created a new very nice looking theme based on the theme of the new Group-Office which will make FrontAccounting very very good looking. However, it is not possible for me to release it, since FrontAccounting is not licensed under AGPL. AGPL is GPL compatible, but it doesn't work the other way around.

As I understand it, the AGPL requires you to make modifications available to others even though you only host the application for your customers. This is not explicitly required under the GPL license.

20

(1 replies, posted in Wish List)

For supplier invoices and your smart new quick entry payment feature, you will need counter post accounts in the tax types. This should control where the VAT should be "counter" posted, if you don't want it to be posted directly to Receivable or Payable Accounts. This feature is usefull for suppliers and customers that are outside the company's country, wherefore there should be no VAT on the invoices, but the company will still need to report a pseudo VAT to the authorities.

It would be very nice if it was possible to enter a negative amount on a sales order line for rebates.

The discount percentage is not enough for a lot of rebates.

Also, negative amounts on bank payments would be nice. It often happens that you need to do a bank payment where you need to do subtract something from the payment. Among others, this is the case when posting vat for foreign suppliers.

A danish company that buy something from a supplier outside denmark, will need to post 25 % in vat, nomatter if there is VAT on the invoice. Afterwards the company will have to do a counter post on another VAT account to equal the first one out.

This is defintly getting one step closer. However, I still think it should be possible to attach dimension values to the payment. Also the VAT function should work also for Supplier Invoices and bank payments that are made to suppliers or customers.

The template idea would be nice to implement also in the GL Journal Entry. Here it should simply list the accounts and then afterwards you should be able to update the values

Since you can already attach tax groups to GL accounts, it should also be possible to use this information when you do GL journal entries and bank payments.

It should then only be nescessary to enter an amount once, select two accounts and a vat group. This should be implemented in the excisiting GL jounal entry page. Two columns should be added. One with the counter entry account and one with the vat group.

On selecting the entry account, the vat group should automatically be selected.

If you leave the counter entry account field empty, the gl journal entry should work as it does now.

24

(1 replies, posted in FA Modifications)

I know that in DK government organizations will only accept electronic invoices. You can do this is in many ways. It is among other options a possibility to use an agent that will transform your paper invoices to electronic invoices.

However, nomatter what, you will need to be able to register an EAN number on a customer for this to work.

25

(2 replies, posted in Report Bugs here)

When  you select item by entering item code instead of using the list, it wont get the price of the item. Also, it doesnt look as if it registers the line when using enter in the item code. These two issues will especially be a problem when using barcode scanners.