ArcherPoint Blog

Component Flushing Methods in Microsoft Dynamics NAV

Bob Bergman — Thu, 23 May 2013 04:50:36 +0000

Component Flushing Methods in Microsoft Dynamics NAV

I get a quite a few questions related to Component Flushing Methods in Microsoft Dynamics NAV. After looking at the various NAV Forums, I thought a more in depth explanation of this function might be of some help.

First of all, we need to define flushing. The APICS Dictionary defines it as "A set of inventory bookkeeping methods that automatically adjusts computerized inventory records based on a production transaction. Examples of automatic relief methods are backflushing, direct-deduct, and pre-deduct processing." This concept is quite complex, so I have written a more detailed definition:

Flushing is the process of recording the movement of inventory items from a storage location to Work-in Process (WIP). Work-in-Process here means the production area where the material will be used. There can be three type of flushing:

Forward Flushing (pre-deduct processing)—An automatic flushing type in which the movement of inventory items to WIP is automatically recorded before the Production Order is started or a single Production Order Routing step is started.

Backward Flushing (backflushing)—An automatic flushing type in which the movement of inventory items to WIP is automatically recorded after the Production Order is completed or a single Production Order Routing step is completed.

Manual Flushing (direct-deduct)—The movement of inventory items is recorded to WIP as it happens

If this were not complicated enough, we also have to consider something called Routing Link Codes in Dynamics NAV.

First let’s define routing. I again went to the APICS dictionary to get this: "Information detailing the method of manufacture of a particular item. It includes the operations to be performed, their sequence, the various work centers involved, and the standards for setup and run. In some companies, the routing also includes information on tooling, operator skill levels, inspection operations and testing requirements, and so on."

Using the screen shots from Dynamics NAV 2013 for a Routing and Bill of Material and Item, we can see that the routing has Routing Link Codes 100 and 300 assigned for Operation 10 and Operation 40 and the Bill of Material has the Routing Link Codes assigned to components on the Bill of Material. The Flushing method is set up on each item card.

Dynamics NAV Routing

Dynamics NAV Production Bill of Material

Dynamics NAV Item Card

Following is how Dynamics NAV handles the timing for each flushing method:

Manual Flushing—A manual flush is performed when the consumption transaction is posted by the user using the Dynamics NAV Consumption Journal or the Production Journal.

Automatic Flush—The table below discusses timing for forward and backward flushing:

	Forward Flush	Backward Flush
With Routing Link Codes	The system will automatically deduct the component(s) with the Flushing Method of Forward on the BOM with the associated Routing Link Code when the Individual Routing Step is Started	The system will automatically deduct the component(s) with the Flushing Method of Backward on the BOM with the associated Routing Link Code when the Individual Routing Step is Completed
Without Routing Link Codes	The system will automatically deduct all of the components on the BOM with the Flushing Method of Forward when the Production Order is Released	The system will automatically deduct all of the components on the BOM with the Flushing Method of Backward when the Production Order is changed to the status of Finished

The choice of which flushing method to use is dependent on your situation, but here are some thoughts to keep in mind:

If you are using Lot or Serial Tracking, automatic flushing is not a choice.
If the items you actually consume and use in production are typically different from what is in the Bill of Material, automatic flushing is not a choice. This may be particularly true in process manufacturing where the quantity of items consumed may be more or less than what the Bill of Material calls for.
If your production cycle is long (more than a week), you should consider Routing Link Codes so that consumption can be recorded when the Routing Step is started or completed.
If your production cycle is short (e.g., one day), you should consider back flushing without Routing Link Codes so that all of the items are consumed when the production order is Finished.

Blog Tags:

Manufacturing and Costing Sessions Set for NAVUG Forum 2013

Bob Bergman — Wed, 22 May 2013 04:06:36 +0000

Manufacturing and Costing Sessions Set for NAVUG Forum 2013

It’s just a short five months until NAVUG Forum 2013 will be held in Tampa, Florida.

I just participated in a planning session for Forum 2013 to set the session content in the Microsoft Dynamics NAV Manufacturing and Costing areas. As it looks at this time, there will be a repeat of the popular sessions in the past, along with some new and informative content.

I will be presenting again and will be conducting a new two-hour session on “Manufacturing Accounting for non-Accounting Professionals.” As Manufacturing and Material Management Professionals, we are graded on key performance indicators like quality, delivery, and efficiency, but, in the end, our performance is ultimately graded on how our departments perform financially.

The session will be directed to Manufacturing and Material Management Professionals who may have had a course or two in accounting, but never got to the advanced courses in cost accounting.

This two-hour session will start with the fundamentals of accounting, then progress to manufacturing accounting. At the end of the session, attendees should have a good understanding of “where do these numbers come from?”

