Accounting and Payment Module

Accounting and Payment Module

The goal of this extension is to be able to register any incoming or outgoing payment made by our company and associate that payment with other entities in the vtiger CRM application. The extension permits to register payments that we will receive or will have to make in the future so it is easy to create a report on payments forecast. With a little effort we could calculate cash-flow or even the money in the cash register at the end of the day.

This module permits us to register payments made against any of the following entities:

  • Invoice
  • PO
  • SO
  • Quote
  • Campaigns
  • Potentials
  • Trouble Ticket
  • Projects and Project Tasks
  • Assets
  • Products
  • Services
  • Service Contracts

by an Account, Contact, Vendor or Lead

The information fields that can be saved are:

  • Assigned user
  • Reference: free text for payment reference
  • Date: date payment is registered in the system
  • Due date: date we should get paid or pay
  • Paid: check box indicating if payment is done or not. Used for filtering and reporting
  • Credit: check box to indicate if we are receiving or paying (debit)
  • Payment mode: dropdown selectbox (Cash, Check, Visa,…)
  • Payment category: dropdown selectbox, basically open for unforeseen usage but could be very useful for filling up with accounting groups for ledger control
  • Amount paid/received: how much we are given or how much we are giving
  • Cost how much does it cost us to deliver this service
  • Benefit: is automatically calculated. Useful for reporting.
  • Related User: Used to assign the money movement to a user. Very useful for calculating commissions.
  • Description: free text for comments

You can use vtigerCRM's reporting engine to get reports on this module.
The module is vtlib compatible and respects the normal vtigerCRM features as role permission control, custom fields, picklist editing, import/export, …

This module (out of the box) is not related to any other entity, in other words you can't go to an Account's “More information” screen and see all the payments made or pending. When we install this for our clients we customize the relations based on their needs. Some need to see the payments of an account, others on the invoice. So this is one of the many features that can be added from this starting point. Others could be:

  • prepayments are accepted and automatically inserted when creating a SO or Invoice (for example)
  • balance due is automatically calculated and printed on PDF
  • relation of payments made on SO or Invoice show up on their “More Information” tab

Without these enhancements you would have to create a new payment each time a payment is made. The enhancements I propose are just to make workflow easier and are very dependent on how each company works, the payment module “as is” is already very useful if you need to control the money moving around in your company.

The module has:

  • a basic Payment History tab where information about the changes can be consulted.
  • a simple receipt output which is a starting point to customize the one you may need

We also have this module integrated into our business intelligence integration for special reporting to get weekly, monthly and yearly ratios of the money in the company. Among others, like OLAP navigation of the payments.

We also have a simple patch that enhances the module with capability to easily support partial payments. We add a few fields on the invoice and have the payment module automatically fill in these fields on each payment. We add an amount paid and an amount due, as payments associated to the invoice are marked paid these fields get filled in, so you can see the pending and received amounts easily, and since they are normal fields you can report on them directly in vtiger CRM reporting system.

The partial payment workflow would be something like this: you create an invoice for the total amount, you create the agreed payments, for example, 30% on the day of creation, 30% in 30 days and 40% in 60 days. You mark the first payment as paid and the others are pending. The amount due on the invoice shows 70% of the total. With this simple scheme you can report on pending payments on any dates, or on payments due, or on pending payments, …

Total and Pending Payment control on Accounts and Contacts adds three new fields on the module that sum the total amount of payments made, pending and the balance due.

BluePay Integration

Thanks to BluePay Credit Card Processing Company we have integrated online payment processing of any payment record.

Both Credit Card and ACH transactions are supported.

With this new version of the payment module you will be able to save on your Account's record a payment token, associated with their credit card or ACH transaction information, and then process any payment that is associated to the account. The actual credit card or ACH information is not stored in your vtiger CRM.

We add a new action on the account which launches an artificial payment of $0 and asks for the accounts charge information. That is sent to the BluePay processing center and stored there, NOT in vtiger CRM. We receive a Blue Pay token which will be used to execute future payment transactions.

We also add a new action on the payment records. This new action will first evaluate if the selected payment record is associated to an account with a valid token and the payment is not already marked paid. If this is the case a payment transaction will be launched against BluePay and the result will be saved in the payment record. If the payment was processed correctly the paid checkbox will be marked and then, in any case, the result codes of the transaction will be saved in the description field of the payment for future reference.

As an additional feature, this version blocks paid payments. If a payment is marked paid it cannot be edited. This behaviour can be changed through the $Block_paid variable in modules/CobroPago/bluepay_config.php

Installing and Upgrading

