@QuickBooksCA Online - When your fleet's on the street - Field Service keeps things neat!

Announcing Intuit Field Service Management for...

The Inventory Management area of Dynamics AX allows you to track all of the inventory within your warehouses, manage all of the movements and inventory adjustments and also set the inventory policies for costing. This is also the foundation for the other modules like Procurement & Sourcing and Sales Order Management because it gives you something to receive into and also ship from which is useful to track.

In this guide we will step you through the setup of all of the basic configuration that is needed in order to get your sites and warehouses configures, show you how to tweak your products so that they can be used within the warehousing structures, how to perform common inventory transactions like cycle counts and also how to configure batch controlled and serialized items.

To help you all, I have published book #8 in the Bare Bones Configuration Guide series that lays the foundation for Configuring Inventory Management Within Dynamics AX 2012. The book covers all of these areas related to Inventory Management:

• Configuring Inventory Management Controls
  
• Configuring Inventory Structures
  
• Configuring Products for Inventory Management
  
• Configuring Inventory Counting
  
• Configuring Batched and Serialized Products
  

If you want to get a printed copy of the book, or if you want an easy way to download a PDF copy then you can now get it from Blind Squirrel Publishing. As a bonus, you will still get 20% discount off the standard list price since it’s still the sites birth month. Catch the discounts while you can, because squirrels are incredibly frugal and hate giving discounts. To find the book on the site just follow this link and it will take you directly to the book details.

If you want more resources for this book then you can check it out on the Dynamics AX Companions website by clicking on the following link: http://www.dynamicsaxcompanions.com/Bare-Bones-Configuration-Guides/Configuring-Inventory-Management We will be posting additional follow up material here for the Premium Subscribers.

PS. Next on the list is Book #10 Configuring Procurement & Sourcing Within Dynamics AX 2012 – it should be available next month,

You’re sitting in a meeting and someone uses a word that you do not know the meaning of. Or you walk into the office and your coworker shouts “How about that game last night! What did you think of the last play?” What do you do? “Google it,”of course.

We now live in a world where we have access to answers and information in a matter of seconds. We don’t even have to type it anymore, in some cases we can verbally speak to our phone and it will spout off the answer.

This same methodology is used when researching business solution tools. Let’s say you are working at a wholesale distribution or manufacturing B2B company. You love your job but you are starting to wonder about the potential of selling your products online. How would that change your workday? More importantly, how would that change your bottom line?

So, you Google “e-commerce”. Boom, 360 million results. Your head is spinning. You try to read through some of the pages, but the topic is so broad you really don’t get the specific wholesale distribution or manufacturing answers you were looking for. Why? Because B2B e-commerce is totally different than B2C/retail e-commerce.

At Sana Commerce, we believe that your ERP system should be the foundation of your B2B e-commerce sales portal for three core reasons; pricing complexity, ordering conditions and order history.

Pricing Complexity

B2B businesses typically have very complex pricing structures. In our experience, most businesses have negotiated pricing with individual customers, resulting in discounts per product, or per product group. Combine thousands of products with thousands of customers and it results in a very large and intricate pricing matrix.

Not to mention all the order discounts, order line discounts, tier pricing and possible promotions. Are you keeping up?

The role of the ERP
Luckily for you, pricing complexity and details are typically handled by an ERP system. That is what these systems are designed for. Take advantage of the investment you already made and leverage the power of your ERP when you are setting up your B2B sales portal.

My advice: Do not replicate this complex pricing matrix in your web store. Do not redo all the calculations there that are being done in your ERP already. Choose an e-commerce solution that integrates with your ERP system and uses your ERP system for its strength; the calculation of complex orders. Your customers will be very pleased to see that they get the exact same price calculations online as they would when ordering by phone, or e-mail with you.

Ordering Conditions

Can a certain (B2B) customer buy on an account? If yes, up to what amount? What are the shipping conditions related to the shipping address of this customer? What is the expected delivery time based on his shipping address and shipping method? What are the specific ordering conditions for this customer?

The role of the ERP
Again, the ERP stores all this information including complex business rules. By making the ERP system the foundation of your B2B web store, you will benefit from the systems that you’ve already invested in without having to rebuild the functionality. You can show all customer-specific ordering conditions to the customer depending on the details of the order in real-time. All ordering conditions will be shown in your web store by using an out of the box solution with no need for customizations. This e-commerce solution will truly empower your customers. They will be able to see exactly what they can expect from you regarding their order, such as payment terms, delivery time, delivery costs, etc.

