Russell Kallman Mr

After taking the trouble to update customer images I have discovered that they do not update the images on the corresponding contact cards, even when their is a relationship setup between them. This doesn't really make sense. It is especially jarring when you switch to the contact view from a customer card. Everyone has already spoken about import/export of images and I second that as a needed capability across all areas.

The new filters are fantastic. I'm sure we will get the ability to save preset views soon. The foundation is really going well. However, there are a few areas where SAP B1, NetSuite and even Netsuite/Xero has significant advantages of dynamics. One of those is helping respond to queries for information which minimise navigation and where you aren't quite sure what you need. Forcing us to go to a specific list to first filter or search is extra hassle. if you can one-up SAP B1 Hana's enterprise search (you should be able to easily beat their user experience) you will make many customers extremely happy. Looking forward to seeing what the creative product team comes up with.

Business Central has a powerful and flexible item charges system. It has a lot of positives. However, it is very inefficient in certain usage scenarios. For example, I have a invoice from separate logistics / broker to apply to a single purchase of inventory items and that invoice includes four to five separate item charges. At the moment I am forced to either manually consolidate these item charge lines (and lose transparency) so that I can do a single item charge assignment, or click on each separate line and perform an item charge. To streamline, I would love to see: -Ability to set a default allocation method on the item charge itself Is it possible to have an action at the invoice level. Assign All Item Charges. This would open a dialog to select all purchase receipt / sales shipment / transfer, etc. at the header level. Once selected you would just confirm. The default allocation methods for each item charge would be used. You would leave the current line method for the more complex scenarios.

Currently you rely on Yodlee which is unreliable and relatively insecure. There are a number of small business packages Xero, MYOB, QuickBooks amongst others who have built more secure and reliable methods of integration with banks. I'd imagine this is the case in many other regions as well. In Australia there is a new payments platform and open banking initiatives that will make this even easier. Both SAP and Oracle will move to build out these centralised bank feed services across all tiers of their offerings in the next two years. It will be important for Microsoft to either build out their own centralised service and API with the banks or partner to achieve this. Benefits include: -More secure integration with banking data -More reliable and timely bank information -Eventual integration with bank payment APIs as well

Ever since I first starting using NAV in 2016, I've understood the benefits of the fast tab in surfacing information, whilst hiding complexity, but been pained by the fact that they are in no way consistent with the shift to widescreen displays, visual widgets and proper separation between textual elements. Yesterday I saw a demo of the future screen design for NetSuite and I saw they have cracked the design problem and leap frogged how Dynamics NAV/Business Central conceive of fast tabs. In essence they have got rid of tabs altogether and transitioned it to a summary highlight of a particular section of information, the boxes ordered horizontally. Clicking on one of these boxes focuses down to that section of information. We would avoid the need to collapse all fast tabs to see those at the bottom and also make promoted information more readable and meaningful. I implore the design team at Business Central to have a look at what they have done. It would be require almost no changes to underlying page data model to implement as it is a visual design choice only. The use of decorators or properties on field elements could be used to intelligently render promoted fields.

It's fantastic that you have now added attachments. However, the ability to use them in customisations and code is limited without a rather essential feature. Please add the ability to specify an attachment properties (similar to how item category attributes are inherited) so that an attachment can be assigned a type when it is attached and a comment can be attached. The ability to set an attachment attribute set allows the following: I am on a sales order and I can attach a customer purchase order. The attachment can be assigned an attribute of Puchase Order (this is on the attachment attribute set for this type). Another attachment could be the specification drawing. On an item I could add a specification, a brochure, product information sheet - all separately and with comments. I could then in code choose to include a specific attachment based on its attributes if it exists. The ability to add a comment deals with the fact that often file names will not be meaningful. Ideally this would be part of an improved integration with microsoft sharepoint or other online file management systems that support attributes and searching for files.

Like everyone I'm looking forward to personalisation of menu / command bar. However, it's not nearly enough. More important (and a long standing problem in NAV) is that the menu shows all sorts of options to that either are not applicable, not available or not relevant at that particular point in time. The experience in my opinion would be significantly improved by adding in the ability to set an actions visibility and enabled property based on certain attributes in the underlying page. For example: Released/Open, Approve, Posting Preview, Prepayment and so many other options that only make sense in certain contexts. Other systems are more complex.

It appears Blanket Contract functionality has not been looked at or improved for some time. Instead Microsoft has depended on customisations by partners. I'd like to see at least some improvements including: 1) Validity date period for blanket contract 2) Column in item list for amount of unposted quantity i.e. ordered but not shipped product 3) Preference to auto-fill blanket contract within validity date period on purchase 4) Separate overall quantity on blanket order from child table for proposed schedule of delivery as current method forcing you to do this on lines makes the line functions not useful. 5) Removal of fields that are more applicable to individual orders and shouldn't exist at the blanket order level. i.e. get rid of anything that is date sensitive and not utilised as a header default.

Help is improving and the reports you are now capturing and mining product telemetry are all good news. However, I'd love to see you finding ways to actually capture human structured feedback on issues and problems by embedding screen capture and bug reporting within the product. Since that feedback is handled by you you can tag it with telemetry and allow richer insight into the actual problem occurring. Just one example - today I've got an issue that on the purchase order after personalising quick entry, the total fields for the subform under the line are no longer updating. It looks like the data is - because it works when I close and open. I don't particularly want to clutter the ideas forum.

Currently Business Central keeps upstream links between orders->receipts->invoices at the line level if you start with a downstream document and use the 'get-receipts' or 'get-orders' functions. There are many circumstances in which you want to use these functions but are retrieving a single order or receipt. My view is that Business Central should be 'artificially intelligent' enough to recognise this circumstance and for simplicity copy the order or receipt reference at the header level - the same way it does if you use the post function directly from the originating document. As a bonus having a field that indicates whether it is single or multiple sources for line items will help identify why the order number is missing in the header. One hopes that as part of the refactoring they look to a single code base that acts a certain way depending on the data, rather than where a particular function was called from.