-
The fixed asset posting profile should require two separate GL accounts: one for the profit and another for the loss on disposal or sale
Customer request is to have two separate GL accounts in the Fixed Asset (FA) posting profile—one for recording asset losses after the disposal of sale and another for profit. As there is a limitation in the current functionality, which only allows a single GL account to be designated for both asset gains/losses in FA posting profile.
Below are the business impact details:
1. Improved Financial Reporting and Transparency: Having separate GL accounts for losses and profiles will provide clearer insights into asset-related financial activity. This distinction can improve the accuracy of financial reporting, especially when tracking impairments, write-offs, and gains/losses on asset disposals.
2. Better Compliance and Auditing: Different GL accounts for losses and profiles allow for better tracking and segregation of transactions, which can be essential for regulatory compliance and internal auditing. It ensures that asset write-offs, impairments, and gains/losses are properly categorized and easily traceable.
3. Enhanced Flexibility: The ability to separately handle losses and profiles offers more flexibility in accounting practices. For example, businesses can manage tax reporting, profit/loss assessments, and budgeting more effectively by isolating these transactions into distinct accounts.
4. Complexity in System Configuration: Implementing this change would require updates to the FA posting profile configuration. It could also involve additional accounting rules, system testing, and validation to ensure the correct GL accounts are used in the appropriate circumstances. This may incur initial setup costs and system modifications.
5. Impact on Reporting Accuracy: If the system allows more granular separation of asset-related postings, it can enhance the precision of profit and loss statements, depreciation schedules, and other financial reports, leading to better decision-making for business stakeholders.
-
After running the fixed assets reclassification proposal, the book in the newly created fixed asset remains the same of previous fixed asset group.
Currently when reclassifying the FA under construction to a new FA the values from the FA under construction are taken while the values from the new FA should be taken. After running the fixed assets reclassification proposal, the book in the newly created fixed asset remains the same of previous fixed asset group.
The new reclassified FA gets the book values from the original FA while it should get it from the new FA group.
Actual Result: The new reclassified FA gets the book values from the original FA.
Expected Result: After the reclassification has been done system should consider the book values from the new FA group.
Customer has always had to manually go to the asset to adjust the book settings. Not efficient at all.
-
Item groupwise credit limit and credit days
There is a requirement to enforce credit limits based on item categories—specifically, to restrict the processing of items in Category One when the amount exceeds for example $20.000, and items in Category Two when the amount exceeds $30,000. However, the current system design does not provide functionality to manage this requirement through existing credit limit settings or blocking rules.
-
Personalizing views, such as hiding the "stretch goal" field, inadvertently affected the standard view.
When personalizing views in the Employee Development workspace—specifically hiding the "Stretch goal" toggle when adding a measurement in a review—the change unintentionally affects the standard view as well. Personalization should be user-specific and should not alter the default system view for all users.
Expected Behavior:
Personalizing a view (e.g., hiding the "Stretch goal" field) should apply only to the personalized view and should not impact the standard/default view for others.
Personalization of Views Should Not Impact Standard Views
-
Require single click purchase order invoice reversal
Currently, reversing a purchase order invoice in Dynamics 365 involves a multi-step process that includes creating a purchase return order, selecting the specific invoice to be reversed, and then posting the reversal transaction. This process is time-consuming and can lead to inefficiencies for users managing frequent invoice reversals. To enhance user experience and operational efficiency, we propose implementing a single-click functionality that enables users to reverse a purchase order invoice directly from the invoice or related form. This feature would automate the reversal process without the need to create a separate purchase return order or manually select the invoice, streamlining the workflow and reducing the risk of errors. By simplifying invoice reversals into a single action, this improvement would save time, reduce user effort, and improve accuracy in financial transactions.