Monthly Archives: April 2011

Imagine if Your ERP is on the Cloud with Amazon Right Now

Posted by on April 22, 2011 No comments

If you haven’t heard already, Amazon Web Service AKA Amazon Cloud, has been down since around 1AM on April 11th, 2011.  I wrote an article about my reservations of having the heart of my business outsourced somewhere in the post here.

Imagine if your company decided to have your solution hosted with Amazon Cloud. You’d be hurting a lot right now as a lot of orders will have to be written by hand. But assuming you’re not using Quickbooks anymore, your company must’ve grown to a significant size, and in a world that’s more connected than ever, your ERP solution is probably integrated and receiving orders electronically (EDI, E-commerce sites, etc).

I realize this cloud computing is still at its infancy and as we can see, even if a hosting company as big as Amazon can fail without warning. The lessons learned here if you decide to host your ERP or Navision or GP or AX, etc. You have to:

  • Make sure how you’re going to process the order by hand
  • Make sure you have a plan to get all those electronic orders by hand
  • Make sure you have a plan to manually ship those orders

These plans will need to be in place for the long term as you never know when the hosting company can get their server back up and running again. It may take hours, days, or even weeks. Even so, you’re risking data loss after it comes back online. Basically, even if the hosting company guarantees, you’d better not expect it’ll be guaranteed.

On the flip side, if your hardware is hosted in house, the manually processes are not as important. You can get a computer and restore a backup last night of your database faster than the hosting company can get their server back online.

Why You Should Not Turn On Expected Cost Posting for Navision

Posted by on April 15, 2011 40 comments

Overview
The ERP software business is a very competitive business. If the software company does not devote a lot of their resources into research and development of the product, it becomes outdates very quickly. Therefore, when choosing to purchase an asset that is the lifeblood of your organization, it’s very important to not just consider how well the product and serve your company, but also the company behind the product.

Having said that, there are also a lot of features that are developed because “the competitors have it”, not because it makes good operational sense. These features are important in sales demos and feature comparison analysis for end users looking to purchase a new system.

One of these features in Dynamics NAV, in my opinion, is the Expected Cost Posting feature in Dynamics NAV. The reason is not the feature itself, but the amount of useless data it generates. This article will exam this feature a little closer and give you some informed decision on how you should configure this for your company.

What Does the Feature Do?
According to Dynamics NAV help, this is what the feature does:

Expected costs are the estimate that you make of the cost of, for example, purchasing an item before you actually receive the invoice for the item.

You can post expected cost to both inventory and to G/L. Whenever you post a document, such as an order or a journal, as received or shipped, a value entry line will be created with the expected cost. This expected cost will affect inventory value, but it will not be posted to G/L unless you have set the program up to do that.

Basically, this feature accrues the values of the inventory that you receive (and ship) that has not been invoiced yet. Sounds great! This is in compliance with GAAP (Generally Accepted Accounting Principles), you should match up the value of your inventory to the G/L. Having this checked, on the G/L entries are created for you automatically.

NOTE: This feature DOES NOT have ANYTHING to do with your inventory cost and how it’s valued! Do not get it confused! This feature is STRICTLY for Navision to post expected cost the G/L.

In practice, this is what the feature does. Consider the following purchase order:

I’m using the CRONUS database with item 70001 and 70002 as our example.

If you create a purchase order and post the Receipt, it creates the following transactions. This is done by Navigating on the Purchase Receipt and showing the G/L Entry table:

As you can see, the system creates 2 additional transactions per item. One goes to the Inventory Interim account specified on your Inventory Posting Setup and the other entry goes to the Invt. Accrual Acc. (Interim) account specified on your General Posting Setup. If you do not turn on the Expected Cost Posting, no G/L transactions are posted.

Now let see what transactions are created when when the purchase invoice is posted.

When invoice, it creates 2 additional transactions per item. The same entries as what we did on purchase receipt, but this entry effectively reverses out the entries in the interim accounts.

For normal transactions for items that are received, there are no G/L Entries created. When you post the invoice, the Direct Cost Applied and the Inventory are hit per item. Then 2 transactions are created for the whole invoice for Purchase and Accounts Payable.

The functionality works on the sales side as well. So if you do post sales shipment and sales invoice, the number of transactions occur the same way except using different G/L accounts.

If you do the math, with Expected Cost Posting turned ON, you’re creating 40% of additional transactions per entry when you post a purchase invoice! In addition, you’re creating additional entries when you post the purchase receipt.

The number of transactions increases significantly if you use Dimensions!

