Sorry, I don't usually look at items that DBlank has answered as they correct and there is nothing for me to add...had some time and the title intrigued me.
I am a bit confused by how things are being used. I understand that you are entering a date and you want all the items that will be projected to be out of stock on or before that date. I think I have that right.
You have a formula in a subreport that does a calculation, but that is not real clear. Is this what you were getting at:
local DateVar ReturnDate := Date (2099,12 ,31 );
Shared dateTimeVar Shared_Out_of_Stock_Date := ReturnDate;
if
{@Monthly Forecast} <> -1 then(
Shared_Out_of_Stock_Date := CurrentDateTime +
{@Monthly Forecast} ;
ReturnDate:=Date( CurrentDateTime +
{@Monthly Forecast}));
);
ReturnDate
Either way, you have this shared variable Shared_Out_of_Stock_Date being set in the subreport. Here comes the big question...can you see this subreport? Does the subreport do more than this, and if this item is to be 'in stock' should it be displayed?
why do I ask? You are going to want to suppress something (and possibly this subreport) in the main report based on the variable Shared_Out_of_Stock_Date, and if you need to run the subreport before you can suppress the subreport, you are in a catch-22. If the subreport is already suppressed, then life might be easier, depending on how the report is displayed, but as DBlank said, it doesn't appear that you are looking at the variable, you created it and set a value, but now what...
In the main report, create another formula:
shared datevar Shared_Out_of_Stock_Date;
this will display the results of the shared variable. you can use it in suppression formula for a row, a field, or whatever you want to do with it. Just remember that Crystal basically reads a report from top to bottom stopping to read subreports, so if the subreport is after the line you want to hide, you will have problems.
As always, if you got the data via a stored proc, you wouldn't need this as you could suppress the records from every making it to your report and the need of a subreport would go away...they are impose a lot more data reads to the database...1 is enough in the vast majority of instances...but the number of rows + 1 can really the impede the performance of your report.
Hope this made sense.