I found this thread from 2014 but didn't have permission to reply:

https://frontaccounting.com/punbb/viewtopic.php?id=5254

The issue they bring up is that reports emailed from FA start with "Dear" and then the person's last name, with no title or first name.

I just wanted to say that I agree with the OP in the thread that "Dear First Last" is much better than simply "Dear Last". In the UK the current arrangement would be a very strange way to start an email or letter. I also agree that "Dear Title Last" is even better in a formal setting.

I have modified my own installation but wondered if it's worth making it default that way.

Is it usual in other parts of the world to start a letter "Dear Last"?

Thanks for your reply,

I'm afraid after deleting the message and moving it back to the inbox the problem remains, message is the same.

Even if the work-around did work, it's not ideal. No other emails I've received on my iPhone exhibit this behaviour.

Let me know if there is anything I can do to help diagnose.

All the best,

Dx

Hi there,

When sending statements from FA, people on iPhones/iPads cannot read the emails.

They get a message in their mail app that says:

This message cannot be displayed because of the way it is formatted. Ask the sender to send it again using a different format or email program.

multipart/mixed

I can attach a screenshot if required but the device gives no further info.

Let me know if I can help further!

All the best,

Dx

4

(20 replies, posted in Report Bugs here)

Sorry! False alarm. Should check things myself.

Still getting the same error with 2.4.14 from source forge.

Let me know if I can help narrow it down.

Dx

5

(20 replies, posted in Report Bugs here)

Thanks Everyone, works as expected!

Dx

6

(20 replies, posted in Report Bugs here)

I replaced my admin/db/voiding_db.inc with the file linked above however the files were the exact same size and the problem remains.

Doing a diff on the two files shows they are the same.

Happy to cary out any experiments that might be useful!

Dx


This invoice cannot be voided because it was already credited.
/PATH/frontaccounting/includes/ui/ui_msgs.inc:14:    trigger_error('This invoice cannot be voided because it was already credited.','256')
/PATH/frontaccounting/admin/void_transaction.php:320:    display_error('This invoice cannot be voided because it was already credited.')
/PATH/frontaccounting/admin/void_transaction.php:345:    handle_void_transaction()

7

(20 replies, posted in Report Bugs here)

Thanks so far! kvvaradha, did you find an issue or Should I just replace my /admin/db/voiding_db.inc with the one linked above?

Thanks!

Doug x

8

(20 replies, posted in Report Bugs here)

With go_debug set to 2 I get the following extra info:

/PATH/frontaccounting/includes/ui/ui_msgs.inc:14:    trigger_error('This invoice cannot be voided because it was already credited.','256')
/PATH/frontaccounting/admin/void_transaction.php:320:    display_error('This invoice cannot be voided because it was already credited.')
/PATH/frontaccounting/admin/void_transaction.php:345:    handle_void_transaction()

9

(27 replies, posted in Setup)

Just thought this was worth a little bump. Has anyone made any progress/has a better workaround than the copy-paste vibe we're currently doing?

Hi All,

I'm running 2.4.13 although the payments in question may have been entered under 2.4.9

I have a customer payment which isn't allocated to anything (in fact I have two).

If I try to void the transaction I get the error "This invoice cannot be voided because it was already credited."

Again, I'm trying to void a customer payment, not an invoice.

The bank account has (and did have) enough in it to avoid going negative.

Any help appretiated.

Hi Tom,

That sounds great, thanks for looking into it. Let me know what you discover!

D

12

(27 replies, posted in Setup)

I've created a post in the jobs offers board to see if we can find an interested developer.

If you would like this functionality to be developed, and are willing to contribute to the project (even if in a very small way) please respond here so I can gauge interest!

Dx

In the UK, HMRC are making it mandatory for all VAT returns to be made digitally from the 1st of April 2019.

This VAT just a first step to eventually include all tax returns.

Here is the government's overview of the change:

https://www.gov.uk/government/publications/making-tax-digital/overview-of-making-tax-digital

And here is a link to the API specifications:

https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/vat-api/

Forum user Vernonr had a look and made the following assessment:

"The API is fairly simple. There would appear to be 2 issues. One that front accounting needs to have OAuth2 embedded in order to authenticate the HMRC - and the chart of accounts will need to specifically identify those transactions and VAT that relate to other EU countries. So the current Tax Report isn't quite comprehensive enough."

As ALL UK VAT registered companies will need this functionality very soon I suggest we crowd-fund the development.

If a suitably skilled developer wishes to take on the task, please let us know your fee and I'll set up a crowd-funding site to raise the cash.

Anyone fancy the challenge?

14

(27 replies, posted in Setup)

If anyone reading this has the knowledge to implement this functionality, please let us know what you would want for your work and perhaps we can set up a crowdfunding thing?

15

(27 replies, posted in Setup)

Hi Everyone,

I'm happily using front accounting in the UK for 4 small companies. I'd love to stick with it if possible.

Is anyone actively developing an extension to give us the functionality required by HMRC after April? If not, is there a plan to support it in the future?

If nobody has the time to develop it, perhaps we can crowd-fund the development? I for one would be up for contributing financially to such an effort.