|
|
|||
|
|||
|
I wouldnt call what I do tracking, more like "keeping up with", I would have responded sooner, but i was waiting to see the responses. I guess we just don't have a better solution for you!
Like you said QB sux, but i have yet to find something that seems to work. |
|
|
|||
|
|||
|
yes, this is something I would like to see. We tried using charges to track inventory (create a charge under a special INVENTORY account) but it was a dismal failure because CommitCRM changes all the fileds any time you move a charge from one account/ticket to another. On this, we would LOVE LOVE LOVE (!) it if we had the option to mark a charge that was being moved or copied to override any changes that currently happen. CommitCRM has explained that the charge needs to go through custom pricing (etc.) but having the ability to keep the charge exactly as is would be a huge benefit AND a big time saver! Currently, whenever we move a charge for whatever reason, we have to take a screen shot of the charge (for real!) and fix the fields after the charge has been moved. ...crazy...
On to the inventory part, we don't hold a ton of inventory and tend to track things using quickbooks PO's... it's not great but kind of works... (!) //ray |
|
|
|||
|
|||
|
We tried using QB but gave up. Honestly i think Commit's "Items" is far better than QB anyway. I think CommitCRM could pull off a lite inventory system with only minor changes to their existing items system. I think I posted something to this affect years ago.
Plus given Commit's current item capabilities i think i would be happier with a CommitCRM solution. I think it could even be an add-on module and marketed as such for additional revenue. I would gladly pay an additional fee for a lite inventory system inCommitCRM. Product charges could reduce the quantity on hand and i could manually update the quantity levels when we receive additional product. We don't stock much inventory so this would work for us. For those with much more inventory this may not be acceptable though. Maybe even a few reports that pulled from an additional field in the items that specified re-order level and qty. Then I could simply enter that info into QB to create a PO. This would be simple givent hat the items are already in QB anyway. Just a thought Chad |
|
|
|||
|
|||
|
Thank you for your comments. We believe that managing inventory is a more complex task than it seems. Inventory levels should be affected by and involved in Charges, Quotes (so you quote only for items you have in stock, or at least know about them and then 'save' these items until the quote is approved, Tickets and other places. When ordering from your vendors you would like the vendor invoices, that you log as expenses in QuickBooks to sync back and automatically update the inventory levels for the synced Items in RangerMSP, etc. So, we're not saying no to this, we just say that it is a larger module than it may seem to be and at this point other tasks have higher priority. We will keep visiting the options here and we truly appreciate your comments and implementation suggestions, we may indeed find the golden path to implement it without making things too complex.
|
|
|
|||
|
|||
|
Sorry, but CommitCRM is never going to replace QB - and I have no expectations of that. CommitCRM won't (and shouldn't) be responsible for accounting functions. It should be responsible for "professional service automation" - which is why I think it needs an Inventory module.
my .02. ...and yes, I would pay the price for said working module. |
|
|
|||
|
|||
|
We run separate Qb databases. We have a master accounting file which is what we use for tax purposes. CommitCRM will never replace this.
We also have a separate data file in each our of retail stores. This is the one we would love to get rid of. This is just customers, sales, items, returns, etc. We then import this data into the master file. Since QB cant work over the VPN and CommitCRM cant talk to both QB data files, we are stuck like this for now. |
|
|
|||
|
|||
|
Natt,
This is kind of off the original subject regarding an Inventory system. I can not imagine using QB's hokey Inventory system for anything business related. Anyway, I am sure you have considered using terminal services or something similar for the remote branches, but if so what were the problems? I can envision using CommitCRM remotely and it connects with QB as intended on the main server. |
|
|
|||
|
|||
|
CommitCRM works great in a TS environment. QB not so well. I have heard people who "got" it working, but many who could not.
The internet is our area is horrible. The cost for dedicated is too expensive. If I could depend on the internet i would "consider" everyone using the same QB. Then there are other issues with using QB in our environment. QB just isn't made for the type of volume we do. It works great as an accounting package, but it sux as a POS. You get more than 3 users in 1 QB data file and it goes south quickly. We would need it to keep up with 2 users at 1 store, 2 at the other, 3 mobile guys + me and the accountants! I think the version we have only support 5 users. Their enterprise version was crap the last time we looked at it.... Our main TS/FS server is a dual xeon with 4x600Gb raptor drives with raid 10 with a 512Mb LSI raid card. QB still is shaky....lol. QB just isn't made for what we want to do with it. We have been exploring what is "after" QB. I haven't found anything yet. It's as if we'd have to go the custom route. I know we cant afford that so we deal with this mess we got now. Our situation is a little unique as we have 2 actual stores + our mobile division. Splitting it makes sure everyone isn't down no matter what. Push come to shove you can call the other store and get basic pricing info from their system. I sooooo want things integrated, but I think it will require starting over. The staff likes commit, we just cant do inventory or sales with it. At least with QB we can do sales, even thought inventory is severely limited. The retail staff always asks "when can we use CommitCRM on the retail side?" I just give them the idunno look. |
|
|
|||
|
|||
|
CommitCRM works great on a terminal server, as long as you dont need advanced features like reports to pdf, reports to email, etc. For all those to work printers, email, etc has to be setup on the server.
You could seemingly put QB on the same server, but we haven't tried yet. QB doesnt work properly in a locked down state, so you would risk all kinds of issues leaving it open enough for qb to function. No good options when using CommitCRM or qb from multiple locations. |
|
|
|||
|
|||
|
Commit, one suggestion would be to simply allow the ability to "lock" pricing on items (price and markup) which would then allow us to simply set up an "inventory" account and keep inventory there. The "lock" could simply be a checkbox. When something moved out of inventory, we could simply re-assign it to another account/ticket (etc.) and the price/markup would remain the same. If the checkbox gets unchecked, then the system would use this as a trigger to re-evaluate the charge as it applied to the accounts custom pricing (kind of like it does now). It's pretty basic but would work for small inventories.
That said, this would require Commit to circle back on the accounting parts and fix the bugs (honestly, I still can't believe they haven't been fixed yet): 1) Rounding errors 2) The inability to calculate markup/discount on a per-piece basis 3) The inability to do a return and have commit reverse out the markup/discount (negative numbers) 4) Inconsistencies with how Commit uses “price” and “cost” Of course, you have heard me talk about these bugs many times. For posterity, some of the old discussions... Here Here Here Here Inventory would be a nice (and pretty simple) addition to the application but until the accounting functions are fixed, I doubt it would do anyone much good. Commit: many people have talked about these issues and most have done what we have done, stop using CommitCRM to do any of the calculations. It’s time: THE ACCOUNTING MODULE NEEDS TO BE FIXED! //ray |
|
|
|||
|
|||
|
Ideas noted. We still think that inventory is more complex than what you've described and that it touches many different aspects. Anyway, thanks for sharing your feedback and implementation ideas. We've already copied them to our system.
Thanks for referring/reminding the other threads. |
|
|
|||
|
|||
|
Is there any sort of update on this?
I am trying to locate a solution to track the devices that we will eventually e-scrap or refurbish and sell because we have no idea what that pile of chassis might have that is usable to repair another system. I also need a solution to track things we decide to stock for walk-in clients (i.e. routers, RAM, monitors, keyboards, etc...) If anyone has any ideas, PLEASE let me know. I need a solution ASAP. |
