OK so we're validating element entries migration data according to the input value rules and specifically we're trying to validate the inputs on a Working Tax Credit entry. . .Within this element definition are 3 dates that are validated via seeded formulas. These formulas do similar things but common to them both is a comparison of the input date with the value of the DB item 'SESSION_DATE'. From looking at the DB item definition it is doing what it says on the tin - get effective date from fnd_sessions where session_id = USERENV('SESSIONID'). No surprises there. . .So I figured that provided I engineer a row in fnd_sessions prior to doing the call to the formula execution routine I'd be sorted. But no! Even with the correct session date in place in fnd_Sessions data which should be valid is reported as invalid. . .BTW the formula execution routine does all the ff_init setting context values etc . .So if anyone is still reading at this point who still has the will to live what gives with this? . .L+K .CT

different session_ids ?

Nope. Next... . .OK seriously no I don't think so the set_session_date and the call to the formula are all happening in the same pl/sql block. . .EDIT: BTW before anyone else asks the formulas are both 'verified' (ie compiled).

okay have you examined the ROUTE of the database item? Is it as you expect it to be?

I refer the honourable member for Hereford to my opening remarks in this thread... OK yes and yes!

I would therefore suggest to the (Dis)Honourable Member for Hampshire Central that his session ID's must be different then.

I may be dishonourable but at least I'm not a................................... git. . .What I am though is a dough-head. It appears that 2 obstacles to success were present - the first was the somewhat questionnable strategy of holding 'date' entry values as YYYYMMDD - courtesy of Neill 'Yee Hahhhhh' Atkins :lol: . Once I'd applied the required DD-MON-YYYY format conversion to the input value that allowed me then to see the second real error - that the formula refers to the database item EMP_TERM_DATE. This is fine apart from the fact that during the pre-loading validation of the data the employee record doesn't exist and therefore the formula cannot find the row to establish the termination date :evil: . .So what I now have to do is work out if a formula uses any database item that has a context that I can't supply e.g. assignment_id and if so don't bother calling it.... so fairly straightforward then...

Too much sea air. If I were you i'd move out into the country. The smell of manure in the morning does wonders for clearing the mind :mrgreen: