Created attachment 162858 [details]
Report 1

Created attachment 162859 [details]
Report 2

Created attachment 162860 [details]
report correct

Created attachment 162861 [details]
report wrong

Created attachment 162862 [details]
report correct 7.0.0.1

Created attachment 162863 [details]
Database

Couldn't confirm any buggy behavior here.
Please write down a detailed description.
I opened all forms in LO 7.0.0.1 on OpenSUSE 15.1 64bit rpm Linux. All will show the content the right way. Which of the reports shows the wrong content for you?

Report where the problem has been detected: "Movimientos_por_fecha_y_cuenta"
Attachments:
Database: Database "Bancos_7.0.0.1.odb"
Report 1: Edit report 6.4.5.2 correct Altura (Height) 0,50 cm
Report 2: Edit report 7.0.0.1 wrong Altura (Height) -0,01 cm
Report wrong: Report 7.0.0.1 detail on the next page, being blank from the header to the end of the first page.
Records exceed one page, not as in "Report correct 7.0.0.1"

(In reply to Emiliano A. González from comment #8)
> Report where the problem has been detected: "Movimientos_por_fecha_y_cuenta"

> Report wrong: Report 7.0.0.1 detail on the next page, being blank from the
> header to the end of the first page.

The database you added gives a report with date "01 febrero 2020" - only one page. Could this be the reason I can't confirm any bug there?

So, after changing the content of one table, I could reproduce the bug:
Open the attached database.
Open the report "Movimientos_por_fecha_y_cuenta"
All looks right in every LO-version. Report has 1 page.
Close the report.

Open table "Prametros".
Change "fecha_fin" to 2020-07-01 (don't know how it is formatted for the user, could be 01.07.20)
Close the table.
Open the report "Movimientos_por_fecha_y_cuenta"
Now the report will get all content for section Detail on the second and third page. The first page shows only the header.

This bug appears since LO 7.0.0.0beta2, could also appear in older LO 7 versions. It doesn't appear, for example, in LO 6.4.5.2

Tested all on OpenSUSE 15.1 64bit rpm Linux

To reproduce it graphically:
Forms: Informe
Fecha inicio: 11/11/2019 dd/MM/yyyy
Fecha final: 03/05/2020 dd/MM/yyyy
Button: "Refrescar"  Yes
Button: "Informe por fecha y cuenta"

It does not appear, for example, in LO 6.4.5.2 or earlier

This is not a base problem but a Writer problem

Created attachment 162965 [details]
File generated by Base. Open it to reproduce the issue

Regression introduced by:

commit 8a21d5053d331160e4913dc80c045a454ec84de3
Author: Justin Luth <justin.luth@collabora.com>
Date:   Mon May 4 22:21:46 2020 +0300

tdf#132642 sw layout: try2 emulate table kept-with-next not splitting

Bisected with: bibisect-linux64-7.0

Adding Cc: to Justin Luth

Comment 14's document looks the same as it looked in LO 5.1 - before my 5.2 changes which were not intended to affect ODT.

It seems like the reports are poorly designed.  Why is the table property set so that it may not split across pages? That is the ultimate problem here. I can see why the small header and footer might not want to split at all, but the detail should be allowed to split across pages.  The "keep with next paragraph" property OUGHT to help keep the whole report on a single page if possible.

So basically, the report is doing just what it is told to do. All of the detail is held in a separate table. If the table properties are changed to that the table is allowed to split across pages, it will work as desired.

There is a report setting that will mostly do this - but it is buried pretty deep. When editing the report, go to view menu - sorting and grouping.  You want "Keep together" "with first detail".  (The only thing this misses is keeping the footer table together, and keeping the detail with the footer - in the unlikely circumstance that some text is added above the report.) [The default seems to be "off", so the designer deliberately set this?]

The error is presented with version 7.0.0.1rc1.
Not with older versions. I have made the same report with both versions. 
Examples:

Attachment 162860 [details] report correct - LibreOffice 6.4.5.2
Attachment 162861 [details] report wrong   - LibreOffice 7.0.0.1

The requested data is the same in both reports.
No changes have been made to the database.

(In reply to Emiliano A. González from comment #17)
> The error is presented with version 7.0.0.1rc1., not with older versions.
It is present in older versions. Test with versions older than 5.2.

The bug actually starts in 5.2 because a table is split that is specifically set not to split. That bug was fixed in 7.0. Your reports need to have the settings adjusted to properly define the results you want to see.

Yes, seems to be a bug in the design of Report Builder. Have tested in LO 5.1.5.2 with the same problem. If you mark the table and set Table Format to Text Flow → Allow Table to split ... it will work.

But how do we solve the bug in Report Builder. I would prefer it will work right now in Writer as it does in LO 7.0.0.1. And the code of ReportBuilder should be changed to work the right way also.

I don't see any developer, who will change code in ReportBuilder. In the last 10 years there has only be added one function. Bugs appear and weren't solved ...

You missed this important part...

(In reply to Justin L from comment #16)
> There is a report setting that will mostly do this - but it is buried pretty
> deep. When editing the report, go to view menu - sorting and grouping.  You
> want "Keep together" "with first detail".


>  (The only thing this misses is keeping the footer table together
... actually it does this. The footer table is still do-not-split...
> , and keeping the detail with the footer
... which is basically irrelevant

According to comment 16. Justin L.
At the time of the creation of the report it was the only option, because I had a lot of problems with the adjustments.
Report Builder sometimes works the way you want it to.
I don't have much knowledge of English, but thanks to Deepl https://www.deepl.com/translator I have been able to get in touch with you.
Thank you all and a greeting,
Emiliano

If you are using Macros to open the report the following should work:

SUB TabSplit
DIM oReport AS OBJECT
DIM oTables AS OBJECT
DIM oTable AS OBJECT
DIM inT AS INTEGER
DIM inI AS INTEGER	
oReport = ThisDatabaseDocument.ReportDocuments.getByName("Movimientos_por_fecha_y_cuenta").open
oTables = oReport.getTextTables()
FOR inT = 0 TO oTables.count() - 1
	oTable = oTables.getByIndex(inT)
	IF Left$(oTable.name, 6) = "Detail" THEN
		oTable.Split = True
	ENDIF
	NEXT inT
END SUB

The report will be opened by a button, for example in a Base form. Tested this with the generated file of the report.

Hope someone will fix this in the ReportBuilder.

(In reply to Robert Großkopf from comment #22)
> Hope someone will fix this in the ReportBuilder.
Robert - what exactly needs fixing? Once the report is given the proper settings for this particular report as mentioned in comment 20, it works fine AFAICS.

(In reply to Justin L from comment #23)
> (In reply to Robert Großkopf from comment #22)
> > Hope someone will fix this in the ReportBuilder.
> Robert - what exactly needs fixing? Once the report is given the proper
> settings for this particular report as mentioned in comment 20, it works
> fine AFAICS.

Open the report for editing in Base.
Change all you are able to change for section Detail, specially "Keep Together" → 'No'
The report will show the same behavior as reported for this bug.
Split won't be allowed for the table in the executed report.
The button for editing the report does ... nothing.

Tested in LO 7.0.0.1 with OpenSUSE 15.1 64bit rpm Linux

(In reply to Robert Großkopf from comment #24)
> Open the report for editing in Base.
> Change all you are able to change for section Detail, specially "Keep
> Together" → 'No'
That is not what comment 20 told you to do though.

(In reply to Justin L from comment #25)
> (In reply to Robert Großkopf from comment #24)
> > Open the report for editing in Base.
> > Change all you are able to change for section Detail, specially "Keep
> > Together" → 'No'
> That is not what comment 20 told you to do though.

You are right. Haven't noticed this. Thank you for the hint. The standard of the field in "Sorting and Grouping" is "Keep together" → 'No' ...

So should we close this one as WORKSFORME?

If it should be closed. 
With the solution provided by Justin L. the problem was solved. It works perfectly.
Regarding the macro of the commentary 22 of Robert Großkopf I am going to test it. 
Thank you very much.

(In reply to Emiliano A. González from comment #28)
> If it should be closed. 
> With the solution provided by Justin L. the problem was solved. It works
> perfectly.
> Regarding the macro of the commentary 22 of Robert Großkopf I am going to
> test it. 
> Thank you very much.

So let us close this one as "WORKFORME".

The macro isn't necessary. But it shows how to get the right object in the executed report. I have just tested to set borders in the table, which is very difficult in the Report-Builder. If you are interested in this write a private mail to me ...

WORKFORME is when there was a bug and unknown fix (which may be revealed by rebisect).
This looks like NOTABUG (which indicates that documentation could be improved).