Instead of basing your report on the parent table occurrence, base it on the child (the TO the portal is pointing to).
An alternative is to use the GetSummary ( ) function, which allows you to define a calculation in the parent table that does basically the same thing as a summary field - but it's a bit less flexible.
Was just preparing this while Mike answered …
In most cases, the table with more granularity (more data) is better suited for creating a report; in a one-to-many relationship this would be the “many” table.
As a concrete example: to print an order confirmation, use the line items table, not the orders table. You can still pull in the relevant related data (order num, date, customer etc) from the order table (or the customer table one hop further) and display them in the header, and you can order/summarize your line items using sub-summary parts and summary fields.
Make this work by using a script that goes to the related records from the portal (matching only, and maybe in a new window) and uses your report layout as the target, then sorts the records to make the summaries work.