From what you posted here:
I created a second TO from the same Table (Offers2) based on primary key and created a portal showing related records from Offers2
By definition, a primary key uniquely identifies each record in the portal. So a self join relationship like this that matches records by primary key fields can only match the current record to itself and thus you get only one record in the portal.
Neither custom functions nor a global field seems needed here. Instead, you need to identify what value in what field stores a value that is common to all the Offers records and which is NOT common to any offers records you don't want to see. That is the field you should use as your match field in the relationship on which you base such a portal.
But may I suggest an alternative?
If you set up a list view layout, you can perform a find for the Offers records that you want and list them in the Body of the layout. Fields that hold the same data for every offer record in your set of found records can then be placed in the header, footer or a grand summary layout part to appear at the top or bottom of your list of Offers. This approach does not use a portal--making it much easier to list a widely varying number of offers records and does not require an added table occurrence for a relationship.