Payroll.pm
Xiwa will provide a Payroll
processing interface where initially you will only be
able to import an XML file and process it. (Eventually, you will
be able to work with previously imported payroll files?) The payroll
XML is based upon the Payroll perl modules that we have developed.
Those modules take raw XML salary data and output Cooked XML with
taxes etc.
The Payroll import screen will
provide a file upload form and collect data (sub entity, batch
size, sendfile, queue ). After uploading the file and
verifying that it is indeed a valid Payroll XML file we begin the
process of transforming the cooked payroll xml to
transactionImport xml.
The steps to complete are: validate, map, add employer matching, create XML.
The validation will be done by simply invoking the Payroll::XML modules and loading up the file. If it suceeds, the data is valid.
The resulting object can then be walked in order to map the incoming data--such as person to employee sub account; adjustment to user definable account - employee sub account ; other rows (Fed Income) to Account - Employee sub account; trigger account for matching FICA, Medicare accounts - 10 for employer sub account. There will be three caches that these mappings will be stored in (employees, accounts, matching). If the system automatically looks in the cache for the mappings first then the user may never need to be consulted. Adjustments may be an exception to this. For now we will simply use the Employee sub account for adjustment sub account entries.
map psuedocode
ask user for ledger to use
check xml
parse employees/persons, adjustments, other accounts to
check cache for each piece of data, create list of missing entries
if missing, ask user to map missing data (employees, accounts, adjustments)
for each person/employee, create a transaction/journalEntry Object
add data from person/employee object(xml) to empty Journal Entry object
While adding each row, check for matching accounts and act accordingly
The matching subsytem will be taken care of by looking for accounts
while processing the Journal Entry object. If an account is used that
is in the matching system, it will trigger the addition of a matching
entry. For example: account FICA will trigger a matching entry
20032 (AP FICA) - 4400 (John Doe) - $44.00
20032 (AP FICA) - 10 (Company) - $44.00
50032 (FICA expense) - 4400 (John Doe) - $44.00
Will need to batch to avoid timeouts. Will send
index number starting with 0 for batch index between batches?
What if employees need to be put in separate Salary
Fica, medicare accounts. We will not support that now.
Matching system
We need to store the account and what the matching value is. For
US it is 100%. Store the value with the
% sign so that we can specify 10.00 and it will be $10.00
instead of 10%.
This xml relationship will need to be initialized by db upgrade?
The relationship could be managed by the same set of screens but
for now will simply be mentioned. We have some screens where we
were setting default accounts for medicare etc. are we still using?
MAYBE this should be done by account type instead of account? or both? If done by account, then when an account of type Fica or Medicare is created it needs to be put into the matching data store.
Current matching accounts are:
Medicare
FICA
special processing
There are required rows: gross, net. If they do not exist check
the exit on first error flag and act accordingly. If it is not
set, then skip this transaction?
This will require a configuration screen to administer.
Use the Portal::XML::ConfigObject. version = "1.0", module = "payroll_employee_cache" or "payroll_account_cache" or "payroll_matching_cache".
To use the xml system retrieve the xml and pass it to
Portal::XML::ConfigObject->new. The resulting object
will contain a hash. For employee_cache each employee id will be the
key and the sub-account will be the value in the
hash.
commands:
display
- displays the file upload form and submits to command='validate'
validate - validates the uploaded
file then calls map
map - checks cache, when finished caching calls transform
transform - creates data objects and places them in a container
command: display
display file upload form and dropdown, Batch size: | 10, 50, 100 |
command: validate
< valid file? >
( NO ) [ screen: display ; message: bad file uploaded]
( YES ) [sub transform ]
commmand: transform
methods needed:
displayMainScreen()
- displays the file upload form
validateFile() - validates the
uploaded file - make sure it is a Payroll::XML::OutData and has at least
one person defined. Make sure that the internal required strings
are present for each entry. What do we do if gross = 0.00? No
problem just leave it. Net should not also be zero, if so ignore
this transaction during transform Store the parsed XML data in the session.
This way each subsequent function/screen does not have to reparse and
re-validate the XML data. return $self->map to call mapping routines.
If no mapping is needed, the mapping routines will return $self->transform
transform() - transform file
We will store the incoming files in a special
Portal defined directory. But will we need a new table that will be used
to store the metadata?
payroll_xml_tb (date - timestamp, user - int, file - text, tracking_id - varchar, type text --raw or cooked)
the end result is an xml file that is given to the user (placed in a temp directory? when does it get cleaned up? if not does the page just start dumping the file to the screen? Also the file needs to be copied into the queue.
Copyright (c) 2002-2003 Xperience, Inc.
Permission is granted to copy, distribute and/or modify this document under
the terms of the GNU Free Documentation License, Version 1.1; A copy of the
license is available at http://www.gnu.org/licenses/licenses.html#FDL.
Updated: $Id: Payroll.html,v 1.23 2003/07/21 19:21:00 moreejt Exp $