Order History

Businesses tend to place orders with their suppliers on a regular basis. In many cases, these orders contain the same products, which are continuously replenished. That makes the order history a far more important piece of information for businesses, compared to consumers, because this overview allows them to easily look up what they ordered last time or simply complete a reorder based on a previous order.

The role of the ERP
The order history of “offline orders” is always stored in the ERP system and we always suggest giving customers full visibility of past orders placed. If you setup your integrated ERP B2B e-commerce, all orders placed offline as well as online will be shown in your online sales portal, without any extra work or synchronization of databases. Combine this with “reorder functionality” and you will have a solution your customers will love.

All three ERP foundation points really boil down to one word, “efficiency.” Efficiency of your B2B e-commerce set-up process, efficiency for your sales team to focus on gaining new business instead of being bogged down with repeat orders, and efficiency for your customers who are looking to routinely place repeat orders.

In terms of Google, narrow down your results by searching “e-commerce” plus the name of your ERP system for a more targeted list of solutions. For example “Navision webshop” or “e-commerce Microsoft Dynamics.”

Happy Googling.

Michiel Schipperus is CEO of Sana Commerce. Sana is a B2B specialist and delivers a fully integrated e-commerce solution for Microsoft Dynamics AX and NAV.

You’re sitting in a meeting and someone uses a word that you do not know the meaning of. Or you walk into the office and your coworker shouts “How about that game last night! What did you think of the last play?” What do you do? “Google it,”of course.

We now live in a world where we have access to answers and information in a matter of seconds. We don’t even have to type it anymore, in some cases we can verbally speak to our phone and it will spout off the answer.

This same methodology is used when researching business solution tools. Let’s say you are working at a wholesale distribution or manufacturing B2B company. You love your job but you are starting to wonder about the potential of selling your products online. How would that change your workday? More importantly, how would that change your bottom line?

So, you Google “e-commerce”. Boom, 360 million results. Your head is spinning. You try to read through some of the pages, but the topic is so broad you really don’t get the specific wholesale distribution or manufacturing answers you were looking for. Why? Because B2B e-commerce is totally different than B2C/retail e-commerce.

At Sana Commerce we believe that your ERP system should be the foundation of your B2B e-commerce sales portal for three core reasons; pricing complexity, ordering conditions and order history.

Pricing Complexity

B2B businesses typically have very complex pricing structures. In our experience, most businesses have negotiated pricing with individual customers, resulting in discounts per product, or per product group. Combine thousands of products with thousands of customers and it results in a very large and intricate pricing matrix.

Not to mention all the order discounts, order line discounts, tier pricing and possible promotions. Are you keeping up?

The role of the ERP
Luckily for you, pricing complexity and details are typically handled by an ERP system. That is what these systems are designed for. Take advantage of the investment you already made and leverage the power of your ERP when you are setting up your B2B sales portal.

My advice: Do not replicate this complex pricing matrix in your web store. Do not redo all the calculations there that are being done in your ERP already. Choose an e-commerce solution that integrates with your ERP system and uses your ERP system for its strength; the calculation of complex orders. Your customers will be very pleased to see that they get the exact same price calculations online as they would when ordering by phone, or e-mail with you.

Ordering Conditions

Can a certain (B2B) customer buy on an account? If yes, up to what amount? What are the shipping conditions related to the shipping address of this customer? What is the expected delivery time based on his shipping address and shipping method? What are the specific ordering conditions for this customer?

The role of the ERP
Again, the ERP stores all this information including complex business rules. By making the ERP system the foundation of your B2B web store, you will benefit from the systems that you’ve already invested in without having to rebuild the functionality. You can show all customer-specific ordering conditions to the customer depending on the details of the order in real-time. All ordering conditions will be shown in your web store by using an out of the box solution with no need for customizations. This e-commerce solution will truly empower your customers. They will be able to see exactly what they can expect from you regarding their order, such as payment terms, delivery time, delivery costs, etc.

Order History

Businesses tend to place orders with their suppliers on a regular basis. In many cases, these orders contain the same products, which are continuously replenished. That makes the order history a far more important piece of information for businesses, compared to consumers, because this overview allows them to easily look up what they ordered last time or simply complete a reorder based on a previous order.

