Jump to content

Calcs w/portals


faaslave

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

Recommended Posts

Here is my problem:

I have 3 tables, Supervisors, employees, evals

many employees for each sup, and many evals for each employee

each employee has five types of evals

on the employee layout you see a portal listing all of their evals

above the portal are fields to show when the next due date for each type of eval is.

The next due date for a PSC eval should be six months from the last entered PSC eval. etc. etc.

The six month calc works fine, but I need a way to have the calc, look at all the eval records, match the type eval for that particular calc, then apply the six month calc, giving me the result.

Look at employee Jeff for an example

If all that can work, I would be able to go to the sup layout and generate reports to tell the sups when things are due or overdue.

Thanks alot,

Dave

SupTracking-1.1.fp7.zip

Edited by Guest
Link to comment
Share on other sites

:eeek:

OFF TOPIC

Please forgive me faaslave. This really isn't a personal thing but I have got to get this off my chest.

That has to be one of the most distracting ( hence annoying) avatars I have ever seen :eeek: - and i am not even in 'grumpy old man' mode :

Phil

Edited by Guest
Link to comment
Share on other sites

Was it the airplane, near miss? Have you changed it already? If so, I DID find myself ducking all the time. :wink2:

Hey, Phil! How do you like my hairless cat? He's beginning to look like a pig to me. ROF!

Link to comment
Share on other sites

I got the calc to work using s different relationship for each type of eval. There are still a few problems though.

One problem still is, lets say you are on an employee that has no record of a TTD, the TTD duedate will just find some other eval's date. I would rather it said missing.

Probably a simple fix, but I can't figure it out.

SupTracking1.2.fp7.zip

Link to comment
Share on other sites

Well I could use some help with the corner I painted myself into.

I have evals for every employee. There are 5 types of evals. When you enter an eval, you pick the employee, the type of eval, and the date. Simple so far.

If you want to list all of the evals for an employee, no problem.

I also needed a way to show when an employee was due for an eval. There are five types, so each employee has five duedates in total.

I made a field for each type of eval like this

eval1duedate

eval2duedate

etc.

Well that works too. The due dates aren't just based off of the last eval date for that type eval, there are some other variables, and I figured out a way to make it work.

Now THE PROBLEM!!

I need a way to get a portal and a report, showing the supervisor what is due for all of their employees in order of whats due.

Since I have a different field for each type of due date, I think I am stuck. :qwery:

Does anyone know how to get around this, or will I have to start over with how I determine the duedates?

I have attached the latest file

Thanks Dave

SupTracking16.fp7.zip

Link to comment
Share on other sites

The next due date for a PSC eval should be six months from the last entered PSC eval. etc. etc.

But the remaining TTD, TME, DARC and OJTI are revolving inside this timespan of 6 month, but not evenly spaced? So every eval is a chain from the time the first of that kind of eval was done?

--sd

Link to comment
Share on other sites

I took the liberty to ignore your template entirely and based instead my template on your desired specs. I see this as a many to many relation between Supervisor, employee and the Notes made during or after the evaluation.....

I've made the Eval file placeholder or join table for the notes to a certain evaluation, where a multiline key makes shure that a evaluation shows up in a timeslot of a month length if it's due (in it's own portal)

Since the current date has a lot to do with which of the values the multiline key shows, did I make a CF to get the right set of dates, one are even serving as primary key for the notes and have to change accordingly.

The multilinekey works as foreign key for the portal of upcomming evals. This makes it urgent that it's indexable, so the record creation of a new eventtype causes the multilinke key to get a stored value, which means that a Get( function can't be part of it, since they only evaluate correctly in unstored calc'fields.

My point is here that if you know the first date for a certain evaluation type you know the rest for quite a timespan - hence the multiline key.

Since it's the same record that shows up each time in the upcomming event's portal, should a function gets the two most contemporary dates to show up in several places. There are two places where "...allow creation of related record is set" first is when something is written in the notes field which originate 2 relations away, the first time are there two cascaded creation of records 1) the join table record and of course in the notes table. 2) When a record exists in the join table will only a new record in the notes be created ...if needed.

I do not know if this is the kind of functionality your wish for, I may have misread a few things here and there ...but I guess I would solve it in the vicinity of what I did in the template here....

--sd

SupTrackSD.zip

Link to comment
Share on other sites

Wow, your relationships are very complex for me, I will have to go through them and try to figure them out.

I really appreciate the time you spent doing this for me.

As far as the funcionality goes, I might not have been clear on some of it. But this stuff is great for me anyway. I will definitely enjoy trying to figure out all the relationships you created, and how they work.

The notes are not connected to the evals. The evals only show what type they are, when they were done, and a container field to put the file in.

The notes are for day to day notes, that are not evals. I still like what you did though as far as the notes go.

The evals due dates are based on when the last eval was done. If you give an employee a TME eval on Jan 5th, and then again on March 10th, the next one is due on Sepember10th.

My problem with the way I did it, is I ended up with a separate DueDate field for each type of eval. The reason for this is because, there are other variables that determine whether or not the employee even needs these evals. Some do, and some don't yet, based on where they are in the training program.

Then trying to put a list of all evals due in a portal became impossible.

I will try and figure out all the relationships you came up with.

Thanks Alot

Dave

Link to comment
Share on other sites

The notes are not connected to the evals. The evals only show what type they are, when they were done, and a container field to put the file in.

The notes are for day to day notes, that are not evals. I still like what you did though as far as the notes go.

There should be nothing preventing you from putting the containerfield in the notes table as well!

They can similar be responsible for the making the both join table record as well as the note table record, when such are required.

--sd

Link to comment
Share on other sites

I have never dealt with some of the functions you used. It looks like you have incorporated using repeating functions. It will take me quite awhile just to figure them out. Then I have to figure out how to incorporate these ideas into my layout.

I will post when I have come up with something.

Thanks,

Dave

Link to comment
Share on other sites

It looks like you have incorporated using repeating functions.

I have, they're faster to develope than recursive CF's ....thats all!

But you can make the key in the join table as CF this way:

HalfYearly(StartDate;Howmany)

 Case(Howmany>-1; HalfYearly(StartDate;Howmany-1) & "¶" 

& GetAsText ( Date ( Month ( StartDate ) + 6 * Howmany ; Day ( StartDate ) ; Year ( StartDate ) ) ))

(for keying purposes doesn't the leading pilcrow matter!)

While the one directing the month view, could be done like this:

http://www.briandunning.com/cf/8

.....If you should feel the repeaters are tough to live with, just remember to make the resulting field text!!!

--sd

Edited by Guest
To prevent the corruption of not yet lost souls
Link to comment
Share on other sites

This topic is 6450 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
×
×
  • Create New...

Important Information

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