Installing/Upgrading this new version requires some additional steps that the prior version did not require, basically to add the account action and configure your BluePay information.

  • You can install or upgrade the module using vtiger CRM module manager. This will install all the code you will need and the basic functionality of the payment module.
  • Then you have to copy the modules/CobroPago/bluepay_install.php file to the root of your vtiger CRM install and execute it once from the browser
  • Now edit the modules/CobroPago/bluepay_config.php
    // BluePay Account Id, fill with yours
    $BLUEPAY_AccountId = '';
    // BluePay Secret Key, fill with yours
    $BLUEPAY_SecretKey = '';
    // Operation mode, TEST or LIVE
    $BLUEPAY_Mode = 'TEST';
    // Prevent cyp edit if paid
    $Block_paid = true;

    As you can see the variables are self explanatory


  • Payment module: free, open source, donations are very necessary, please consider maintaining our effort
  • Payment relations: make a donation of any amount and I will send you the script
  • Partial Payment control on invoices costs 45 euros.
  • Partial Payment control on purchase orders costs 45 euros.
  • Total and Pending Payment control on accounts costs 45 euros.
  • Total and Pending Payment control on contacts costs 45 euros.
  • Total and Pending Payment control on vendors costs 45 euros.

Our paypal account: paypal (at) tsolucio (dot) com

Thank you

Some demos

Demo of Total and Pending Payment control on accounts

The Adobe Flash Plugin is needed to display this content.

Automatic Partial Payment with vtiger CRM Workflows

vtiger CRM 5.4.0 has introduced a new workflow functionality: Creation of Entities. With this functionality we can create new records in a module when an event is launched in another related module. For example, we can create payment records when we create an invoice automatically.

This is a very powerful feature in many modules but has special relevance in conjunction with the partial payment extension in our module. For example, we could add a picklist of payment methods to our invoice and have all the payments directly created for us depending on the method. Let's suppose we have a payment method of 30% on creation, 30% after 45 days and 40% after 75 days. We could create a workflow that automatically created the payments for us using the workflow system.

Here are a few screen shots of how that would look (more or less):

Now the bad news The workflow create entity feature will only creates entities that are directly related to the record we are inserting and it will automatically relate the two records. In this case, it will automatically relate the invoice and the payment but it will not relate the account. So you will have to manually mass edit the payments and set the account/contact.

We have a patch that fixes this and automatically sets the account. Please send 6 euros to our paypal account and we will send you the code

Partial Payment Mass Creation

This is an idea that a potential client has given me to help create partial payment records and also to easily distribute a payment made against various invoices. This extension would permit to receive a payment and distribute it's amount among various invoices helping you make sure the amounts sum up correctly or simply create three payments against the same invoice according to the payment details reached with your client.

Here is a screenshot of what this would look like.

We are currently looking for funding for this extension

Payment Mass Creation Discussion

ax Accounting to TSolucio Payment Control

We have created a simple process to copy all your payment information from ax Accounting to our payment control module.

Both modules are very similar in functionality, but not in the form of implementing that functionality. We think our modules is much more inline with vtiger crm philosophy. This makes the code easier to maintain and presents an inexistent learning curve for the users as they already know how to use vtiger crm. It also means that it is less eye-catching as it is less colorful (as vtiger crm itself).

In any case both modules solve the problem and this process we give away here is mostly for those people who want to move away from axAccouting for whatever reason. Since the modules are not identical I will try to explain some of the sacrifices that need to be accepted.

The main change is in the way partial payments are handled. In axAccounting you create one payment record which presents the whole of the amount to be collected and then add partial payments to it. The way I see it there is no other module in vtiger crm that works like this, at most invoices have a similar (master-detail) relation and we already know how hard it is to customize that module, so this makes their module harder to maintain, with a lot of special code to handle that new way of working, this also breaks the user experience. I don't know if their user experience is more user friendly or not, but it has nothing to do with the way all the rest of the application works, so there are additional questions asked and more support needed.

The way we approached partial payments is that the full amount to be collected is reflected on the sales order or invoice, then each payment record you associated to the invoice represents a partial payment, you establish it's relation as you do with any other module, since each record is just a normal record, related lists, filters, reporting, … all follow the vtieger crm way.

So the migration process we have created will actually migrate the partial payment records contained inside the axAccounting payment records, not the main full amount record. Obviously most of the information there will be copied to payment control records as we strive to not lose any information. In other words we will flatten the existing structure, relating each partial payment directly to it's SO or invoice.

We add a currency picklist to the payment records and copy the information into it but this does not make the payment module multi-currency. There are many more things to contemplate in making the module multi-currency then adding a picklist. We simply do not lose the information.

We also add a new auto-numeric reference field and create the necessary custom fields for the migration.

Finally there is one last thing to consider.

The rest of the fields are already equivalent and will simply be copied.

We have left out the special graphical reporting screen which can probably be obtained in 5.4.0 with the native reporting and graphic support, and also the mass partial payment creation feature which, hopefully we will implement some day following the guide line of the Partial Payment Mass Creation section


We have a vtlib version for 5.4.0, 5.3.0. 5.2.x and 5.1. This was working for 5.0.4 but it is discontinued, we recommend upgrading.

By default it is NOT related to any other module as the relations and other actions depend on the necessities of each user. We have a script to establish the relations.

The payment module only registers payments, in or out, you have to manually add the payments in the module.
For example, you create an invoice, then you go to the payments module and add a payment, a client pays a partial sum of an invoice, you go to the payment module and add a payment (in), you receive an order and pay the shipping company so yo go to the payment module and register the payment (out).

