If they are both global fields (not variables) you don't need any relationship, as they are 'global' all records will match to all records. You can make this month::start_of_reporting_period a calculation, with a global storage, where it is exactly as you say:
this month::start_of_reporting_period = main::start_of_reporting_period
Although as they are global and equal, why not just refer to the one field?
It could be useful to show both values on the layout that has the problem, and see if the values update as you expect. It may be that the values update perfectly, but some calculation or relationship downstream is what is failing.
Thanks. I did actually try the straightforward approach that you described but could not get it to work. I cant have single field as the this month::start_of_reporting_period will be used to sum the values of related records in another table. Then there will be "next month::start_of_reporting_period" in a seperate table which will feed of from the value of this month.
any thoughts ?
That still doesn't indicate that you need two fields--unless both are needed for relationships to different tables.
Are you sure that the fields are both set up with global storage?
You can also replace one global field with an unstored calculation field (NOT global) that references the other global field. Then the two fields will always show the same data--but this should not be necessary unless, both are needed as match fields in different relationships from different tables.