This issue came up before, but it's turned into a problem...
We're using TS2009 (my computer) and TSRemote Plus in a small office. One of my attorneys added a client to his Remote TS, and I had a bunch of problems with it, so I CLOSED the bad one and created a new one on my computer. The Nickname1's are almost, but not quite, identical. The problem is that now when we exchange databases, I'm NOT getting the slips for this client, and the attorney keeps NOT getting the client data loaded into his database.
So, two questions:
1.) What's going on? (I would have figured that the NEW version of the client would have some internal ID number or something that would just "go" to the remote without question, but now I'm curious about how it works and why what I did isn't working.)
2.) How do I fix it? (i.e., get the new client into the Remote TS database and get his slips into mine)
laurie_lynne wrote:This issue came up before, but it's turned into a problem... We're using TS2009 (my computer) and TSRemote Plus in a small office. One of my attorneys added a client to his Remote TS, and I had a bunch of problems with it, so I CLOSED the bad one and created a new one on my computer. The Nickname1's are almost, but not quite, identical. The problem is that now when we exchange databases, I'm NOT getting the slips for this client, and the attorney keeps NOT getting the client data loaded into his database. So, two questions: 1.) What's going on? (I would have figured that the NEW version of the client would have some internal ID number or something that would just "go" to the remote without question, but now I'm curious about how it works and why what I did isn't working.) 2.) How do I fix it? (i.e., get the new client into the Remote TS database and get his slips into mine) -laurie
I've been trying to stay out of this one because I am not a fan of the exchange database function and remotes. It always seems to eventually lead to something like this, or slips coming in scrambled, or whatever.
What I have my remote using firms do is 1) create the initial transfer database to seed the TSRemote with some clients, timekeepers, activities, etc. and have my remote user enter his/her time, but then when it comes time for the return trip, I have them use the Archive function in the Remote to spit out a TSF (Timeslips format) file with the new slips in it (choosing the option to mark them as Exported when they send them). They then transfer it back to the central billing computer and use the Combine function (specialized form of TSImport) to bring those slips into the main Timeslips database. If there are any issues bringing them in TSImport will prompt me for what to do about it, and note any anomilies in the Journal.
New clients are entered into the main computer as usual. The remotes can be updated with the new clients either A) with a periodic new TSF file (but beware, getting a new one will replace the one the remote has with slips in it, and they will start anew with a blank slate), or B) just let the remote users put a nickname themselves to track time on (all you need to make a slip is a nickname) and when they produce the archive, use a filter of not yet exported. If the remote users happens to put in a different nickname than central did, you will catch it on the import and can either have the remote edit their nickname to match central, or create a translation in the import template that essentially says "Every time George sends an archive file with a slip for Hany, match that slip up with the central billing computer's client Haney). You can also do a combination of both, say giving them new TSF files every 6 months to keep them more or less in synch.
Clear as mud?
Hope this helps. If you think this suggestion was especially helpful, please consider clicking the KUDOS! (yellow) icon in this message. Thanks.Nancy Duhon, Esq.Certified Consultant for Timeslips and Amicus AttorneyDuhon Technology Solutions, LLCduhon@duhon.biz404-325-9779Providing personalized local and remote online support for Timeslips users for over 15 years.
Well, &%*$@#&$%@! I'm really sad to hear that TSRemote doesn't really funtion as well as I had expected, since all my co-workers like it much, much more than having to write down all their time then fight over my computer to get all their time slips entered. Unfortunately, we get new clients all the time, so your processs seems really cumbersome for me and my staff. (Especially because they need to have more than just the Nickname set up -- they need hourly rates, whether the client's slips default to No Charge, etc.)
Now that I know how to count records, at least I can make sure we're not losing any...
In the meantime, do you (or anyone else) have any ideas WHY I'm not getting the slips from my user who created his own client or why he isn't getting the updated client? Here's what is happening...
I'm guessing part of what is happening is that I'm not getting his slips because my db thinks that client X is closed. (So, maybe I should just change it to Open and try exchanging again.)
But I cannot understand why he isn't getting client X2. It's a completely new client, and he should get new clients -- right? (The Nickname1's are spelled exactly the same for the first 12 characters, but that's it. The Nickname2's are different.)
OK, with TS Remote there are two ways of exchanging info between databases: one is file transfer and the other is the exchange function. You're using the exchange function where people on the network are clicking 'exchange' on the menu and finding the main database and then sending their slips and getting new and changed clients back from the main database.
Unfortunately the exchange function is buggy. It does not appear to be well supported by Timeslips. It is much more convenient than the file transfer but the file transfer method is probably more reliable. Although as I recall, that method had problems also.
I don't understand all the ins and outs of the exchange function, b/c I don't have time to test and check every possiblity. However I believe that your problem is very likely because you closed the old client file (Client X) in the main database. Unfortunately, clients put in the 'Closed' list don't appear to exchange information with the Remote databases. So Client X never got moved to the closed list in the Remote database. As far as the Remote database is concerned, it hasn't heard anything about Client X so it didn't make any changes.
Now if you had moved client X to the 'Inactive' list, then this would have moved Client X to the Inactive list in the Remote database and everything would have been OK. But the same thing doesn't work for the Closed list. So what you have now is a new client in the main database (Client X2) and an old client in the Remote database, both very likely with the same names, but TS doesn't think they are the same client. This is because they aren't 'connected.' TS sees a problem, but it doesn't do anything about it.
You should reopen the file you closed and give it a new name, like "Client X_Old." Then when your attorney exchanges, Client X should get the changed name and all the slips that the attorney wrote should come to the main database. From there you can move the slips from Client X into Client X2. And the new file should get into the Remote client list. Once everything is squared away, you can move Client X into the Inactive list and then have the attorney exchange again, this should move client X into the Inactive list in his Remote.
If you've already deleted Client X, you should go to the attorney's Remote and print out his slips, so that you can enter them manually into Client X2. Then you can close and purge client X in his Remote.
If you want to close client files in the future, you basically have to close it in the main database, and then go around and manually do the same thing on each of the Remote databases. It's easier just to move them to the Inactive list and forget about it.
Other workarounds are to use the file transfer or better yet to get network licenses. I can do neither as my boss and the other attorneys will not go back to file transfer nor will my boss buy network licenses. So my solution is that I don't use either the Inactive or Closed list at all. I just keep everything in the Open list and all the closed files begin with underscores like this: "_Client X." This puts all the closed files below the open files. Also open files are assigned to an attorney while closed files are assigned to 'closed.'
I also have other categories, closed files that are 'saved' and others that are 'destroyed.' I use the tilde sign for files I'm going to get rid of and the | character for dummy files where I store alternative addresses. That way I have all the information I need immediately at hand and don't have to laborously reopen files just to find out something.
This has worked out very well for us, in fact I would not do anything differently if we had network licenses. With modern hard drives, there is no reason to have information put away where it isn't immediately available.
Hope this helps, let me know if I'm not clear.
(Well, after leaving my reply window open for about 3 hours and spending at least 30 minutes composing a reply, I got an "authentication error" and completely lost my long, long reply!!)
I'm afraid that I wasn't exact enough about my process. By "exchanging" info with my remotes, what I meant is this:
I would have expected that this would result in me getting their time slips (I enter all of the expense slips), and them getting all new and updated information from me (clients, client references, rates, etc.). What was surprising so far is:
I understand what you're saying about the attorney's TSRemote not "getting" the Closed client, and see how your suggestion of reopening it, giving it a new name, etc. may work. I also see why you went to the naming convention for "closed" clients and the like. It makes a lot of sense.
Thanks, again, for your great explanation and suggestions!
© 2016 The Sage Group plc, its licensors or its affiliated companies. Sage, Sage logos, and Sage product and service names mentioned herein are the trademarks of The Sage Group plc, its licensors, or its affiliated companies. All other trademarks are the property of their respective owners. For more information, visit www.sage.com.
Community Terms of Service | Community Guidelines | Blog List | Community Help