The role of the ERP
The order history of “offline orders” is always stored in the ERP system and we always suggest giving customers full visibility of past orders placed. If you setup your integrated ERP B2B e-commerce, all orders placed offline as well as online will be shown in your online sales portal, without any extra work or synchronization of databases. Combine this with “reorder functionality” and you will have a solution your customers will love.

All three ERP foundation points really boil down to one word, “efficiency.” Efficiency of your B2B e-commerce set-up process, efficiency for your sales team to focus on gaining new business instead of being bogged down with repeat orders, and efficiency for your customers who are looking to routinely place repeat orders.

In terms of Google, narrow down your results by searching “e-commerce” plus the name of your ERP system for a more targeted list of solutions. For example “e-commerce SAP” or “e-commerce Microsoft Dynamics.”

Happy Googling.

Michiel Schipperus is CEO of Sana Commerce. Sana is a B2B specialist and delivers a fully integrated and certified (CfMD) e-commerce solution for Microsoft Dynamics AX and NAV.

Dynamics Ax 7 is now at door step. But still there are many things to explore Dynamics AX 2012.   Here I started again from basics from Dynamics Ax 2012 architecture.

Dynamics Ax 2012 is based on  Three tier Architecture consists of

1. Database tier.
2. Application tier
3. Presentation tier.

Database tier:

If you saw standard Dynamics Ax databases with default installation you found. Three databases

MicrosoftDynamicsAX:

This database contains the data used in Dynamics Ax. AOS used this database for transaction.

MicrosoftDynamicsAX_model:

Meta data for forms, tables, and all other code are stored in model_store exists in MicrosoftDynamicsAX_model database. It contains the all application element data inside Microsoft Dynamics Ax.

MicrosoftDynamicsAXBaseline:

This baseline database stores the model store that is used to upgrade X++ code to Microsoft Dynamics AX 2012. The Baseline database is used to analyze application updates before they are applied.

It stored the old model store before applying the upgrade.

There more databases are installed which has no direct link Microsoft Dynamics Ax 2012. These are

SSRS database, Sql server analysis server database and if you installed the Interpise portal then data bases required for Share point also include installed.

Application Tier.

In Dynamics Ax 2012 AOS, Reporting server extensions, enterprise portal, Workflow, Application Interface Framework all consider to be application tier,

AOS Application object server.

AOS is responsible for communication between Client and Database. Services also deployed on AOS so external application can communicate with AOS. Dynamics Ax 2012. Application business logic resides at AOS.

Enterprise portal.

Enterprise portal is asp.net and share point porta also consider to be at application tier. SSRS reports, dashboards and other websites are hosted on IIS.

Workflow. Also consider to be application tier. These allow to user to create and automate some workflow activities.

Reporting and analytical services.  Reporting using SSRS and Analytical services used in Dynamics Ax 2012 also part of application Tier.

Application integration framework.

Services and integration framework that is used to communicate external and internal system is also part of Application tier.

Presentation Tier.

Microsoft Dynamics Ax 2012 client, Enterprise portal and external application that communicate with Dynamics Ax all are consider to be Presentation tier.

Reference : https://technet.microsoft.com/en-us/library/dd362112.aspx

Project employee expense report

• Project Employee Expense Report and Project Timesheet Entry replace all of the functionality of both Business Portal T&E and PDK.

Employee profile

• Employee able to view and edit their employment information
• Address, dependents, emergency contacts and position history

Employee profile workflow

• Workflow available for Employee Profile information
• Set up workflow for your business process
• Route using Active Directory hierarchy

Manager team profile

• Manager able to view and edit their team members’ data
• Address, dependents, emergency contacts and position history

Employee skills and training

• Part of self service for employee to view and maintain their education and tests
• Employee can view skills and training history

Employee skills workflow

• Workflow available for Employee Skills (for education and tests)
• Set up workflow for your business process
• Route using Active Directory hierarchy

Manager skills and training

• Part of self service for manager to view and maintain their employee’s education and tests
• Manager can view employee’s skills and training history
• Driven from navigation lists

Employee benefits

• Employee can view their benefits with employer and employee contributions

Employee paystubs

• In self service, an employee can now view or print their paystubs from the paystubs navigation list

Employee W-4

• An employee can edit their W4 information, add or change the additional withholding, update the number of deductions and reduce the potential for data entry errors
• With workflow, the payroll administrator can route the W4 information appropriately
• Set up employee W4 workflow for your business process
• Route using Active Directory hierarchy

Employee Direct Deposit

