TAM application move from one to another

[Hans Manhave]

In TAM 10.x can I move an application from one customer to another?  If so how?  Somehow there were two customer codes set up and two CSRs put in information.  Now I need the UMB app to move over to the "keeper" customer.  Then I want to delete the "bad" customer.

[Todd Arnold]

Yes, you can do that.  Two ways, but conglomerating is safer than 'the prospect shuffle'. 
Temporarily conglomerate the two accounts with the account that has the UMB to be moved as the parent.  When you go to add a new policy on the "keeper" account, it will give you the option to move a policy from the conglomerate parent.  Be sure to checkt he box to copy the apps. 
When you are done, you can remove the conglomerate settings - conglomerating in TAM on a temporary basis is a pure 'no harm - no foul' option.

[Jeff Zylstra]

Yes, you can do that.  Two ways, but conglomerating is safer than 'the prospect shuffle'. 
Temporarily conglomerate the two accounts with the account that has the UMB to be moved as the parent.  When you go to add a new policy on the "keeper" account, it will give you the option to move a policy from the conglomerate parent.  Be sure to checkt he box to copy the apps. 
When you are done, you can remove the conglomerate settings - conglomerating in TAM on a temporary basis is a pure 'no harm - no foul' option.

I'll bet this conglomeration trick may also be useful when you need to move policies around in divorce situations too. 

[Hans Manhave]

The procedure was extensively tested on Monday and found to work very well.  It has now been written up for our specific situation and shared.

The nice part is that I did none of this myself. 

[Mark Rowe]

Regarding this process of using conglomerates to move apps and/ or combine accounts (as listed below int his thread), does anything else move along with the apps?  Will activity information or transactions move as well? I must admit that we do not use conglomerates so I am totally unfamiliar with how they work.

[Bob]

Having just done this last week, no.  Only the apps and billing screens move.  Activities remain on the main conglomerate.  I had the staff review any open activities and re-enter them on the new client close out on the old.  You also have to go back and delete those apps and billing screens on the main client.   It only copies it does not move and delete.  Have to delete future apps, current apps before you can delete them.

Nice trick but Applied could have done better with MOVE vs. COPY so you wouldn't have to go back and clean up.  At the very least make a utility that lets us do this as this situation happens and it would be nice to lesson the work involved.   Doing the prospect shuffle as Todd calls it, lose more and have to re-enter more.   This way you just have to go back and delete the copied apps from main client.

[Mark Rowe]

I can't believe after all these years this functionality still doesn't exist.......

[Jeff Zylstra]

I can't believe after all these years this functionality still doesn't exist.......

I have to guess that this issue is because of the old DBase database structures.  Not sure if it's possible in EPIC or not, but I would think that with some reprogramming, that EPIC would be capable of object based drag and drop functionality, like moving policies between customers and the like.  I  doubt that would ever be possible with TAM.

[Mark]

I'd have to suggest that there is more to it than the database aspect.  We already have drag and drop from Outlook, don't we?  From a TAM perspective, moving ALL of the data that comes along with a policy would probably require a reindex somewhere.  Think of the accounting that might be attached to it, too.  We already see that with the conglomerate trick, the history doesn't come over with it.  Also, think of the mistakes that could be made from dragging and dropping policies between clients accidentally or even just from or to the wrong client.

I think that this feature or a feature close to it is possible, I just don't see it ever happening.  Do I think there should be a wizard/utility to do this?  Probably, but it's likely that there would still be data that does not move with it anyway.

Just my two cents.

[Jeff Zylstra]

I'd have to suggest that there is more to it than the database aspect.  We already have drag and drop from Outlook, don't we?  From a TAM perspective, moving ALL of the data that comes along with a policy would probably require a reindex somewhere.  Think of the accounting that might be attached to it, too.  We already see that with the conglomerate trick, the history doesn't come over with it.  Also, think of the mistakes that could be made from dragging and dropping policies between clients accidentally or even just from or to the wrong client.

I think that this feature or a feature close to it is possible, I just don't see it ever happening.  Do I think there should be a wizard/utility to do this?  Probably, but it's likely that there would still be data that does not move with it anyway.

Just my two cents.

I think you're right that there might be more to it as far as data safety and data consistency go, but isn't the whole "reindexing" thing part of DBase and doesn't that go away in SQL?  I was under the impression that SQL does not have to be reindexed and can also "link" or "refer" to data in a separate database, rather then needing to store the data itself.  If that were true, the reindexing would be a moot issue I would think.  And I see your point that making this process "foolproof" just may bring out the fool in people.

[Billy Welsh]

Yes, there is a risk of error in allowing this functionality.  That does not mean that the agency should not be given a choice.  Put the functionality there, secure it, and let the agency decide if they want to use it, and who gets that responsibility.  Do NOT dictate to me that I must use inefficient processes because you think you need to hold my hand like a child.  Would I have allowed my CSR's and Acct. Mgr's/Producers to do this?  Not likely - maybe the "chief" CSR but then again she would likely have been wise enough to say "no thanks you run it."

There is a risk of error every time we let anyone do anything in the databases.  There is a risk of malware whenever we allow a user to connect to the Internet, and that malware could destroy the databases.  It should not be up to A$ what risks I choose to take with my business.

Just my $0.02.

[Mark]

I think you're right that there might be more to it as far as data safety and data consistency go, but isn't the whole "reindexing" thing part of DBase and doesn't that go away in SQL?  I was under the impression that SQL does not have to be reindexed and can also "link" or "refer" to data in a separate database, rather then needing to store the data itself.  If that were true, the reindexing would be a moot issue I would think.  And I see your point that making this process "foolproof" just may bring out the fool in people.

Both dBase and SQL are what's called Relational Databases.  SQL has much better performance and manages the indexes itself (can still be reindexed manually if necessary).  Both database types refer to data in other tables.  In SQL, you generally have one database with multiple tables.  In dBase, you have multiple database files (DBF) and they can reference data in one another.

At the file level, a SQL database is one file and all the tables are in that file.  A dBase database is any number of files in any number file paths and they reference each other as needed.  there a little more to it with SQL log files and dBase indexes (NDX), etc.

And before someone suggests dBase is NOT a relational database, here is a quote from Wikipeida:

Its ability to simultaneously open and manipulate multiple files containing related data led Ashton-Tate to label dBase a "relational database" although it did not meet the criteria defined by Dr. Edgar F. Codd's relational model;

So, it is and it isn't, but it is. 

[Jeff Zylstra]

I am quite weak in my Database knowledge, but this helps.  Thank you for the education.

[Mark]

I am quite weak in my Database knowledge, but this helps.  Thank you for the education.

That was my coffee conversation this morning! lol

[Jeff Zylstra]

That was my coffee conversation this morning! lol

Yeah, talking about database issues always makes me drink too!