[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the 12 Payroll tables

On Sun, Jan 19, 2014 at 12:49 AM, <..hidden..> wrote:
Good morning Ledgersmb developers I am trying to decipher the 12 payroll
tables so i can backport them to my 1.2 system for now.
I see there are perldoc in LedgerSMB/Payroll dir and I am slurping that up.
However I am curious about payroll_income_class is this what jurisdiction
the payroll tax is incurred in? Like what state you live in?

Here's the idea:

income and deduction classes are intended to be rough categorizations of income and deduction.  You could use them to cover jurisdictional matters if needed, but usually you would probably tie these to the employee (in most cases), and use them more for categories like hourly, salary exempt, salary, and payment for production (common in agriculture).

The idea is that a country payroll module would define these typically as applicable to the country.

So it's generally a classification system for payroll and it's fairly generic.
I see from perldoc "These are not defined through the user interface but
rather defined country-wise."

I see you no longer use nextval ( 'id' ) for anything that needs an id
after I don't know when 1.2? How do you generate an id? In the Perl
Will it cause a problem in 1.4 if I use it for now in 1.2?
For example
INSERT INTO payroll_income_class (id,country_id,label) VALUES (nextval (
'id' ), 1, 'Oregon');

id's are usually generated on insert using serial types.  These use implicit sequences for the table.  The problem with the old schema was that id was a global sequence and so there was a tendency to have ambiguous foreign keys (some of these we are still cleaning out in 1.3, see recurring transaction bug 888).

As of 1.3, we've moved away from nextval('id') for everything outside of financial transactions.  This means that most tables have their own id sequences which cannot be assumed to overlap.  Eventually when we redo the financial side, we will have tables structured so that this is not used there either.

In general in PostgreSQL a 'serial' type is an int with a default for the nextval of an implicit sequence.  If you need bigint instead, use bigserial.

Hope this helps.
Chris Travers 

Cheers Turtle

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
Ledger-smb-devel mailing list

Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.