There was an error updating your session... Please refresh this page before continuing! EB: This is now an alert in Master.js
  • Data-centric security for the enterprise.

    Protect end-user data in a single repository, speeding recovery and remediation from the inconvenient file loss to a business-wide disaster.

    Learn More
  • Bol Crash Plan.

    Enterprise Endpoint Backup + Restore

    Learn More
  • Service with a smile.

    Our Customer Champion team maintains an impressive 97% customer satisfaction rating.

    Learn More

Welcome to this Business Portal

Customers and Partners can create orders and shipping labels.


Note: If a page or action is not allowed with your current credentials, please contact our support department.

How to Handle Set Up Time with Standard Costs in Microsoft Dynamics NAV

ArcherPoint How-To Blog: Step-by-step instructions on how to perform specific tasks in Microsoft Dynamics NAV

NOTE: This blog applies to any version of Microsoft Dynamics NAV, including NAV 2016. The screenshots are taken from NAV 2013.

To begin a discussion about setting up time with standard costs in Microsoft Dynamics NAV, we must first examine the dilemma of trying to include setup as part of the “Direct” cost of an item.

Setup is a one-time cost; it is not a cost that reoccurs for each piece that is produced. So the question is, how do you split the one-time cost and assign each item that is produced as part of the setup cost?

That is a somewhat rhetorical question. The only way that this can be done is to make an assumption about how many pieces will be run when you set up to run this item. If you always run 100 pieces when you set this item up, for example, then it makes sense to divide the setup time by 100 and assign 1/100th of the setup cost to each item. The problem is, rarely do companies run the exact same quantity each time they setup to run an item up. My guess is that this varies on an order by order basis. 

So let’s take a look at how to handle setup time in NAV when using Standard Cost as the costing method.

There are really two choices for you to consider when you think about including setup time in your cost of the product.

  • Include as a “Direct Cost”
  • Include as an” Overhead Expense”

There is no right or wrong way to handle setup expenses. It can be included as a Direct Cost, or it could be included as Overhead Expenses. Both are acceptable and provide valid costing based on the assumptions you make. The sections below take each of these options and walks you through how you would use NAV to include the setup costs based on the assumption you move forward with.

Before detailing how to set up the setup costs in NAV, let’s review the circumstances where one option seems to make more sense than the other.

  • When using Standard Costing, there is a basic assumption that your costs are predictable and repeatable. This means that your purchase price is fairly consistent, your production process is consistent, and therefore, your costing is consistent. The assumption is that any variance to your production rate and costs are small and therefore recognized as a monthly operating expense rather than the cost of the item.

If your production run size is pretty consistent when you set up to run an item, then using Setup as a direct cost makes sense. This means that the run size difference from order to order is a very small percentage to the size of the production run.

  • If the run size varies significantly from order to order, then the base assumption that the cost is predictable is not necessarily valid. Large swings in the run size from order to order mean the setup cost per unit is significantly different and therefore may be more appropriate to consider as an overhead expense. Considering setup as an overhead cost means that you would estimate all the setup costs for the year and then spread all overhead costs over each piece that is made in that work center. By making it a global estimate, the average for all pieces is more accurate than the order by order difference per part.

Setup as Overhead

When applying setup as overhead, two things need to be estimated by work center:

  • Total setup costs for the year
  • Total production run time for the year

Dividing the total production run time for the year into the total setup costs for the year would calculate the setup cost per hour that should be absorbed with each hour of production through that work center. This rate would then be added to the other overhead expenses that are associated with that work center and included in the cost of the item. This value would be populated in the Overhead Rate field on the Work Center card.

In the example below, the work center is set up to track production in hours. The Overhead Rate field is the amount of overhead expense that is applied for each hour of Run Time on production routings for this Work Center.

Work Center set up to track production in hours.

Figure 1. Work Center set up to track production in hours.

Overhead Example

Let’s walk through an example of how setup costs would be absorbed as an overhead expense.

In our example, the following conditions are true for our Machining Work Center:

  • Production runs 250 days a year
  • There is typically 1 setup done per day
  • The average setup time at this work center is 30 minutes
  • The expected total setup time for the year = 250 * .5 = 125 hours
  • The setup hourly wage is $20 per hour
  • The total Setup Cost for the work center is 125 Hours * $20 per Hour = $2500
  • Production runs 1 shift 6 hours a day (1-hour setup, 1-hour breaks and lunch)
  • Total production run time for the year is 250 * 6 = 1500 hours
  • Setup Cost per hour of production run time is $2500 / 1500 = $1.66667 per hour

The $1.66667 per hour would be added to the other overhead costs per hour, and loaded into the Overhead Rate field on the work center card.

Setup as a Direct Cost

An average setup cost per unit must be determined if the setup cost will be included as a direct cost of the item. This means that NAV must be able to calculate this average cost per unit. This is done by defining three things:

  • Setup Time for an item
  • Cost per hour
  • “Normal” quantity produced per run

