David Boehm Professional Business Software, Inc. President

Quite often, customers have multiple shipping addresses.  In fact, it is not uncommon for a single customer to have dozens of shipping addresses.  There is currently no way to automate the entry of shipping addresses to D365FF.  This can't be done through RapidStart, nor can it be done via Excel (from the "Ship-to Address" list).  We need to be able to do this.

You've been good enough to include a "Customer" spreadsheet in the RapidStart workbook, but the real data volume is typically in the shipping addresses.

Thanks,

--Dave--

This is relevant in RapidStart, but it would be relevant through Dynamics 365 for Financials. One of the shortcomings to using Cloud-based software, is the slowness when scrolling through a list page. If you showed line numbers (say, on the left side of the page), we would at least have our bearings in terms of knowing how many records we've scrolled through. This is especially important when scrolling through a list that is "fectching more data", but only scrolls up a few records at a time (instead of a whole page at a time).

This is relevant in RapidStart, but it would be relevant through Dynamics 365 for Financials. One of the shortcomings to using Cloud-based software, is the slowness when scrolling through a list page. If you showed line numbers (say, on the left side of the page), we would at least have our bearings in terms of knowing how many records we've scrolled through. This is especially important when scrolling through a list that is "fectching more data", but only scrolls up a few records at a time (instead of a whole page at a time).

One of the greatest drawbacks to working with Financials, is the slow pace of data entry.  Users essentially add one field at a time, and have to deal with internet latency each time we hit the "enter" or "tab" key.

I also noticed that as the number of lines in a journal increase, the response time becomes slower.  As an example, this past weekend I converted a company from QuickBooks to Financials.  As a part of this process, I create journals in the G/L Journal entry screen to book their trial balance.  As I add more and more lines, I get more "working on it" messages.  If I tab through the rest of the fields on the screen and start entering the next line too soon, the "Amount" field on the previous line becomes blank.  I would estimate it takes anywhere from 2 to 5 times as long to do an entry in Financials, as opposed to doing the same entry in a Windows-based ERP.

Why don't you use Excel as a data entry platform for Financials?

You already have the basic programming in place for this.  There is an "Export to Excel" icon on most screens.  Of course, you'll have to validate data received through a spreadsheet upload, but a lot of this logic already exists in your RapidStart capability.

If you use Excel as a data entry platform, you will have combined the best of both worlds (i.e. Windows-based and Cloud).  Users would be able to use Excel's capabilities to quickly create data, and the data would ultimately end up in a Cloud-based ERP (i.e. Financials).

Would it be that difficult to do this?  Your current "Export to Excel" capability allows me to make limited modifications to records that already exist within Financials, but it doesn't allow me to add new records to a spreadsheet and successfully publish these.

This past weekend, I migrated a company from QuickBooks to Financials.  I ran into all sorts of unnecessary issues that at least doubled the time for doing this.

As an example, your "RapidStart" doesn't import quantities for inventory items.  O.K., so I figured I would enter inventory items through RapidStart, and then use the "Export to Excel" function from with the "Financials | Item List" to export the items, enter the quantities, an then publish the updates back to Financials.

Unfortunately, quantities aren't updatable when I try to "publish" the Excel spreadsheet back to Financials.  Consequently, I had to step through the item screen (one item at a time) in order to add the quantities on hand.

Were your ears ringing?  If not, they should have been...  You allow inventory adjustments from the Item card, why not allow them through "RapidStart", "Export to Excel", or both?

By not allowing us to do this en masse', you nearly made this task impossible to complete over a weekend.

Let me start by stating that I think RapidStart is basically a wonderful tool.

In order to use it most efficiently, I usually enter the first Journal Entry line manually, export the RapidStart package, and use that first journal entry as an example when creating the rest of the entries for any given spreadsheet within the RapidStart package.

In regard to inventory items, I created an inventory item manually in Financials with  a "base unit of measure" of "PCS".  Of course, "PCS" is one of defaults that are included in Financials when you first generate any new tenant.

Since I couldn't add item quantities through RapidStart, or "Export to Excel", I had to go item-by-item through the Item Card screen.  When I tried to use the "Adjust Inventory" action, I would receive an error message telling me that "PCS" was not a valid base unit of measure.  To get around this, I would click on the elipsis next to "base unit of measure" on the Item card, select a different unit of measure, save it, then hit the elipsis again, and re-select "PCS".

"PCS" is pretty easy to spell, but I actually used Excel's "Fill Down" function to populate this column in each row of my RapidStart Inventory Items spreadsheet, so I know it wasn't mis-entered.  I'm guessing that your RapidStart validation doesn't trim this field when it uploads it to Financials.  Apparently your lookup routine with the Item card also doesn't trim this field during the lookup process.

In any event, when you consider that quantities can't be entered via RapidStart, quantities can't be updated via "Export to Excel", and quantities can't be adjusted through the Item card without first re-selecting the "base unit of measure", you've managed to create an environment of almost total frustration!

In the end, it was humanly possible to get inventory items (along with on-hand quantities) into Financials, but because of a series of design shortcomings and bugs within your solution, this took far, far, far longer than it ever should have.

"Edit in Excel" is a wonderful tool.  Unfortunately, it sometimes seems like a developer used the dart board approach when deciding which fields to make editable.

Aside from "Item no." and "Description", "Unit_Price" is probably the most crucial field to have available for update in the "Edit in Excel" capacity.  When a company increases its prices, it normally does so either universally, or for a selected group of items.  In either event, you are basically considering a mass update.  Quite often this takes the form of a "5 % update", "10 % update", etc.  This is the perfect situation to be addressed in Excel.

While I understand you would have to validate the decimal when validating during the "Publishing" process, exposing the "Unit_Price" field is probably the most useful change you could possibly make to the "Edit in Excel" function within the "Items List" screen.

There seems to be no way to determine whether a purchase document (i.e. a P.O or a Purchase Invoice) has been generated from a sales order.  If one has been generated, there seems to be no way to determine which one it happens to be.  In experimenting with this functionality, I can also create any number of duplicate P.O.'s or Purchase Invoices from the same sales order.

After I've created a P.O. (and especially a Purchase Invoice) directly from within the Sales Order screen, I should at least get a warning if I try to create a duplicate.  I should be able to navigate from the sales order to the applicable purchase document.  I should also be able to navigate from the purchase document to the related sales order, as well.

This kind of functionality is essential for managing purchases when these are directly related to sales.  This sort of functionality is basically available for drop shipments, and should be available for normal shipments as well.

This pertains to timesheets and projects.

Currently, I'm not aware of any way to add comments at the line item level, in timesheets.  As an example, I would like to add a description of the work performed, results found, etc.  I would then like to see these line item-level comments show up on a  sales invoice.

Currently, I have to keep track of this sort of information in a Word document, then copy the information to "comment" lines in the Sales Invoice after I've generated the sales invoice.  The comment line in a sales invoice only allows for something like 55 characters, so I end up adding multiple short comment lines to describe each time charge.  This results in a really amateurish looking invoice.

I would consider attaching my word document as an addendum to the invoice, when I utilize the "Post and Send" action, but there is no way to do this, other than embedding the contents of the Word document in the Custom email text.  Once again, this looks quite shoddy.

The Time Sheet page is available on a computer screen or a tablet screen, but it is not available on a telephone screen. Users don't always have their computers or tablets with them when they "go out into the field", but they always have their phones with them. Always, always, always...