Versions Compared

Version Old Version 9 New Version 10
Changes made by

Persia Xenopoulou (Deactivated)

Persia Xenopoulou (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Anchor
top
top

...

  • The classification determines the nature of the Financial Transaction, including its notation in the double-entry accounting system (debit or credit). Financial transaction type classifications are predefined in the system and cannot be overridden. The following Classifications are available:
    • Payment : Used to credit the account. i.e. deduct money from balance
    • Invoice: Used to debit the account. i.e. add money to balance
    • Credit Note: Used to credit the account. i.e. deduct money from balance
    • Refund: Used to debit the account. i.e. add money to balance (Can only be created if a negative account balance exists)
    • Invoice Cancellation: Used to credit the account. i.e. deduct money from balance
    • Payment Cancellation: Used to debit the account. i.e. add money to balance
    • Write Off
  • Financial transactions that are not already posted can be rejected if they have not been already posted, in which case they affect the balance of the account or cancelled in case they have already been posted. Posted transactions can be cancelled.
  • Posting of financial transactions depicts that the transaction is taken into consideration by system financial processes, such as its inclusion in the account's balance. Once posted the transaction can no longer be updated.
  • Transactions can be created with an intermediate step (before being posted) giving you the ability to make subsequent changes before posting.
  • Allocations are used to allocate credit financial transactions against invoices, in order to settle any outstanding amount. Allocations are applied automatically by the system based on the allocation principle specified in the system.
  • Invoices which are not expected to be settled, due to customer's inability to proceed with the settlement can be written off.
  • Payments can be moved between accounts

...

  • Allocations are always performed Against Item when the credit Financial Transaction refers to one or more specific invoices. 

    • If the credit Financial Transaction is referring to more than one invoice, then the Allocation is applied on those invoices using FIFO

    • If the amount to be allocated to the invoice is more than the un-allocated amount then
      • If there are other transactions which are already allocated against an invoice using FIFO, then they are de-allocated and re-allocated based on 'FIFO'
      • If the amount that should be allocated is still more than the unallocated amount of the invoice, then an amount equal to the unallocated amount is allocated against that invoice, setting the Allocation Type to 'Against Item' and the remaining amount of the credit Financial Transaction is allocated using FIFO.

    • Otherwise, "If the credit Financial Transaction amount is just enough to cover the invoice  then the whole amount of the credit Financial Transaction is allocated against the invoice, setting the Allocation Type to 'Against Item'

  • Allocations are always performed on a FIFO basis if the credit Financial Transaction is not referring to specific invoices.

  • Allocations are always performed on an Against Item basis when an invoice cancellation is posted.

    • In the case of an invoice cancellation, the cancellation is always allocated against the referred invoice and the Allocation Type is set to 'Against Item'

    • If other transactions were already allocated against the invoice, then they are de-allocated and allocated again based on 'FIFO'

  • When cancelling a payment already allocated against an invoice, the cancelled payment is de-allocated and the invoice is allocated again based on 'FIFO'
  • De-allocation is performed by creating an Allocation record with a negative amount and setting the Allocation Type to 'De-allocation'
  • The de-allocated record keeps a reference to the Allocation record that resulted in its de-Allocation. 

...

 

Panel
nameblue
titlePosting refunds after bank confirmation

Scenario 1.

Company ZX would like to create refunds once a month for its customers with a negative outstanding balance. The refunds are paid out to the customers through their bank account. Once the bank makes the payment to the customer's account, the bank sends a file back to Company ZX with all the successful payments. Company ZX can the update the customer's accounts balances.

Solution

User Process
All the refunds should be created in a 'Draft' life cycle state and be sent out to the bank. Once the file with the successful payments is received from the bank, the refunds should be updated to 'Posted', (automatically) updating the balance of the account by that amount.



Panel
nameblue
titleCancelling erroneously created Invoices

Scenario 2.

Company ZX would like to cancel 'Posted' Invoices that were created by error.

Solution

Configuration
An 'Operations' user should be responsible for cancelling Invoices created by error. 'Admin' users can configure different types of 'Invoice Cancellation Classified Transactions', in order to differentiate between reasons for cancelling an Invoice. For example, Cancellation Error Invoices & Cancellation Complaint Invoices.

User Process

The user should select the Invoice to be cancelled and create a Financial Transaction of the appropriate Type.

As a result, the Invoice will be available for future reference without affecting the account's Balance. The Financial Transaction 'Invoice Cancellation Type' indicates the reason the Invoice was cancelled. More detailed information can be viewed through the Cancellation's Issue Reason.

 

 

Panel
nameblue
titleMove Payments from Suspense Account to customer accounts

Scenario 3.

Company ZX imports Payments from the bank through an import file.
If the intended account is not found the Payment will be created in Company ZX system Suspense account. Back office personnel are responsible to manually check and move the Payments to the correct customer account.

Solution

User Process

Back office operators should follow the process described below:

Company's ZX Back office personnel should access Company's ZX suspense account daily. The action "Move to Account" should be executed for each of the Payments once the intended account has been determined.

 

 

Panel
nameblue
titleCompany ZX issuing an invoice with Discount

Scenario 4.

A customer of Company ZX purchases 2 Cards. He gets a discount for both, 15% for the first one and €20 for the other one.

Solution

User Process

Create a new Financial Transaction of Type Invoice. In the Items tab add 2 lines with the following information

  1. Card 1
    • Cost: 100
    • Quantity: 1
    • Discount
      • Discount Percentage: 15%
  2. Card 2
    1. Cost: 100
    2. Quantity: 1
    3. Discount
      • Discount Amount: €20

System Calculations:

    1. Card 1
      1. Subtotal: (100-15) = 85
    2. Card 2
      1. Subtotal: 80

 

 

Panel
nameblue
titleCompany ZX - Invoice Due Dates - Fixed Date

Scenario 5a.

Company ZX wants the 15th day of the month as the Invoice 'Due Date'.

Solution

Configuration 

The Accounts Receivable Credit Rule should be set up defining the nth day to be equal to 15 after x months are equal to 1.

User Process
When posting the invoice:

  • If the user defines a date, the system either validates the date or returns an error message. e.g. In case the Date of Posting is on 20 May:
  • If the 'Due Date' is Set to 21/05 an "Invalid Due Date" message is returned from the system
  • If the 'Due Date' is Set to 16/06 an "Invalid Due Date" message is returned from the system
  • If the 'Due Date' is Set to 15/06 no error message is returned and the 'Due Date' is saved successfully

If the user leaves the 'Due Date' empty the system will set it to 15/06


Scenario 5b.

Company ZX would like to have the 'Due Date' always set 10 days after the 'Posted Date'.

Solution

Configuration
 The Accounts Receivable definition 'Credit Rule' should be set up defining X Days after the transaction's 'Posted Date' ( X = 10)

User Process 

When posting the Invoice:

If the user defines a date, the system either validates the date or returns an error message. e.g. In case the Date of Posting is on 20 May:

  • If the 'Due Date' is Set to 28/05 an "Invalid Due Date" message is returned from the system
  • If the 'Due Date' is Set to 31/05 an "Invalid Due Date" message is returned from the system
  • If the 'Due Date' is Set to 30/06 no error message is returned and the 'Due Date' is saved successfully

If the user leaves the 'Due Date' empty then the system will set it to 30/06


Scenario 5c

Even though Company ZX would like to allow agents to set the 'Due Date' at a maximum of 10 days after the 'Posted Date', it requires the System to set the 'Due Date' to 5 days after the 'Posted Date'.

Solution

Configuration

The Accounts Receivable definition 'Credit Rule' should be set up defining X Days after transaction's 'Posted Date' (X = 10)

Proximity range should be set to -5

User Process

When Posting the Invoice:

If the user defines a date, the System either validates the date or returns an error message. e.g. In case the Date of Posting is on 20 May:

  • If the 'Due Date' is Set to 28/05 no error message is returned and the 'Due Date' is saved successfully
  • If the 'Due Date' is Set to 31/05 an "Invalid Due Date" message is returned from the system
  • If the 'Due Date' is Set to 30/06 no error message is returned and the 'Due Date' is saved successfully

If the user leaves the 'Due Date' empty then the system will set it to 25/05 (the smallest allowed 'Due Date' based on the set 'Proximity Range')

 

Panel
nameblue
titleMake an online payment

Scenario 6a.

Company ZX allows its customers to make payments using an online payment gateway

Solution

Configuration 

  1. Financial Transaction Payment Methods
    Configure the payment method that will be used for making payments through the online Payment Gateway
  2. Financial Transaction Payment Type
    Configure a  payment transaction type and add the Payment method as allowed
  3. Generic Gateway Provider
    Configure the provider and select the allowed payment methods and the payment types that will trigger payments for the provider
  4. Accounts Receivable Payment Preference
    Configure an accounts receivable payment preference and relate it to payment gateway
    Select fields which will be available and/or mandatory and will be entered by the user when selecting the payment preference on an accounts receivable
    Set one of the selected fields as an identifier which will be used as a unique identifier (this could be an account number or a card number)
  5. Accounts Receivable Definition
    Add the payment preference in the allowed preferences of the account

User process

  1. Accounts Receivable
    Enable the gateway payment preference on the accounts receivable
    Provide the unique identifier (this could be an account number or a card number) and any other required information as configured in the payment preference
  2. Financial Transactions
    1. Create a transaction and select the payment type you created
    2. Select the payment method which is related to the payment gateway
    3. The system will load the identifier you have provided in the accounts receivable payment preference
    4. Select it and proceed with saving the payment

 

Note

Refer to Generic Gateway and Accounts Receivable manuals for more information

 

 

Panel
nameblue
titleFIFO Versus FIFO & Against Item Principle

FIFO Principle

In the following example, we have one Invoice which has already been allocated to a Credit Note using the FIFO model. After a second Invoice is created the first Invoice is cancelled.

  1. Invoice 1: €20
  2. Invoice 2: €10
  3. Credit Note 1: €20
No
Action
Intended Invoices
Allocations
Allocation Type
Allocation amount
Unallocated Amount
1Creation of Invoice 1N/AN/AN/A  
2Creation of Invoice 2N/AN/AN/A  
3Creation of Credit Note 1N/ACredit Note 1 allocated on Invoice 1FIFO20 
4Cancellation of Invoice 1Invoice 1

 

 

   
4a

Credit Note 1 de-allocated from Invoice 1

N/AN/ADe-allocation20 
4b

Creation of Cancellation Invoice 1

N/AInvoice 1 allocated on Cancellation Invoice 1Against Item20 
4cCredit Note 1 allocated on Invoice 2N/ACredit Note 1 allocated on Invoice 2FIFO1010

 

FIFO & Against Item Principle

In the following example, we have 3 Invoices of which the 2 first are allocated from Credit Notes that were intended for the invoices in question. The first Invoice is then cancelled.

  1. Invoice 1: €10
  2. Invoice 2: €20
  3. Invoice 3: €20
  4. Credit Note 1 : €10 (Intended Invoice: Invoice 1)
  5. Credit Note 2 : €20 (Intended Invoice: Invoice 2)
No
Action
Intended Invoice
Allocations
Allocation Type
Allocation amount
Unallocated Amount
1Creation of Invoice 1N/AN/AN/A  
2Creation of Invoice 2N/AN/AN/A  
3Creation of Invoice 3N/AN/AN/A  
4Creation of Credit Note 1Invoice 1Credit Note 1 allocated on Invoice 1FIFO and Against Item100
5Creation of Credit Note 2Invoice 2Credit Note 2 allocated on Invoice 2FIFO and Against Item200
4Cancellation of Invoice 1 

 

 

   
4a

Credit Note 1 de-allocated from Invoice 1

 N/ADe-allocation100
4b

Creation of Cancellation Invoice 1

 Invoice 1 allocated on Cancellation Invoice 1Against Item100
4cCredit Note 1 allocated on Invoice 3 Credit Note 1 allocated on Invoice 3FIFO1010

 

 

Note
titleNotes
  • If you are using a previous release, view CRM.COM Release Changes.
  • Use the Financial Transactions WEB API to create and manage Financial Transactions from an external system, such as a customer portal. View Credit Notes, Refunds, Payments and Invoices WEB APIs for a complete list of actions available through the WEB API.

Back to top 

Glossary  

CRM.COM TermDefinition
Accounts ReceivableA ledger of the financial transactions carried out between a company and its customers, such as invoices and payments.
Payment GatewayAn e-commerce application service provider that authorises credit card payments for e-businesses.
StripeA build in integration of CRM.COM and Stripe payment system, which can be used  to accept online customer payments.
WalletA financial account which allows customers to use a credit balance to fund transactions within CRM.COM.
Wallet TransactionA financial event used to debit or credit the wallet
Normal Billing RunA mechanism that is used to charge customers for goods and services provided over a period of time.  Each run is usually performed on a monthly basis and issues a bill including the invoices and credit notes associated with customer subscriptions or jobs.
Rewards ParticipantThe customers who have signed up for Rewards or have been automatically selected to participate.
Quick SaleIs the process through which users are able to easily and quickly sell physical goods to customers and invoice them the same time. 
VouchersVouchers are an alternate way of paying an amount of money across CRM.COM modules. Customers can buy Vouchers and use them to perform payments within the system, while optionally, limitations can exist on the products money can be spent on. 

 

...