These three important fields are stored in different places in NAV. The sections below define where these key pieces of information are stored.

Setup Time

The setup time is defined on the routing for the item being built. Each routing operation could have a setup time assigned to it.

Setup Time.

Figure 2. Setup Time.

Cost per Hour

The cost per hour is the work center cost fields. The value of the cost per hour is determined by the cost fields on the work center. These fields are the:

  • Direct Unit Cost
  • Indirect Cost %
  • Overhead Rate

Work Center card with work center cost fields highlighted.

Figure 3. Work Center card with work center cost fields highlighted.

These fields are totaled in the Unit Cost field. The Unit Cost field is the Cost per Hour (whatever the scheduling unit of measure value is).

Normal Production Run Quantity

The setup cost for a production run must be broken into a cost per unit. This means there must be an assumed quantity that is being produced so that a setup cost can be calculated for each unit produced. This assumed run quantity is stored in the Lot Size field of the item card.

Item Card with Lot Size field highlighted.

Figure 4: Item Card with Lot Size field highlighted.

To set this value correctly, you will need to study your production run sizes and establish your “Standard Cost Lot Size” for each item. Once established, you would store this value on the NAV Item Card. NAV will then divide this quantity into the Setup Time for each operation to calculate the setup time per item. The per-unit Setup Time costs would then be added to the run time costs to calculate the total labor cost for the operation.

If you study the Detailed Calculation Report for the above item, you will see how the Lot Size is used to calculate Setup Costs per item.

Detailed Calculation report.

Figure 5. Detailed Calculation report.

Summary

Including setup costs in Standard Costing can be tricky and generate variances on an order by order basis. Including setup time in your direct costs makes sense if your production run size for that item is consistent from order to order.

If your run sizes vary, then it may make more sense to treat setup as an overhead expense and build it into the Overhead Rate associated with the work center.

If you have any questions about this or other processes, contact ArcherPoint.

For more step-by-step instructions on how to perform specific tasks in Microsoft Dynamics NAV, see our collection of How-To blogs.

Other blogs on this topic include:

Rolling Up Standard Costs in Microsoft Dynamics NAV
ArcherPoint’s costing experts show how to use the Standard Cost Worksheet in Microsoft Dynamics NAV as a more reliable method to roll up Standard Costs.

Determine Actual FIFO or LIFO Value of Inventory Using Standard Cost
This blog discusses how to determine actual FIFO or LIFO value of inventory using Standard Cost in Microsoft Dynamics NAV.

Purchases and Direct Cost Applied Accounts in Microsoft Dynamics
This blog discusses Purchases and Direct Cost Applied Accounts and how they are used in Microsoft Dynamics NAV 2013.

Which Dynamics NAV Costing Method Should Manufacturers Choose?
Read about the various costing methods available in Microsoft Dynamics NAV with a special focus on manufacturing.

Blog Tags: 
Original page

Testing display of HTML elements

This is 2nd level heading

This is a test paragraph.

This is 3rd level heading

This is a test paragraph.

This is 4th level heading

This is a test paragraph.

This is 5th level heading

This is a test paragraph.

This is 6th level heading

This is a test paragraph.

Basic block level elements

This is a normal paragraph (p element). To add some length to it, let us mention that this page was primarily written for testing the effect of user style sheets. You can use it for various other purposes as well, like just checking how your browser displays various HTML elements by default. It can also be useful when testing conversions from HTML format to other formats, since some elements can go wrong then.

This is another paragraph. I think it needs to be added that the set of elements tested is not exhaustive in any sense. I have selected those elements for which it can make sense to write user style sheet rules, in my opionion.

This is a div element. Authors may use such elements instead of paragraph markup for various reasons. (End of div.)

This is a block quotation containing a single paragraph. Well, not quite, since this is not really quoted text, but I hope you understand the point. After all, this page does not use HTML markup very normally anyway.

The following contains address information about the author, in an address element.

Jukka Korpela, jkorpela@cs.tut.fi
Päivänsäteenkuja 4 A, Espoo, Finland

Lists

This is a paragraph before an unnumbered list (ul). Note that the spacing between a paragraph and a list before or after that is hard to tune in a user style sheet. You can't guess which paragraphs are logically related to a list, e.g. as a "list header".

  • One.
  • Two.
  • Three. Well, probably this list item should be longer. Note that for short items lists look better if they are compactly presented, whereas for long items, it would be better to have more vertical spacing between items.
  • Four. This is the last item in this list. Let us terminate the list now without making any more fuss about it.