• An employee can edit their deposit information, add accounts or change the distribution reducing the potential for data entry errors
• With workflow, the payroll administrator can route the deposit information appropriately
• Workflow available for Employee Direct Deposit
• Set up workflow for your business process
• Route using Active Directory hierarchy

HRP Pending Approval Nav List

• Navigation list for HRP Workflow Approvers
• Displays all workflow tasks assigned to a user across the HRP Workflows
• Can complete workflow actions across active workflows

Hope this helps!!!

Issue Introduction

Workarounds

#Create Separated Files

Result

In this week's Microsoft Dynamics partner news roundup:

• Mozu, eBridge Connections Partner on ERP Integration for Ecommerce;
• InDemand Interpreting Taps The Resource Group to Implement Dynamics GP;
• MTC Announces UK Office and Regional Manager;
• Shift4 Supports Retail Realm Essentials powered by Dynamics AX

Mozu, eBridge Connections Partner on ERP Integration for ECommerce

Mozu, the cloud commerce platform built by Volusion, is teaming up with eBridge Connections, a provider of accounting and ERP integration solutions for eCommerce. The partnership is aimed at further simplifying and supporting the needs of Mozu's customers ...

read more

Being able to handle consignment inventory in Microsoft Dynamics NAV is a common requirement. There are four scenarios of consignment inventory that I frequently bump into;

1. Inventory at a Customer

2. Inventory at a Vendor

3. Customer Owned Inventory

4. Vendor Owned Inventory

Some may argue that case 2 and 3 is not consignment, and they might be right, but nevertheless they are cases that needs to be handled and to me the overall concept is closely related to consignment inventory and therefor I included them here. Case 2 and 3 are typically found in relation to subcontracting or product repairs. Case 1 and 4 are the classic examples of Vendor Managed Inventory (VMI).

Here is how it can be handled in Dynamics NAV using the standard functionality;

1. Inventory at a Customer

Inventory at a customer can be handled by creating a location that represent the customer and replenish it using transfer orders. You then invoice from the customer location based on what they used.

What I recommend is to create locations using the same codes as the customer numbers, the location ‘C-10000’ is created for customer ‘C-10000’ for example (I prefer to have prefix for master data codes and not just numbers like it Cronus). The location should have the same name, address, etc. and typically does not require bins or any type of warehouse transactions.

You can then define the inventory posting setup for the customer location(s) to point to a specific consignment inventory account in the balance sheet. This way it is separated from an accounting point of view as well.

When the customer asks you to replenish the inventory you just create a transfer order to transfer the items to the customer.

The transfer order has the advantage that you can process the shipments the same way as you process regular sales order shipments (see processing of shipments) and you get packing slip etc. printed from Dynamics NAV.

You also have the option to create a SKU for the items at the customer locations and through the planning parameters and MRP get suggestions of what to transfer. This could be useful if you have an agreement with the customer to keep the stock at a certain level. Don’t forget to setup the transfer routes if you want to do this.

In your balance sheet you now see the inventory you have at customers separated on a different account.

When the customer communicates that they have used some of your inventory you just create a sales invoice with the items at the customer’s location and post it. This depletes the inventory at the customer, creates the COGS, revenue and the AR. The alternative to a sales invoice would be to create a sales order that is shipped and invoiced; the end result will be the same.

This way of handling consignment inventory at a customer location is straight forward and works well.

2. Inventory at the Vendor

Similar to how you would handle inventory at a customer you can also have your inventory at a vendor. This is typically for subcontracting processes where a vendor performs operations on your parts (see subcontracting posts).

You create a location for the vendor, preferably with the same code as the vendor number and the same address. Just like with the customer in the previous example.

You also have the option to define the inventory posting setup to separate the inventory at vendors on a separate inventory account in the balance sheet. This time it might be raw material that you have at the vendor (and not finished goods like in the case of the customer). If it is for subcontracting where the vendor is going to consume your inventory then you also need to setup a WIP account, the WIP account is by NAV determined using the location where the components are consumed in combination with the inventory posting group of the item being produced (see production order posting into general ledger for more information).

I am a big fan of doing the posting setups as needed in Dynamics NAV, so if you never going to have finished goods at a vendor then don’t do the setup for this account. This way you also control what transactions that are possible. I know consultants that by default sets up all different combinations and populates all the accounts in the setup matrixes, I think that approach makes the setup more confusing than necessary.

You then replenish the inventory at the vendor using transfer orders and you can get packing slips, etc. (the same way as with the customer example).

