---
title: "Important: Study plan credit points take decimals"
manual: "Academic StudyPlan"
version: "main"
source: "Changelog/3.0/Important-StudyPlanCreditPointsAreDecimal.rst"
rendered: "2026-10-02T15:38:26+00:00"
---

# Important: Study plan credit points take decimals {#important-study-plan-credit-points-are-decimal}

## Description {#description}

The credit points of a study plan semester and of a study plan module accept a
number with up to two decimals now, such as 2.5 for a module worth two and a
half credit points. The backend field used to accept whole numbers only. It
takes a decimal point or a decimal comma, and rounds a third decimal, as every
decimal field of the backend does.

The column `credit_points` of the tables
`tx_academicstudyplan_domain_model_semester` and
`tx_academicstudyplan_domain_model_module` changes from an integer to a
decimal column with two decimals. The extension no longer declares it in
`ext_tables.sql`; TYPO3 derives it from the field definition. Version
2.4 carries the same change with a declared column, so an installation
updated from 2.4 already has the decimal column.

The study plan shows credit points without trailing zeros: "2.5" and "30",
never "2.50" or "30.00". The semesters and modules handed to the template carry
the credit points as a number rather than as the value the database returns,
so this holds for template overrides as well, see
[What a partial is given](../../Templates/Index.html#templates-arguments).

## Impact {#impact}

Updating from 2.3 or older, the database compare offers a change of the
column in both tables. It keeps every stored value: a module with 5 credit
points keeps them, and the study plan shows "5" as before. Run it before
editors enter a decimal value, which the integer column cannot hold on
MariaDB, MySQL and PostgreSQL. Updating from 2.4, the compare leaves the
column alone on those, and on SQLite changes only its type.

On SQLite, updating from 2.x, the database analyzer can report two errors for
each of the two tables, "table … already exists" and "no such table:
\_\_temp\_\_…": 3.0 also adds the workspace columns to both tables, and on SQLite
both changes rebuild the table in the same run. The tables end up complete
with every value kept, and a second compare offers nothing more.
`extension:setup` does not report these errors.

A semester or module without credit points still shows none.

Credit points render with a decimal point on every page language. A template
override that wants a decimal comma formats the number itself, for example
with `<f:format.number decimalSeparator=",">`, which prints a fixed
number of decimals.

## Affected Installations {#affected-installations}

Every installation with the extension installed. Run the database
compare in the install tool, or with `vendor/bin/typo3 extension:setup`,
after the update. From 2.3 or older, the change rewrites both tables; they hold
the semesters and modules of all study plans, which is rarely many rows.

An installation that redefined the column in an `ext_tables.sql` of its
own - as a float column, for example - removes that definition before running
the compare. A declared column takes precedence over the derived one, so it
would otherwise stay as it is. A TCA override that only adds
`'format' => 'decimal'` is no longer needed.