The problems with this approach

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 Business::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.

Why use XML for the matching system? It just makes it harder to work with the data.

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.


XML cache format:

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

export - calls the xml routine on the container to output xml file

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 Business::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.24 2005/01/11 18:35:47 pcxuser Exp $