Batch tracking met ORRTIZ:BMS

Batch (of lot) tracking is essentieel voor producenten, die levensmiddelen produceren. Niet alleen uw eigen producten moeten voldoen aan de eisen van de Voedsel en Waren Autoriteit, maar ook dient u te weten waar uw grond- en hulpstoffen vandaan komen en waar ze in verwerkt zijn. Zo helpt u uw bedrijfsrisicos te reduceren.
Maar batch tracking is ook interessant voor iedere ondernemer die levensmiddelen (en andere producten) in- en verkoopt.

De ORRTIZ: BMS oplossingen bieden een geïntegreerde batch tracking oplossing voor iedere ondernemer, die hier bewust mee omgaat. Met de oplossing heeft u inzicht van levering naar klant terug naar het ontvangst van het goed, of de productie ervan (achterwaartse tracking), als van oorsprong (ontvangst of productie) tot aflevering (voorwaartse tracking).

Per batch heeft u een overzicht van de voorraadmutaties van het product (zie afbeelding 1).

overzicht batch

Afbeelding 1: Overzicht batch

en iedere voorraadregel geeft u de specifieke details (zie afbeelding 2). Of deze nu zijn ontstaan door een ontvangst, een verwerking of een levering.

Overzicht batch met details

Afbeelding 2: Overzicht batch met details

Wilt u meer weten over de producten en diensten van ORRTIZ, ga dan naar

ApacheCon CORE EU 2015

After holding the ApacheCon event in Austin, Texas in the U.S. of A. in the first half of this year, he Apache Software Foundation (the ASF) heads once again to Budapest, Hungary.

Last year I attended ApacheCon EU 2014 (also Budapest) and presented my talk called ‘Brewing with Apache OFBiz‘ which addressed the manufacturing capabilities in OFBiz, and I enjoyed the interactions with other OFBiz contributors who also presented (see this track description). It was a great way to meet fellow contributors in person and exchange thoughts and ideas, so I have decided to do it again and present at:

ApacheCon Core EU 2015

For this 2-day event, I have submitted 2 talks:

  • Leveraging Community Management with Apache OFBiz
  • Managing the project with Apache OFBiz

Leveraging Community Management with Apache OFBiz

As a part of the greater Apache Communtiy I follow many mailing list to stay informed about what is happening at the ASF and in its projects.  Considering that the ASF encompasses more than 200 projects, that mean that the day to day operations regarding onboard and offboarding people into the various roles of the project and the ASF itself (members, etc), but also providing services as JIRA, SVN and  is quite the arduous task. I found that the tools for managing and creating visibility of the persisted data are somewhat scattered across the various pages and show duplication and variations in user experiences.
Based on the above, I have looked at how it is currently done, and investigated how a solution in Apache OFBiz could look like that could help any open source project in managing en enabling its contributor base to collaborate and share organisational information.

Of course, taking the ASF as a starting point, that means that inclusion of delegation of authority and role based authorizations are a necessity. Something I expect the larger open source projects need as well.

And so I started with a Proof of Concept (PoC) regarding in a hot-deploy component, that enables an open source project to:

  • manage offices (treasurer, secretary, etc)
  • identify officers and assign those to offices
  • identify members
  • create and delegate management of development projects and services
  • enable self registration of contributors to projects and its mailing lists
  • identify and maintain PMC Membership, committer lists of projects

All by utilising and extending core functions and services in OFBiz, persisted in an RDBMS.

The result of this PoC will be part of the talk at the event.

Managing the project with Apache OFBiz

My second submitted talk is about how professional service organisations and self-employed subcontractors can use OFBiz, to create and manage projects, assign resources to project tasks, register time spent and process project hours for billing. This all mainly through the ProjectMgr application, but also leveraging functions in other components like accounting, sfa and partymgr

Now I have to wait and see if one or both get selected by the organisers.

Thoughts on the role definitions of the ASF

A while back I started thinking about the roles the Apache Software has defined in this page:

First of all I like the limited number of roles, as less is more. And the other roles of the ASF (regarding the other officers) are explained elsewhere. Unfortunately the role definitions described do not, in my opinion, ensure clarity. In stead they are ambiguous and thus are expected to breed confusion and insecurity.

In this posting I will (re)share those definitions and provide a definition that will remove the confusions.


A user is someone that uses our software. They contribute to the Apache projects by providing feedback to developers in the form of bug reports and feature suggestions. Users participate in the Apache community by helping other users on mailing lists and user support forums.

