Although there are third party solution for this, they come with a larger suite of code that over-layers the standard code. They are also expensive for what new customer sees that should come as standard.
Customers that need to use catch weight cannot use WHS, and the change required is very hard to write without over-layering the standard product.
The creation of vendors can lead to expenditure being spread over more vendors thus increase managements costs and decreasing the concentration of expenditure, reducing bargaining power. To overcome this, I am proposing a feature to add workflow to the creation of a vendor.
The personalization options in the application are very strong, limiting the need for customizations while enabling users to simplify their user interface.
A simpler user interface improves the usability and acceptance of the system. It would be great that an administrator (/ consultant) can create the optimal personalization for the forms in use and easily share or deploy this to all users. This limits the need for customizations to hide and change form objects and increases the maintainability.
One of the most heard requests during an implementation is around simplifying these fields. With this option, we can stay away from customizations / code releases and functional designs while quickly helping the new users to adapt to the system.
Advanced bank reconciliation has been designed but no bank statement report provides clear information.
Bank statement report is required base on cutoff date. This report should have option to detail
* reconciled transactions
* Un-reconciled transactions
Customer should be able to have a statement at date of what is in his bank account for Audit, cash management, management decision.
For financial accounting and statutory reporting purposes companies have to be able to evaluate their inventory according to different valuation methods, such as FIFO, LIFO, etc. in parallel.
Currently it is only possible to assign a single inventory model to an item. There is a standard Russian functionality (dual warehouse) available that allows assigning two inventory models. This Russian functionality does, however, also not help in cases where companies need more than two inventory models, which is often the case in international companies that have to report to local GAAP, local tax rules and - at the group level - IFRS if those accounting standards require different valuation methods.
Please note that this does not require that items in the inventory are revalued. What is needed is a financial feature that allows obtaining alternative inventory values based on different inventory valuation principles.
It would be great if this gap could be closed with the next release/update.
Many thanks and best regards,
It is a very common scenario:
Inventory is physically moved from one site to another (moving from warehouse on the east coast to warehouse on the west coast)
Freight cost is incurred during the move, and this cost needs to increase the inventory value.
There can be other charges such as duty and tariffs if the source and destination in different countries.
Right now there is no reasonable way to add the charges cost to the inventory value of the products moved (as can be done with purchase orders, using charges)
This is a MAJOR pain, and a repeated request.
The Dynamics grid (d365f0 ListView component) lacks many of the features that our users expect, based on their experience with other web-based applications.
In particular, it isn't at feature parity with the Office 365 components. Through the life of the new Dynamics, we haven't seen the grid improve through the update process yet.
Performance of scrolling is the major deficiency that concerns us.
- When scrolling a large dataset (more than a few dozen rows), the client-side control loads a fixed number of records from the server. When these records are exhausted, the UI is pre-empted to load the next set of records.
- Developers have no control. Missing API features are: the page size (number of records to load at a time), and the number of pages to load ahead of time (buffering).
- The scroll bar resizes with each new set of data. This means it cannot be used to navigate a dataset - its primary purpose.
Major missing features that our users have voiced their concern about include:
- A simple column selector.
- Users have to go through the personalization UI. Most controls provide a context menu available on right-click to select columns.
- Wrapped headers.
- Text in headers cannot wrap, leading to truncated labels where there are more than a trivial number of columns.
- A functioning scrollbar.
- Current scrollbar resizes every time a new data page is loaded (as the user scrolls down). As a result, the scrollbar cannot be used to navigate a dataset - it's primary purpose.
- Hierarchical presentation of records.
- Many controls allow nesting, providing a visual indication of hierarchical lists. We're limited
- Frozen (pinned) columns
- Allowing user-specified collumns to remain visible on the left side while the control is scrolled left-to-right.
- Grouping and summary.
- Grouping by user-selected columns, and providing a summary row below.
- Functioning paste or fill-down.
- Selection works at a record-level initially, rather than providing focus to the cell a user clicks in (or keyboard navigates to).
- Users therefore cannot copy/paste a value from a point (x,y) in a grid to a point (x, y+1). This is a very common operation when working with tabular data, and moving the to Excel and back is not feasible in many scenarios.
- Programmatic formatting of the contents of single cells.
Microsoft grid controls that implement most of these features:
- Fabric UI React List control used in Office 365:https://dev.office.com/fabric#/components/list
- Fabric UI JS List control: https://dev.office.com/fabric-js/Components/List/List.html
Other common grids that have managed to implement the features above include:
- Kendo UI grid: http://demos.telerik.com/kendo-ui/grid/index
- JQWidgets' jqxgrid: https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxgrid/index.htm
Generally, the grid started off incomplete in AX7, and since release, has fallen farther behind most other business applications. Please evaluate these (and other!) gaps for inclusion in platform updates.
Transaction-based financial dimension:
There was an easy-to-implement possibility to largely improve GL reporting and analysis capabilities by extending the ledger integration by financial dimensions.
In several setups, a posting integration is defined by ledger account defined in the posting profiles and some additional set-up tables (i.e. item postings, resources postings, fixed asset postings, indirect cost postings, project postings, bank postings, customer/vendor postings, automatic postings, etc.).
The idea is to add financial dimensions to the main account entries. The filled dimension depends on the posting type / transaction type and brings all types of transactions together (cross-module) and hence makes it easier to run reports on GL postings on general level.
1. Quite easy to implement since the framework is already there.
2. Separation of quantity values from transaction values in the GL - more transparancy
3. Enables cash-flow statement according to the direct method as required in financial reporting of many groups of companies
4. Enables standard reports (tax development, provision development, cash development, fixed asset balances, inventory changes) or makes it easier to create from GL (using financial reporting)
5. Reduces number of required GL accounts
This kind of "movement" or "flow" analysis is almost always required by customers but so far hardly supported by D365. The extension brings big improvements by low effort.
When looking for an GL-account, for example in General ledger > accounts > main accounts there is no possibility in Operations furthermore to directly have a look on the postings. Instead a time consuming trial balance has to be run (for all accounts) before the account can be selected to view the transactions. From the technical point of view this may be ok. But from the view of an accountant not. An accountant needs the possibility to quickly access the transactions of a main account like he could in former Ax-Versions.