Don’t miss this and other informative sessions and an opportunity to network with others in the NAV community. Register for NAVUG Forum and be sure to become a member of NAVUG.

Blog Tags:

The Effects of Inventory Setup in Microsoft Dynamics NAV

Bob Bergman — Tue, 21 May 2013 06:12:31 +0000

The Effects of Inventory Setup in Microsoft Dynamics NAV

I am often asked questions on the effects of Inventory Setup in Microsoft Dynamics NAV. The two most common questions are:

1) How do the settings affect system performance?

2) How do the settings affect what is posted to the General Ledger and when?

In this blog, I will discuss these questions in the context of Automatic Cost Posting, Expected Cost Posting to G/L, and Automatic Cost Adjustment in Dynamics NAV, saving Average Cost for a later blog.

Let’s start by going to Inventory Setup. Go to Warehouse->Inventory->Setup->Inventory Setup:

Inventory Setup Window in Microsoft Dynamics NAV Classic Client

Automatic Posting

To understand what Automatic Cost Posting does, it’s important to understand Dynamics NAV’s Value Entries. When an inventory transaction is recorded in Dynamics NAV, an associated Value Entry is automatically entered into the Value Entry Table. This Value Entry reflects the cost of that transaction, whether positive or negative. Additional Value Entries can be added later by the Adjust Cost program.

If Automatic Cost Posting is checked, every time a Value Entry is entered into the Dynamics NAV database, the corresponding General Ledger entries are automatically made.

Expected Cost Posting

The key to understanding how Expected Cost Posting to G/L works is being aware that there can be two types of Value Entries. For instance, when a purchase order is received but not invoiced, Dynamics NAV automatically enters a Value Entry with an expected cost. When that purchase is invoiced, NAV automatically enters a Value Entry that reverses the original expected entry with the expected cost and replaces it with one with the actual costs.

By checking Expected Cost Posting to G/L, the system will post expected values to the General Ledger. If this is not done, an accrual General Journal Entry should be posted at the end of an accounting period to bring the General Ledger into balance with the Inventory Sub Ledger.

Inventory Setup Window with focus on Automatic Cost Adjustment

Automatic Cost Adjustment

Automatic Cost Adjustment is a fairly complex process and will be covered in more detail in a later blog, but for now, I’ll explain it this way:

There are two types of inventory transactions: 1) those that add inventory (inbound) and 2) those that remove inventory (outbound). For each transaction type, NAV enters at least one Value Entry to represent the cost of that transaction. Outbound Value Entries get their cost from the Inbound Value Entry that supplied it, for instance, a purchase order lot is received and a sales order is shipped from that lot.

There are times, though, when the original cost that was entered for the purchase order receipt was incomplete and, therefore, the cost transferred to the sales order cost of goods sold is incomplete (i.e., freight costs were added later). When the added cost is made to the purchase receipt, the Adjust Item Entries Cost program finds the outbound entries that were supplied by the purchase order and adjusted to show the additional cost.

To explain Automatic Cost Adjustment, I have included the following from NAV Help:

In this field you can set the program up to adjust for any cost changes automatically every time you post inventory transactions. The adjustment process and its consequences are the same as for the Adjust Cost - Item Entries batch job.

Because potential cost adjustment during every inbound posting could slow down database performance, this setup field includes time options (see below) so that you can define how far back in time from the work date an inbound transaction can occur to potentially trigger adjustment of related outbound value entries.

When setting a time option for automatic cost adjustment, you should therefore select one that balances your requirements for cost accuracy with the performance level of your database. Generally speaking; the shorter the time setting, the less accurate the cost information, but the better the database performance during posting.

In my experience, I have always selected ‘Never’ or ‘Always.’ If you select ‘Never,’ however, you must run the batch job Adjust Cost – Item Entries.

Microsoft Dynamics NAV Financial Management Window

If you are experiencing system performance issues (locked tables), it probably means you have set up Automatic Cost Adjustment to Always and Automatic Cost Posting is turned on. To alleviate these performance issues, change the setting Automatic Cost Adjustment to Never and turn off Automatic Cost Posting. This means, however, that you will need to run the Adjust Cost and Post Cost batch jobs.

For a new implementation, I try to make a determination as to transaction volume. If there is a high transaction volume, then I recommend turning off the automatic features.

As for Expected Cost Posting, it is the choice of the financial team as to whether to use it or not. From a performance point of view, there is not much effect, but it does add a significant number of records to the General Ledger. My choice is to turn it on as it does provide valuable information and it does make reconciling the Inventory Sub Ledger to the General Ledger much easier.

If you are in doubt about which setting to use, the good news is that you can turn Automatic Cost Adjustment on or off without compromising costing accuracy.

