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 <chloe.desout...@atasta.net> 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 > >
