I'd check to see if your relationship is linking the correct fields in your relationship graph since you've already verified the type of the fields.
Your order 'date' field is set as a number. I figure you might not believe it, so here is a file which shows it:
5/5/2010 would also appear in the portal, along with 3/7/2010, 4/4/2008 and many more. Strange that some will NOT appear, such as 6/17/2009 and 2/15/2010. I assumed it is because FM is handling 5/5/2010 as: 5 divided by 5 divided by 2010 but even those numbers should relate (6/17/2009 is .0001756800281088) and 5/5/2010 is .0004975124378109.
I find it inconsistent but that only means that I haven't spotted the pattern (yet).
Ah. Strange as it sounds, FM tries to create the relationship by converting true dates on the parent side to a number (and NOT FMs standard number of number of days). It does this: GetAsNumber ( GetAsText ( startDate ) )
Anyway, it's not that easy to explain but easy to view so I'm uploading another file if anyone is interested. But it explains why it is important not to mix data types. However, I am VERY surprised that FM converts a true date on the parent side to attempt to match to the child (if this is indeed what is happening). Although the theory holds in all dates I've tried so far, I could be wrong.
Hmmm, I wonder if we can take this strange behavior and actually USE it. :^)
As an aside ... if you were entering your dates as 5/5/10 (but it was into a number field), FM couldn't convert to true date of 2010. In this case, 5/5/10 wouldn't appear to relate because it was 5510 on the child side instead of 552010.