PROJECT HISTORY

In the Beginning

The development and consulting team here at J. L. Sherman and Associates has accumulated over sixty man-years of experience creating a comprehensive array of programs providing complex, accurate, and compliant loan calculations for our clients. All of this experience and expertise goes into our Sherman Calculation Engine (SCE) - the most robust loan quotation engine on the market.

Prior to the development of our desktop based loan quotation software for the 32-bit Windows platform (see WinLoan32), several of our customers expressed an interest in having access to the calculation routines contained in the WinLoan16. Due to previous design decisions, this was not possible. With Winloan32, however, the powerful calculation engine that is the foundation of our end-user loan quotation software (both WinLoan32 and eWinLoan) was developed as a separate product, which we call the Sherman Calculation Engine (SCE).

The SCE was released as a product in the form of a 32-bit dynamic link library (DLL) for the Windows environment. Loan and insurance setup information is stored in text files that are created and maintained by Sherman's technical support team. Depending upon the level of support you desire, we can handle all of the steps in setting up a new account for you. This process involves gathering samples from the client and payment protection provider, and thoroughly testing to ensure that the final calculation results match what the client is expecting.

By separating the calculation logic from the user interface, we make available to our partners all of our applied knowledge and expertise. However, our new partners encountered three problems as they worked to interface directly with the SCE:

1. Initially, the user of the SCE needed to implement all of the data structures used by the SCE for input and output, as well as create the interface to the functions found in the DLL.

2. As the SCE was modified to suit customer needs and federal or state regulations additions and changes, these data structures needed to be altered. This required the data structures in our partner’s applications to also be altered, and then the applications which call the SCE must be recompiled.

3. Some of our partners wanted to access the power and functionality of the SCE from applications not written for the 32-bit Windows platform. There is no simple way to access a 32-bit Windows DLL from another platform.

These three problems prompted Sherman and Associates to begin development on two new satellite projects of the SCE: the SCEX XML interface (hereafter called the SCEX) and the SCE Loan Server.

Emergence of the SCEX

The SCEX addresses problems number one and two in the list above. It provides an XML interface wrapped around the SCE. By using the SCEX instead of the SCE, the calling application no longer needs to duplicate the data structures used by the SCE. Instead, all input sent to the SCEX is contained in one character buffer (or character string). Similarly, the SCEX returns all results in a single character buffer, which the calling application must provide.

The format of the text contained in these character buffers is what the "X" in the SCEX is all about - XML. XML is a simple, flexible text format which is platform independent and extensible and is playing an increasingly important role in the exchange of data between disparate platforms and systems.

The SCEX alleviates problem #1 by doing away with complex input and output data structures all together. Instead, the application calling the SCEX provides the necessary input in a character buffer, which contains the XML data. As an example, here is the XML input data for a 36 month equal payment loan based on a 10% interest rate and $10,000:

<inLOAN_BUILDER>
   <EditInterest Date="2019-01-01" IntRate="10.000" AccrualCode="320" />
   <Advance Date="2019-01-01" Amount="10000.00" />
   <PmtStream Begin="2019-02-01" Term="36" />
</inLOAN_BUILDER>

The result of the loan calculation is then passed back to the calling application in a buffer. The application then need only parse the returned XML to use the calculation results as appropriate. Here is a sample result returned from the SCEX, using the inputs specified above (with the amortization table turned off):

<outLOAN_BUILDER>
    <Results>
        <Description>Successful Calculation</Description>
    </Results>
    <FedBox>
        <AmtFin>10000.00</AmtFin>
        <FinChg>1615.40</FinChg>
        <TotPmts>11615.40</TotPmts>
        <RegZAPR Type="Actuarial">9.995</RegZAPR>
    </FedBox>
    <Moneys>
        <Proceeds>10000.00</Proceeds>
        <Principal>10000.00</Principal>
        <Interest>1615.40</Interest>
    </Moneys>
    <Accrual>
        <Method>Actual/365 USRule</Method>
        <Days1Pmt DayCount="Actual">31</Days1Pmt>
        <Maturity>2022-01-01</Maturity>
    </Accrual>
    <PmtStream Term="36" Pmt="322.65" Rate="10.000" Begin="2019-02-01" PPY="12"/>
</outLOAN_BUILDER>

Furthermore, the second problem mentioned above is also handled. If a new input or output data field is added to the SCE, then the appropriate XML input/output tags will also be added to the SCEX. Applications which do not require this new functionality will not need to be recompiled. Instead, they will simply not provide the new input field, or not recognize the new output field. So long as your application does not require the use of the new data fields, then no recompilation is necessary!