Friday 9 September 2016

Using KwaMoja for not for profit accounting - Part 2

According to the thread on the mailing list at http://npoacct.sfconservancy.org/ the second thing that an NPO accounting system needs is a method of tracking expenses against donors and projects. Can this be done in KwaMoja? Yes, easily.


Expenses can occur in three different ways:
1 A direct payment to a person or organisation
2 A suppliers invoice being generated
3 Through a petty cash re-imbursement system.

Direct Payment System

In KwaMoja payments can be made against a general ledger code in any currency, and from any bank accounts. You can make a payment in USD from a EUR bank account whilst your main accounting currency is KES. KwaMoja will make the appropriate Exchange rate entries for you taking out the complexities.














As can be seen the payment can be tagged against any number of tags, from zero to many. So, in this case it is tagged to the research project the vehicle is used for, the donor who is financing it, and the vehicle the insurance is for. This means we can report against any of those tags, producing a report showing everything for that donor, a report for all the project receipts and payments, and a detailed costing report for each vehicle.

The double entry will be of the form:
Dr Expense account
       Cr Bank Account

Supplers Invoice

Secondly expenses for a project can come in via a suppliers invoice. Firstly the supplier is chosen and then you click the link to generate a supplier invoice.







Clicking on the general ledger button takes us to a new screen allowing us to enter the details of the expense.







Here you enter the GL code for the expense, the amount and as before, from zero to many tags for each line of the invoice.

Petty cash reimbursement system.

This is the preferred method for entering expenses incurred by employees of the organisation as it allows for close control over what is spent, authorisation at every level, and the tagging of expenses to particular projects and donors.

Overview

The Petty Cash module enables employees to submit expense claims directly into the system that can then be authorised by their immediate supervisor.
Petty cash expenses are controlled in a friendly way, enabling all employees (including those without accounting knowledge) to enter their expenses and get paid for them.
The Petty cash module uses a temporary GL table (pcashdetails), containing all information about payments and expenses entered as petty cash. When cash assignments or expenses are authorised by a supervisor, they are posted into the gltrans table and flagged.
Once any transaction in the petty cash system has been posted it cannot be modified, edited or deleted in any way. Once posted, that's it.

Setup General Parameters

Set up expenses

Definition of expenses allowed to be used in the Petty Cash system.

This table is used to isolate non-accountant users (most of workers/users of KwaMoja) from the technical details and names used in accounting. E.g.: Code Expense: VEHFUEL
So when the system posts a petty cash expense against expense code VEHFUEL, it will be posted against the GL account code 7600. You can define a default tag for this expense code, though it can be overridden when the actual expense is posted.

Set up types of tabs

Different kinds of users have different privileges. CEO can spend petty cash money on a different way than a truck driver does.



Set up expenses allowed for type of tab The link between types of tabs and expenses.




















Here we need to define which expenses are allowed to a certain type of tab. This table is used to prevent users assigning expenses for expenses not allowed. as example, a user with role "member of parlament" could have a tab of a type "all allowed, including night drinks in a pub", while a user with role "hard worker" could have a tab of a type "transport to workplace" only, so the system can achieve a better control of each one's expenses.
This is where the organisation defines here policy of petty cash payments.

Set up tabs

A petty cash tab contains:
  • Tab Code
  • User: User of the tab. Who is spending/receiving moeny for petty cash expenses. Must be a KwaMoja user.
  • Type of tab: As previously defined
  • Currency: A tab will handle money in one currency only. So users allowed to spend in 2 or more currencies (e.g. international commercial team) will have 1 tab for each currency
  • Limit: Maximum amount the user can spend, to have a better control. Nowadays it only issues a warning of the supervisor, but can be coded to work differently (better)
  • Authoriser: User supervisor of the petty cash user. User authorising (or not) expenses done, checking money is spent wisely and asigning cash to users
  • GL Account For Cash Assignment: GL account where the cash assigment comes from. It must be a bank account, so when assigning cash to a tab, the system will deduct the amount from the bank account and increase the petty cash account
  • GL Account Petty Cash Tab. In GL we should have an account (one per currency) to reflect "amount of money distributed among employees" or "Petty Cash Account". This is the account where the money goes after a cash assigment is done or where the money comes where an expense is posted

At this point we have the system ready to work.

Workflow

Assignment of cash

The supervisor (authoriser) gives money cash to an employee to be used as petty cash. In script PcAssignCashToTab.php we record this fact.
Supervisor can select only the tabs he/she is supervisor. Must specify amount, date. There are 2 additional fields:
  • Notes: For any further detail needed to remember
  • Receipt: In case the company has a physical receipt, or any proof, the code, number, etc of this receipt, to help solving disputes later on



At this stage no tranasction is posted in gltrans table, only at pcashdetails we write down: "Supervisor gives to user X (tab really), Y dollars on date D".
Cash Assignments can be edited and deleted before are authorised. Once authorised and posted can not be modified in any way.
Note this assignment can be at the end of the tab where the employee can be re-imbursed.

Expense claims