If you register all the payments and relate them to the account and invoice/SO, then you can obtain reports on the amounts paid and received.

That is what you can see on the demo and what the payment module is for.

Now from this starting point we can adapt the module to your companies needs.

If you want to automatically create a due payment every time an invoice is created we have to add this. If you want to be able to go to the “more information” tab on any account and see a relation of all his payments, we have to add this in, etc….

So our payment module gives you a starting point from which to register all payments, from there we can help you make things easier by customizing some processes.

This is similar to the question above. This module gives you a starting point from which you can adapt to your company, the exact same philosophy we follow with the whole vtiger CRM application.

In this case I would not recommend creating two invoice for the same concept. What we usually do to follow partial payments is add some process to the invoice. Each time a payment is registered against an invoice we update a new custom field called “Amount Due”, once you have this field you can report and easily obtain invoices with some pending amount. We then add some more process and change the status of the invoice to Paid once the amount due falls to zero. So our “most used” implementation creates invoices as you usually do in vtiger CRM and then the payments module registers the payments made to control the pending invoices and their state.

Although this is what I would recommend and seems to be the easiest way to use the module we can adapt it to your specific business process needs in any way you may see fit.

This implementation IS NOT included in the base module.

I understand, thing is that since this is open source we get many requests for just a basic starting point on which others construct their own needs, so the gadget is useful to some. Also since, the other features require code modifications it makes distributing the solution a bit more complex so we try to avoid that.

In any case, as to your request, you need all three options: the module, the relations of this new module and the partial payment control.

With all three you will be able to manage partial payments, linked to invoices and other entities, you can already flag an invoice as paid or partially paid as these are just states that you create on the invoice, to send reminders isn't really something associated to the payment module but directly to the invoices, you can use the workflow extension to send the reminders, although that is limited, but gathering a list of unpaid invoices based on date is easy with a filter or report, sending reminders is a bit more difficult, but we can discuss a solution if necessary.

Have a look at the Online Demo, define what is missing for it to accomplish your needs, or simply put together a list of needs and send them to us. We will send you a quote to get vtiger CRM doing what you need.

English, Spanish and French, among others are supported at the moment

It is NOT multi-currency.

It is platform independent, but works better in linux :-)

The payment module that you can download is not integrated with other modules automatically, that is, if you create an invoice, and you associate a partial payment, this fact is not reflected on the invoice. Obviously, you can go to the more information tab and see the payments, but there will be no change in the fields of the invoice. The extension of partial payments, adds some new fields on the invoice representing the amounts paid and the amount due automatically, or if you make a payment associated with an invoice, it automatically updates the amount paid and the balance, and if the outstanding amount is 0 it will change the status of the invoice to paid. This greatly facilitates the reporting of outstanding amounts.

The other extensions is similar, it adds some fields to the account where totals and pending amounts are registered, independently of the invoices or amounts pending to be paid. These calculations are done automatically when payment records are created/edited.

Both are independent, and can be acquired separately

  • first invoice: 30% of the amount
  • 2nd invoice: 30% of the amount
  • final invoice: 40% balance

Payment control is not for generating various invoices. The idea is that you generate one invoice for the full amount and receive partial payments until the invoice is fully paid. The extension controls the amounts paid and due on the invoice. You can then create special PDF outputs for invoices with pending amounts and fully paid ones.

Obviously you can create the three invoices and associate a payment to each one. As you mark the payments as paid the invoices will change their status so you can easily control the pending ones also with this system.

We have some clients that do this: create the first invoice and associate the three payments. The first payment cancels the first invoice. The other two payments are pending and related to the first invoice. When time comes to create the second invoice, they create the invoice and associate the second payment to this one.

No, this must be programmed either in the PDF of vtiger CRM or using PDFMaker functions. Using PDFMaker, you can generate a PDF for each payment or you can create a custom function that includes all the Payments directly in the PDF of the invoice in the format you need. We have created several of these functions for different customers with their specific formats so it should be easy for us to create one to cover your requirements quickly.

We use and recommend PDFMaker for this. It is, by far, the easiest and fastest solution. You can edit the current output in this file: modules/CobroPago/recibo.php but that is really direct database access, totally obsolete code that we just haven't eliminated because it works, but frankly, you are complicating your life not buying PDFMaker. If you appreciate your time at all, and consider that you could be doing better things (taking a walk with your friends/family, attending your clients,…), buy PDFMaker.

This is hard to do in vtiger CRM, what we have done is implement a “usual” use case. Try going to the related list of an invoice and adding a payment, you will see that most of the fields are filled in for you. This happens with sales order also (at least). The idea is that you create an invoice and once you are on that invoice you go to it's related list and create the payments from there.

vtiger CRM has some translation limitations in many parts of the application so the module isn't correctly translated in all places. By adding

'CobroPago' => 'Payment',
'SINGLE_CobroPago' => 'Payment', 

To your language file (with the correct translations), you should get them all correct