(14 replies, posted in Report Bugs here)

apmuthu wrote: wrote:

You will of course need to be aware that database changes will possibly devolve in time for this branch though upgrade paths will exist for standard installs.

Call me an idiot (and you are probably right) but what does that mean when you say "database changes will possibly devolve." If I use this branch will I still be able to easily upgrade to the final...?


(5 replies, posted in Dimensions)

Without being able to set a dimension for supplier purchase orders, invoices, specific products etc it's basically useless for us (as we would use this for project and customer job tracking, including tracking products purchased for specific customers and jobs).

Quickbooks has a similar feature, where you can set up dimensions, but the difference is you can assign them to almost everything.

So this COULD be a pretty useful feature if its incorporated into future versions. The potential for it to be very powerful and flexible is definitely there, it just needs a bit of work.

Basically all you need is for it to clearly display what amount goes into the receiving account. If it shoes that then the rest IS intuitive.

The issue is if you enter in a "bank charge" you have NO IDEA where it gets that amount from. Is it A or B?

Amount transferred: 100
Bank charge: 20


Amount transferred: 100
Bank charge: 20


Basically there is no way to know the answer to question, unless you enter in a transaction, and then go back and check the GL. So, in this regard its very non-intuitive and makes for a lot of mistakes..


(10 replies, posted in Announcements)

Add in a few bit and pieces to clarify things as mentioned in this topic below and will downloading and testing right away. Wink wink - nudge nudge wink


I Love FrontAccounting compared to our previous software however one of my biggest complaints is I spent 1/2 my time voiding and re-entering transactions because its not clear what is being deducted from where.  And NON of this is programming related but rather simply user friendliness.  A lot of places where amounts are deducted from accounts, it's still horribly confusing as to what is the TOTAL amount and WHERE the amounts are being deducted from.

For example, if I do a bank transfer (in this case an ATM withdraw into a petty cash account), obviously there is a bank charge.  Following the fields on the bank transfer screen here is what I see/have entered:

From Account:    HSBC XXXXX
To Account: Petty Cash
Amount: 10,067.50
Bank Charge: 60.00

So logically, that would mean,

HSBC XXXX: deducts 1067.50
Petty cash receives: 10,007.50
Bank charges account receives: 60.00

This is also how my bank see's it from the bank statement. HOWEVER if I check the general ledger for this transaction I see it actually records the transaction as this:

HSBC XXXX: deducts 10127.50
Petty cash receives: 10,067.50
Bank charges account receives: 60.00

Add in a multi-currency transaction and its just hopeless... sad

I think the issue is LESS about WHERE it deducts (as maybe other banks use a different method) and MORE about it just being simply SEE CLEARLY WHAT it's deducting from WHERE with a TOTAL before you press "enter."

Easy fixes that make FrontAccounting a thousand times easier to use. For now I simply VOID, VOID, VOID... sad


(15 replies, posted in Wish List)

Rascal - Sorry for the slow reply. I have been using Front accounting for quite a while now and I almost forgot about how Phreebooks works.  But in general Front accounting seem a lot more robust yet still somewhat user friendly. I think it still has a ways to go for anyone who is working internationally and has varying currency needs but they do seem to be improving this (some of the issues here, I noticed got better in later releases).

Weberp is amazing but way to complex - Phreebooks has a nice interface but is way to simple and Front accounting seems to be the best balance of the two. Therefore we are sticking with Front Accounting.

I know the ERP exaustion feeling too. But unless your needs are super hardcore to the extend that you need weberp, then go with Front Accounting!


(15 replies, posted in Wish List)

Definitely looking forward to this in the next release.

Customer Payment Entry is another spot that could use a little love. There is a bank charge, but its not clear if:

A) this charge is deducted from the total remittance amount or
B) it is it added on top of the remittance amount...??

If it is deducted from the remittance amount then it would make more sense for it to be down below along with the discount, remittance amount etc.


(15 replies, posted in Wish List)

Right now, the way transactions are handled in various currencies is horribly confusing. One of the biggest aspects of this is you never really are clear what currency you are working in at any given time. As a result I spend a TON of time voiding transactions and then re-entering them.

