pkONE® : SveDocumentation

1. Mutationen - Speichern / Einreichen

Momentan werden beide Schaltflächen Speichern und Einreichen angezeigt.

Frage: Kann bei der Anzeige auf Speichern verzichtet werden oder müssen immer beide Buttons/Fkt eingeblendet werden? Das wäre in vielen Fällen einfacher, da nicht 2 Aktionen ausgeführt werden müssen.

  • Bei JJS Mandanten kann es bei jeder Mutation zu einer FUM kommen.

Probleme:

  • Tendenziell könnte man bei SVE Mandanten (nur VL "SVE") auf Speichern verzichten, wenn nicht auch hier eine Ausnahme vorhanden wäre: Bei Unterschreitung Lohnschwelle muss dennoch ausgewählt werden, ob die Person direkt austreten soll

  • Die Auswahl Anzeige ja oder nein müsste vor dem Laden der Page getroffen werden, was aber nicht möglich ist.

  • Immer nur Einreichen anzeigen: Im Falle einer komplexen Mutation keine Möglichkeit für einfach mal speichern OHNE Einreichen.

  • Speichern und Einreichen anzeigen, direkt Einreichen möglich, beide Knöpfe angezeigt: Dann wieder Verwirrung, wieso einmal direkt eingereicht werden kann und wieso manchmal nicht!

2. Distribution Specification

2.1. Ausgangslage / Anforderungen

2.1.1. Reduzierung Anzahl Verteilungen

Bei der Verteilung von Dokumenten, beispielsweise Gruppendokumenten, anhand von name-based distribution würde unter Berücksichtigung der rollenbasierten Verteilung die Anzahl der Konfigurationen sehr stark ansteigen. Dadurch würde die Konfiguration unübersichtlich. Ziel ist eine Vereinfachung, sodass die Konfiguration übersichtlich und einfach bleibt.

2.1.2. Namensgebung Multi-Language-Dokumente

Bei der Verteilung von Multi-Language-Dokumenten mit mehreren Sprachsektionen soll die Namensgebung so gelöst werden, dass ein Dokument wie GR_SVE_Certificat_Certificate.pdf beim Verteilen in mehrere Sprachen übersetzt wird. Damit wird jedem Benutzer in seiner Sprache ein sprechender Name präsentiert.

Beispiele:

  • SVE-Kurzgeschäftsbericht-2026.pdf

  • 2026-BriefBusinessReport-2026.pdf

  • SVE-rapport d’activité succinct-2026.pdf

Bisher wurde ein Common-sense-Dateiname verwendet, der keiner Sprache wirklich gerecht wurde.

2.1.3. Extractor - zusammengesetzte DocumentTypeId

Bei der Faktura ist der verarbeitete Text-Code vorgegeben und kann nicht geändert werden. Für die Reduzierung von Benachrichtigungen soll die ermittelte DocumentTypeId aus mehreren Werten beziehungsweise Matching-Gruppen zusammengesetzt werden können.

Beispiel:

  • bisher IDX1_DEB

  • neu IDX1_DEB_SVE oder IDX1_DEB_JJS

So können zwei DocumentTypes definiert und separat benachrichtigt werden.

2.2. Anpassungen

2.2.1. Umstellung name-based auf code-based Verteilung

Die Reduzierung kann über den neu eingeführten DocumentType erreicht werden, indem die Konfiguration von filename-based auf code-based umgestellt wird.

  • 1 Extractor

  • 3 Konfigurationen für MD, MDVS, MDAG

  • 3 Konfigurationen für IS, ISVS, ISAG

Damit kann die Anzahl der Verteilungen von ungefähr 40 auf 7 reduziert werden.

Neue Anforderung:

Der Code mit dem entsprechenden DocTypeId muss bei den umgestellten Dokumenttypen aus dem Dateinamen extrahiert werden können. Das kann auf SVE-Seite einfacher automatisiert werden. Bisher wird der Code aus dem PDF-Dokument selbst extrahiert.

Beispiel Dateiname:

.\*FDA1;…​;DocTypeId;…​;FDA1\.*.pdf

Lösung:

Erweiterung des Text-Code-Extractors.

Verteilungstyp Suchort Logik / Bedingung

Text-Code Extractor

File-Name

Schritt 1: Suche nach Code/Pattern, z.B. IDX1. Wenn gefunden, Suche abbrechen.

Text-Code Extractor

File-Inhalt

Schritt 2: Wenn Schritt 1 kein Ergebnis liefert, Suche nach Code im Dokument.

QR-Code Extractor

File-Inhalt

Suche nach Pattern, z.B. IDX1, im QR-Code auf der ersten Seite des Dokuments.

