Anyone Else Want "as of" date for receiving POs?

The whole COGS system in RMS does not make sense. The fact that the COGS is permanently recorded in the database at the time of the sale does not take into account timing issues that occur in the normal course of business.

For example, quite frequently I am unable to receive and commit items to the database the second they physically arrive (either due to time constraints or because I have not received the invoice from the supplier or know all of my costs yet, so I do not know the exact cost value yet). However, if it is physically in stock, I want to sell it if a customer asks, even if the database quantity it zero. Especially in the case of new items where the item cost is zero until received and committed, if I sell it, the COGS is recorded as zero (100% profit margin).

There should be an as-of date/time for commiting POs and transfer to the database. The system should go back and correct COGS numbers for items that were sold after the as-of time.

This problem also throws off the weighted average calculation at the time of receiving if you have sold items that have not been committed.

Every month I have a huge accounting adjustment to COGS to account for these problems. The COGS and profit numbers that come out of RMS are completely useless.

Reply to
Jason
Loading thread data ...

Jason - I have the same problem on work orders. I prevent the selling of items if quantity on hand is zero by the built in RMS option. However, an item on a work order has the cost of the item when the item was placed on the work order and it will never change unless the item is reloaded onto the work order and sales people do not do this even if instructed. You can receive the item against a PO at some cost and pick up the work order but the cost on the item on the work order is not updated. I don't think this is a bug. I would not want it updated.

I have fixed this by running cost comparison queries in HQ daily and I send out worksheet 51 to update TransactionEntry.Cost if it's not equal to Item.Cost where applicable. Just make sure you work on current data so you don't update old TransactionEntry.Cost with current Item.Cost. It must be done daily to keep your PM in line, and the CFO from having seizures...

Be very careful! SQL update statements > The whole COGS system in RMS does not make sense. The fact that the COGS is

Reply to
Otto

Try explaining it to an outsourced accounting firm that is not familiar with RMS. They can't believe it.

Anyway, I was worried about the work order thing, and just confirmed what you are saying. That is expecially bad because we create new items for special orders quite often. The item goes on the work order with the cost as ZERO! When the item comes in and the sale is finally generated, the cogs is zero on this sale. Not good.

I am considering abandoning the whole COGS system in RMS and just using the data for inventory tracking and sales.

Reply to
Jason

What I'm confused about is how you know what to charge for an item if you don't know what you paid for it first. When I create a new item I know what I'm paying for it, and I put that value in the cost field. When I sell the item the amount I put in the cost field shows up as the COGS for the item on all reports. Even though I never officially recieved on my purchase order yet. If I don't know exactly what I'm paying for it I don't sell it until I do. One thing to try is to call your supplier and request they fax you a copy of the invoice. Several of my suppliers do this for me because I complained loud enough that I needed my invoice with my shipment instead of mailed to me and I get it next week. That's just not a good practice and I don't stand for it. Craig

Reply to
Craig

That's easy if you are dealing with one country and there aren't import duties and taxes and other costs associated with your inventory value. Sometimes we need to take a risk and start to sell items before we work out the exact cost.

The bottom line is that you shouldn't have to commit items to inventory before you sell them at the POS. That is making you a slave to your computer system, and I don't believe in it - that's bad business.

Reply to
Jason

Seems to me if you can't get a timely invoice from your supplier that you have become a slave to your suppliers. My suppliers are there to serve me, not the other way around. You should know you're costs before you sell an item. You don't have to commit the inventory to have it work, just have the cost in the cost field. Also, I wouldn't want my POS to go changing profit margins after the fact. By that time I already have my batches posted to my accounting software, and I want my POS figures to match my accounting figures. Craig

Reply to
Craig

Apparently you don't understand the difficulties involved in international trade. We DO have invoices from suppliers before the goods even ship, but sometimes we do not pay duties until days after the goods are in our possession. Sometimes we pay estimated duties. Often our actual costs end up different due to tariff issues that take time to resolve. We have a very good idea about our costs, so we can price our goods with relative safety and begin selling immediately, but we do not know exact costs, so committing to inventory in RMS is not possible.

I'm not sure where you get off telling me I should know my costs before I sell an item. It's my business, and I'll run it the way I want to!

I don't want to get into a fight here, but I think I know a little about how to run a business, and I have decades of successful retail experience. In the "old days" you did not calculate COGS on the fly as you generated sales. This was an accounting function that was done later, often after month-end. RMS calculates COGS simultaneously with the sale. Setting COGS in stone IS enslaving me to my computer system. That is why I consider the COGS numbers coming out of RMS useless, and I have to have a whole outside process to properly calculate it.

The bottom line is that you should be able to correct COGS numbers for prior sales, whether it is due to mistakes or unique business processes that require it.

Reply to
Jason

I apologize if you think I was telling you how to run your business, that was not my intention. What I was saying is that I would not want COGS to be changed after the fact. I have already posted it into my accounting program and allowing RMS to change figures after the fact would make everything a mess. If you need a POS system to do that maybe there are ones that specialize in international trade that would work better for you. By the way, I remember the Old Days when I wasn't computerized and I still knew my costs when I priced an item. As far as the numbers coming from RMS being useless I totally disagree with you and I would bet that many others here would too. Craig

Reply to
Craig

What I meant to say is that the COGS coming from RMS is useless in *my situation*. I agree that when used in the regimented way that RMS requires, the results are great.

I also agree that once you post to your accounting software, there is not much you can do from the POS system to go back and correct things. In my case I just post once a month ans sort out the disaster later...

Isn't retail fun?

Reply to
Jason

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.