For example in "Bank Account Payment Entry" you first choose the bank account that you are making the payment from. In this case, I am selecting a USD account. I enter the payment amount in USD and (it seems in this case) the payment is made correctly in USD. However, its NOT at all clear what currency you are making the payment in (since in some places it must be in the home currency, and in others its not..). It lists the exchange rate in this screen which is further confusing since it seems in this case that the payment being made is in the currency of the account you have selected. A quick fix here would probably just have the currency name of the account you selected display somewhere (maybe next to the amount) so that its clear what currency this transaction is occurring in. Along with the amount in the destination currency (display purposes only).

In SO MANY places this could be really really easily fixed in the short term by simply making it clear what currency you are working in on each of these different screens with with some sort of notice or display.

For now though I have gotten quite proficient in using the void feature.

Quite useful. Two questions:

a) Is there a way to have it display the line item descriptions? (right now each line shows the suppliers reference)
b) I could badly use a report that shows purchase orders (open or closed) as we regularly need to run PO reports of all PO's with suppliers (even ones not delivered yet). Is there a way to use to report and modify it to show PO's only instead of supplier invoices?


(15 replies, posted in Wish List)

I was just doing a search and it seems multicurrency is a concern for quite a few others:



(15 replies, posted in Wish List)

Sorry Joe, I was just referring to Chris's comment: "Also, FA currently does not easily convert a "Sales Quotation" into a "Sales Order" although you can use cut-and-paste if you have installed the textcart extension."

But for me, it seems to work fine..


(15 replies, posted in Wish List)

On a side note, I should mention one reason we specifically DID NOT go with weberp (which is also pretty impressive) is the inability to enter a back dated transaction. So I am VERY glad front accounting has this feature.


(15 replies, posted in Wish List)

Essentially an RFQ (request for quote) works in much the same way as SALES QUOTES work. The main difference between the two is that RFQ's are intended for the supplier/vendor sides where are SALES QUOTES are intended for the customer side. Another way of saying this is FRQ's are used in purchasing, SALES QUOTES are used in selling.

With customers, you provide an initial SALES QUOTE. When the customer then receives and confirms this quote, the sales quote converts into a "SALES ORDER" and then finally into a SUPPLIER INVOICE.

The process is the same with an RFQ. With suppliers you provide a RFQ. The supplier comes back with the details such as specs ordering terms etc and if you confirm it, the RFQ is converted to a PURCHASE ORDER and then finally into a SUPPLIER INVOICE.

The advantage to having RFQ's is you can a) see what items you have out there soliciting quotes for and b) you have a place to record what suppliers quoted for each item (we usually fill in the details they came back with into the RFQ).

I am surprised that "Sales Quotation" don't easily convert into "Sales Orders" easily. My understanding of the proper work flow for this would be that they SHOULD easily convert, with the ability to make changes on the final sales order if necessary.

I recently switched over from Phreebooks to Front accounting which is years ahead. Definitely happy to have made the switch. However I am really missing one feature that Phreebooks had which is true multi-currency support.

I often have customers that sometimes send us payment in an other currency other then their home currency.  And the same with suppliers. We may be billed in one currency (for example Chinese RMB) and make payment locally in that currency, but on other occasions we may wire transfer the payment in another currency (US Dollars). We also sometimes sell in different currencies to one customer. One order might be quoted in USD. Another might be quoted in Chinese RMB...

For now, the work around is I have set up "dummy accounts" in other currencies and have to do lots of manual conversions. For lots of transactions though it really ads up to a lot of extra time. The limitations on multi-currency in front accounting is a huge downside for me and I am guessing for any semi-international business this is a problem. I have seen some other posts here so seems others have this need as well.

The other feature that I surprised is missing (which Phreebooks also has) is RFQ (request for quote). Its basically a PO as far as the structure. Workflow is a) RFQ which then is converted to PO if confirmed. I would imagine adding RFQ should be pretty basic.

Anyways, beyond that pretty happy with Front accounting and overall very impressed!