Archived Features
Fillable Field Default Behavior Change
Effective Date for Hosted Expere users:
- Customer Test Environment: July 2024
- Production Environment: August 2024
Effective Date for self-hosted Expere users:
- 2024 Release Two
Expere’s behavior has been updated to generate Fillable Fields when specified rather than producing them by default. These changes simplify the logic and makes Expere more maintainable.
The current default allows documents to support fillable fields but not eSignature fields. The new behavior will support fillable fields when eSignatureAndFieldSupport options are specified in the request; otherwise, fillable fields will not be generated on the documents
There are two types of fields that can be added to the generated documents.
- Acroform fields (referred to as “fillable fields”) can contain user-entered data for editing a document after it has been generated and output by Expere.
- Electronic Signature fields (eSignature) are used to populate signature names, dates, or initials.
The ability to control these fields is based on data passed in the API Request from the Loan Origination System (LOS) integration to Expere.
User action and impacts
The com.bankerssystems.expere.render.acroformSupport property ONLY
supports a "false" value.
No user action is required provided that fillable fields are not needed unless the eSignatureAndFieldSupport ancillary output is specified. To return fillable fields without eSignature fields (the current default behavior), the following eSignatureAndFieldSupport ancillary output options should be specified:
- eSignatureAndFieldSupport = true
- eSignatureCoordinatesOnly = true and
- NonSignatureFieldCoordinatesOnly = false
These ancillary options are currently available and can be utilized at any time. If the desire is to have documents with no fillable fields nor eSignature fields, no further action is required.
Document List
When a package is created, Expere creates a list of documents included in that
package, the names of which are derived from the
InstanceDisplayName within the document .REQ file. The REQ file
properties file specifies that a full document list should be created within the
document that is selected, such as the Closing Instructions
(ClosingInstructions.req)
Partial Document List
When a package is created, Expere creates a list of documents included in that
package, the names of which are derived from the
InstanceDisplayName within the document .REQ file. Wolters
Kluwer has enhanced Expere to now support the creation of a "partial" document
lists." Expere users may now select the specific documents to be included in this
partial document list.
eOriginal: native Expere eNote files
Expere integrated users can utilize Expere to create and upload dynamic eNote files to eOriginal.
Callback to Salesforce
Wolters Kluwer has enhanced callback functionality to utilize Salesforce using token authorization. For more information, see Callback to Salesforce feature, Callback, and Callback Authorization.
Hosted Expere > Wolters Kluwer ESign Delivery
Wolters Kluwer has integrated Hosted Expere and Wolters Kluwer ESign (WKES) in order to utilize the latter's delivery options. For more information, consult the Hosted Expere > Wolters Kluwer E-Sign Feature Guide.
Augment Transaction
During the course of the content authoring process, a new Augment Transaction
REQ file is available for authoring. Expere can update, or "augment" an incoming
request if the transaction contains an /txn/AugmentTransactionInd =
true element and value. When this value is provided, Expere resolves
the XPath(s) in the related line of business Augment Transaction file based on the
transaction XML and sets the XPath(s) in the transaction. Remaining autoselection
logic is employed and documents are generated.
Multiple notes supported for commercial transactions
Expere now supports a single transaction with multiple promissory notes for the Commercial line of business.
SMART Doc 1.02
Wolters Kluwer enhanced Expere to generate MISMO SMART Doc version 1.02. A MISMO SMART Doc is an electronic document that meets specified standards set forth by the Mortgage Industry Standards Maintenance Organization (MISMO). SMART is an acronym that stands for Securable, Manageable, Archivable, Retrievable, and Transferable. The MISMO SMART Doc is the industry standard for eNotes. The SMART Doc format links the visual representation or text of the note along with data included in the note and the signature. They can be viewed using a variety of technologies, most commonly PDF, and they are electronically sealed to prevent tampering. This format ensures that what a borrower signs on their computer screen is the exact document that will be stored. Once an eNote is signed, it is transferred to an electronic vault or eVault where the original file is securely stored and where it can be transferred to another eVault as needed.
FOP 2.8 upgrade
Expere uses Apache™ FOP (Formatting Objects Processor) to generate PDF documents. Currently, the Expere Engine supports two FOP versions: 1.1 and 2.8.
- Expere uses version 1.1 to generate standard PDF documents and is the default rendering engine.
- Expere uses version 2.8 to generate Web Content Accessibility Guidelines (WCAG) compatible Tagged PDF documents.
Scheduled for March 2024, Expere will use FOP 2.8 to generate both standard PDF and Tagged PDF documents.
What do you need to do?
If you want to test or use FOP 2.8 before March 2024, contact your Project Manager or your Account Executive to request a Content URI be set up and configured to use FOP 2.8. Let them know what content and environment (Customer Test or Production) you want to be configured.
- Once you have the Content URI, change your application to use this new Content URI, as you would with any other content update.
Otherwise, you can wait until we enable FOP 2.8 for all customers in March 2024.
What is changing?
With the upgrade to FOP 2.8, you can expect to see the following:
- Minor document generation performance improvement.
- Transaction barcodes are no longer bolded and now honor case-sensitive values.
- Transaction barcode height will be supported in the September and October Hosted Expere release.
- For single page documents containing Header and Footer notices, Wolters Kluwer-authored source content files (REQs) must include a "FirstPage" attribute when document logic dictates different Header and Footer requirements per page.
- For single page documents containing specific margin requirements, Requirements Editor files must include "InstanceFirstPage...Margin" and a corresponding value when document margin logic dictates different Margins per page.
- REQs using the Integrated Disclosure Stylesheet no longer produce barcodes when not specified to do so.