Implementing Pay slips

[Chloé Desoutter]

Hello,

Here's a requirements map for implementing pay slips. Am I mistaken ? I
seek guidance here.

We need two-columns accounting to keep accounting for various benefits
and taxes that are due to the state & various external entities. This,
ofbiz can do with a little configuration.

We need to compute, using business rules, the presence and rate of
benefits and taxes, taken from the gross wage of the employee and as tax
on this gross wage for the employing entity. The business rules involve
Worker status (employee, managing employee, contractant, intern, etc.),
worked days, gross income, employment duration. These business rules are
not implemented yet but they could be managed as rulesets associated to
worker categories.

We need to compute other elements aswell, such as employer sponsored
days-off (in France we have a full five weeks of 'em per year) and
equivalent money amount (days can't be cashed out but when employment
comes to an end a certain amount of money is due based on the number of
available days). This needs business rules aswell, based on the number
of hours worked.

Then we need to generate pay slips. They are simply reports with
specific formatting, tapping into a data source for a given actor and a
given amount of money at a given point in time.

If we consider that paying a worker is an invoice (a "due" invoice) it's
a pretty good model. An invoice has lines giving an amount, an emission
date, a due date, an origin and a target (either of them being the
Company entity).

Am I on the right path? Are there any ongoing efforts out there going in
that direction?

The big challenge is to make the business rules manageable. The option I
prefer is to forget that and just hook computing rules to the invoice
"gross" amount to generate the miscellaneous lines and get the net
amount due to the employee and to the various tax collectors. What do
you people say?

--
Chloé Desoutter
C[A-Z]O, Atasta NET

[Pierre Smits]

Hi Cloé,

What you're talking about is in essence a payroll solution. Yes, this can
be built on top of OFBiz. There are enough pieces of functionality in the
feature set to get you started.

But you have to keep in mind that payrolling is one of the most sensitive
business domains in any organisation. Merely extending functionality in
existing components to get your solution going might be good for a proof of
concept, but the production ready variant must be as secure as possible.

Only payrolling staff should be the only ones who see the details of the
income and benefit statements of each individual employee, or be able to
configure/set up the rates and business rules associated with payrolling.
That means that even generating the statement in the accounting module (or
the specific GL transaction and its details regarding each employee income
statement) must be avoided.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Thu, Sep 4, 2014 at 6:51 PM, Chloé Desoutter <[hidden email]>
wrote:

> Hello,
>
> Here's a requirements map for implementing pay slips. Am I mistaken ? I
> seek guidance here.
>
> We need two-columns accounting to keep accounting for various benefits and
> taxes that are due to the state & various external entities. This, ofbiz
> can do with a little configuration.
>
> We need to compute, using business rules, the presence and rate of
> benefits and taxes, taken from the gross wage of the employee and as tax on
> this gross wage for the employing entity. The business rules involve Worker
> status (employee, managing employee, contractant, intern, etc.), worked
> days, gross income, employment duration. These business rules are not
> implemented yet but they could be managed as rulesets associated to worker
> categories.
>
> We need to compute other elements aswell, such as employer sponsored
> days-off (in France we have a full five weeks of 'em per year) and
> equivalent money amount (days can't be cashed out but when employment comes
> to an end a certain amount of money is due based on the number of available
> days). This needs business rules aswell, based on the number of hours
> worked.
>
> Then we need to generate pay slips. They are simply reports with specific
> formatting, tapping into a data source for a given actor and a given amount
> of money at a given point in time.
>
> If we consider that paying a worker is an invoice (a "due" invoice) it's a
> pretty good model. An invoice has lines giving an amount, an emission date,
> a due date, an origin and a target (either of them being the Company
> entity).
>
> Am I on the right path? Are there any ongoing efforts out there going in
> that direction?
>
> The big challenge is to make the business rules manageable. The option I
> prefer is to forget that and just hook computing rules to the invoice
> "gross" amount to generate the miscellaneous lines and get the net amount
> due to the employee and to the various tax collectors. What do you people
> say?
>
> --
> Chloé Desoutter
> C[A-Z]O, Atasta NET
>
>