2.2.2. Erweiterung Multi-Language-Dokumente

Bisher:

  • Multi-Language-Dokumente enthalten kein Sprachsuffix im Dateinamen und werden daher keiner Sprache in den Metadaten zugewiesen.

  • Renaming über Dateiname ist möglich, aber keine Übersetzung anhand der ermittelten Sprache.

Neue Anforderungen:

  • Multi-Language-Dokumente sollen über I18N übersetzt werden können.

  • Automatische Spracherkennung soll auch Multi-Language-Dokumente verarbeiten.

  • Multi-Language-Dokumente sollen im UI immer angezeigt werden, unabhängig vom Sprachfilter.

  • Beim Verteilen in mehrere Sprachen sollen die Dokumente übersetzt werden.

  • Erkannte Sprachen sollen in den Metadaten angezeigt werden.

  • Die Spracherkennung soll langfristig alle Dokumente verarbeiten, sodass keine lang-based suffixes mehr nötig sind.

Lösung:

  • Übersetzungen werden in den Metadaten gespeichert, als 1:n Beziehung: ein Dokument, mehrere Sprachen.

  • Anzeige im DocumentStore erfolgt in der Sprache des Benutzers.

  • Originalnamen und alle Übersetzungen werden in den Metadaten angezeigt.

  • Es wird weiterhin keine Sprache direkt in den Metadaten gesetzt, damit entsprechende Dokumente im UI korrekt behandelt werden und immer sichtbar bleiben.

Szenario ISO Code im Dokumentnamen Spracherkennung Erkennung Metadaten Sprache Sichtbarkeit im UI Übersetzung I18N

Single-Language

Ja

Über ISO Code wie _de, _en, _fr

Eindeutig

de / fr / en

Wenn entsprechende Sprache ausgewählt ist oder bei -

Anhand des Sprachcodes

Single-Language

Nein

Durch Sprache der Owning Entity

Eindeutig

de / fr / en

Wenn entsprechende Sprache ausgewählt ist oder bei -

Anhand der Sprache des Benutzers

Single-Language

Nein

Spracherkennung Inhalt

Eindeutig, z.B. DE > 90%

de / fr / en

Wenn entsprechende Sprache ausgewählt ist oder bei -

Anhand des Sprachcodes

Multi-Language

Nein

Spracherkennung Inhalt

Verteilt, z.B. DE 35%, EN 30%, FR 40%

NULL

Bei allen Sprachen und bei -

Anhand der Sprache des Benutzers

Für die korrekte Erkennung bei Anglizismen müsste der Prozentsatz der erkannten Wörter über einem konfigurierbaren Schwellwert liegen, beispielsweise 10 %.

2.2.3. Extractor - zusammengesetzte DocumentTypeId

Bei Verteilkonfigurationen vom Typ Extractor soll die im Parameter-Lookup unter lookupMap definierte entityId zusammengesetzte `DocumentTypeId`s unterstützen.

Beispiele:

  • Einfach kombinierte IDs: $1$2$4

  • Erweitert kombinierte IDs: $1ID$2

2.3. Offene Fragen

  • Default-Sprache: Wenn ein Dokument Multi-Language mit EN/DE ist, der User aber FR als Sprache hat, soll die Übersetzung auf DE oder auf den technischen Namen zurückfallen? Annahme: Default auf DE.

2.4. Tickets

3. Document Distribution - Naming Conventions

3.1. DocumentType Naming Conventions

Für die Archivierung soll beim DocumentTypeIdentifier folgende Namenskonvention verwendet werden:

Kontext DT für Mutationsbeleg DT für Dokument / Anhang in Mutations

AG / Employer

XXX_MUTATION_YYY, zum Beispiel LOM_BELEG_AO_SVE

XXX_DOCAG_YYY, zum Beispiel WAHLSPARPLAN_DOC_AG_ENTRY

AN / Beneficiary

XXX_ANTRAG_YYY, zum Beispiel EINKAUF_ANTRAG_ABLEHNUNG_SVE_JJS

XXX_DOC_AN_YYY, zum Beispiel Einkauf_DOC_AN_SVE

  • Ausnahme / Spezialfall: EZS

4. DocumentType-Level OwningEntity And Role

Date: 2026-02-25
Domain: Document Distribution

4.1. Problem

DocumentDistributionDefinition trägt owningEntity und Rolle über parameterLookupDefinition auf DDD-Ebene. Für EXTRACTOR-basierte Flows ist dadurch pro OwningEntity- beziehungsweise Rollen-Kombination ein separates DOCUMENT_TYPE-DDD nötig, auch wenn alle anderen Einstellungen identisch sind.

4.2. Goal

