Contracts

Module purpose

Contracts manages more than PDF files. A record may retain its source mode, template, generated content, customer, service lines and prices, status, signature, attachments, payment method, custom values, and operational history.

A contract can be generated from an ISP Billing template or acquired as an externally prepared PDF. Both modes create a uniquely coded practice available to authorized operators.

List, search, and status

The list shows status, contract code, name, customer, and creation date. Search by customer or filter Non-signed, Signed, and Cancelled records. Open the code or name for full details; the customer link opens the CRM record.

A filtered status is not legal proof. Review the document, signature, dates, attachments, and event history.

Prepare the module before first use

Complete Issuer details, PDF template, attachment library, and at least one contract model before creating operational records. Also verify payment gateways, referenced customer fields, service catalog, and—where required—OTP Service and Resellers.

These settings feed every later document. A correction does not automatically rewrite PDFs already delivered, so keep recognizable versions and run one complete fictional contract before commercial use.

Issuer and PDF rendering

Issuer settings hold company name, fiscal identifiers, country, province, address, street number, postal code, e-mail, and phone of the contracting entity. PDF Template configures style, color, recommended 400×200 PNG logo, and reusable footer.

Generate a sample after each change and inspect margins, contrast, logo, page breaks, and readability. Keep customer-specific terms out of a global footer.

Build a contract model

A model has a clear name and may be exposed to resellers or classified as a Form instead of a Contract. Compose A4-oriented HTML or upload a base PDF; when conversion cannot handle its compression, resave the source as PDF/A.

Insert placeholders for identity, address, contacts, customer code, date, custom fields, contracted services, and payment methods from the side panel. Test long values, companies, and individuals. The service-list placeholder depends on Contract Details configured in each service model.

A model may include shared attachments and create tasks for selected accounts when signing completes. Expose only partner-approved models to resellers.

Custom fields and reusable pages

Contract custom fields collect information that is not already available in the customer, service, or billing records. For each field configure a clear name, the correct input type, any selectable options, a safe default, an operator-facing description, validation rules, and whether completion is mandatory. A regular expression must be tested with both valid and invalid values before the field is used in a live model.

Before renaming or deleting a field, search every model that may reference its placeholder and inspect existing contracts. A removed or renamed identifier can leave an empty value in newly generated documents. Do not use these fields to store passwords, payment credentials, or other secrets.

Reusable pages centralize clauses or information blocks shared by several models. Give each page an unambiguous purpose and version, then inspect every model that includes it whenever the content changes. An update affects future generations; it does not silently rewrite PDFs already produced, delivered, or signed.

Attachment library

The shared attachment library is intended for PDFs that can be reused by multiple contract models, such as standard terms, technical schedules, or privacy notices. Record a meaningful filename, purpose, and version so that an operator can identify the correct document without opening several similar files.

Shared library files are different from attachments uploaded for one specific contract. Before replacing or deleting a library item, check the models and contracts that depend on it, the storage information shown by the module, and whether the same version must remain available for audit purposes. Deletion can be irreversible and must never be used as a substitute for document retention policy.

Creation wizard

Select Create contract and complete Customer, Mode, Details, and Services. Choose the correct customer first; Create new opens CRM creation and returns to the contract path.

Save and continue validates the current choices. The system rejects saving when the required mode or template is missing.

Template mode

Template mode creates the contract from a configured Contract or Form model. Select the model only after checking its title, version, intended customer type, visibility, reseller scope, clauses, placeholders, reusable pages, and linked attachments. Service-specific contract details must also be configured where the selected services require them.

Complete the wizard values, generate the document, and inspect the resulting PDF before sending it. In particular, verify issuer and customer identity, contract code, selected services, quantities, prices, recurring terms, notices, and signature markers. A successful generation confirms that the file was produced, not that its commercial content is correct.

External PDF mode

External PDF mode registers a contract document that was prepared outside the model engine. Upload the definitive file only after checking its origin, page order, readability, customer identity, dates, commercial terms, and signature areas. Use PDF/A when the organization's retention process requires it.

The upload does not certify the document, validate an existing signature, or make the file compliant by itself. The main contract PDF must remain distinct from supplementary attachments so that operators and customers can always identify which document is authoritative.