If you would like to learn more or have questions about Inventory Setup for your company, contact ArcherPoint.

Blog Tags:

Managing Negative Inventory in Microsoft Dynamics NAV

Bob Bergman — Tue, 14 May 2013 21:37:07 +0000

Managing Negative Inventory in Microsoft Dynamics NAV

I think that we all can agree that in the real world there can be no such thing as negative inventory; likewise, inventory on hand accuracy is vital to any company that uses a computer to track its inventory.

In an accounting/business management software system, however, it is quite common to see a negative quantity on hand. This can be caused by poor inventory accuracy or by ‘timing issues.’ For instance, an item can be issued to production before the purchase order is received in the system for that item.

Potential Problems with Negative Inventory

Given that you have good inventory accuracy, there should be no negative inventory at the end of any day. Negative inventory means your replenishment planning system is using invalid data—which yields incorrect reordering recommendations—and your costing system has no chance of reflecting accurate inventory and COGS values.

In Microsoft Dynamics NAV, we can also think of negative inventory as being negative in one location and positive in another location. For instance, in Location A, the system shows 1 on hand, but in location B, it shows -1 on hand. When we look at the total, the system shows 0 on hand, which is accurate when viewed globally. However, this is still not acceptable and needs to be addressed.

An easy way to prevent negative inventory in Dynamics NAV would be to change the system to never allow negative inventory. This sounds good in theory, but I find that in some companies it would be culture shock to do so. You can imagine if, at the end of a month, quarter, or year, the boss asks why you didn’t make the shipment that would have made the company’s shipping goal, and you answer, “Because the system wouldn’t let me post negative inventory.”

It is best to identify the areas that are causing a negative inventory number to occur and then correct those issues. However, because there can be many reasons for negative inventory numbers, this blog post focuses on identifying negative inventory and determining the cause rather than correcting the issues.

Finding which items have negative inventory

To discover what items have negative inventory in total is quite easy. In Dynamics NAV, go to the item list and set a filter for Quantity on Hand as less than zero, which will display a list of items showing negative inventory.

To find the items that have a negative inventory in one location only, you will need to access the Item Ledger Entry Table. Follow these steps:

Go to any item card.

Item Card - Quantity on Hand

Drill down on the Quantity on Hand. This will bring you to the Item Ledger Entries for that item.

Item Card - Ledger Entries

To see the Item Ledger Entries for all items, clear the filters set by the system.

Item Ledger Entries - Clear Filters

The system will display a list of all of the Item Ledger Entries for every item.

Item Ledger Entries - Display All

Now we want to make a list of all of the items with negative inventory, either in total or in one location only. To do this, set a table filter with Positive = NO and Open = YES.

Item Ledger Entries - Filter on Negative

The system will display a list of all Item Ledger Entries that need to be corrected.

Item Ledger Entries - Display Negative Entries

Now that you have identified the negative inventory entries, you can correct them. Keep in mind, however, that inventory values should never reflect a negative value, so it is just as important to correct the root cause of why the inventory went negative in the first place.

If you need assistance dealing with negative inventory or managing your inventory effectively, contact ArcherPoint for more information.

Blog Tags:

Main Street vs the Internet - The Sales Tax Showdown Is Here

NAV Insights — Thu, 09 May 2013 20:20:44 +0000

Main Street vs. the Internet – The Sales Tax Showdown Is Here

Guest blog provided by the sales tax experts at Avalara

On May 6, the Senate passed the Marketplace Fairness Act by a vote of 69-27, and it will now go to the House for approval. Retailers are divided on issue, but whether you’re for it or against it, chances are it will affect your business one way or another if enacted.

If passed, states will be given authority to require out-of-state or “remote” sellers to collect sales tax on sales made in that state, regardless of whether the seller has a physical presence or “nexus”.

The proposed bill could result in a major increase in the number of retail businesses who are required to collect sales tax, and it’s not just online retailers who will feel the impact. Vendors who sell via catalog and over the phone will also see changes in their out-of-state compliance requirements.

We’ve seen a preview of this with the so-called Amazon Laws, where certain states have passed legislation to compel Amazon to collect state sales tax. Variations on Amazon Tax laws include “affiliate nexus”, where you must collect and remit tax if you maintain certain affiliate relations in the state, and “click-through nexus”, where you must collect and remit tax if you generate a certain amount of revenue via online referrals.

It seems the states, many of which are facing budget shortfalls, are determined to get their piece of the pie on all purchases made within their boundaries one way or another. Raising taxes is not typically a popular decision, but making sure you collect every penny of what you’re allowed can have the same effect without the negative political implications. Hiring more auditors and expanding nexus laws to allow taxation of more transactions are two common strategies states are employing to maximize collections.

