tag:blogger.com,1999:blog-23345268449686744382024-03-05T08:26:13.225-08:00Dynamics for DistributionA blog dedicated to the wholesale distribution industry with an emphasis on using Dynamics GP to improve distribution business processes.Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-2334526844968674438.post-11727533953345024522011-01-05T18:39:00.000-08:002011-01-06T16:17:19.304-08:00Psychic InventoryThe <a href="http://en.wikipedia.org/wiki/Carrying_cost">Wikipedia </a>article on carrying cost includes an interesting concept called "psychic stock." While we are all familiar with reorder points and safety stock, psychic stock may be a new concept. In retail, this is best demonstrated by the process of fronting shelves. For those of us who had grocery store jobs in our high school or college past, there are terrible memories of sliding items to the front of the shelf to make the shelves appear full even if the next truck wasn't due for another 2 days.<br /><br />So how does this apply to wholesale distribution and GP?<br /><br />One of the worst things you can tell a customer is that you are out of stock of an A item they want to order. Wouldn't it be nice if you could provide your customer service reps the ability to see into the future and determine if the item a customer is requesting will be available even if the current inventory is zero? To accomplish this, Dynamics GP provides you with the Available to Promise or ATP functionality.<br /><br />Available to Promise looks at existing sales, purchase, and manufacturing orders and determines what will be available when your customer requests delivery. If your customer requests delivery a week from now and you have a PO due tomorrow, your customer service rep can easily see that quantities will be available.<br /><br />Now for the bad news: First, Available to Promise is only "available" for Advanced Management users. It is not included or available for Business Essentials. Second, the calculation is only as good as the dates on the documents. If you CSRs or your purchasing department accept the current default on documents, ATP will calculate based on those dates. Garbage in, garbage out.Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.com96tag:blogger.com,1999:blog-2334526844968674438.post-42597634496335197792010-10-20T05:55:00.000-07:002010-10-20T05:57:55.176-07:00Cross-Docking with GPCross-docking is the act of transferring goods directly from an incoming receipt to an outgoing order without putting the stock away. Obviously, cross-docking can improve your inventory turns, reduce material handling costs, and improve customer satisfaction through the quicker delivery of orders.<br /><br />So how can you cross-dock with Dynamics GP. The first step is to begin using the Backordered Items Received report. This report prints out when a purchasing receipt is posted and lists all the items on the receipt that are backordered on a sales order. This is a step in the right direction but the report has a couple issues:<br /><br />1. It only prints after the receipt is posted. Many companies do not post receipts until the goods are put away to keep the bin quantities accurate.<br />2. It is a paper report. Are your receiving people realistically going to print and review a paper report after they post the receipt?<br /><br />A more proactive approach can be implemented using the purchase order dates discussed in an earlier post. If you know the expected receipt date of an item, you can create a report or smartlist showing items expected in the next few days that are also backordered sales order items. This report or smartlist can be posted daily in the receiving department to alert personnel to cross-docking opportunities.<br /><br />As I final note, I would suggest that if you do not have some cross-docking opportunities, you are carrying too much inventory. You cannot afford to have everything your customers want in stock at all times. But that is another post…Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.com1tag:blogger.com,1999:blog-2334526844968674438.post-59970103509649803272010-10-05T05:04:00.001-07:002010-10-05T05:17:22.529-07:00Easy Expediting and Vendor Performance Management<span xmlns="">Expediting purchase orders and monitoring vendor performance are key to increasing inventory turns and improving your return on assets. Dynamics GP provides some easy to use, but often overlooked tools for monitoring expected and actual delivery dates.</span><span xmlns=""><br /><br /></span><span xmlns=""><br /><div><img style="TEXT-ALIGN: center; MARGIN: 0px auto 10px; WIDTH: 320px; DISPLAY: block; HEIGHT: 228px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5524533904884038850" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5UtsYLWzS3PwpDc8SxQZImu6mrqrsdsTnmcPyNSHo0EAYH0PVSHR31o5NXk__A5MelKqh9tWiy7z_2OvGC30KpxnWUhyphenhyphenw2GAd_7Dhaplj0xfRInqvtFh2-KqiTr5WYvtkgl6v2Zz284o/s320/POItem.jpg" /><br /><p></p><br /><p>Each line of a purchase order has a required date and two vendor promised dates. These dates default to the purchase order date but should be entered and maintained by the purchasing department. A standard smartlist is provided to show overdue purchase order lines. </p><br /><p><img style="TEXT-ALIGN: center; MARGIN: 0px auto 10px; WIDTH: 320px; DISPLAY: block; HEIGHT: 228px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5524533342632938498" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiScTsZ9tKs8OoGYatpvwL2E1D3XzYLl8SWggG6jCVMXSOokKk2KsLtFHWFRQxzWkdLFoskH5Sz_p3zOCdaGgO4nryYtJBPnTc_drI70tcAUnGG-XHhxK8HwsTQe2I_PhNelHhuXJguqN0/s320/smartlist.jpg" /><br />The system also records the first and last receipt date for each purchase order line. This allows you to report on a vendors historical performance by comparing the required and/or vendor promised dates to the receipt dates and calculating the number of times a vendor is late on delivery and the average lead time for each item.</span></p></div>Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.com0tag:blogger.com,1999:blog-2334526844968674438.post-14368017143346279272010-10-01T13:54:00.000-07:002010-10-01T17:26:58.730-07:00Dead Stock WalkingSo you went through all the trouble of identifying your dead stock, appointed someone to get rid of it, finally got it out of your warehouse and next week a replenishment order for the same dead stock shows up. Its hard to blame the purchasing people since they saw demand and wanted to make sure you were stocking the things that sell. What could you have done better?<br /><br />In Dynamics GP, there are two safeguards you can use to avoid replenishing dead stock. First, as soon as the item is identified as dead, change the inventory type to discontinued. This will prevent the item from being added to a purchase order and allow you to delete it at year end if desired.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgr9shisP5B1PrfRUgGgAaF_ijt7g5nq8qB03s8AIbc6p5K-xcL8Thuzk-aIRCbiCFqWMKGs2d59OsbVLWxSc_x8JeoS_uiIP-OEhSVQxSXfzcLHGr_WU86oCJKKwotoLXAqdATPxPZJl8/s1600/10-1-2010+4-53-45+PM.jpg"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 242px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgr9shisP5B1PrfRUgGgAaF_ijt7g5nq8qB03s8AIbc6p5K-xcL8Thuzk-aIRCbiCFqWMKGs2d59OsbVLWxSc_x8JeoS_uiIP-OEhSVQxSXfzcLHGr_WU86oCJKKwotoLXAqdATPxPZJl8/s320/10-1-2010+4-53-45+PM.jpg" alt="" id="BLOGGER_PHOTO_ID_5523185024735675138" border="0" /></a>Second, all dead stock sales should be on a separate document type in Sales Order Processing and the line items should have the exceptional demand box checked. This will allow you to easily identify these sales and remove them from any replenishment calculations.Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.com1tag:blogger.com,1999:blog-2334526844968674438.post-9487159398121880482010-09-30T02:49:00.000-07:002010-10-01T17:26:12.196-07:00Perplexing GP QuestionsThere are quirks and annoyances in Dynamics GP like all systems but some design decisions are more puzzling than others. One thing in purchasing that has always bugged me is that there are no user defined fields available on a purchase order. I know that I can now use Extender to add fields but most other transactions and cards have at least 2 user defined fields.<br /><br />Then to make it more bizarre, receiving transactions are blessed with 35 user defined fields including 20 dates. Who needed 20 user defined dates on a receiving transaction? And how long does it take them to receive items?<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0OHVYAluUn9yCJwhcNrhwp_UuLLqswQZStUxtNPnvZSAXGYmttlvrhCrnURLdzkAh-ncuAE8X2BCPWM6slI9peG6HpbQBn-_gAm_AHPNW_l09t8iOHE9D6nHjKcofO0nVydkv1JD_eP0/s1600/9-30-2010+5-49-31+AM.jpg"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 231px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0OHVYAluUn9yCJwhcNrhwp_UuLLqswQZStUxtNPnvZSAXGYmttlvrhCrnURLdzkAh-ncuAE8X2BCPWM6slI9peG6HpbQBn-_gAm_AHPNW_l09t8iOHE9D6nHjKcofO0nVydkv1JD_eP0/s320/9-30-2010+5-49-31+AM.jpg" alt="" id="BLOGGER_PHOTO_ID_5522642902336788162" border="0" /></a>Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.com0tag:blogger.com,1999:blog-2334526844968674438.post-31138351083708696922010-09-30T01:43:00.000-07:002010-09-30T02:38:11.228-07:00Effective Inventory Item Ranking<div><a href="http://www.effectiveinventory.com/index.html">Jon Schreibfeder</a> is an inventory guru who has written several <span id="SPELLING_ERROR_1" class="blsp-spelling-corrected">white papers</span> for Microsoft and provides many of his <a href="http://www.effectiveinventory.com/articles.html">articles </a>for free on his website. If you are responsible for inventory in your organization, these articles can make you look like a genius.<br /><br /><br />His article on <a href="http://www.effectiveinventory.com/article59.html">item </a><a href="http://www.effectiveinventory.com/article59.html">ranking</a> proposes a 3 way ranking system for items based on total cost of goods sold, number of hits, and profitability. Dynamics GP only stores one rank and provides 4 methods of calculating this rank using the Item ABC Analysis Routine:<br /><br /><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIFpB_uKm0FesCTjSIw6SvUEq96VDnBfxYW-JK6Rao1hbesqaU-MW9qMqR4B7QkoauvkTrnP9OYoUhtw9MZ0gV9U5O5-lvkZeh0QvaXsVy9-_ZPHsq-kVZgPjiBLJd58MrA8JUsEHWbRw/s1600/9-30-2010+5-01-08+AM.jpg"><img style="margin: 0px 10px 10px 0px; width: 320px; float: left; height: 262px;" id="BLOGGER_PHOTO_ID_5522630135981599570" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIFpB_uKm0FesCTjSIw6SvUEq96VDnBfxYW-JK6Rao1hbesqaU-MW9qMqR4B7QkoauvkTrnP9OYoUhtw9MZ0gV9U5O5-lvkZeh0QvaXsVy9-_ZPHsq-kVZgPjiBLJd58MrA8JUsEHWbRw/s320/9-30-2010+5-01-08+AM.jpg" border="0" /></a><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />The Usage Value option would rank item based on total cost of goods sold for a time period but to apply the other rankings requires some SQL work.<br /><br />Hits: The number of times an item has been sold is calculated from the SOP30300 table using only non-voided invoices.<br /><br />select items.itemnmbr, items.itemdesc, isnull(soplinesum.hits,0)<br />from iv00101 as items<br />left join (select COUNT(itemnmbr) as hits, itemnmbr from sop30300 as a<br /> join sop30200 as b on a.soptype = b.soptype and a.sopnumbe = b.sopnumbe<br /> where b.soptype = 3 and b.voidstts = 0<br /> group by a.itemnmbr) as soplinesum<br />on items.itemnmbr = soplinesum.itemnmbr<br /><br />Profitability: The query to calculate item profitability is similar but uses extended price and cost to return a sum of gross profit by item.<br /><br />select items.itemnmbr, items.itemdesc, isnull(soplinesum.profit,0)<br />from iv00101 as items<br />left join (select sum(a.xtndprce-a.extdcost) as profit, itemnmbr from sop30300 as a<br /> join sop30200 as b on a.soptype = b.soptype and a.sopnumbe = b.sopnumbe<br /> where b.soptype = 3 and b.voidstts = 0<br /> group by a.itemnmbr) as soplinesum<br />on items.itemnmbr = soplinesum.itemnmbr<br /><br /><br />Now the real fun begins. The results from these queries can be exported to Excel for analysis. Create a formula that returns the percentage of total hits or profit for each item and then sort by that percentage. This will give you a basis to begin assigning ABC ranks by hits and profitability.<br /><br />If you want to store all 3 ranks in Dynamics GP consider using inventory categories or extender fields.<br /><br /></div>Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.com0tag:blogger.com,1999:blog-2334526844968674438.post-17415844473380945042010-09-23T17:37:00.000-07:002010-09-23T17:38:34.015-07:00GP and Management Reporter service packsDynamics GP 2010 service pack 1 was released today and Management Reporter 2.0 service pack 1 was released last week. Let the upgrading commence.Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.com2tag:blogger.com,1999:blog-2334526844968674438.post-29188653933684185932010-09-23T17:10:00.000-07:002010-09-23T17:32:31.948-07:00No company makes money on special ordersNo company makes money on special orders. If a customer calls you and asks for a product that you don't stock, the best P&L decision you could make is to hang up the phone as quickly as possible.<br /><br />Estimated costs of processing a purchase order vary between $50 and $300+ dollars. Lets use the low side of the range and assume a PO will cost your company $100. Even at 50% margin that means you should refuse all special orders under $200. But what if I combine it on another PO? Ok, what if the customer returns or refuses the item? Will you be able to return it to the vendor? Will it wander around your warehouse with no bin home until someone finally throws it away?<br /><br />So I have come to the conclusion that the special order department should be a cost to the sales department. They are the only ones that have anything to gain from special orders through customer loyalty. If special orders are really important to your company, I am sure your salespeople will not mind the reduction in commission to fund the special order department.<br /><br />While you are making changes in special orders, do some analysis on which customers use your special order service the most. Are they your best customers in sales and margin dollars or are they cherry picking you for your product research specialists?<br /><br />In summary, I would like to stress the importance of tracking special order sales and costs separate from normal sales. Each sales order and PO related to a special order should be identifiable. In Dynamics GP, the sales orders should have a separate document ID and PO's should be committed to these orders. Use allocation accounts to apply shared expenses to the special order department to get a real picture of how much this service costs you.Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.com0tag:blogger.com,1999:blog-2334526844968674438.post-55849345807850726992010-09-22T18:41:00.000-07:002010-09-22T18:56:36.304-07:00Purchase Order StatusesDynamics GP has 6 statuses for purchase orders and purchase order line items:<br /><br />New - The purchase order has been entered but not released to the vendor. Interestingly, new purchase orders do not update the on order quantity of an item but can be received against.<br /><br />Released - The purchase order has been entered and released to the vendor. In a throwback to the 1970's, Dynamics GP considers a PO released to the vendor when printed. The printing process updates the on order quantity for the PO line items.<br /><br />Received - Purchase order line items have been received but not fully invoiced.<br /><br />Change Order - The purchase order was entered, released, and then changed but has not been re-released. Change order purchase orders can be received against but changes to quantities will not be reflected in the on order amounts until the PO is re-released (printed).<br /><br />Cancelled - The purchase order has not been fully received or invoiced but no further activity is anticipated. For example, the purchase order was for 100 widgets and 99 have been received and invoiced. The PO would be cancelled if the receipt of the remaining 1 widget was not anticipated.<br /><br />Closed - All line items on the PO have been received and invoiced or cancelled. These <span id="SPELLING_ERROR_0" class="blsp-spelling-error">PO's</span> can be removed from the system using the Remove Completed Purchase Orders window.Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.com0tag:blogger.com,1999:blog-2334526844968674438.post-55896870397584611282010-09-22T18:29:00.000-07:002010-09-22T18:41:29.320-07:00PO Commitments and Historical Sales DocumentsA couple of my clients have experienced an interesting issue lately. Purchase order are tied to sales documents that are already moved to history. This puts the PO in a limbo state where it cannot be closed or cancelled. I don't know for sure the exact sequence of events that causes this but here is how it can be resolved:<br /><br />1. Delete the records in the SOP60100 table related to the offending PO number. (Standard disclaimer about modifying SQL data applies here. If you are unfamiliar with SQL queries and/or Dynamics GP table structure, please call your partner for assistance.)<br /><br />2. Reconcile the offending PO number.<br /><br />3. Edit the PO and change the status to Cancelled.Todd McDanielhttp://www.blogger.com/profile/14243445122237951421noreply@blogger.com0