Why is it a Waste of Space?
Space is cheap, we all know that. But even if storage is cheap, I’m still a firm believer that you should only keep track of data that’s of some value.

Having Navision post these additional transaction, in my opinion provides no value and typically adds to the confusion of the company using it. Not to mention that it creates additional work for the accounting folks if all of a sudden accounts are off because someone decided it was a good idea to turn on Direct Posting for those accounts. Or if a bad implementor decided it was a good idea to turn on Expected Cost Posting without closing all the outstanding orders.

In addition, think about your back up. By creating an additional 40%+ of transactions per purchase and sales order, you’re making your database size bigger than it has to be. And we all hate dealing with large files and all the problems that it comes with.

How do I Get the Expected Cost for Accrual Purpose?
That’s easy. There’s a outstanding report in standard Navision that’s there since version 1.x called Inventory to G/L Reconcile. This report gives the figures for receipt not invoiced and shipped not invoiced. The example of the report from our example above:

All you need to do is take that amount and book your accruals accordingly. You can set this up on the Recurring Journal easily enough so you post the accrual entries, and the system will automatically reverse it out on the next period. Look at the Recurring Method in the Help file if you’re not sure what I’m talking about.

Since we highly recommend (I should say mandate) our clients to turn off direct posting to Inventory, COGS, Purchase, etc accounts, we usually ask them to create separate account for accrual purposes, just like the example in the CRONUS company.

Conclusion
I truly believe this is a function that was created out of necessity during the “feature wars” of the ERP software. Ultimately, the “feature war” is good for the ERP software consumers because it forces ERP software companies to invest, or be phased out. However, in practice, not all of the features should be implemented just because it sounds like a great idea.

A good Navision consultant should walk you through these key features and what impact it has. The person should have enough knowledge to know where the pitfalls are so you’re not wasting your time going through every little feature in the system.

The balance of what needs to further explanation and what doesn’t is really up to your Navision consultant. And the way that the Navision consultant should know these is through experience. If your Navision consultant is new or not that experienced, just reading from the manual, he/she will think that this is a great feature and a must, just like the end users!

Navision RDLC reporting – SetData and GetData – Why It Is REQUIRED

Posted by on April 1, 2011 15 comments

Ever wondered why there’s no tutorial on how to create a Sales Order report from scratch in the RDLC? The reason is because it takes a LONG TIME! Even for an experienced developer, it takes a long time. As I previously mentioned on my article, Microsoft really needs to address this in future versions.

The reason for SetData and GetData is not because of performance reason as stated in the manual 80146B. For additional information on defining SetData and GetData, please look here.

For multiple pages, the header data is dependant on whether there are lines. If you’re printing multiple form type reports like the sales order and you do not use the SetData and GetData, the header will only link to the lines displayed on the first page of the report. So this means that if your sales order is printed to the 2nd page, the header information will all disappear.

Here’s an example if you create a report without using the SetData and GetData logic:

This is the first page. As you can see, the header displays nice and pretty. I used whiteout to remove some sensitive information in Paint.

Now this is what happens when you print the 2nd page:

No, it’s not an error. You’re seeing it correct. It’s a blank page. I didn’t even have to use Paint to remove any information.

The reason why the 2nd page is blank, again, is because the link was done only on the first page on the header. If the report goes to the 2nd page, the link is essentially gone, therefore, no value is loaded and so nothing is displayed.

 

So when you create a report that has headers in forms (sales order, quote, etc). You need these:

Shared Offset As Integer
Shared NewPage As Object
 
Public Function GetGroupPageNumber(NewPage As Boolean, PageNumber As Integer) As Object
    If NewPage
        Offset = PageNumber – 1
        NewPage = False
    End If
    Return PageNumber – Offset
End Function
 
Public Function IsNewPage As Boolean
    NewPage = True
    Return NewPage
End Function
 
Shared HeaderData As Object
 
Public Function GetData(Num As Integer) As Object
   Return Cstr(Choose(Num, Split(Cstr(HeaderData),Chr(177))))
End Function
 
Public Function SetData(NewData As Object)
    If NewData <> “” Then
        HeaderData = NewData
    End If
End Function

 And you need these controls with the proper code:

We spent hours and hours trying to get our report header to print on multiple pages. Don’t make the same mistakes we did!

EDIT – Thanks to Steven for pointing this out. It turns out that this was mentioned on the 80146B manual on Chapter 3 page 35. Shows you that you shouldn’t go through the 300+ page manual quickly!