D365 – BC – “For a Better Tomorrow #1” – Work Date ≈ No Date

D365 – BC – “For a Better Tomorrow #1” – Work Date ≈ No Date

Hello everyone,

I would like to share a thought that crossed my mind. I'm sure you're all aware that when setting up sales & receivable and purchase & payable, we have the two options "Work Date" or "No Date" to choose as the "Default Posting Date."

The above feature was introduced to prevent users from posting invoices, shipments, or receipts on the same day the documents were created. There have been instances where actual sales or purchases did not take place on the day the record was created.

Users failed to update the posting date of the documents to the current date before posting which would cause posting a document to prior dates. This will lead to create unnecessary reversal and correction entries. Yes, There can be an argument that we can restrict users' posting via User Setup date limitations.

Still…

When creating a new document, the posting date of the document will be same as the date updated in the "Order Date" field. According to the feature, the posting date of the document will be empty during creation, if "No Date" has been chosen as the "Default Posting Date”.

The document posting system will prompt the user to choose the posting date when trying to post the document. So, users will be cautious when choosing the posting date.

Even though the above feature provides some relief, we still have a bottleneck in the following case: When documents are posting partially (e.g.: multiple receipt for one purchase order), system will throw an error only when user posts it for the first time. After that, the system will not indicate that you should update the posting date.

Solution in mind:

  1. After each posting instance, leave the "Posting Date" field empty. This forces users to select the posting date whenever they post the document.
  2. Confirmation message on posting if posting date doesn't comply?with?work date.

Please comment if you have different way of thinking to cater this problem.

要查看或添加评论,请登录

Jeevarathan Raveendran的更多文章

社区洞察

其他会员也浏览了