Jump to content

Look Up Values


This topic is 2571 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I want to be able to calculate a payroll check.  I have done the calculation in Excel.  I was able to replicate the calculations in Filemaker, but I am not sure it is the best way.  I used a CASE statement to handle the various level of pay to get a proper withholding rate.  

But each time the tax tables change, the case statements have to be changed.  Is there a better way?  A better way to store the tax information?

Link to comment
Share on other sites

Create a table that stores the tax rate. Then Lookup the tax rate from your original table. That way, when the rate changes, you simply change the rate in the rate table. This way you preserve history as each record will look up the tax rate and store it in the current record. Previous records will retain their values.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
 

I have two sets of ranges to put in the table.  The two ranges are Single and Married.  I have set the relationship from Wages in the Calc Table to the TaxTable.  

I get a ZERO for the TaxRate.  So I am not sure what I am doing wrong.  I looked up the Employee PayRate from the Employee Table.  So I thought I understood the concept.  

Right now I only have the Single tax ranges in the table.  I am not sure how to distinguish the look up of wages from single and married?

post-84605-0-79368200-1405070827_thumb.p

post-84605-0-57393900-1405070840_thumb.p

post-84605-0-20982500-1405071011_thumb.p

Link to comment
Share on other sites

I should add that there are many payroll services and they take the headache of keeping up with tax laws (state and federal), withholding tables, quarterlies payroll taxes, W-2s, tracking requirements for W-4s and they hold the burden of responsibility in case of error.  

 

They are VERY inexpensive compared to the design costs of such a solution in addition to the cost of its administration.  All you really need to track are hours, which you send them - THAT FM can track for you.

 

Even with strong accounting background, I would suggest against rolling your own Payroll because of the complexity and risk.

 

Added - BTW, I've done 5-6 large payroll solutions and I know what is involved and I STILL recommend against rolling your own.

Edited by LaRetta
Link to comment
Share on other sites

I am not sure how to distinguish the look up of wages from single and married?

 

I am not sure what your screen shots show us. It seems to me that the relationship that looks up the tax rate needs to be based on matching both status and amount - and the tax table needs to have a distinct record for each rate.

 

Alternatively, you could use an auto-entered calculation instead of a lookup and pick the appropriate field (single or married) from a common record.

 

 

I should add that ...

 

Something is missing?

Link to comment
Share on other sites

LOL, I agreed with Rick (by rating UP) but I wanted to add a caution and suggestion not do do payroll at all.  My response DID sound a bit 'out of thin air', I suppose. ;-)

Link to comment
Share on other sites

I have to disagree with the idea of avoiding payroll. Payroll is one part of the solution I use to run my business and it's just not that difficult to do properly. If it were difficult I wouldn't be able to do it! Perhaps one difference is that the people I hire are still considered self-employed sub contracted entities and normally do not have taxes deducted at source. However, the devil is always in the exceptions. It's not uncommon for Revenue Canada, a union or the IRS to make a demand for withholding. My software manages to do this as well as write cheques to the appropriate entity as well as print up the tax forms etcetera. While it's certainly important to be aware and up to date with laws and rates it's certainly doable. Last year I used my own software to answer a huge HST audit. The auditor told me it was the easiest audit he had ever done. Even asked for a tour of the solution. To me that's an indication that this can work.

Link to comment
Share on other sites

Perhaps one difference is that the people I hire are still considered self-employed sub contracted entities and normally do not have taxes deducted at source. However, the devil is always in the exceptions.

 

Self-employed contractors are issued simple 1099s.  It is far from same as employees. Keeping up on the tax rates and rules IS a comprehensive task - just ask any payroll service; just ask any large business who must employee several staff to handle it properly.

 

Do not take my word for it - check out the facts.  It is known true by any accountant. :-)

Link to comment
Share on other sites

Agreed on all counts. I know it requires a lot of diligence to run a payroll application. My point is that it's possible to keep up with the rules and implement them in a solution. From a database point of view it's not difficult. Whether a person wants to spend the time staying current or farm the work out is another issue. To have an A to Z solution it's simply necessary to keep up with the current rules. This is much the same as saying that a solution needs to stay current of business practices. They change as do tax rules.

Rick.

Link to comment
Share on other sites

For me this is an exercise of learning more about FileMaker Pro than writing a payroll solution.   I have been doing accounting for too many years to not know how complex the tasks are.  There are real world times when a check needs to be cut outside of the payroll process.  This could supplement.  

More importantly the lesson is learning to set up a table of values and being able to look them up.  

Link to comment
Share on other sites

My three attachments show the tax table from the IRS.  A screen shot of the relationship screen section, and the last is the table that I have for look up.  

My FileMaker lesson is that using an ID I have always been able to look up fixed data, i.e. employee name, pay rate, addresses, phone numbers.    But for this I need look up the tax rate for $500, which is 15% from the IRS Tax Table. 

Formatting this as a calculation and using a CASE Statement works.  But that is not easily updated.  Hence I want to do it from the table.  And I hopeful I am just overlooking something simple.

I hope the clarifies.  As to the attachments when I click on them they enlarge for viewing.    I do not not what to do differently there.  I appreciate all of the discussion.  I learn more from a real problem than an abstract.

Link to comment
Share on other sites

Formatting this as a calculation and using a CASE Statement works.

 

That's certainly not what I suggested. Basically, you have two options here: either set up your TaxRates table to look something like this:

 

FromAmount    Status    TaxRate

   0          Single      0%

  43          Single     10%

 218          Single     15%

...

   0          Married     0%

 163          Married    10%

 512          Married    15%

...

 

then look up the appropriate rate using a relationship defined as:

Payroll::EmpStatus = TaxRates::Status
AND
Payroll::GrossAmount ≥ TaxRates::FromAmount

with records from TaxRates sorted by FromAmount, descending.

 

 

Upon closer inspection of the IRS tax table, the second option is not practical because the amount breakpoints are different for the two categories.

Link to comment
Share on other sites

Thanks for all of the assistance.  I was not setting the correct options in the LookUp screen.  The relationship was right; the field was right.  But the options to NOT COPY, LOWER or HIGHER were not touched.  Made the difference.  

Link to comment
Share on other sites

I am not sure we're on the same page here. Having a relationship based on two matchfields, you should NOT use the "copy next lower/higher value" option, because the behavior is unpredictable. Note that "married" is the next lower value relative to "single".

Link to comment
Share on other sites

All SINGLE are together and then all MARRIED.  I have the records sorted decreasing order Single and High to Low Amounts followed by Married and High to Low Amounts

 

Does that help the look up?

 

 

Editted. .

Link to comment
Share on other sites

All SINGLE are together and then all MARRIED.

 

I am not sure what you mean by "together". We are talking about a lookup over a relationship here; the order of the records in the source table (TaxRates) is irrelevant. The important point here is how they are sorted in the relationship's definition. Since the relationship "sees" only records of matching status, the sort order needs to apply only to the FromAmount.

Link to comment
Share on other sites

This topic is 2571 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.