Proponents claim the Marketplace Fairness Act will level the playing field for brick-and-mortar retailers, who have argued that online merchants have an unfair advantage by not having to charge sales tax. But many online retailers claim that the burden of having to keep up with the 11,000+ tax jurisdictions in order to accurately calculate the tax rates would be a major hindrance.

While it seems an unlikely ally, Amazon has actually expressed support for the act. Some theorize that they hope that any upstart competitors will have a difficult time complying with the new requirements. Others believe that they plan to open warehouses in most states and offer same day and/or expedited delivery.

One thing’s for sure, though, times are changing, and all retailers need to work out a plan to stay competitive and compliant in the new sales tax frontier.

For a historical perspective on sales tax legislation and tips to prepare yourself for the changes, download our free whitepaper: Sales Tax Legislation Beyond Ecommerce - What every retail business needs to know, whether you engage in Ecommerce or not.

You can also watch a recording of a webinar recently hosted by our partners, Avalara, that discusses the legislation: Main Street vs. the Internet – How Online Sales Tax Affects Every Business.

Blog Tags:

Creative thinking and NAV flexibility beats customization

Bob Bergman — Thu, 09 May 2013 01:05:45 +0000

Dynamics NAV’s flexibility and some creative thinking can address unique business processes without the need to customize

The other day, a client presented me with a scenario that took some thinking on to how to set it up in Dynamics NAV without requiring a customization.

The client, who is running Microsoft Dynamics NAV 2009 R2 with the Role Tailored Client, sells wooden stakes. A vendor supplies green (not dry) stakes, which the client then sorts, dries, shapes, treats, and bundles for shipment.

The challenge he presented is in the purchasing and receiving process. The green stakes are stocked in NAV as ‘each,’ but the purchase unit of measure is 1,000 ‘Board Feet.’ There are approximately 3,000 stakes per 1,000 board feet.

When the delivery of the green stakes is made, the vendor expects an 80 percent cash on delivery payment. The stakes are then sorted to determine which are of good quality and which are of 2^nd quality. The client makes the final payment to the vendor for the good quality stakes only. The client is able to keep the 2^nd quality stakes and use them for other purposes; these are put into inventory with a zero value.

Here is the solution I came up with to manage this process within Dynamics NAV without requiring a customization:

We created the following 3 items in NAV with associated costing methods:
- Green Stake - FIFO Cost
- Good Quality Stake -FIFO Cost
- 2^nd Quality Stake - Standard Cost = 0.00
We create a purchase order for 1,000 board feet of Green Stakes.
We receive the purchase order for 1,000 board feet that will put 3,000 Green Stakes into inventory.
We make a prepayment for 800 board feet.
We create a NAV Released Production Order for 3,000 to output Good Quality Stakes.
The workers do the sorting and report the quantity of Good and 2^nd Quality Stakes.
Using the NAV Consumption Journal, we consume all 3,000 Green Stakes to the production order.
Using the NAV Output Journal, we output as many Good Quality Stakes that were counted. This will bring all of the cost to the Good Quality Stakes.
We calculate the total price to pay and ‘invoice’ the receipt for the entire 1,000 board feet.
We create an item journal entry to put the 2^nd Quality Stakes into inventory at zero value.
We apply the prepayment to the invoice.
At a later date, we pay the balance of the cost to the Green Stake vendor.

As you can see, with a bit of creativity and the flexibility of Dynamics NAV, many business process challenges can be addressed without resorting to a customization. This particular solution could be used in similar situations where the purchase prices are in part determined by the quality of the goods received.

If you’re challenged with unique business processes, talk to ArcherPoint today. If you have a creative solution to share, we welcome you to leave a comment.

Blog Tags:

Which Microsoft Dynamics NAV Costing Method Should Manufacturers Choose?

Bob Bergman — Thu, 02 May 2013 14:25:08 +0000

Which Microsoft Dynamics NAV Costing Method Should Manufacturers Choose?

I am often asked by manufacturers, “Which costing method should we use in our Microsoft Dynamics NAV system?” Before addressing the question, let’s set the stage with some important definitions.

In large part, “Cost Accounting” should be considered “Managerial Accounting,” not “Financial Accounting.” The exception to this is that cost accountants are responsible for providing and being able to validate the value of inventory items on the balance sheet. As for managerial accounting, cost accountants are responsible for providing “actionable information” to the management team so that management can make necessary adjustments to improve a company’s financial performance. There are no GAAP rules for managerial accounting, so a company’s cost accounting should be tailored to provide management with the information they need. Also, cost accountants are, at times, responsible of informing management with the future cost of items.

While the ultimate choice of which costing method to use should be left to your company’s financial management team and CPA, I can offer the following thoughts:

Microsoft Dynamics NAV gives us the choice of FIFO, LIFO, Average, Standard, and Specific costing methods.

FIFO: In Dynamics NAV, FIFO means that the items taken out stock for production or sales shipments will be taken out in the order of first received, first out and are costed with the actual cost of procurement for that FIFO layer (there are specific exceptions to this costing method if you are using lot or serial number tracking, but they are beyond the scope of this discussion). Using Dynamics NAV FIFO, the balance sheet will reflect the actual procurement/production cost of items remaining in inventory.

LIFO: In Dynamics NAV, LIFO means that the items taken out stock for production or sales shipments will be taken out in the order of last received, first out and are costed with the actual cost of procurement for that LIFO layer (Again, we will ignore specific exceptions here). Using Dynamics NAV LIFO, the balance sheet will reflect the actual procurement/production cost of items remaining in inventory.

Average: In Dynamics NAV, instead of using the actual cost when items are taken from inventory for production or sales shipments, the items are costed at the average cost for that item in inventory (before taking the items). The averaging period can be set to day, week, month, or accounting period. The balance sheet will reflect the actual procurement/production cost of items remaining in inventory.

Standard: Instead of using the actual procurement cost or the average of the costs, Standard in Dynamics NAV uses a fixed value set by cost accountants. In a distribution environment, cost accountants, with the cooperation of the purchasing staff, set the standard for the purchased items which ultimately becomes the COGS when shipped. This standard may contain provisions for overhead absorption and/or landed cost elements. In a manufacturing environment, not only do cost accountants set the standard for purchased items, but they also set the standard for produced items. The standard cost for a produced item may contain material, direct labor, overhead, or subcontracting cost. Cost accountants need the assistance of production engineers for establishing the standard cost of an item. The balance sheet will reflect the standard cost of items remaining in inventory. When there is a variance between the standard and actual costs, a Purchase Price Variance will appear on the P&L statement as a period expense.

Specific: For Specific, Dynamics NAV assumes that the company is going to buy, produce, and sell items one at a time. Specific requires that the items in inventory are serialized. In Dynamics NAV, Specific costing means that the items taken out stock for production or sales shipments will be taken out by serial number and the cost reflects the actual cost of procurement. The balance sheet will reflect the actual procurement/production cost of items remaining in inventory.

There are advantages and disadvantages to using each method.

Using any of the methods but Standard, you can provide an up-front estimate, but the actual cost and margins will vary from accounting period to accounting period. There is no easy way to provide an answer to the question, “Why are our margins what they are?” because all of the costs are coming out of inventory at the actual costs. We are only able to provide COGS analyses, because the margin at the end of the accounting period is either higher or lower than estimated, but why? Did you use more material and labor, or did it just cost more to procure them? It is easier with Standard costing because you can compare actuals against the standard to see where the costs originated.

An advantage of using Average cost is that COGS is smoothed and does not swing when emergency purchases are made to fulfill a special customer order. In this way, a salesperson is not penalized when a shipment goes out using the FIFO or LIFO layer that was procured at an inflated cost when sales commissions are based on margin.

In a distribution company, identifying the costs is easier: You purchase the product at one price; you sell it at another price.

But in manufacturing, there are often several stages of sub-assemblies, making it nearly impossible to understand why margins are high or low for a specific accounting period. Therefore, manufacturing companies typically use Standard costing when management is interested in tracking variances for the purpose of identifying where the process can be improved. Using Standard costing:

COGS is fixed and you can provide management with purchase price variance, material usage variance, and labor efficiency variance.
You can provide sales and marketing with a fixed cost number that can used to set sales prices.
Margins will remain the same until new standards are set.
A drawback for Standard is that there is a significant amount of up-front effort to set the standards.

Ultimately, costing accountants must choose the most appropriate costing method to provide management with the actionable information they require. However, it is important to understand how each method is handled within your Dynamics NAV system to make a well-informed decision.

Blog Tags:

Virtually There

Robert Garofallou — Wed, 01 May 2013 01:07:56 +0000

Virtually There

A lot of companies, ArcherPoint included, are allowing employees to work remotely. Webinars and other virtual events are more common than ever (nearly all ArcherPoint’s events are remote, and with employees throughout the country, remote communication is part of our culture). Today, both public and private high schools and colleges are offering online classes – some even have online requirements. I’ve not only taken online classes, I’ve taught them as well, and, having a technical background, I am not only comfortable with virtual learning, I’m a big fan of it. It saves on gas and travel time, and best of all, I don’t have to brush my hair, put shoes on, or look someone in the eye (I am a nerd, of course).

However, I recently had an experience that made me remember that, comfort and convenience aside, there are distinct advantages to physically being there.