Employee will go out and spend money. Then will report to KwaMoja these expenses in script PcClaimExpensesFromTab.php
Employee will select a tab (from his/her own tabs). And then records details of all expenses incurred:
  • Date
  • Code of expense (from the list his/her tab is allowed depending on the type of tab involved)
  • Amount
  • Notes: For any further detail needed to remember
  • Receipt: In case the company has a physical receipt, or any proof, the code, number, etc of this receipt, to help solving disputes later on.



At this stage no tranasction is posted in gltrans table, only at pcashdetails we write down: "User U reports spending X amount in concept C on date D".
Expenses reported can be edited and deleted before are authorised. Once authorised and posted can not be modified in any way.

Expense authorisation

Supervisor will need to authorise expenses and cash assignemnts reported.



The supervisor must select a tab he/she is supervising
If there is any assignment or expense not authorised yet, it can be checked and if correct just tick it. If incorrect or in doubt (an employee claiming 10.000.000 USD for fuel car) he can call/email/report him and sort it out. Because it's not authorised yet it can be modified (to 100 USD...)
Once the update button is pressed and there are some entries ticked, then GL posting occurs.

Notes

Users

All users must be KwaMoja users. So employees can login into KwaMoja only to claim / report their expenses, if allowed.

About advance payments

About advance payments or refunds, we always run "open tabs", so employees asks for money first, and later on they spend it (we hope in an appropriate manner) and then report expenses incurred. Any difference will be settled "next report" or "next cash assignment".
That's the idea keeping expense report and cash assignment separate, as it's flexible and fits all situations



Thursday 8 September 2016

Using KwaMoja for Not For Profit (NPO) Accounting - Part 1


Using KwaMoja for not for profit accounting - Part 1

After recent discussions on the mailing list of http://npoacct.sfconservancy.org/ regarding how to do accounting for non profit organisations (NPOs) I thought it would be helpful to write some articles on how to go about it using KwaMoja ERP.

I am going to assume that the organisation already has a suitable chart of accounts and that they have loaded it into KwaMoja.

The company preferences page has a setting to denote whether the organisation is an NPO:


This should be set to Yes as above.

The first of these articles will be regarding the treatment of donations. For the sake of the accounting, these can take 3 forms,

1 Monetary donations
2 Donations of stock items used in the running of the organisation (for instance pharmaceuticals in the case of a hospital)
3 Donations of fixed assets (for instance a CT scanner for a hospital)

Monetary Donations

Monetary donations are easily dealt with as a bank account receipt, accessible from the general ledger module. 


This is fully multi currency so that if the organisation accounts in Kenyan shillings, donations in GBP can be received into a USD bank account. As can be seen above each donation can have zero to many tags attached to it. In the above example the donation has been tagged to a Malaria research project, and also to the KwaMoja foundation.

This enables us to produce reports on all transactions for the Malaria research project, but also for tracking donations received from the KwaMoja foundation. The double entry record for the above would be:



Dr Bank Account
          Cr Monetary donations received account

Donations of stock items


In order to correctly deal with donated stock items we must receive the goods through the usual process. Firstly we create a zero value purchase order as below:



The items are then received in the same way, with the value still being zero



The final step is to enter an invoice for this supplier against this GRN. If the organisation is setup as an NPO (see top of this article) then a further column is created to contain the “Fair price by unit”. This is needed as the current accounting standards require donated articles to be valued at a “Fair value” - as defined in Statement of Financial Accounting Standards (SFAS) 157.


Each line can be given a tag on which it can later be reported.


Every stock item is associated with a stock category and this assigns GL codes for various aspects of those stock items. If the organisation was setup as an NPO (see top of article) then one of these options is a GL code for donations of those items:


Now when the supplier invoice above is posted the inventory will increase by the fair value of that item. The double entry for this will be the donations account for the category that item is associated with. The full journal will be:

Dr Stock of pharmaceuticals
      Cr Donations of pharmaceuticals

Once the original setup is in place any donation is done as easily as any other acquisition of materials.

Donations of fixed assets


The final method of donations is for receipt of donated fixed assets. Like stock items, all Fixed assets are members of a fixed asset category, and this category is used to assign various GL codes to a fixed asset. If the organisation is flagged as a NPO then one option is for a GL code for donated assets of this type.


Now as we proceed to enter the fixed asset in the normal way via a suppliers invoice we will be prompted for a “Fair value” of the asset - as defined in Statement of Financial Accounting Standards (SFAS) 157.


As can be seen any number of tags can be selected against this donation. When the invoice is posted an asset gets created with an initial value of the “Fair Value” and the credit instead of being the bank/cash accounts will be the account chosen as the “Donations” account in the Fixed asset categories screen.




This deals with all the methods the organisation could receive a donation. In the next article I will deal with the process by which the organisation deals with expenses, and associates them with different projects, and categories.

Friday 29 July 2016

A call for developers, translators, documenters and medical professionals