DocumentType soll seine eigene owningEntity und role tragen können, sodass mehrere DocumentTypes mit unterschiedlichen OEs und Rollen ein gemeinsames DOCUMENT_TYPE-DDD verwenden können. Das reduziert die Anzahl der DDDs, ohne die bestehende Konfiguration zu brechen.

4.3. Scope

  • Gilt für: DOCUMENT_TYPE-DDD-Typ

  • Nicht betroffen: FILENAME_BASED, EXTRACTOR_TXT, EXTRACTOR_QR

4.4. Design Decisions

Decision Choice Rationale

Which DDD types benefit?

DOCUMENT_TYPE only

Extractor löst bereits einen konkreten DocumentType aus dem Dateiinhalt auf.

Role representation

@ManyToOne zu Role

Referentielle Integrität; role.prefix ersetzt roleEntityId.

Override strategy

DocumentType OE hat Vorrang; DDD OE ist Fallback

Backward compatible, keine Datenmigration nötig.

4.5. DDD Consolidation Example

Vorher: drei DOCUMENT_TYPE-DDDs, identisch bis auf OE/Rolle.

DDD owningEntity roleEntityId in paramLookup

VA_WEBCUSTOMER

WEBCUSTOMER

—

FAKTURA_MANDANT

MANDANT

AG

LOM_BELEG_MUTATION

MUTATION

—

Nachher: ein gemeinsames DOCUMENT_TYPE-DDD; die DocumentTypes tragen ihre eigene OE und Rolle.

DocumentType owningEntity role

VA_SVE

WEBCUSTOMER

null

FAKTURA

MANDANT

EMPLOYER

LOM_BELEG_LE_SVE

MUTATION

null

4.6. Edge Cases

Case Behaviour

Both DDD and DocumentType have OE set

DocumentType wins.

Neither DDD nor DocumentType has OE

Log WARN with NO_OWNING_ENTITY, skip file.

DocumentType has role but OE ignores ROLE_ENTITY_ID

Role is unused, no error.

DocumentType role and parameterLookupDefinition has roleEntityId

DocumentType role wins.

4.7. Tests

  • Unit: DocumentType OE overrides DDD OE in doOwningEntityBasedDistribution()

  • Unit: DocumentType role injects correct prefix into parameter map

  • Unit: neither OE set emits NO_OWNING_ENTITY

  • Integration: multiple DocumentTypes with different OEs share one DOCUMENT_TYPE-DDD end-to-end

4.8. Referencing Tickets

5. Dokumente in pkONE

5.1. Dokumente in pkONE Arbeitgeber

Typ Name Logo übersetzt Übersetzung basierend auf Testing Notiz

Mutationsdokument

STM

Ja

Sprache des Mandanten

Mutationsdokument

UBU

Ja

Sprache des Mandanten

Mutationsdokument

Austritt

Ja

Sprache des Mandanten

Mutationsdokument

LOM

Ja

Sprache des Mandanten

Mutationsdokument

FM

Ja

Sprache des Mandanten

4.11.25 Fehler bei Use Case 6G

Mutationsdokument

Dokumentenupload

Ja

Sprache des Mandanten

4.11.25 Not working

Mutationsdokument

LE Beleg (Firma)

Nein

Nur in Deutsch vorhanden

5.2. Dokumente in pkONE Arbeitnehmer

Typ Name Logo übersetzt Übersetzung basierend auf Testing Notiz

Registrierungsbrief

Brief für Registrierungszugangsdaten

Nein

Nur in Deutsch vorhanden

Mutationsdokument

Antrag Einkauf

Ja

Sprache des Versicherten

Mutationsdokument

Antrag Wahl Sparplan

Ja

Sprache des Versicherten

4.11.25 Testdaten fehlen, brauche EN VT mit Spraplanwahl Funktion

5.3. Logo in pkONE AG Portal

Beschreibung Detail Logo übersetzt Übersetzung basierend auf Testing Notiz

LoginPage

url LoginAG

Ja

Systemsprache gewählt, oben links, Default Deutsch

LoginPage

url LoginVT

Ja

Systemsprache gewählt, oben links, Default Deutsch

LoginPage

Homescreen

Ja

Sprache des Benutzers

Registrierung

Erstregistrierung

Ja

Systemsprache gewählt, oben links, Default Deutsch

Registrierung

Registrierungsbrief erhalten

Ja

Systemsprache gewählt, oben links, Default Deutsch

Passwort vergessen

Passwort vergessen

Ja

Systemsprache gewählt, oben links, Default Deutsch

4.11.25 Not working

Innerhalb pkONE

Pages angemeldeter User

Ja

Systemsprache gewählt, oben links, Default Deutsch

5.4. Ticket Link