-
Enhance ControlAddIn to support different display techniques
There are many known limitations to using ControlAddIn at moment. Some are inherent to IFrames and might be solved by HTML5 Web Components (once legacy browsers are no longer supported), but others are to do with the management of CSS and DIV components, combined with Z-Index. There are times when we do want to pop-up a ControlAddIn and layer it over the screen, rather than take up space. As far as I can see this is not supported at the moment. -
Add page field type of file
Business Central technical team have added a coding entity of permanent blob and re-engineered temporary blob, but there is still no way to easier create an experience for a user (apart from a custom component) where a specific field on the page (not a factbox) represents a file. There are many use cases where this is required - such as certificates of analysis on lot info pages. We can workaround with tenant-specific extensions, but it is messy and not at all optimal. Ideally we could create a page field (specify an underlying 'big integer field') in which to capture the permanent blob reference and it would have an advanced and user friendly upload/download/drag'n'drop capability on the page - with different modes depending on web/mobile. NetSuite and Odoo both do an excellent job in this extensibility area. -
During a Posted Purchase Invoice correction process link to Incoming Document is lost
Is is a reasonable expectation that the system would when correcting a Posted Purchase Invoice the new Purchase Invoice document would now own the link to the incoming document (or a duplicate). I'd imagine the vast majority of times for correction are due to data entry, not a 'genuinely' new document being supplied by the vendor. This can be fixed through a series of manual steps, but it is cumbersome, not obvious and can be skipped. -
Conditional filter when field has multiple potential table relationships
In many areas of the application a field gets it lists of possible values via a table relationship. When this relationship is conditional on the value of another field the way tables are filtered breaks down. For example in payment reconciliation application an account no. field may contain different sets of data depending on the field account type. At the moment the application handles this scenario terribly. It basically appears to use the first of the possible relationships - which for example in payment reconciliation is useless as it usually a customer or vendor - not a general ledger account. The way to fix this (given that you can have different relationships per row) appears to be to surface those possible conditional relationships in the interface and allow setting that constraint first and remembering as a default in the future until changed. This would help in many areas of the application, especially given how valuable and helpful those conditional relationships are. -
Indicate visually if a list page action is enabled to work with multiple selected rows
-Theme - Usability -Sub-theme - Context-aware intelligence -Problem solved - Avoid unexpected results from action Business Central has the powerful ability to select more than one record on a list and have an action on the page handle them in batch. Unfortunately there is no way to know when selecting the action whether it operates on only a single record (most of the actions), or supports multi-record selection. Using a declarative property or compile-time code-analysis (look for setselectionfilter in code executed as a result of action) it would solve some usability issues if an action indicated visually if it is enabled for multi-selection. An option also exists to disable any actions that don't support multiple rows being selected. This would avoid confusion and mistaken errors. -
Integrate next generation email with customers and vendors
The new email functionality keeps a log of all sent email. However, this only partially useful as it is not linked for entity (customer, vendor, employee, contact) or transaction (sales order, invoice, etc). The ability to add that information would finally improve the sub-par relationship management within the product beyond the current ínteraction recording. It would finally mean a timeline similar to NetSuite, Salesforce or Dynamics Sales could be implemented that would show both emails send, transactions created which is a key question that often comes up in enquiries. It could also finally mean we get rid of that simple counter and actually allow a user to link from a transaction to see when emails were sent. I'm sure these are already planned. -
Multi-select field supporting many-to-many relationships
Currently there is no way other than to build a new table and list page to represent a many-to-many relationship as evidence by how Job Responsibilities are currently added to Person Contacts. This is both significant extra work and provides a sub-optimal user experience compared with best practice label/tagging offered in other web applications. Can we provide a new field type or properties that support this type of relationship (with underlying table plumbing generated transparently) and also a corresponding visual user interface representation that works across web, mobile, tablet, etc. -
Blanket Purchase Order and Sales Order should ignore location field during adding to actual orders
When setting up a blanket agreement you do not yet know the exact location that goods are being received into. Yes there appears to be validation that means a blanket agreement must have the correct location set at the header level (it ignores the line which appears to be a defect). No one should know where goods are being used at the time a blanket agreement is set up for purchasing. These fields should be removed from the page and from validation, with the existing location on the actual sales and purchase lines being the only location which matters. -
Indicate a General Ledger Entry Document No does not require a matching Incoming Document
Problem. We make use of the functionality that shows general ledger entries that do not have a matching incoming document against them. This is used as part of financial audit. However there are transactions that do not require a matching document (less than financial thresh-hold) or for another reason have it missing. To use this screen correctly it would be useful to be able to mark these as 'closed' in terms of requiring an incoming document. -
Improve handling of ship-to Addresses in Sales Quote and Sales Order APIs
The idea Microsoft Idea (dynamics.com) already refers to general improvements. I'm not sure I agreed with all of them and the scope was larger. We just implemented a custom integration around quoting and ordering.
We were surprised to find no inbuilt wait to get a list of ship-to addresses. Obviously, they thought in API you would either use default or custom. I suspect a lot of custom implementations exist to overcome.
On the customer API there should be a part that provides a list of potential ship-to addresses. In our implementation we have flattened the hierarchy create a temporary buffer table that is loaded with both the address details on the header and then any additional ship-to addresses identified. We add boolean fields to indicate if address is standard (i.e. on header) or a default - which might be header level or an additional ship-to address.
However - we are unable to take advantage of the Sales Quote and Order API as is to specify a ship-to code. Instead we take that alternative address data (if it is non-default) and specify the ship-to fields manually in API which means we are filling it with a custom address rather than ship-to. Not a deal killer, but might impact reporting at a future point if we want to differentiate.
Our code perhaps is not production but happy to do a pull request or contribute.
You’re offline. This is a read only version of the page.
