-
Enabling additional exchange rate type for foreign currency revaluation simulation
Suggested by Mohamed Abdelkader Soliman Elsayed – Completed – 0 Comments
the current implementation of Additional exchange rate type for foreign currency revaluation Enhancement does not support simulations, which poses a significant risk when running postings without accurate simulation results.
This limitation affects our ability to perform precise forecasting and planning. To mitigate this risk and ensure consistency in our financial processes, I propose enabling the simulation feature for this enhancement.
This will help us avoid potential errors and financial discrepancies. Please consider this request and keep it in mind for future feature developments. Thank you for your attention.
-
Enable option to dropdown into GL interim accounts open transactions and settle/post automatically at once via General journals
Suggested by Mateja Mersnik – Completed – 1 Comments
Dear all,
it would be very practical to enable option to dropdown into GL interim/balance sheet accounts open transactions, pick them up and post & settle them automatically all in one via general journals. There are numerous reasons and examples for this.
Mentioned already exists on vendors or customers where we can pull, for example open vendor invoices and book & settle it with payments.
Same we can do with for example GL repostings, write offs and etc. - booking and settling in one step.
Please be so kind and review this request because Ledger settlements would be closed automatically, cleaner and much sooner.
This options exists under general journal Functions - Settle transactions but it is grey for Ledger.
Our work and daily challenges would definitely be easier and faster while doing balance sheet recon. This can work worldwide for all M365 users.
Thank you in advance.
Best regards,
Mateja
-
New feature "Exchange rate type enhancement for accounts payable and accounts receivable foreign currency revaluation" apply for simulating function
Suggested by Thang Nguyen – Completed – 0 Comments
Currently, The feature in ver 10.0.39 "Exchange rate type enhancement for accounts payable and accounts receivable foreign currency revaluation" does not support FCR simulation function, and it is by design.
Normally, the user will simulate to check the result first before running FCR. This feature should be supported for FCR simulation function as well.
-
Year-end closing: "Transfer Balance Sheet dimensions" by financial dimension
Suggested by Syed Mujahid Abbas Bukhari – Completed – 22 Comments
Currently, In the year-end closing process, "Transfer balance sheet dimensions" can be selected or not (Yes/No switch). That means if YES is selected, it will transfer balances in all Balance Sheet main accounts along with their Financial Dimensions.
However, it is commonly required to close some financial dimensions and get opening balance without any dimensions and also for few main accounts, it is required to get the opening balances with Financial Dimensions.
Feature is somehow available for P&L accounts but not for Balance Sheet heads where it is equivally important even more important in our case.
Looking forward for its incorporation at earliest possible.
-
Financial Tag available in Pending vendor invoices > Distribute amount
Suggested by Malene Furbo – Completed – 0 Comments
To be able to add a Financial Tag in Pending vendor invoices > Distribute amount.
When using Vendor Invoice Automation cost invoices are imported to Pending vendor invoices, The coding such a ledger account and dimensions must be added in "Distribute amount", but there is no ability to add Financial Tag.
The option to add Financial Tag on Cost invoices is required.
-
Invoice capture PO invoices
Suggested by Maria Pedersen – Completed – 0 Comments
In the Invoice capture solution - a suggestion for the possibility of using procurement category for invoices related to non-stocked items such as rent. Many customers uses procurement categories for purchase orders, and this creates some issues when using invoice capture for PO invoices, as the mandatory line fields are item numbers, and not able to use procurement categories. It is not possible for those customers, to use the cost invoice type, as it needs to relate to a purchase order.
-
Adding more formats to ABR statement ER formats
Suggested by Jose Manuel Rey Benlloch – Completed – 0 Comments
Converting Excel to MT940 every month using some Third-party tool is cumbersome, we believe that Microsoft can add more flexibility to customer by adding more formats to ABR statement ER formats.
This request stems from the challenges our customers are facing when attempting to convert Excel bank statements to MT940 format for importing into Dynamics 365 system.
As you are aware, our customers rely on the efficiency and accuracy of their financial data integration with D365. However, a recurring issue has emerged where Excel bank statements, which are commonly provided by banks, need to be converted into the MT940 format before they can be imported into Dynamics 365 system. This conversion process can be cumbersome and error-prone for many of our users.
To address this challenge, we are exploring the possibility of creating a seamless solution that would allow our customers to directly import Excel-based bank statements into D365 without the need for manual MT940 conversion. Specifically, we are interested in:
• Deriving existing ABR Statement model, MT940 mapping, and MT940 format into Excel, ensuring that all relevant data fields, relationships, and formatting are preserved.
• Establishing a standardized Excel format that aligns with the requirements of our system, making it easier for our customers to import their bank statements without errors.
We believe that this enhancement would significantly improve the user experience for our customers and reduce the complexity.
-
Electronic reporting sales tax: Expand the setup in the StandardTaxCodes_Lookup-section with Sales tax group and Item sales tax group
Suggested by Mette Skjærstein – Completed – 0 Comments
In Norway there are still customers using the old Norwegian VAT-report because using the new electronic reporting-format is too time-consuming. Characteristics for the customers using the old VAT-report: they have a lot of legal entities and in each legal entity they can have several properties (using ISV FlexProperty). The Norwegian tax-law demand to have specific sales tax codes with different deduction-rates related to each property. Different deduction-rates are taken care of in the setup of the sales tax code.
Each legal entity can acquire properties during a year, but it’s also common to acquire properties that require a new legal entity. New legal entities can also be created several times during a year.
The customers find it very time-consuming to create and maintain the setup for sales tax codes in electronic reporting, where each sales tax code must be assigned to a standard sales tax code.
The idea: the setup in the StandardTaxCodes_Lookup-section can be expanded with Sales tax group and Item sales tax group, like the way it’s already done in the VATSpecificaton_Lookup-section.
-
Standard entities for Electronic reporting destination
Suggested by Alireza Eshaghzadeh – Completed – 0 Comments
"Electronic reporting destination" form is a company-specific that primarily utilized for configuring the destination of generated reports or invoice layouts (such as Email, Archive, Screen, etc.) within business documents. Presently, we face a challenge due to the absence of standard entities (Reference, File Destination, Document Layout Setting) that can be accessed through the Data Management Framework (DMF). Given our frequent use of business documents and the shared requirements across multiple companies, the implementation of standard entities for these forms would greatly facilitate the process of copying configurations via DMF.
-
May we know which version change the DimesnionValueDelete logic? The MainAccount '8500' is used in one or more default accounts and cannot be deleted.
Suggested by Elsa Guo – Completed – 0 Comments
The Repro steps as below:
- Create a 8500 main account in GL -> Chart of accounts->Accounts->Main account.
- Create a new customer posting profile in AP-> Setup->Customer posting profile. use it in summary account. save it. then delete the posting profile.
- back to main account, try to delete 8500 account from main account, got the error message: A financial dimension value is based on the 8500 record and has been used on a transaction. You cannot delete the 8500 record.
However, if test the same steps in 10.0.33 and above version , the main account can be delete without error. the same scenarion in 10.0.18 version, confirmed that we cannot delete the main account even if we delete the main account using in customer posting profile. May we know the root cause of the different behaviors. thanks.