Last weekend, I attended Florida Drupal Camp, a day-long conference covering various aspects Drupal, an open source Content Management System (CMS). If you’ve never heard of Drupal, it’s similar to WordPress. Although there are a plethora of online classes and self-study materials offered, the event was only an hour away and very affordable, so I decided to check it out…and I’m very glad I did.

I know one of the primary reasons for attending an in-person event is networking, but honestly, networking has never been comfortable for me, so that wasn’t a big motivator. However, from the moment I checked in, I knew I was surrounded by like-minded individuals—people who were there to learn and share ideas and challenges (and some horror stories) and become better Drupal programmers.

I also had an opportunity to meet several presenters, and after making that personal connection with them and gaining a better understanding of their topics, I decided to attend their sessions. I even got a chance to get to know several members of my local Drupal Users Group.

Here is perhaps the biggest advantage to attending this event. Drupal is a very versatile CMS, with over 20,000 contributed modules and over 1,500 themes. That’s wonderful—and overwhelming. If I spent just one second looking at each module, it would take me over five and half hours to simply look at each one, let alone learn anything about them. It was through attending conferences like this and being involved in the local user group that I have been introduced to several of the modules that I use today. I have been able to see them in action, ask questions, and follow up individually with presenters after their sessions.

I have often wondered about the merits of traveling to attend conferences and trade shows – is it worth the time and expense? This experience reminded me that, particularly for products that are your “tools of the trade,” the third dimension you gain by being there alongside other users and experts is unique experience and well worth the investment (and I believe it is better classified as an investment rather than an expense). Make it a point, even if it’s only once a year, to get out there, stretch your legs, remind yourself how to carry on a face-to-face conversation, and enjoy.

Blog Tags:

6 More Reasons You Should Consider Upgrading NAV

Jon Long — Sun, 21 Apr 2013 23:09:33 +0000

6 More Reasons You Should Consider Upgrading NAV

The Hidden Costs of NOT Upgrading NAV

Obsolete Technology – It gets harder and harder to bridge the gap between old technology and new technology the further upgrading is put off.

Microsoft and Add-On Software vendors create upgrade tools that support upgrading from the current version to the new version. This is called an "Upgrade Path". Sometimes, this path will support previous versions, essentially skipping versions. However, every time an Upgrade is put off, waiting for the next upgrade, higher costs for the future upgrade is guaranteed. This is because the future upgrade path may essentially require the equivalent of multiple upgrades, i.e., to get from point A to point C, you need to get to point B first. Each path step (version upgrade) involves more layers of code changes that need to be factored into the upgrade costs.
Asset Overhead – Customizations are assets, value added features that satisfy a need by the client. The value of these assets was evaluated at the time the feature was requested, approved, and implemented. At the time, it seemed like an awesome feature, and, over time, it was forgotten or taken for granted and perhaps now seems like a standard feature of NAV itself. The value from the benefits of the feature continue on and have now fully covered the cost. However, customizations are not "do it and forget about it". Customizations are perpetually managed forever.

Think of customizations as assets that require maintenance and care over time. They will forever be managed code. They will always be merged into new code during every upgrade. It can be a simple automated task, and usually is. However, old, obsolete, or incompatible code can be tricky to merge and add time to an upgrade. The code might even have to be refactored (re-written) to accommodate new technology, or a new customization, or a code change introduced by an upgrade, add-on or even a HotFix. During an upgrade, merging these customizations into Microsoft's new code, is a major part of the upgrade. In fact, if there were no customizations, an upgrade would be a trivial task; perhaps taking just a handful of hours, depending on training and server setup.

The cost of an upgrade is largely dependent on how many customizations(assets) are involved. The cost to manage these assets will always be higher when upgrades are not done consistently. This is due to the Code Debt factor. In this sense, upgrading can be thought of literally as Asset Management.
Code Debt – Unnecessary costs associated with customizations can be mitigated by always upgrading to the latest version of NAV. I call these unnecessary costs, Code Debt.

During the merge process, some code will merge automatically using various tools. However, some customized code requires developer interaction, sometimes re-writing the code. Some code becomes obsolete and is removed. Other times, it might be a customization for a feature that Microsoft has subsequently introduced in their base code. Either way, during the upgrade process, the code is somewhat cleaned up and likely in better shape for the next upgrade. It's much easier for a developer to refactor to code from a one-step upgrade path than it is to try and figure out how to merge code into a version that is two or more upgrade paths away – linear vs circuitous.

Code Debt Example: Client is procrastinating an upgrade, yet wants some of the functionality of the new version. Somehow, the client talks a Solution Center into implementing a customization that does the same thing in their current (old) version of NAV. I call this the "Borrowing Forward" Anti-Pattern. When it comes time to upgrade, this will invariably create a data conversion task and a code re-factor. The “Borrowing Forward” anti-pattern will always add to Code Debt.