The following is a menu list:

  • One.
  • Two.
  • Three. Well, probably this list item should be longer so that it will probably wrap to the next line in rendering.
  • The following is a dir list:

  • One.
  • Two.
  • Three. Well, probably this list item should be longer so that it will probably wrap to the next line in rendering.
  • This is a paragraph before a numbered list (ol). Note that the spacing between a paragraph and a list before or after that is hard to tune in a user style sheet. You can't guess which paragraphs are logically related to a list, e.g. as a "list header".

    1. One.
    2. Two.
    3. Three. Well, probably this list item should be longer. Note that if items are short, lists look better if they are compactly presented, whereas for long items, it would be better to have more vertical spacing between items.
    4. Four. This is the last item in this list. Let us terminate the list now without making any more fuss about it.

    This is a paragraph before a definition list (dl). In principle, such a list should consist of terms and associated definitions. But many authors use dl elements for fancy "layout" things. Usually the effect is not too bad, if you design user style sheet rules for dl which are suitable for real definition lists.

    recursion
    see recursion
    recursion, indirect
    see indirect recursion
    indirect recursion
    see recursion, indirect
    term
    a word or other expression taken into specific use in a well-defined meaning, which is often defined rather rigorously, even formally, and may differ quite a lot from an everyday meaning

    Text-level markup

    • CSS (an abbreviation; abbr markup used)
    • radar (an acronym; acronym markup used)
    • bolded (b markup used - just bolding with unspecified semantics)
    • big thing (big markup used)
    • large size (font size=6 markup used)
    • Courier font (font face=Courier markup used)
    • red text (font color=red markup used)
    • Origin of Species (a book title; cite markup used)
    • a[i] = b[i] + c[i); (computer code; code markup used)
    • here we have some deleted text (del markup used)
    • an octet is an entity consisting of eight bits (dfn markup used for the term being defined)
    • this is very simple (em markup used for emphasizing a word)
    • Homo sapiens (should appear in italics; i markup used)
    • here we have some inserted text (ins markup used)
    • type yes when prompted for an answer (kbd markup used for text indicating keyboard input)
    • Hello! (q markup used for quotation)
    • He said: She said Hello! (a quotation inside a quotation)
    • you may get the message Core dumped at times (samp markup used for sample output)
    • this is not that important (small markup used)
    • overstruck (strike markup used; note: s is a nonstandard synonym for strike)
    • this is highlighted text (strong markup used)
    • In order to test how subscripts and superscripts (sub and sup markup) work inside running text, we need some dummy text around constructs like x1 and H2O (where subscripts occur). So here is some fill so that you will (hopefully) see whether and how badly the subscripts and superscripts mess up vertical spacing between lines. Now superscripts: Mlle, 1st, and then some mathematical notations: ex, sin2 x, and some nested superscripts (exponents) too: ex2 and f(x)g(x)a+b+c (where 2 and a+b+c should appear as exponents of exponents).
    • text in monospace font (tt markup used)
    • underlined text (u markup used)
    • the command cat filename displays the file specified by the filename (var markup used to indicate a word as a variable).

    Some of the elements tested above are typically displayed in a monospace font, often using the same presentation for all of them. This tests whether that is the case on your browser:

    • This is sample text inside code markup
    • This is sample text inside kbd markup
    • This is sample text inside samp markup
    • This is sample text inside tt markup

    Links

    This is a text paragraph that contains some inline links. Generally, inline links (as opposite to e.g. links lists) are problematic from the usability perspective, but they may have use as “incidental”, less relevant links. See the document Links Want To Be Links.

    Forms

    This is a form containing various fields (with some initial values (defaults) set, so that you can see how input text looks like without actually typing it):

    The following two radio buttons are inside a fieldset element with a legend:
    Legend
    Check those that apply

    Tables

    The following table has a caption. The first row and the first column contain table header cells (th elements) only; other cells are data cells (td elements), with align="right" attributes:

    Sample table: Areas of the Nordic countries, in sq km
    Country Total area Land area
    Denmark 43,070 42,370
    Finland 337,030 305,470
    Iceland 103,000 100,250
    Norway 324,220 307,860
    Sweden 449,964 410,928

    Character test

    The following table has some sample characters with annotations. If the browser’s default font does not contain all of them, they may get displayed using backup fonts. This may cause stylistic differences, but it should not prevent the characters from being displayed at all.

    Char. Explanation Notes
    ê e with circumflex Latin 1 character, should be ok
    em dash Windows Latin 1 character, should be ok, too
    Ā A with macron (line above) Latin Extended-A character, not present in all fonts
    Ω capital omega A Greek letter
    minus sign Unicode minus
    diameter sign relatively rare in fonts

    Hyphenation

    In the following, a width setting should cause some hyphenation, depending on support to various methods of hyphenation.

    CSS-based hyphenation

    Until recently the great majority of naturalists believed that species were immutable productions, and had been separately created. This view has been ably maintained by many authors.

    JavaScript-driven hyphenation

    Until recently the great majority of naturalists believed that species were immutable productions, and had been separately created. This view has been ably maintained by many authors.

    Explicit hyphenation hints (soft hyphens)

    Un­til re­cent­ly the great ma­jor­i­ty of nat­u­ral­ists be­lieved that spe­cies were im­mu­ta­ble pro­duc­tions, and had been sep­a­rate­ly cre­at­ed. This view has been ably main­tain­ed by many au­thors.

    Please wait...
    We need a little bit more time.