FORECAST.ETS in ONLYOFFICE Spreadsheet Editor

• Introduced: Original introduction release is not established by the checked sources.
• Available: Listed in current unversioned ONLYOFFICE help, checked October 18, 2026.
• Implementation inspected: Official SDKJS v10.0.0.169, commit 3679e0375a758d7dc59d31337a45461be3525ed8. The snapshot does not prove identical behavior in every installed editor.
• Retired or deprecated: These sources do not establish retirement or formal deprecation.
• Testing: Numerical examples are independent mathematical expectations, and implementation discrepancies are labeled source predictions. No ONLYOFFICE application or calculation-engine execution was performed.

The examples use English function names and commas. Use your locale’s argument separator if different. Retain full precision in formulas; round only the displayed result. The examples use clean, unique, equally spaced timeline columns. They establish only the stated mathematical and source-trace cases, not general forecast accuracy, application execution or cross-product numerical equivalence.

=FORECAST.ETS(target_date, values, timeline, [seasonality], [data_completion], [aggregation])

Three to six arguments are registered. values and timeline must describe paired historical observations. The documented target is after the final timeline point. Use numeric dates or numeric period positions, not date-looking text. The timeline must have a consistent sampling step after any intended preprocessing.

Seasonality defaults to 1, meaning automatic detection. Set 0 to use the nonseasonal level/trend path, or supply an integer at least 2 for a chosen cycle length in observations. A length of 12 means twelve samples per cycle, not automatically twelve months. The nonseasonal path is exponential level/trend smoothing, not a general promise of ordinary least-squares regression.

Data completion defaults to 1, documented as averaging neighboring observations for missing timeline positions; 0 means zero filling. Aggregation defaults to 1, documented as averaging duplicate timeline observations. The inspected implementation has material problems in those preprocessing paths, described below. Prefer a clean timeline with duplicates already resolved and missing positions explicitly reviewed.

1. Enter timeline values 1 through 8 in A1:A8.
2. Enter 10,12,14,16,18,20,22,24 in B1:B8.
3. Enter target 9 in D1.
4. Evaluate =FORECAST.ETS(D1,B1:B8,A1:A8,0,1,1).
5. The source-derived expectation is 26, with target 10 giving 28.

These are synthetic period positions, each one unit apart. Their use avoids ambiguous text-date parsing and irregular calendar spacing. Keep the target in the same coordinate system; target 9 is one step after 8.

The source initializes level at the first response, 10, and trend at (24-10)/(8-1)=2. At each observation, the previous level plus trend equals the next response exactly. The level update blends two identical quantities, so its result stays on the line for every candidate smoothing weight. The trend likewise remains 2. The final state is level 24 and trend 2, so one step ahead is 24+2=26. This is an independent recurrence proof for this special dataset, not a fabricated fitted result for a noisy series.

The source target path also returns the observed value at an aligned historical timeline point: target 8 predicts 24 in this example. Current help asks for a future target, so use future positions for ordinary forecasting rather than treating historical lookup behavior as a general validation method.

Put targets 9 and 10 in a separate column and copy a formula with fixed historical references. For the control dataset, expected values are 26 and 28. Keep seasonality, completion and aggregation settings fixed while comparing horizons. Otherwise a change in model can be mistaken for a horizon effect.

For real observations, first decide the intended frequency, consolidate duplicate timestamps using an explicit reviewed calculation, and create a regular timeline. An absent timestamp differs from an explicit zero-valued observation. A missing value does not become zero merely because a cell looks empty. If you fill a gap, retain a flag showing which values were imputed.

The inspected code attempts monthly treatment when all dates share a day of month, converting positions to month indices. That is different from a fixed number of days, and its conversion code has limitations. The simple period-index example does not establish correct behavior for every month-end or fractional-date case. Use aligned future targets and check calendar-specific cases separately.

The documented aggregation codes are 1 average, 2 count, 3 counta, 4 maximum, 5 median, 6 minimum and 7 sum. In the inspected source, code 1 discards later duplicates without averaging their responses. The median branch does not sort its collected values and uses a fractional middle index for odd counts. These paths must not be assumed to implement the documented statistics correctly.

The missing-position branch uses a replacement operation while increasing the recorded number of observations as if it inserted a new item. This creates a structural consistency concern. Although help describes processing up to 30% missing points, that statement is not evidence that this snapshot handles all such gaps reliably. Precompute a complete, unique timeline instead of relying on those paths for an important forecast.

The wrapper rejects aggregation values below 1 or above 7 and completion other than exactly 0 or 1 with internal not_numeric, conventionally #NUM!. Use integer documented seasonality and aggregation codes; passing a numeric range check alone does not validate every fractional or out-of-domain control.

A target before the earliest timeline observation predicts #NUM! in preprocessing. The source has dimension/type validation, but its column-oriented preprocessing and Boolean-expression details do not justify a universal error matrix for every malformed range. Use equally sized numeric columns for the examples.

A computed forecast of exactly zero is treated as a false return by the inspected GetForecastRange helper and can become #NUM!. A numeric error therefore need not mean that zero is an impossible modeled response. Irregular off-step targets also use rounding and remainder logic; the aligned targets above avoid that ambiguity.

Smoothing parameters are selected by a bounded numerical search, and source comments explicitly note differences from Microsoft results. Do not copy an expected result from another editor and label it an ONLYOFFICE observation. A perfect synthetic control does not validate seasonal fitting or noisy-series accuracy. Assess a model on held-out observations, inspect residuals and preserve its assumptions; a point forecast alone carries no guarantee about the future.

Recalculate representative formulas when moving a workbook between editors. Matching names do not guarantee identical argument coercion, array behavior, numerical precision or error handling. These source-derived examples do not establish automatic spill behavior or a general import/export guarantee.

• FORECAST
• AVERAGE
• SUM

• ONLYOFFICE FORECAST.ETS help, checked October 18, 2026.
• Official SDKJS implementation, 3241–4100, tag v10.0.0.169 and exact commit above.