Archive for March, 2011

HR Attendance analysis with OpenERP

March 27, 2011 2 comments
KDE 4.0

Image via Wikipedia

My partner, Cristian Sebastian Rocha, has been working the past three months in the development of the hr_attendance_analysis module, which, as its name suggests, helps companies analyze their employees attendance.

This module allows you make calculations on the worked hours by employees. You can apply formulas and calculation rules in order to automate attendance calculation. It can also be integrated with other HR related modules, such as the clock_reader module.

This module also has a workflow for confirming the entered date on each document type, journal and payroll. The first document holds daily attendance information for the employee, whereas payroll holds payroll information on a monthly, bi-weekly or daily basis.

These are some screenshots for the module:

In this image you can see the main menu for accessing the HR module. You can also see the menu items for accessing the Payroll documents (selected) and Attendance Journals.

In this image you can see the document with the summary of employee hours (filtered by a date range). You can leave notes for each employee or for the document. It can have two states: draft and validated. We still have to develop the workflow for cancelling and re-setting the document.

In this screenshot we can see the entry for the employee Journal. Here you can see in detail the in and out time for a given date. You can also see the vacations or time off hours (such as late arrivals, early departures, sick days, etc.) To the left you can also see the result of the hours calculation.

This is a formula for summarizing the values stored in the journal, in order to be shown in the Payroll document.

This is a formula for calculating normal hours in a given  date for a given employee:

In this screenshot, you can see a rule. This rule assigns reasons for the actions of entering or leaving the plant. IN this case we can see how to calculate an early leave without a warning.

We still have things to do, but soon we will upload the module to LaunchPad. If you have any comments, or suggestions, they are more than welcome.



Thoughts on why some SMBs will switch to OpenERP over traditional ERP systems

Python logo

Image via Wikipedia

Today I had the chance to learn about the features of a propietary ERP system. This gave me a good  insight of why small businesses are moving to OpenERP. Some of the features customers appreciate are:

  • Customers can customize OpenERP. I did not realize it, but there are many systems around that are closed and can not be modified. And making changes to it means making changes to its core. And this could take months. This is the opposite of OpenERP, just look at OpenObject and you can see how easy it is to extend or override its functionality. Also, workflow functionality is quite powerful. Not all ERPs have the capability of changing its behaviour as OpenERP does.
  • Customers can look at the code. This might sound paranoid, but gives them confidence on the system.
  • No vendor lock-in. Customers love this. The fact they don’t have to stop the plant in order to switch vendors is highly appreciated. And being capable of keeping the code and giving its customization to someone else who is capable of maintaining it, makes life easier for our clients.
  • Support forums
  • Have I mentioned Python? OK, not all the IT people I know have ever heard of Python, but the people I met today were running their ERP system with Centura, which is a framework based on SQLWindows, one of the first object oriented programming languages in the mid-90s. With this I mean… OpenERP runs with one of the most productive programming languages in the world. Plus, even though we are not millions, the group of people working with Python is growing every day.
  • TCO. This is a big deal. Not only the licenses (all the ERP systems I see over here have licenses that are more expensive than $40,000) but the hardware and software as well. You only need a browser on your desktop to use OpenERP, no Windows licenses. And no server license as well. This saves thousands and thousands of dollars.
  • And last but not least, the web client. This makes the life of the system administrator much easier


Getting started with the OpenERP MRP module

March 8, 2011 1 comment

Image via Wikipedia

Getting started with the MRP module can be a daunting enterprise, and it is easy  to get lost at it. But actually it is easier than it seems. I will cover the functional elements you need to get started with the MRP module. I will not cover how to do that, it is already covered in the documentation.

In order to start with the MRP module, you just need four pieces of information:

  1. Product information; the first information item you need. Which products you are planning to sell and procure.
  2. Bill of Materials, sometimes called formulas. They are a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, components, parts and the quantities of each needed to manufacture an end product.
  3. Stock information, pretty much how much inventory you have at hand. If you don’t have this information, you can’t even get started. MRP uses inventory information to determine when and how much to procure.
  4. Master Procurement Schedule; this provides the list of the products you need to procure (either purchase or manufacture) and when you need them. This can be provided by the stock_planning module. Or you could keep an spreadsheet updated with your procurement needs and create the procurement orders from there.

If you are planning on implementing the MRP module, you need to assess the four points I described above. Chances are bill of materials are maintained in paper or spreadsheets. The stock information might be maintained by an information system within the company. But at the end of the day, you will need to assess the quality of the bill of materials. Implementing them will be the longest item in the MRP implementation plan, and you can’t take shortcuts over there. Chances are you will need someone manually checking they are fine, and that you will need to import them manually (which might be the healthiest thing to do).

Well, just wanted to cover some information issues that come up when you are implementing the MRP module.