Dynamics GP built on Microsoft SQL uses extensive temporary files that enable multiple users to read the same record at the same time. True multi-user capability combines functionality of the underlying database along with functionality encoded within the application.
Chances are, like me, you're not an SQL architect, and haven't given all that much thought to all of the technical underpinnings of your ERP system. But as a user, this is what GP's Microsoft SQL foundation means to me. When I access a Dynamics GP customer master record to make changes, the system writes a copy of the record to a temporary file. When I finally click the save button, the changes are written back to the main table and the temp file is closed. The ability of shadowing the main table with a temporary table allows multiple users to access the same record at the same time.
If while I’m making my changes, someone else opens the same customer master record, neither of us is impeded or is even aware of each other unless the second user (or third, fourth…) also makes a change. Whoever clicks the save button first wins. The second user to click save receives a message, “This record has been modified by another user. Your changes will not be saved.” Okay, maybe that’s frustrating if you made a lot of changes, but the record is undamaged and the integrity of the database is preserved.
Several functions are at work to make this a different experience with Dynamics GP and Microsoft SQL than with QuickBooks and its underlying proprietary database. QuickBooks simply won’t allow a second user to access the same record. When the first user opens the record, the record locks. If the first user who opened the record doesn’t close it and goes to lunch, a second user has to wait an hour. Or prowl the office hoping the other person didn’t lock their computer.
With some older, less functional systems, I’ve seen much worse scenarios. While doing a needs analysis for one wholesale distributor, I found that only 1 of 14 customer service users could process a sales order at the same time. Red and green flags were visible throughout the office. If someone wanted to process an order they got up from their desk, went to the nearest flag station, viewed all the other flag stations, if there were no red flags visible, they put up the red flag, returned to their desk, processed the order, and returned to the flag station to put up the green flag. If another red flag was visible, the person would wait a minute or start yelling, “Who’s processing? Let me know when you’re done.”
As they explained to me, it was a freaking nightmare. People got interrupted and forgot to switch back to the green flags. Impatient at times, and some users more impatient than others, users would simply click “Process” and hope for the best if they couldn’t see a red flag. No one was adverse to ignoring the system while simply yelling out, “I’m processing!” The customer service manager had a private office so when she needed to process an order, she had to leave her office and walk around the corner to put up her red flag.
When I was finished with the needs analysis, I determined they could easily cut one-half or more of their customer service staff simply because they could process orders that much faster. Or they could double their sales volume and not hire additional staff. They also would save considerable down time because they weren’t restoring their corrupted system to a backup several times a week because users would ignore the necessary procedure to raise the red flag.
In Dynamics GP, if six users want to create a sales order for the same customer at the same time, no problem. In QuickBooks, if the customer record is in use, it’s inaccessible to other users. While I don’t support QuickBooks, I assume its weak record locking in a multi-user environment contributes heavily to its instability. It takes a lot more programming to design logic that allows multiple users to view records at one time, locks fields down rather than the entire record, keep track of who saves first, and what to do if multiple changes are made while the record is open.
Dynamics GP allows multiple posting processes simultaneously. Daily procedures are truly multi-user.
When single-user of the system is vital, it tells us. For example:
- You can’t change the Account Format because there are other users in this company.
- You cannot clear files because there are others using this company.
If you’re using an entry-level accounting system and its lack of true multi-user capability is holding you back, Dynamics GP can provide great value and return on investment. We can deploy rapidly, transferring data from QuickBooks using the RapidStart tool. Using Computeration’s proprietary Zap Integration tool, we can even migrate historical data.
Gloria also writes about the distinctions between Quickbooks and Microsoft Dynamics GP at https://