Share
ReportHi Dynamics Community
I am working on a project for my organisation to implement registered invoices. I have researched all the options extensively so please accept as given that the registered invoice and invoice approval process is a good fit for the requirements.
However there appears to be one significant issue that I am hoping that someone can suggest an workable solution to? The issue is being able to easily identify via reports and inquires whether a registered invoice has been or not yet been approved in an invoice approval journal. This is important because if the registered invoice is not approved and just an accrual then we will need to be able to report separately or sometimes exclude from reports. For any one not familiar the accounting entries are as follows:
Registered invoice (VINR)
|
Account |
Debit |
Credit |
|
Unapproved expense (P&L) |
100 |
|
|
Accrued expense (BS) |
|
100 |
Approve registered invoice (VINAP)
|
Account |
Debit |
Credit |
|
Unapproved expense (P&L) |
|
100 |
|
Approved expense (P&L) |
100 |
|
|
Accrued expense (BS) |
100 |
|
|
AP Trade (BS) |
|
100 |
So for example if I am running a vendor ageing report and I want to reconcile this to the AP trade account I need to exclude unapproved registered invoices.
In my test set-up I have used two journal names VINR and VINAP (see screen shots of journal name set-up).
They both have voucher sequence numbers prefixed by the journal name. However, when the VINR is selected into the approval journal the sequence number used is VINR the same as the original invoice. So if you look at a vendor invoice inquiry screen (see screen shot)
VINR-00000004, 5 & 6 have been approved and 3 has been selected into a vendor invoice approval journal but not yet posted. But without looking at the voucher details you cannot tell. Which means I cannot create a view over this screen to filter by approved or unapproved. It would be nice if the VINAP voucher sequence number was used for the approved invoices. I fear the way this works is by design and is unfortunately a significant flaw in what is otherwise very perfect functionality for our requirements.
Any suggestions on a solution will be gratefully received.
Best regards
Simon
All responses (
Answers (
