|
| | | Junior Member
 
Group: Forum Members
Last Login: 10/1/2008 2:08:42 PM
Posts: 18, Visits: 27 |
| | This may be an obvious or even ridiculous question - but here goes... Our company is looking to develop a document imaging application which organizes documents collected throughout the loan process into an easy to find/use location. The technology has been used in medical practices in the past to organize patient charts and I have identified that there is a need for this type of application in the mortgage industry. I want to use Calyx Point because of their Supremacy over the Loan Origination applications on the market. The issue at hand is that for our application to work properly, we like to retrieve the key data from a 3rd party database which will be the data which provides the indexing of our document imaging application. I realize that the data in the PDS is 'read only' which will be sufficient for what we are looking to do. But beyond that, I want to know if the PDS houses the actual data regarding the loan files. Can I query the PDS from an outside source and retrieve borrower information (Name, Subject Prop. Address, etc) and plug it into the application we are developing? I have a lot of experience with the traditional version of Calyx Point, but not the PDS version. Thanks in advance for your input. Sean |
| |
| | | Forum Guru
Group: Forum Members
Last Login: 9/8/2008 5:20:14 PM
Posts: 51, Visits: 183 |
| The pds database in sql can be queried very easily. We use it extensively for dashboards, analytic reporting and document management. The only issue we have is that the PDS database doesn't hold every field that Point offers. It holds quite a few and to their credit most of the fields you will probably use for a Doc Mgmt app. There are 100 fields you can add to the db, which we have used all of and are still trying to prioritize which fields we need and which we want.
We built our doc management app internally mainly to avoid the heavy cost (25k + LOS integration of 10k). Our scanned docs/PDF/etc are stored in a folder which is the same name as the loan filename. We created a simple web page that allows users to select a loan (from an SQL query against PDS) and "dump" the file into the specific folder. When someone wants to search for a file, they really just search for a loan (via name, filename, loan officer, close date, etc) and our web apps shows a listing of all the files in that filenames folder.
This solution actually works remarkably well. The biggest downside that I have run into is security (we limited what loan officers had access to, which is ) and search ability of the closed loan packages. They are up to 300 pages and we currently don't index the actual pdf doc. So our users have to search through the pdf a bit, although our files are stacked fairly orderly.
As far as our dashboards go, I've included a screenshot, which shows a processors "today" view. All of these headings are sql queries against the PDS database. This is just one of soooo many dashboards. Users only see their items, unless they are managers and then they see a lot more.
So sql/pds/web integration really plugged a major hole for us. Our people are significantly more efficient. Hope this helps.
|
| |
| | | 
www.ehuna.org
Group: Administrators
Last Login: 12/17/2008 10:36:11 PM
Posts: 258, Visits: 13,336 |
| | Wow, isupport, your app looks amazing! I like the way you linked the docs by using the loan file name and creating a separate directory for it - very cool. To answer goamb's original question: > Can I query the PDS from an outside source and retrieve borrower
> information (Name, Subject Prop. Address, etc) and plug it into the application we are developing? Yes, like isupport mentioned, this is easily done. The information you mention above is found in the "Files" table in the PDS SQL database. Look for the f100, f101, etc... varchar fields. You can use ADO.Net, ADO, ODBC or any other standard library to access a SQL Server instance. If you are looking for fields that are not present in the "Files" table, you'll need to join on iFileID on other tables, such as Field, Extra, Macro, Large, Custom, or Additional. Important note: the PDS SQL schema may change in the future. If you use the data directly from SQL, there's a risk your application might break after a future upgrade. Although for the data you mentioned above (name, subject prop. address) the probability a change would occur is small. We've been throwing around the idea of creating an API for developers that would allow you to access data in a loan file regardless of how we store it (in the BRW/PRS file or in the SQL Server database). I can't give you any schedule or any additional information, sorry.
Disclaimer: this post carries no explicit or implied warranty. Nor is there any guarantee that the information contained in this post is accurate. It is offered in the hopes of helping others, but you use it at your own risk. The author will not be liable for any damages that occur as a result of using this post.
|
| |
| | | Forum Guru
Group: Forum Members
Last Login: 9/8/2008 5:20:14 PM
Posts: 51, Visits: 183 |
| We actually thought about what happens if Calyx changes the schema... So 90% of our dashboards and queries to PDS/SQL are made through a few SQL views. While this is not the recommended approach, it resolves that issue. If the schema changes, as long as we can make our views spit out fxxx field names, we should be good. The other 10% of our queries go directly to the PDS tables due to speed/overhead issues of using SQL views to pull data.
We're pretty proud of our dashboards. Each department has their own set of dashboards and the management staff have dashboards that even show future closings by week factoring in lock date, expiration date, fallout, etc. So our closing manager can see approx how many loans will close in the next couple weeks. While it's still a moving target, we do get a good idea of workload.
We actually got the idea of dashboards, etc from Calyx... In the PDS admin app, there is a reports section that shows how many loans are in each status per folder. Our Ops Manager saw that and said "why can't we do that" Viola, we now have dashboards. |
| |
| | | Forum Newbie
Group: Forum Members
Last Login: 9/29/2008 8:18:00 AM
Posts: 1, Visits: 18 |
| I'm new to this but an interested in accessing data from sql directly. Does anything special have to be done to get this data from the db or is it in there by default?
-Cory |
| |
| | | 
Sepal
Group: Moderators
Last Login: Today @ 4:06:35 PM
Posts: 1,183, Visits: 9,261 |
| PDS would store most of what you need. You might have to add a few additional fields.
Disclaimer: This post carries no explicit or implied warranty. Nor is there any guarantee that the information contained in this post is accurate. It is offered in the hopes of helping others, but you use it at your own risk. The author will not be liable for any damages that occur as a result of using this post.  |
| |
|
|