The inventory value in the balance sheet has now moved to the inventory at vendors account.

When the vendor informs you that they have used any of the inventories you consume it against the production order (in case of subcontracting). The inventory at the vendor location is then credited and WIP is debited.

3. Customer Owned Inventory

If you handle inventory that is owned by the customer then you want to make sure there is no inventory value associated with the items. You do this by checking the inventory value zero field on the item card (a field that needs to be added to the page).

If it is an item that you initially sold to the customer that is going back to be repaired then a good option is to create a new item with the same item number plus a prefix (like ‘-C’ in the end). No need to setup separate g/l accounts or posting groups.

You can then handle the inventory just like any other inventory on your regular location(s), which is typically what you want. The receiving part can be done based on sales return orders, this way you have a process to do the receiving and you have a record for the receipt (the sales return receipt).

The only thing to make sure is that the sales return order is for a zero amount (if the customer is not going to get a credit that is) and that it gets closed by being invoiced.

If the customers inventory is used as a component in a production process (like performing subcontracting or repairs) then the value of the finished product will be the value of the components that where used from your regular inventory (if any) plus the capacity costs (labor and overhead) you added to the production process.

4. Vendor Owned Inventory

If you have inventory that belongs to vendors then the main thing is to setup posting groups that allows you to separate the inventory value that belongs to vendors from your own inventory. You do normally want the inventory costs on the items to be maintained since you are going to pay for it when you use it. If you are on a standard costing method you want the standard costs of your manufactured items to include the cost of the vendor owned items and if you are on a FIFO costing method you want the cost of your products to include the costs of the vendor owned items once they have been produced (since you pay for them).

From an operational point of view you want to be able to receive the inventory, move it around, count it, and use it just like it was your own inventory.

The way to handle this is to create separate posting groups, you need both a separate inventory posting group and a separate general product posting group. In this case I call them both ‘CONSIGN’.

The inventory posting setup is then defined to have the expected inventory value on a separate consignment inventory account in the balance sheet.

In the general posting setup you define the inventory accrual accounts to go to a separate account next to the expected inventory account in the balance sheet. The direct cost applied can be the same as the regular direct cost applied account in the P&L.

Now you have separate accounts in the balance sheet where you will have transactions when you receive the vendor owned inventory which net each other out. Note that some would prefer to use liability accounts (instead of an asset accounts) for this, I prefer having it together with the rest of the inventory like below, both ways work.

When you do get the invoice from the vendor those transactions will be reversed and the in inventory will be posted against the regular inventory accounts.

Here is how it would work;

The item is setup with the consignment posting groups. In this case I use the standard costing method and the cost of the item is $10.

I establish a purchase order with the vendor that would cover a period of time (almost like a blanket purchase order). The vendor sends you inventory and you receive it just like you would receive any other inventory against the purchase. The transactions you get in the general ledger will be as below after receiving 100 pcs @ $10.

The offset account makes sure that you don’t inflate your inventory value with something that is owned by a vendor. The inventory sub ledger will still show that you have 100 pcs in inventory and when you run your inventory valuation report you could exclude the items with the ‘CONSIGN’ posting groups.

You can then move then inventory around and use it as you normally would do. When consumed it creates WIP as regular inventory would, and if sold it creates COGS as regular inventory would. This is ok, and something you want since you are now going to pay for what you have used.

Below is the result of consuming 40 pcs of the vendor inventory against a production order. The vendor consignment inventory account is credited and WIP is debited.

The inventory used is communicated to the vendor who sends you an invoice. The purchase invoice is posted just like a regular purchase invoice (in this case I use the ‘get receipt lines’ function to retrieve the oldest receipt and invoice it (I want the oldest one since that is the item ledger entry that has been consumed or sold, the exception to this might be if the inventory is serial or lot number tracked, then you need to invoice the receipt that is related to the serial or lot number that was used). Note that you only want to invoice what you have used and not what has been received. In our case 40 pcs out of the 100 pcs received.

Invoicing the receipt debits the vendor consignment offset account and credits accounts payable. In case of standard cost you might also get a purchase price variance posted into the P&L. The inventory value for the vendor’s inventory is now netted to zero again.

Note that the above examples uses the expected cost postings, which is something I think everybody should use (at least if you are in a manufacturing environment).

This was all I could think of in relation to consignment inventory.

Make sure to visit the new Dynamics NAV FAQ section on my blog.