Details and custom values

Details include an operational name, optional external reference, status, and template or custom-field values. The system-generated contract code remains the internal short reference.

Use a clear name without unnecessary personal data. An external reference links another workflow but never replaces the internal identifier.

Services and commercial values

Service rows may retain offer, existing instance, address, billing cycle, price, quantity, discount, activation charge, VAT, and display order. Review recurring and one-off amounts before generating the PDF.

A service row does not necessarily mean that an operational instance already exists. A separate command can create missing instances after saving; review the resulting status, start, and billing schedule and never create duplicates.

PDF preview and download

Generate or open the final PDF and inspect it page by page before delivery. Verify issuer and customer identity, contract code, dates, services, quantities, one-off and recurring prices, taxes where applicable, clauses, notices, referenced attachments, page numbering, and every expected signature marker.

Keep the generated document conceptually separate from a provider-signed or customer-signed result. Download the exact version needed for the operation and verify that status, history, and stored file agree; the presence of a PDF alone does not prove that the signing workflow has completed.

Additional attachments

Additional attachments belong to one contract and supplement the primary document. Upload only supported file types and sizes, use a meaningful name, indicate purpose and version in the operational record, and make sure the file is intended for the same customer and contract.

These files can become visible through the protected Customer Area according to the configured workflow. Minimize personal data, never upload credentials, and verify dependencies and retention obligations before removal. Deleting an attachment can make the historical dossier incomplete even when the main contract remains available.

Status and cancellation

Non-signed means no recorded signature; Signed retains signature information and date; Cancelled records cancellation. Do not change state merely to simulate an external result.

Cancellation retains history, while deletion removes a record subject to application constraints. Prefer traceable cancellation for issued documents and review service effects.

Customer signature

The customer-signature flow presents the contract through the protected customer path configured by the ISP. Before enabling it, verify the document version, signer identity, authorized e-mail address and mobile number, required notices, consent text, and any embedded SMS OTP configuration.

The customer must review and perform the signature action personally; an operator must never complete it on the customer's behalf. After the action, confirm the final contract state, timestamp, audit events, and resulting PDF. A sent link or entered code is not sufficient evidence unless the workflow records completion.

OTP Service signature

When OTP Service is enabled, the contract can be prepared as an external signature dossier using the configured simple-signature or FEA process. Verify the mapped signer identity, contact channels, definitive PDF, signature points, provider credentials, callback URL, and the correspondence between local and provider identifiers before submission.

Follow the dossier through preparation, submission, customer action, callback, and final synchronization. Completion must update contract status and history and store the signed PDF or its verified reference according to the configured process. Do not create a second dossier merely because the callback is delayed; inspect the existing provider state first.

Send the contract

Use the available communication channels to notify the authorized recipient and deliver the configured link or attachment. Before sending, verify recipient addresses, communication preferences, language, message template, sender configuration, and the exact contract version. Avoid exposing the document through an unprotected link.

Check both the local timeline and the relevant sending queue or provider outcome. A local Sent event means that the delivery request was created; it does not prove that the message reached the recipient, that the document was opened, or that the contract was signed.

Linked payment method

A contract can retain the intended payment gateway and a supported customer payment method when the billing workflow requires it. Select only a provider already configured for the tenant and a method that belongs to the correct customer, then verify how that association is used by service activation, recurring billing, or contract automation.

The association records the chosen commercial path; it is not proof of a charge, mandate, or successful authorization. Never copy card data, bank credentials, or provider secrets into contract fields. Confirm the resulting link in the contract details and verify payment outcomes only in the dedicated payment and billing records.

History and audit

The event history records creation, updates, state changes, delivery, OTP preparation or completion, operator, and time. Use it together with the PDF, attachments, signature, services, custom values, and provider outcomes to reconstruct the practice.

Operator checklist

• Select the authorized customer
• Choose template or external PDF deliberately
• Review name, reference, and custom values
• Validate services, prices, discounts, activation, and VAT
• Distinguish contract lines from operational instances
• Inspect every PDF page and attachment
• Verify signer, contacts, and signature points
• Confirm provider completion, not merely preparation
• Protect payment data
• Check delivery provider and event history
• Use traceable cancellation when history must remain