The Upgrade is where the Code Debt interest comes due! Code Debt is perpetuated and compounded by Upgrade Procrastination. A good analogy would be Credit Cards that have zero percent interest for 12 months, then change to 35%. It would be wise to eliminate your debt before 12 months.

There will always be a cost of managing your assets (Code), but the cost of your debt (Code Debt) can be zero with consistent and current upgrades.
Human Resource Atrophy – Users will use the technology given to them. They will get really good at using this technology, potentially to a flaw.

Users could be happy with ancient technology, as long as they are comfortable using it, or they’ve been using it forever and they’re used to it. Meanwhile, their competition is moving on and running their businesses with the latest supportable, scalable, and superior technology. The user is missing out on technology that's full of new features and power and losing out on learning to use and talking about the new technology.

A staff of users that are really good at the old stuff, but have no exposure to the new and/or current stuff are risking atrophy of certain parts of their brain, or entire parts of the staff. Sounds extreme. I believe it's true. Sadly, it will go unnoticed due to the rapid pace of technology in our society. The symptoms will be denial, frustration, apathy, and eventually, thoughts of an early retirement. (Side note: I've been known to exagerate to make a point.)

Microsoft is constantly adding new features in NAV. Users that are on the most current version of NAV will be ahead of the curve with respect to the latest technology. Many of the most awesome features in the latest version of NAV contain usability functionality that users will find familiar in all user interfaces, including Web Browsers, Phone OS's, Mail App's, Music App's, etc. By perpetually procrastinating upgrades, users will be missing a cross platform training opportunity. What users are learning on their own by simply browsing the Web, organizing their pictures, or downloading music, can be applied to the latest NAV interface.

NAV, up until the Role Tailored Client, was virtually unchanged from around the turn of the century until NAV 2009, when Microsoft introduced the RTC client. The old "Classic" client was admittedly out-of-date feeling, even in 2000. Nevertheless, it was much loved. It was great for data input, searching, viewing data, etc. It was a user's User Interface, built for user input and data analysis. Users got really good at using the Classic client.

NAV didn't contain any significantly changed UI features until the RTC. So, with the introduction of the RTC, longtime NAV users were presented with a mind-blowing new interface built on XML(the Gold Standard for digital transactions and communications since the turn of the century). So, with the advent of RTC, NAV has somewhat caught up with the latest technology, finally.

Transformation of customizations to the Role-Tailored Client really is like pounding a square peg into a round hole. It requires the developer tool equivalent of a chisel. Luckily, this is a one time task.

RTC, behind the scenes, and the visible UI, is a paradigm shift from Classic. It’s not just a simple code merge, at least for Forms(to Pages), Dataports(to XMLPorts) and Reports(to RDL, RTC enabled reports). So, the “transformation” process is a big deal. There are tools that attempt to convert, but they fall short and require Developer interaction, usually manually re-writing a good bit of the customizations. The key here is that the customizations exist in these objects (some are custom objects themselves) and the Developer needs to duplicate or simulate the same behavior in the new object. This can be incredibly difficult, especially if the client has not upgraded since any version prior to NAV 2009. In fact, it can even be more difficult than the original request because the developer has no context for the customization. They only have the delta between the customized version and the old base NAV code. They can only base their new customization on that delta. So, getting to RTC is a major step and can be compounded when coming from an older version of NAV.

That being said, development for Pages and Dataports is much simpler and, therefore, cheaper for the client in RTC, especially in NAV 2013. In fact, my prediction is that upgrades will also be cheaper going from any RTC to RTC upgrades. This, again, is because the RTC is such a paradigm shift from Classic. It literally brought NAV from 10+ years behind the times from a UI perspective, to current technology. We may never see such a drastic upgrade path again.

Every day that goes by using the old Classic client adds to the stubbornness and resistance to change by the user. It's not about whether the user thinks "The old way works fine", "The new upgrade will not directly benefit us", "The new way is ridiculous", "If it's not broke, don't fix it.". It's about letting that attitude slip so far that it will get to the point where your upgrade path is three or five upgrades behind. Then, not only are the costs of upgrading exponentially higher with each step, but the user training experience will cause increased cost and undue stress for everyone during the transition.

I make the point about Classic and RTC because I experienced similar attitudes and resistance to change when I was first implementing new clients to Navision 2.6 back in 2002. Users were used to their old system, AccPac, QuickBooks, Web based stuff. It really doesn’t matter. Trying to compare one system to another is like comparing an apple to an orange. The important thing is that NAV upgrades always are for the better. Really. You can argue all you want about what you like better about the old version, but the fact is, the cost of procrastinating will far outweigh the perceived value of the old version. And, that cost will continue to increase with every NAV version.
Support and Maintenance Cost – What is never talked about in upgrade cost discussions is how users will directly benefit from the latest enhancements to the Development Environment, Debugger, Code Designer, Report Capabilities, External Integration Tools, Data Access, etc.

