We are in the middle of summer which also means strawberries. Yummy.
Strawberries remind me about being in my early twenties when I decided to make strawberry jam. I bought a few containers and popped them in the fridge. When I came back a few days later I had a problem. My containers of strawberries were now rotten. Turns out the moisture and mold caused this problem. Who knew. I was young.
All these years later, I use the situation as an analogy when talking about keeping a Visual ERP database clean. One of the more prevalent problems is “parts without product codes”. Since I am an accountant, I am rather passionate about product codes being correct since they are the key to make costs post to the right accounts in a Visual ERP database. Now, just imagine a new part has been set up but a product code wasn’t provided because it is not known yet or maybe it was overlooked. In the meantime, people have started using that part elsewhere in Visual. Just imagine. Jimmy in manufacturing starts to make this part. Now the work order doesn’t have a product code. When we receive the work order we don’t have a product code so it posts to the Inventory default from GL Interface table or Inventory – No Product code as I like to call it. Also, Susie from customer service creates an order for that part with no product code which means no revenue account or the cost of goods sold account. The entries will post to Revenue – No Product Code and COGS – No Product Code. Let’s take this a little further, instead of 1 customer order there are 5 or 10, maybe more. We could have lots of work orders. This so reminds me of those strawberries. One bad one resulted in 10, 20 or 30 or even more- bad transactions which as an accountant, we need to put in the right place.
But these bad strawberries can exist with other types of data. How about having a default expense account in vendor maintenance? Now, that seems like a nice handy feature because it will automatically apply the General Ledger account to the cost on an accounts payable invoice. However, when you are recording a purchase order it can also be used there. What can easily happen is your buyer might create a PO for miscellaneous items, let’s say strawberries for the annual strawberry social, but we don’t put the right General Ledger account on the PO line. This could result in our strawberries going in as a factory supply expense but should be posting to employee relations. Now, if you’re on the operations side you don’t see anything wrong with this but if you’re on the finance side, at month end you have values going into the wrong account.
Another thing that can also cause a problem is not defining a purchase unit of measure on a part for vendor pricing. In Canada, we will more likely use kilograms as our stocking unit of measure on parts such as steel or plastic. Now, if you place a purchase order without a correct purchase unit of measure you might just have a sticky mess. An example: the purchase unit of measure (UOM) is pounds (but isn’t on the PO) and the stocking UOM is kilos. Let’s say the PO is for 1,000 pounds which is 454 kilos. What happens? Quantity of 1,000 is received as kilos but it should be 454. Now inventory is overstated but you don’t have that much so you may mess up the operations folks. The other effect is the cost per unit is about half what it should be. Every place the part is used has the wrong cost which can wreak havoc on your customer or part margin analysis.
These are just a few places bad data in our database can put you in a jam. Some because we didn’t make our jam as soon as we bought our strawberries. Or we didn’t assign the product code as soon as we created the part.
Have you come across “bad strawberries” in your database? Please feel free to add to the list in the comments below. We may end up with a big fruit salad. Hey! Peach season is here now.
