This is likely common knowledge in the community however its something I only discovered recently so I thought I’d share in the hope it helps someone else :).
Someone requested for the “Notes and Attachments” FactBox pane to be added to the Customer Ledger Entries page so they could record notes against a customer ledger entry.
As this wasn’t available at first sight I assumed it would require development to add this, however a colleague advised its already there, its just hiding and you can expose it using standard Personalisation 🙂
Therefore to expose this FactBox pane you just use follow the steps in the clip below:
It turns out this is hidden on all sorts of other pages!
For example the General Ledger Entries page and the Vendor Ledger Entries page. Just follow the same steps above to add to those pages.
When you post a transaction in a subsidiary module in Dynamics GP, a journal is created in the General Ledger to record the transaction in the chart of accounts. The journal has its own unique journal number that groups all the distributions related to that transaction together and is stored in the GL table on all the lines.
Being a long time Dynamics GP user, when I started using Business Central, on posting a transaction I looked for the equivalent journal number in the G/L Entries, but couldn’t find it? Yes, there are G/L entries created, but I couldn’t find what I classed as a unique journal number that binds these together just like the Dynamics GP journal number.
In this post I’ll walk through what I regard as the closest equivalent to the Dynamics GP journal number in Business Central.
Dynamics GP – Journal Number
When you post a transaction in a subsidiary module in Dynamics GP, like a Sales Invoice for example, this is recorded in the General Ledger as a Journal Entry.
For example when I post the Sales Invoice below its recorded in the General Ledger using a unique Journal Entry number. The same journal number is stored on all the lines of the journal.
And here’s the Journal Entry recording the transaction in the General Ledger. The journal entry number is stored on all the distribution lines.
Therefore when posting one transaction in Dynamics GP, you get one Journal Entry with a unique number grouping all the distributions relating to that transaction in the General Ledger.
** Please note things like the originating document number and customer number are also transferred and stored in the GL table in Dynamics GP just like Business Central.
Dynamics 365 Business Central – G/L Entries
Going back to the example of a Sales Invoice, when you post a Sales Invoice in Business Central a series of Entries are created including G/L Entries.
Therefore if I were to post the Sales Invoice below
I’d get the following G/L Entries.
As you can see each line has a unique “Entry No.”. There is no obvious unique number from a GL point of view that groups all these lines together. (You can group them together using the “Document Number” but this is the Sales Invoice document number. There is no GL specific unique reference that groups these together in the G/L Entries table.)
Up steps the G/L Register
Although not obvious at first, whenever you post any transaction in Business Central, along with all the various entries that are created, a G/L Register is also created.
The G/L Register has its own unique number and encompasses all the entries that have been created by posting the transaction. It does this by holding the “From Entry No.” and the “To Entry No.”
Below is the G/L Register that was created by posting the Sales Invoice above
As you can see this has a unique GL reference. This is the “No.” column.
Therefore this is what I regard as Business Centrals equivalent to Dynamic GPs journal number.
Conclusion
Once I’d grasped this concept of entries and registers, I felt I had a greater understanding of the posting flow in Business Central.
Thanks for reading!
** Please note there is also a “Transaction No.” field stored on the G/L Entries which appears unique however I’ve found you can post one document number which can generate more than one “Transaction No.”. I blogged about this here
I ran into a situation when trying to “Correct” or “Cancel” a Sales invoice generated the following error:
“Cancelling the invoice failed because of the following error:
Sales Credit Memo must be approved and released before you can perform this action.”
The error was occurring because I had a workflow configured for Sales Credit Memos however the client only wanted the workflow to trigger for manual credits, not for cancellations or corrections.
Therefore in order to prevent this I had to tweak the workflow condition as I’ll explain further in this post.
The Error
When trying to cancel or correct a posted sales invoice I’m presented with the following error:
I then have to open the credit memo and send it for approval. However in the clients scenario they want to bypass the workflow when creating a credit off the back of an invoice, so the credit note posts automatically.
The Fix
In order to prevent the error I had to figure out a way of bypassing the existing Sales Credit workflow by adding a condition to the workflow.
As part of my investigation I switched off the workflow and posted a correction on a Sales Invoice successfully. I then noticed the “Applies-to Doc. No.” field is automatically populated on the “Sales Cr. Memo Header” table as part of the correction process:
I therefore added the following condition to the workflow:
Now when cancelling or correcting an invoice the Sales Credit Workflow isn’t activated and the credit is created successfully.
Conclusion
Although it seems you overcome this situation by getting creative with the workflow conditions, I’d be interested to know if there are any other workarounds for this scenario.
The Dynamics Explorer 