Care2x (http://www.care2x.org) is a fully featured open source hospital information system (HIS). It is used in many hospitals all around the world. However in recent years for various reasons activity on the project has slowed and has practically come to a standstill. Another problem is that there are a number of different versions of Care2x around.

However the code did not run at all on PHP 7.0 and as more and more server operating systems are distributed with PHP 7.0 the project was in danger of dying. This would have been a major shame as it is a great application, and the developers have done amazing job in the past.

A few of us decided we didn't want this to happen so have been working on bringing the code base up to date. Our work so far can be seen here (https://care2x.kwamoja.org/) The user name/password is admin/kwamoja. This server is running PHP 7.0 and the code should now work on both PHP 5.x and 7.x versions. The very latest code can be downloaded from here (https://github.com/care2x/care2x/archive/master.zip). Please note this is still being updated very regularly and is for testing purposes.

I have been working on integrating this code with the medical branch of the KwaMoja open source ERP (https://medical.kwamoja.org). If this integration is not required then both will run fine as standalone applications.

We have now reached the point where we need help. In no particular order we need:

1. Developers: Care2x is written using PHP/MySQL/Javascript. If you know any of these, or just want to learn, then go to github, clone the repository and get coding. There is a mailing list for developers that you can subscribe to here (https://lists.sourceforge.net/lists/listinfo/care2002-developers) where you can ask questions and get any advice you need to get going.

2. Translators: Translation files are stored under the language/ subdirectory. Each language is then stored under a two letter sub-directory denoting the language. So language/en for English, language/de for German etc. Each of these files contains variable assignments such as this from language/en/lang_en_departments.php:
 $LDHeadlines='Headlines'; 
Then there should be a corresponding entry
$LDHeadlines='Nachrichten';    
in language/de/lang_de_departments.php and in each of the other translations. What is required is that people check that the files contain the same variables (at the moment they don't) for each translation, and where they don't new variables with appropriate translations are done. If somebody wishes to create a new language translation they just need to create a new subdirectory under the language and get translating.

3.Documenters: Like most open source projects Care2x could always do with improved documentation. There is an old wiki here (http://wiki.care2x.org/index.php?title=Main_Page). We need people to read this documentation, update with regard to the new code, and add new documentation.

4. Medical Professionals: Care2x is intended to be used by medical professionals. It would be great if such people can use care2x, especially with regard to the work flow, and make any suggestions (though we don't make any promises on implementation!). Any suggestions can be logged on github here (https://github.com/care2x/care2x/issues). This includes any bugs that are found. As said previously this code is still being developed so will contain bugs. Please try to put an appropriate label to each issue to help us resolve them.

Tuesday 11 November 2014

Introducing Colin

Announcement

I am pleased to announce the first release of Colin, our integrated testing suite for KwaMoja. This software automatically controls KwaMoja using the libcurl libraries, and compares the results against expected results, outputting the results in a nice web viewable format. The tests can be batch run, so hundreds of tests can be automatically run and their results viewed.

Technical Details

The suite contains a a library of functions for automating a complete KwaMoja session. There is a function to login, to choose an appropriate module, to choose an appropriate menu item, to run any number of options within that option, and to logout. Each step of the way, various tests are run for PHP errors/warnings/notices etc and any of these are recorded. All links in a page are verified to make sure they are not broken. When a page carries out some action against the database the result is verified. More verifications will be put in, software of this kind is never complete.

Output

The output from a Colin session can be viewed through your web browser, and looks like this:
If there are any details clicking on the "Details" link will bring up a new page showing these:
 
This will include any screenshots automatically saved by Colin:

Can I get a Colin of my own?

Yes. Colin is released under the GPL v2.0 license and is obtainable from my github site https://github.com/timschofield/colin

Why Colin?

Why not? It just seemed like a good name to me!

Monday 3 November 2014

Plagiarism

This page is written in response to the lies that +Phil Daintree has written about me, and spread on the internet. Despite years of searching he has been unable to find anything I have written that is untrue, and he has had to resort to vague generalities, faked emails, and badly fabricated screenshots (you can see the joins if you zoom in using any bit mapped image editor). +Phil Daintree is welcome to make any comments to these pages, as he has done in the past. If I agree with what he says I will amend my writings, if I do not agree I have allowed his comments to stand next to mine so that people can make their own judgements. I have every confidence in the intelligence of readers to make a sensible judgement based on the facts. +Phil Daintree will not allow me the right of reply to any of the lies he has told about me. It seems to me significant that he realises that if people see both sides of the argument they will see through his lies.

In the world of open source software a lot of emphasis must be placed on honesty and trust. You have to be able to trust that when you submit code to the administrator of a project that the code is released under the correct license and that is correctly accredited to you. This accreditation is not a question of ego but of common decency and of honesty.

Whenever code gets added to KwaMoja I go to great lengths to attribute the code to the correct author as can be seen here

All the work we do in KwaMoja is made available to the webERP project, however recently the project admin +Phil Daintree has been consistently attributing the work to himself rather than to the actual author.

For instance +Fahad Hatib did some considerable work to remove the $db variable throughout the code base, and I personally made that available to +Phil Daintree.

This work was committed to webERP here. Instead of correctly attributing that work to +Fahad Hatib Phil decided to claim the credit for this work to himself:


Unfortunately this seems to be typical of the recent dishonest behaviour of the leadership of the webERP project.