The main technical components of FinDock Core are present in every FinDock installation. Some installations might include extension packages with separate components. These components are described in their respective articles.
The full FinDock solution consists of several packages, each containing specific logic for their task. Most FinDock installations consist of at least:
- FinDock Core package
- ProcessingHub package
- A source connector package
- A payment extension package
All FinDock packages are managed packages that have passed the Salesforce security review. This means that the objects and code contained within these packages do not count against the custom object or apex limit in your org. However, other limits on API calls, data and file storage still apply!
FinDock data model
The FinDock core objects are related as illustrated in the follow Entity Relationship Diagram (ERD). It is important to keep this model in mind when configuring and customizing FinDock.
FinDock contains several objects itself, and uses the Salesforce standard Account and Contact objects.
Some extension packages might contain additional fields or objects.
Accounts and contacts
These are standard Salesforce objects you are most likely already familiar with. FinDock does not modify these objects. However, FinDock is equipped to handle any custom field you might create or install through a third-party package. For more information about contacts and accounts, see the Trailhead module Accounts & Contacts.
The Installment object might be the most important object in FinDock. It represents a single amount receivable. It always represents that particular amount receivable, meaning that you can at any time track if this amount was paid and when. In the case of a reversal or refund, you can track the amount back to the exact Installment that is involved. Read more.
The payment object mainly represents cash flow. Every time money changes hands (collection, refund, reversal), a Payment record is created to reflect this transaction. Each Payment is linked to an Installment. One Installment, on the other hand, can have multiple Payments. Read more.
The Payment Profile object contains card or bank information. A contact or account can have one or more Payment Profiles containing credit card tokens, IBANs, bank account and sort code combinations, etc. Read more.
The Mandate object contains the authorization given by a donor or customer to collect funds from their account. The most common use cases for the Mandate object are the SEPA Direct Debit Mandate and the BACS Direct Debit Instruction. In these cases, a correctly registered mandate allows you to perform direct debit collections on the IBAN or bank account specified in the Payment Profile. Read more.
The Payment Schedule object represents a single bulk payment collection run for a specific source and payment method. Read more.
The Recurring Payment object is only used if FinDock is configured as its own source. The Recurring Payment object allows you to define a certain amount to be receivable each month, quarter, twice a year or yearly, as well as define the required payment method and processor. Read more.
Transaction Set and Transaction
The Transaction Set and its child Transactions are linked through a Master-Detail relationship and are used to capture bank statement imports in FinDock. Every transaction on a bank account becomes a single Transaction record linked to a Transaction Set that groups all the records of that import. Read more.
The Audit Trail object is used to store audit records listed in the Audit Trail tab under FinDock Setup. Read more.
The Logs object is used to capture system log messages submitted by various components of the FinDock solution. Read more.
The message object is used to add actions to a queue for asynchronous processing. Read more.
The inbound report contains reporting related to bulk collection results and mandates for specific payment schemes. Read more.
Aside from the data objects, FinDock also contains a number of Custom setting objects. These records contain information needed by FinDock to function correctly. Although these settings are not protected and can potentially be viewed and even modified by administrators or users with sufficient access, doing so might cause your FinDock installation to break!
Never change these settings directly on the Custom Setting object. Always use the proper page or action to modify these settings.
Custom Remote Site Setting
Contains remote site settings that need to be added to the Salesforce Remote Site Settings for certain functionality to work, for example the ProcessingEngine URL. These are added when FinDock packages are activated.
Contains regex expressions to validate the IBAN pattern for each country. These records are added or modified on installation or update of the FinDock Core package.
Contains the main settings for FinDock, these are set through the FinDock setup page.
Registers activated payment methods in FinDock. These records are modified by activating or deactivating payment methods in payment extension packages.
Payment Service Provider
Contains the setup registration of installment FinDock extension packages. There records are modified by installing, updating or uninstalling FinDock extension packages.
Contains a local copy of the targets defined in ProcessingHub.
Apex batch and schedule classes
FinDock contains a number of schedule and batch classes that perform various tasks. Configuration for each of these classes is discussed in the relevant function are configuration article(s).