This is difficult because I cannot access your data and you cannot access mine, but let’s give a free-hand SQL approach a go anyway. My examples are for SQL Server. If you have a different database platform, your IT person will need to adapt the syntax to that.
Here is my sample data. I can be found in a reproducible format at the dbfiddle link toward the end.
The central idea is that you need a data source that represents all of the time periods (i.e., YRMTH) in your range of data. We have a Calendar containing one row for every day out something like 50 years. So this query…
DECLARE @START_DATE DATETIME;
DECLARE @END_DATE DATETIME;
SET @START_DATE = '2022-01-01';
SET @END_DATE = '2023-12-31';
SELECT
x.YRMTH
, x.SomeYRMTH
, x.SomeNumber
, x.MovingSum
FROM (
SELECT
cal.YRMTH
, tmp.SomeYRMTH
, tmp.SomeNumber
, SUM (tmp.SomeNumber) OVER (ORDER BY cal.YRMTH
ROWS BETWEEN 13 PRECEDING AND 1 PRECEDING
) AS [MovingSum]
FROM (
SELECT CONVERT (CHAR(4), Y) + RIGHT('0' + CONVERT (VARCHAR(2), M), 2) AS [YRMTH]
FROM Common.dbo.Calendar
WHERE dt BETWEEN @START_DATE AND @END_DATE
AND D = 1
) cal
LEFT JOIN #SomeTable tmp ON cal.YRMTH = tmp.SomeYRMTH
) x
--WHERE x.SomeYRMTH IS NOT NULL;
Yields this…
This window function repeated below will get the sum for the previous 13 periods based on the Calendar table, not your data table. If you need to adjust the period range for which you are find the sum here is where to do it.
SUM (tmp.SomeNumber) OVER (ORDER BY cal.YRMTH ROWS BETWEEN 13 PRECEDING AND 1 PRECEDING)
When you uncomment that last line you will then just get the data from your data table having accounted for missing YRMTH time periods.
If you do not have a Calendar table, a similar result can be achieved with a common table expression (CTE). Here is a dbfiddle with the CTE code which you can run there.
Hopefully, SAP will add support for a RollingSum() function as I suggested in my idea submission linked above or someone will come up with a way to do this in Web Intelligence with the functions currently available to us without having to resort to mildly complicated free-hand SQL code. Short of either of those this may be a viable solution.