Why would anybody care about the Development Environment except the developer? Well, every issue resolution or customization will require the Development Designer. That is where the magic happens. Cost savings due to efficiencies in the latest designer are directly passed on to the client.

The latest Development Designer allows the developer to perform complex coding tasks and issue analysis much faster than in previous versions of NAV, directly affecting the cost of every single issue analysis, resolution, and feature request. If the issue or feature is for an older version of NAV, any development, at the very least, perpetuates the old technology, adding to code debt and ultimately making it harder to upgrade. At worst, it technologically limits the development options and requires more work for the developer, adding cost to the client. Either way, this adds to a Code Debt snowball effect.

If the client is on the latest NAV version, developers who are tasked with solving an issue or satisfying requests for a new feature are not constrained to the limits that are inherent in old technology.

By making technological decisions based on the latest current NAV version, Code Debt is mitigated. Developing in the latest NAV version, it will be much more likely that code changes will adhere to the latest “best practices” and will more likely be automatically merged in the next upgrade, virtually guaranteeing zero percent interest on that code debt.
Finally and selfishly – developers simply like working in the latest development environment. So, make a developer (me) happy. Please upgrade!

Blog Tags:

Sales Tax Is No Laughing Matter – But It Has Its Moments

Robert Garofallou — Tue, 16 Apr 2013 22:17:03 +0000

Sales Tax Is No Laughing Matter – But It Has Its Moments

A colleague of mine from Avalara once asked me, “Did you ever hear the joke about sales tax compliance?”

“No,” I replied.

“That’s not surprising,” she said. “There isn’t one.”

Anyone who has ever dealt with sales taxes can appreciate that few things in business are as dull, as complex, or as important as sales tax compliance.

Still, I can always count on our friends at Avalara to find the lighter side of a very serious subject.

For instance, cookies in New York are not taxable – but candy is. So what happens when you buy a Twix bar – a “cookie layered with caramel covered in chocolate” (or “cloaked in chocolate”, if you’re the Left Twix)? Do I have to pay sales tax on it or not? The answer is: It depends. According to the New York State Department of Taxation and Finance: “Are you buying them as candy or as cookies?”

Or that in Iowa, the milk chocolate version of the Milky Way is tax exempt because it contains wheat flour and “Candy shall not include any preparation containing flour…” By the way, the Midnight Bar version is not tax-exempt.

While some of these tidbits of sales tax trivia can be kind of funny (like the fact that, in Maryland, hot buttered popcorn is taxed differently than buttered popcorn), the serious undercurrent is that sales tax laws are different from state to state and even from town to town, and enforcement is heating up. With more and more local and state governments facing budget shortfalls, they look to sales tax enforcement as one place they can recoup some of their lost revenue.

Avalara offers some good advice to help companies avoid, or at least survive, an audit by state taxing authorities in their Sales Tax Survival Guide, including:

Determine which jurisdictions can apply sales tax on your business. Sales tax is not simply determined based on where your primary store is located. Stores that operate in several municipalities, across state lines, or on the Internet, may (or may not) be subject to sales tax compliance according to nexus rules. Businesses that have a substantial presence in a state, such as holding a business license or establishing a headquarters, are required to collect sales tax and remit the funds back to the government.

Know what products are taxable. Most grocery items are not taxable, but prepared food items are. And most services are not taxable in most states, either. But there are exceptions: In New York City, a donut or bagel is not taxable if eaten on the premises of the establishment where it is purchased, but if it is placed in a box and taken outside, it is taxable. And Ohio has reclassified dry cleaning services from being tax-exempt to being taxable.

Apply the correct tax rate for the jurisdiction. Don’t mistake postal ZIP codes for municipal jurisdictions. ZIP codes are used by the US Postal Service for efficient delivery of the mail and may or may not accurately reflect municipal boundaries. You must comply with the state, county, and city boundaries to arrive at the proper sales tax rates for each of your stores.

Collect the appropriate sales tax from your customers. Not all your customers must pay sales tax – some individuals and businesses are exempt (for example, businesses that are buying your product for resale to another party). However, to be exempt, a person must present a tax exempt certificate to you to keep on file. According to Avalara, this is one area where a lot of companies get into trouble, because they either cannot produce these certificates during an audit or the certificates might be out of date.

To find out more, download the Sales Tax Survival Guide from Avalara.

And be sure to join us on April 25 when ArcherPoint and Avalara present a free Lunch & Learn webinar, Exemption Certificate Best Practices: Reducing Audit Risk.