November, 2007

  • Microsoft Dynamics NAV Team Blog

    Overview of Microsoft Dynamics NAV W1 5.0 SP1

    • 0 Comments

    I have often been asked about the content of Microsoft Dynamics NAV W1 5.0 SP1.

    I will here give a short overview of what we are planning to include in servicepack 1 for Microsoft Dynamics NAV 5.0, please be aware that the scope can still change:

    1.       Product improvements

    More than 300 product improvements based on feedback to Microsoft Support Services from customers and partners worldwide have been included in Microsoft Dynamics NAV W1 5.0 SP1. The improvements are split into the areas of the Microsoft Dynamics NAV platform and the Microsoft Dynamics NAV ERP system.

     

    2.       Performance improvements

    a.       SIFT including indexed views

                                                                   i.      Purpose: To gain performance by using indexed views in relation to SIFT

                                                                 ii.      Goal: To create one indexed view for each SIFT key that is enabled

    b.      Bulk Insert

                                                                   i.      Purpose: To gain performance by buffering inserts and send them in one go

                                                                 ii.      Goal: To reduce the amount of roundtrips to the SQL Server

     

    3.       Refactoring of the Planning Engine

    a.       Address all real issues

    b.      Have improved readability

    c.       Clear decision principles

     

    4.       New ERP Requirements based on feedback from Microsoft Dynamics NAV partners

    a.       Better access to sales and purchase history 

                                                                   i.      Purpose: Provide access to sales and purchase history from Customer and Vendor cards

                                                                 ii.      Goal: To see open as well as posted documents based on the Pay-to/Bill-to or Bill-to/Buy-from role each vendor or customer can play

    b.      Option for not auto-filling Quantity to Ship/Receive on Orders

                                                                   i.      Purpose: Option to prevent auto-filling of Quantity to Ship/Receive

                                                                 ii.      Goal: To be able to set up whether Quantity to Ship/Receive should be filled automatically or not

    c.       PO dashboard

                                                                   i.      Purpose: To align purchase documents with sales documents

                                                                 ii.      Goal: Include the info pane from sales documents on purchase documents

    d.       Option for not auto-filling Posting Date  on Sales and Purchase Documents

                                                                   i.      Purpose: Option to prevent auto-filling of Posting Date

                                                                 ii.      Goal: To be able to set up whether Posting Date should be blank or work date

    e.       Automatic Archiving of Quotes and Orders

                                                                   i.      Purpose: To be able to force archiving of quotes and orders

                                                                 ii.      Goal: Optional to force archiving of quotes and orders before deletion

    f.        Archiving of Return Orders

                                                                   i.      Purpose: To align to other orders

                                                                 ii.      Goal: To be able to archive Return Orders manually or automatically

    g.       Print Archived Quotes and Orders

                                                                   i.      Purpose: Align to other posted documents

                                                                 ii.      Goal: To be able to print archived Quotes and Orders

    h.      Add External Document No. and Applies-to Doc. Due Date to payment journal

                                                                   i.      Purpose: Improve information about what is paid in the journal

                                                                 ii.      Goal: To display the External Document No. and Applies-to Doc. Due Date columns on the Payment Journal form

    i.         365 Days Depreciation for Fixed Assets

                                                                   i.      Purpose: To extend the depreciation methods for fixed assets

                                                                 ii.      Goal: Make it optional to use 360 or 365 days for depreciation calculation

    j.        Line Comments on Documents

                                                                   i.      Purpose: Extend comment to document lines.

                                                                 ii.      Goal: To be able to enter comments for each line entered in sales and purchase documents and have them posted/archived as well.

    k.       Posting Date on posted document lines

                                                                   i.      Purpose: Better reporting on posted documents.

                                                                 ii.      Goal: Add Posting Date field to posted document lines tables.

    l.         Purchase Quote No. maintained in sales and purchase documents

                                                                   i.      Purpose: To be able to see where the document originates from (if a quote existed).

                                                                 ii.      Goal: Add quote number to not-posted Order and Invoice, and add quote number to posted Invoice and Receipt/Shipment.

    m.    Add Account Description to G/L Entries Form

                                                                   i.      Purpose: Better information on G/L Entries

                                                                 ii.      Goal: To be able to show the G/L Account Name next to the G/L Account No. in the G/L Entries form.

    n.      Filter Balance Field on Customer/Vendors to show Open Entries only

                                                                   i.      Purpose: To make it easier to get an overview of content of the balance on the Customer and Vendor cards.

                                                                 ii.      Goal: Show only open entries.

     

     

     

    5.       Mobile integration (Ready for Mobile Integration)

    a.       Purpose: To prepare Microsoft Dynamics NAV 5.0 SP1 for integration with mobile devices

    b.      Goal: To be able to gather the backend information in Microsoft Dynamics NAV 5.0 SP1 to be represented on a mobile device

     

    - martinni

  • Microsoft Dynamics NAV Team Blog

    Money Up Front: Prepayments in Microsoft Dynamics NAV 5.0

    • 3 Comments

    In a lot of business contracts, you’ll find that payment either in full or partial has to be made before the order is handed over to fulfillment. Like in ordering imported items, made-to-order items, or simply when a customer has no previous record with the selling company.

    On way of creating the proper documents for this is to create an invoice for the advance payment, and then remember to deduct it when the order is fulfilled and final invoicing is taking place. Common practice, but also one that relies heavily on the user tracking all the documents to an order, relies on someone to check if payments are received before order fulfillment, and one that is prone to errors when the advance payments is deducted on the final invoice.

    In 5.0 we’re addressed the advance payment issue with the Prepayments feature. It allows the creation of Prepayment Invoices and it keeps track of the Prepayment Invoices so correct and full deduction can be automatically applied to the final invoice.

    Many scenarios can be thought of in relation to advance payments so NAV 5.0 has functionality that allows the user to create a very diverse set of prepayments invoicing scenarios for both sales and purchase orders, including among others setting prepayments % or amounts for individual lines, setting a fixed prepayment amount, and controlling how the prepayment amount(s) are deducted as the order is fulfilled, e.g. when partially invoicing – all aiming at giving the user flexibility enough to accommodate the most common current business practices.

    For a first release of a new feature it of course comes with limitations – some due to initial requirements, some due to time and resource scarcity in a release. Some are already being considered for improvement in coming versions. Three of the limitations are:

    • The VAT setup relies on G/L account setup; this was due to the fact that this was intended more as a replacement for doing a manual extra invoice for any advance payments. Requests are that this be modified so it follows the items, e.g. prepayment VAT accounting is based on the specific content of the order.
    • Invoice discounts are not included in the prepayment calculations, due to complexity when tracking multiple prepayment invoices, e.g. when updating an order and sending new prepayment invoice. This limits the scenarios with 100% prepayments combined with invoice discounts.
    • Installments-like prepayments are not possible. There is no planning tool for issuing fixed interval prepayments, e.g. for larger order you could have fixed dates for multiple future advance payments. The Prepayment invoices must be created one by one.

    Improvements on this limitation will happen as we gather feedback from market.

    Brian Nielsen

  • Microsoft Dynamics NAV Team Blog

    New trace flag in Update 4 for SQL 2005 SP2

    • 1 Comments

    The current release cycle for SQL 2005 SP2, is to release a new update every 2-3 months. Currently (November 19th 2007), the latest update for SQL 2005 SP2, is update 4, which is available here:

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;941450

    The updates for SQL 2005 SP2 are all accumulative, so you will not have to install Updates 1 - 3.


    Each SQL update may contain small changes to the way that SQL Server behaves, including changes to the query optimizer. So when having any kind of SQL related problem (performance problems or otherwise), I would recommend to apply the latest update to begin with.

    This update (Update 4) also contains a new trace flag which was made specifically for Navision installations. I have only seen the issue that it addresses very few times, so I would only recommend activating this trace flag if you see any of the symptoms. But this is how this new trace flag works, and what the symptoms are:


    Symptoms:
    Changing filters in a list form, which used to be quick on SQL 2000, is slower after moving to SQL 2005, even when filters and indexes are a perfect match. The symptoms typically cause a few 1.000s of extra reads. They are unlikely to cause complete table scans. So the problem we have here, is more of the system slowing down a bit, than the system hanging completely.

    The queries causing the problem will look like this:
    SELECT  Name FROM "CRONUS International Ltd_$Contact"  WHERE (("Name" LIKE @P1)) AND  "Name">@P2 ORDER BY "Name"','Steve%','Andy Anderson'

    Note that the two filters (predicates) LIKE and > are on the same field (Name). 

    Index hints or RECOMPILE will not make any difference to this query.

    Navision can generate a query like this if you have a list of contacts sorted by "Name". Then while the cursor is on 'Andy Anderson', apply a field filter (F7), and filter on 'Steve*'.


    So we have these two predicates:
      1)  LIKE 'Steve%'
      2)  > 'Andy Anderson'

    SQL 2000 would evaluate each of them, and use the most selective predicate first, in this case the first one (LIKE). So SQL 2000 would first select contacts where name LIKE 'Steve%', and then from these contacts find the ones where name > 'Andy Anderson'.

    SQL 2005 behaves differently when queries are parameterized (as they are). It will assume that a LIKE-predicate is always less selective than a > - predicate (which is often the case). So on this query, SQL 2005 will always run the second (>) - predicate first. So it would first select contacts where name > 'Andy Anderson', which would be most of the contact table.

     

    Update 4 for SQL 2005 SP2 contains a new trace flag 4119, which will change SQL Servers behavior in this specific situation back to SQL 2000 behavior.

    Before you set this trace flag, I would recommend that you collect some traces, and analyze whether you do see queries like the one mentioned above. You can read more about identifying problem-queries in the blog "Diagnose your SQL Server".

    - Lohndorf

Page 1 of 1 (3 items)