X-Basic....Help

[fairviewcomputing]

Problem: Payroll application, I have a data entry form tied to a set. Top level of set is "Hours", under that is "Employee". In "Employee" is a field for "Wage Attachment", Field12. On data entry form is a field that calculates a specified percentage of the amount in Field12 to be deducted each pay period. This works fine...BUT when I try to subtract the pay period amount from the amount in field 12, I can't get it to work. I tried using action
scripting, converting it to xbasic, as shown below, without success.
DeductAmount:N = :Hours:Field72.value
TotalDeduct:N = :Employee_Data:Field12.value
var->NewTotal = var->totaldeduct-var->deductamount
:Employee_Data:Field12.value = var->NewTotal

What am I doing wrong??

[Stan Mathews]

RE: X-Basic....Help

"On data entry form is a field that calculates a specified percentage of the amount in Field12 to be deducted each pay period. " - What is the object name of this field on the form? (check it's properties)

Once this is known the calculation should be (on the onchange event for field12?):

dim global diff as n
var->diff = field12.value-objectnameofpayperiodamt.value
end

I think.

[Tom Cone Jr]

RE: X-Basic....Help

Howard,

Understanding the problem is the key to the answer.

Describe the specifics of each data table field involved, including tablename, fieldname, type and meaning.

Describe the specifics of each display calc field on your form, including it's objectname, type and meaning.

Then explain which subtraction you are trying to achieve.

This is necessary because the xbasic technique for referencing fields in your tables is very different than the technique for referencing values displayed in objects on your form.

-- tom

[fairviewcomputing]

RE: X-Basic....Help

Stan, the pay period amount on the data entry form is a calculated field. The object name is Field72 but when I type your suggested code in the interactive window, I get "Field72 not found". I tried changing that to the name of the calc (calc->wageattach) which didn't work either. Thanks for the suggestion. I will keep plugging away until maybe I learn something.
Howard

[fairviewcomputing]

RE: X-Basic....Help

Tom, Here are the specifics:
Object name of the field on the data entry form is Field72 and in the field is "calc->wageattach"
Calculation is: If (calc->reggrosstotal=0,0,IF(employee->taxattach>0,employee->taxattpercent*calc->reggrosstotal/100,0))
EMPLOYEE TABLE:
Object name in employee form is Field12 (type in) and holds the total amount owed by the employee. The field name is Employee->taxattach
Field22 holds a whole number percentage of the amount to be subtracted from gross pay each pay period.
Purpose: Each pay period a user defined percentage of gross pay is deducted from the employee's paycheck. This part works fine. The problem came up when I tried to use this calculated value and subtract it from the total amount that is in the employee database, so the program will stop deducting when the total reaches zero. The client normally does this manually by keeping track of the year to date deduction, then removes the total amount from the employee's record when the wage attachment is satisfied.
Thank you for taking the time to respond to my dilemma.
Howard

[Tom Cone Jr]

RE: X-Basic....Help

Howard,

So, let's see if I got it right:

1) If Employee->taxattach >0 you want to subtract calc->wageattach, unless calc->wageattach is greater than Employee->taxattach. In this latter case you would adjust Employee->taxattach to zero by adjusting the payment amount by subtracting employee->Taxattach

2) If employee->taxattach = 0 then you do not want to adjust employee->taxattach regardless of the amount in the calc->wageattach.

Assuming I have it reasonably correct, now let's talk context:

Is this an adjustment you want to occur automatically? If so, under what circumstances? While entering a new record? While changing an existing record? I foresee difficulties if this happens each time the record is changed. Perhaps you need another field to flag whether an adjustment has already occurred for this particular record. Even so, it's going to get complex, since a changed record might necessitate a recalc and further adjustments. This will have to be thought through very carefully, there are lots of ways this can go wrong.

Consider what happens if the adjustment is implemented to be triggered each time the record is saved.

At first save the adjustment occurs fine.

Then the user discovers an error and goes back and changes some item in the record. How do you implement an adjustment to the adjustment? You'll have to keep track of the amount of the last adjustment it seems to me. If the new adjustment is different, then you adjust by the difference only, storing the new total adjustment for the second set of changes when the user discovers that the original record was right after all. This means plus and minus adjustments are possible and must be allowed for.

Having said all this, assuming the form is in change mode already the following will modify the value of the TaxAttach field in the Employee table:

Employee->TaxAttach = Employee->TaxAttach - Calc->wageattach

As indicated above this type of expression will cause TaxAttach to become negative if the WageAttach value is greater than TaxAttach.

-- tom

[fairviewcomputing]

RE: X-Basic....Help

I see what you mean. I will probably leave it up to the user to check the balance manually instad of banging my head against the wall any more.
Actually, to state the initial formula, If regulargross pay is zero (as it is for some employees in this particular business, as it is a seasonal business), I don't go any further. If gross pay is greater than zero, then the amount of taxattach in the employee table is multiplied by the percentage in the employee table and deducted from the paycheck. This will probably deduct slightly more than necessary at the final deduction but then it would stop deducting because the total amount to deduct has gone to zero or less. I see I need

[Lowell Wardlow]

RE: X-Basic....Help

Howard - you might try this.

Assuming that at some point in your program, that the deduction balance owed, gross pay this check, and the percentage to use are all known, then use these two lines
for the calculation, using your own variables.
------------------------------------------------------------
amount_to_deduct = min(amount_owed,(gross_pay * deduct %)
amount_owed = amount_owed - amount_to_deduct
------------------------------------------------------------
Amount_to_deduct will be the lesser of the calculated amount_to_deduct or the current balance of the deduction. It will be zero if there is no balance owed, and will never be greater then the gross pay, nor the amount_owed.

You do not need to check if the variables are zero, since
anything times zero will be zero.

Note that this should be done AFTER any federal/state tax deductions are subtracted from the current gross.

Lowell

[fairviewcomputing]

RE: X-Basic....Help

Thanks for your reply Lowell. I understand your response and I already have the first part programmed BUT, it's the second part that is the trouble. As Tom Cone Jr. pointed out, it's what triggers the second calculation that's the problem. If the user edits an entry, and the subtraction gets triggered a second time, the outstanding balance will be reduced erroneously. I have thought of triggering the calculation on the form field that contains the actual deduction but am having trouble with xbasic and action scripting commands, getting the proper syntax.
Howard

[Tom Scholis]

RE: X-Basic....Help

This sounds strangely familiar? I'm in a rush and didn't read
all of this very well but have you tried using an extra field
with a checkbox value to hold off recalculation? Something
like:

Allow Recalculation(Y/N):

[Lowell Wardlow]

RE: X-Basic....Help

Howard, I guess I was assuming that this was a batch job, now I think you are talking about working from a form, one
entry at a time.

Another aproach is to create work files for the
calculations, print edit lists, then do an xbasic post from the work files to the real files. This allows changes to the work files, up to and including zapping them and starting over.

I personaly NEVER update anything but static data in real time, always created transaction records and updated dynamic fields from an edited work file.

Any corrections to the original amount would be made in
a second posting, preserving an audit trial of the changes.

Lowell