This role definition is ambiguous in many aspects. A user can be both a person and an organisation (both private and public). But that latter aspect is neglected.  On top of that: a user does not contribute as he would then be more than just a user…

The better definition would be the following:

A user is a person or organisation experiencing a benefit from the contributions made to the ASF in general or a project in particular.


A developer is a user who contributes to a project in the form of code or documentation. They take extra steps to participate in a project, are active on the developer mailing list, participate in discussions, provide patches, documentation, suggestions, and criticism. Developers are also known as contributors.

Though correct in a way, it is a limiting definition. Everybody who contributes to the project in another way is not recognised. Better would be that this role definition would be stricken from the document and replaced by the following:


A contributor is a person, who contributes to a project of the ASF and therefore to the ASF. Contributions are (but not limited to) participations in mailing lists, conferences, providing improvements to code, documentation, supplying suggestions and criticism to further the project in particular and the ASF in general.
Recognized contributors are contributors who have a signed Contributor License Agreement (CLA) on file with the ASF.


A committer is a developer that was given write access to the code repository and has a signed Contributor License Agreement (CLA) on file. They have an mail address. Not needing to depend on other people for the patches, they are actually making short-term decisions for the project. The PMC can (even tacitly) agree and approve it into permanency, or they can reject it. Remember that the PMC makes the decisions, not the individual people.

Here the roler definition is talking about a developer again. It also states that the committer make short-term decisions for the project. This latter aspect is wrong, as a committer does not have the power to change the direction of the project (a procedural issue). A committer only has the power to persist code changes in the repositories of project. Furthermore, in this definition a new term is introduced (PMC) and what that project body can do. The better (shorter) definition is:

A committer is a contributor who has been given the privilege of write access to the repositories of the Project. A committer is a contributor (recognised, with an CLA on file) with an email address of the ASF (extension

PMC Member

A PMC member is a developer or a committer that was elected due to merit for the evolution of the project and demonstration of commitment. They have write access to the code repository, an mail address, the right to vote for the community-related decisions and the right to propose an active user for committership. The PMC as a whole is the entity that controls the project, nobody else.

Again the role definition talks about the developer. Better would be the following definition:

A PMC Member (member of the Project Management Committee) is a contributor who has been elected by the governing body of the project (the PMC) due to merit to the evolution of the project and the demonstration of commitment to the project. On top of the privileges of a committer, a PMC Member has the right to vote on procedural issues and the right to ratify or reject the code changes of the commiter.

PMC Chair

The Chair of a Project Management Committee (PMC) is appointed by the Board from the PMC Members. The PMC as a whole is the entity that controls and leads the project. The Chair is the interface between the Board and the Project. PMC Chairs have specific duties.

Again, this is correct in a way, but could be worded better. And also again the definition introduces duties of the governing body of the project. The role definiton also make statements about the (primary) task o a PMC Chair , that would better be defined in the separate document about the duties of the PMC Chair. A better role definition would be:

A PMC Chair is the PMC Member, who is appointed by the Board of the ASF as the Vice-President of the project. In this capacity the PMC Chair reports on the health of the project to the Board of the ASF, and ensures that directives issued by the (Board of) ASF are implemented in the by-laws, policies and/or standing rules of the project.


Apachecon ACNA 2015 in Austin, Tx, US of A.

Apachecon ACNA 2015 Date: April 13th-17th,2015

I won’t be attending the Apachecon event in Austin, Texas this year. But, together with Sharan Foga, we have come up with a great OFBiz track that is appealing to developer, integrator and (potential) users.

Have a look here for insights on the talks in the tracks:

Apache OFBiz

Apache OFBiz

I am a contributor to the Apache OFBiz project.

In January 2015 I registered 56 issues, of which 9 were bugs, 28 were improvements and 19 were sub-tasks. Of those 56 issues, 8 were implemented and closed successfully (6 patches provided). In total I submitted 17 patches during January. And these issues addressed almost every aspect of OFBiz, whether that was regarding framework components, base applications like accounting, manufacturing and order mgr, and special purpose applications as project mgr and scrum.

Apart from that my OFbiz contributions encompassed feedback in threads in both user and developer mailing lists, as well as postings to issues created by others in JIRA, and related postings in Twitter and LinkedIn.

For a complete overview, click here: OFbiz issues created in January 2015

Refactoring OFBiz roles

The biggest set of issues I started to work on is related to how OFBiz deals with roles for the various parties: internal vs external and organisations (and organisational units, teams, etc) vs persons. This refactoring of how roles are handled in the life cycle of their applicability touches every application in the feature stack.