Microsoft Dynamics GP 2016 Feature of the Day – Automatically Batch Deposit Cash Receipts

Enjoy your Microsoft Dynamics GP 2016 Feature of the Day!

 Automatically Batch Deposit Cash Receipts

GP 2016

Are you a Tridea client interested in installing Microsoft Dynamics GP 2016?

Contact us first!  Tridea Partners 858.755.3700 or info@trideapartners.com

By Tridea Partners, Microsoft Dynamics Partner www.trideapartners.com

Read original post at: http://community.dynamics.com/gp/b/gpteamblog/default.aspx

Microsoft Dynamics GP 2016 Feature of the Day – Support Named User Pricing

Enjoy your Microsoft Dynamics GP 2016 Feature of the Day!

 Support Named User Pricing

Dynamics GP 2016

Feature of the Day Program

In addition to educating everyone on new features, the Feature of the Day is also meant to evangelize the tremendous features and functionality available in the Microsoft Dynamics GP product. 

Microsoft Cloud Backup

Organizations and companies are increasingly using Microsoft Azure Backup to protect physical or virtual machines and data including SQL, Exchange and SharePoint. Traditional tape backups are costly and unreliable, while disk backup solutions have become more affordable and reliable.

You can choose to store backups on a local redundant storage or Geo-redundant storage. Local redundant stores –  3 copies of the backup data within a single facility. Geo-Redundant stores –  6 copies of backups, 3 local and 3 backups in a secondary region. A well planned backup strategy requires careful design, planning, execution and testing to reduce data lost and downtime. Two important elements of a continuity plan are the RPO (Recovery Point Objective – Time between each backup) and RTO (Recovery Time Objective – How long will it take to recover the data).

No additional cost for restore operations or network bandwidth. Data backups are compressed and encrypted to improve faster restore times. Backups are deployed and managed from the Microsoft Azure Portal with several capabilities including monitoring and scheduling.

Other backup solution including Backup Exec, Acronis, Veeam, Dura, EMC, Netback and Yosemite to name a few are available with a variety of options and features.

This article was written by Osei Owusu, Technical Consultant for  Tridea Partners. Tridea is a leading Microsoft Dynamics provider. www.trideapartners.com

Dynamics AX 2012: Understanding the Swings in the Running Average Cost Calculation

Everyone using Dynamics AX for inventory should be familiar with the concepts of physical inventory and financial inventory, as well as physical costs and financial costs. When receiving an item against a purchase order or when reporting an item as finished on a production order, the physical quantity is incremented using a physical cost that is understood to be based on incomplete information. Only when invoice matching has been performed against the purchase order can we be assured of having all the necessary information (price revisions, taxes, handling fees, etc.) to replace the original “placeholder” physical cost with the “true” financial cost. In the case of production orders, we need to wait until the production order is “ended” (when no more transactions can be recorded against it) to finally assign the financial cost.

In a similar fashion, when consuming an inventory item (for example on a sales order packing slip or a production order picking ticket), AX assigns a temporary physical cost that will ultimately be replaced with a financial cost that is based on the inventory valuation method selected for the item (FIFO, weighted average, etc.). The physical cost gets replaced by the financial cost only when the transaction is finalized (the ending of the production order or the invoicing of the sales order). Regardless of the inventory valuation method assigned to an item, the physical cost assigned when consuming inventory is always computed using a simple running average. Assuming that the “include physical” checkbox is selected on the Item Model Group, the running average is computed using the following formula: Running Cost Average = (physical amount + financial amount) / (physical quantity + financial quantity).

Many clients are surprised to find that the running average cost of any item can vary significantly from the actual cost of an item, often by much greater amounts than the wildest swings in purchase prices. The explanation is simple, as illustrated by the below example:

  1. Purchase 10 widgets @ $10 each for a total of $100
    • $10 cost is derived from the purchase order and is a physical cost
    • Running Cost Average = (physical amount + financial amount) / (physical quantity + financial quantity).
    • Running average calculation = ($100 + $0) / (10 + 0) = $10
  2. Issue 5 widgets to production pick ticket @ $10 each
    • Use running average calculation from above step as a starting point: ($100 + $0) / (10 + 0) = $10
      • Subtract $50 from physical amount and 5 from physical quantity
    • New running average calculation = ($50 + $0) / (5 + 0) = $10
  3. Obtain invoice for widgets – including fees, cost is now $11 each for a total of $110
    • Use running average calculation from above step as a starting point: ($50 + $0) / (5 + 0) = $10
      • Subtract $100 from the physical amount and 10 from the physical quantity; the quantity initially received is no longer a physical quantity, as it has now been invoiced.
      • Add $110 to financial amount and 10 to financial quantity (per the invoice)
    • New running average calculation = (-$50 + 110) / (-5 + 10) = $12
  4. The system has calculated a running average cost of $12, even though the only purchase price was for $11.

The reason for this is that we understated the value of the 5 widgets issued to production prior to obtaining the invoice that informed us of the true $11 cost per widget. We brought the 10 widgets in at $110, and issued out 5 of them at $50, so we now have to spread the remaining $60 over the 5 that are still in stock. So the undervaluation of the quantity issued to the production order is offset by the overvaluation of the quantity still in inventory. AX will eventually rectify this only when the production order that consumed that quantity of 5 has been “ended” and the correct financial cost of $11 can be assigned to the quantity consumed. This is because AX does not make adjustments to physical cost transactions, but rather leaves the initial physical cost amount intact until it can be replaced by a financial cost amount.

So, once the production order is ended, the new running average calculation will yield a result of $11, using the following logic:

    • Use running average calculation from above step as a starting point: (-$50 + 110) / (-5 + 10) = $12
      • Add back the -$50 physical amount and physical quantity of -5 (the quantity initially issued as a physical transaction is now issued as a financial transaction)
      • Subtract $55 from the financial amount and 5 from the financial quantity (the picklist transaction is now a financial transaction)
      • New running average calculation = ($0 + $55) / (0 + 5) = $11

It is important to point out that AX will ultimately always assign the correct financial cost to each transaction. We just have to recognize that until we can feed the system with all of the necessary data to produce true financial costs, our financials will necessarily reflect these “estimated” costs.

This article was written by Matthew Boese, Partner at Tridea Partners, a Gold Certified Microsoft Dynamics Partner.

 

 

 

 

Microsoft Dynamics GP 2016 Feature of the Day – Workflow Reassignment Notifications

Enjoy your Microsoft Dynamics GP 2016 Feature of the Day!

Workflow Reassignment Notifications

Dynamics GP 2016

Feature of the Day Program

In addition to educating everyone on new features, the Feature of the Day is also meant to evangelize the tremendous features and functionality available in the Microsoft Dynamics GP product.