1                     Themenübersicht

Dieses Dokument gibt eine Übersicht über die Datentypen, ihre Bedeutung und ihre technischen Eigenschaften.

In den folgenden Kapiteln werden die vorhandenen Datentypen mit ihren grundlegenden Eigenschaften und die wichtigsten jeweils zur Verfügung stehenden APIs aufgelistet. Die Abbildung und Verwendbarkeit der Datentypen ist vom jeweiligen Kanal abhängig und in folgenden weiterführenden Dokumentationen beschrieben:

• Abbildung auf der Datenbank: Einführung: Datenbanken
• Abbildung auf der Toolshell: Toolshell
• Abbildung im Business Integration Service (BIS): Einführung: Datenaustausch, Entfernte BIS-Schnittstellen
• Abbildung auf der grafischen Oberfläche: Oberflächenentwicklung

2                     Zielgruppe

Entwickler

3                     Beschreibung

Die Beschreibung der APIs ist folgendermaßen aufgeteilt:

• Primitiver Typ: Datentyp, wie er in der Anwendung „Entwicklungsobjekte“ definiert wird.
• Logischer Datentyp: Der logische Datentyp, der als Basis für eigene Datentypen verwendet werden kann. Bei einigen Typen (z. B. Bool, Property) ist die Verwendung des logischen Datentyps oder einer entsprechenden Ableitung für die Funktionalität unumgänglich.
• Datentyp für Abfragen: Der logische Datentyp, der oder dessen Ableitungen für Abfragen verwendet werden. Für die meisten Datentypen ist kein abweichender logischer Datentyp für Abfragen notwendig.
• GUI-Feld: Dies ist die Java-Klasse, die für eine Eingabe bzw. Ausgabe eines Wertes dieses Datentyps in der graphischen Oberfläche verwendet werden kann.
• GUI-Feld für Abfragen: Dies ist die Java-Klasse, die für eine Eingabe bzw. Ausgabe einer Abfrage auf Werten dieses Datentyps in der graphischen Oberfläche verwendet werden kann. Diese Felder erlauben je nach Datentyp Mehrfachangaben, Bereiche oder die Verwendung von Platzhaltern. Sie werden insbesondere in Suchen und in Cockpit-Anwendungen verwendet. Je nach Fall kann ein GUI-Feld in einem speziellen Modus für Abfragen („SelectionMode“) verwendet werden oder ein spezielles Abfragefeld existiert.
• Prüfungen: Die Klasse „cisag.pgm.util.RepositoryValidation“ und einige andere Klassen ermöglichen auf der Basis des Datentyps zusammen mit seiner Data-Description, Werte zu überprüfen und „generisch“ Meldungen zu senden. So kann beispielsweise geprüft werden, ob ein „String“ angegeben wurde und die zulässige Maximallänge nicht überschritten wird. Die Verwendung dieser APIs vereinfacht die Erstellung von Prüfungen und reduziert die Menge identischer Meldungen.
• Null-Werte: Der Persistenzdienst behandelt Null-Werte beim Setzen in Business Objects und beim Lesen aus der Datenbank. Wenn die set-Methoden von Business Objects den Wert null erlauben, ist beschrieben wie der Persistenzdienst mit diesem Wert beim Schreiben auf die Datenbank umgeht. Weiterhin wird beschrieben, wie der Wert NULL auf der Datenbank (z.B. entstanden durch Outer Joins), vom Persistenzdienst aufbereitet wird.
• Hilfeklassen: Für das Erzeugen von Werten und elementaren Operationen auf Werten eines Datentyps existieren zumeist eine oder mehrere Hilfeklassen mit dem Namen „…Utility“. Zu diesen Operationen gehören beispielsweise das Erzeugen eines Wertes, das Überprüfen, ob ein Wert angegeben wurde, und das Konvertieren eines Wertes in eine benutzerspezifische Darstellung für die Verwendung in Meldungen. Die Methoden dieser Klassen liefern im Allgemeinen nur Werte und erzeugen selbst keine Meldungen.

3.1               Boolsche Datentypen

Boolsche Datentypen sind die einfachste Form eines Datentyps. Ein solcher Datentyp kann nur die Werte „true“ oder „false“ annehmen. Wird dieser Datentyp auch für die Typisierung eines Parameters eines Toolshell-Befehls verwendet, so können für diesen Parameter die Werte „true“ und „false“ angegeben werde oder der Parameter kann ausgelassen werden.

3.1.1          Boolean

3.1.2          Bool

Der Datentyp „Bool“ entspricht im Wesentlichen dem Datentyp „Boolean“. Der einzige Unterschied besteht darin, dass der Datentyp „Bool“ bei Toolshell-Befehlen verwendet wird, um Parameter zu typisieren, deren Angabe dem Wert „true“ und deren Fehlen dem Wert „false“ entspricht und eine explizite Angabe des Wertes nicht erforderlich ist.

Die Verwendung des logischen Datentyps oder einer entsprechenden Ableitung ist für die Funktionalität unumgänglich.

3.2               Zahlen

3.2.1          Byte

3.2.2          Short

3.2.3          Integer

3.2.4          Long

3.2.5          Dezimalzahlen

3.2.6          Float

Der Datentyp „Float“ wird im System normalerweise nicht verwendet, da er Fließkommawerte und somit potenziell implizit gerundete Werte darstellt. Im System werden Dezimalzahlen verwendet. Einzig einige GUI-Klassen verwenden diesen Datentyp im Rahmen von Layout-Definitionen.

3.2.7          Double

Der Datentyp „Double“ wird im System normalerweise nicht verwendet, da er Fließkommawerte und somit potenziell implizit gerundete Werte darstellt. Im System werden Dezimalzahlen verwendet. Einzig einige GUI-Klassen verwenden diesen Datentyp im Rahmen von Layout-Defintionen.

3.3               Zeichen

3.3.1          Character

3.3.2          String

3.3.3          Text

Texte sind „Strings“ unbestimmter Länge.

3.3.4          URI-String

3.3.5          Property

Propertys sind Einstellungen in Property-Dateien. Dieser Datentyp wird verwendet, um mögliche Einstellungen zu identifizieren und ihnen eine Direkthilfe zuzuordnen. Nähere Informationen zu Propertys und Property-Dateien finden Sie in der Dokumentation ERP-Properties und der Dokumentation Hilfe zur Property anzeigen (dspprphlp).

3.4               Binärdatentypen

3.4.1          Binary

3.4.2          GUID

Die GUID ist eine technische Identifizierung der Objekte. Die GUID ist ein byte-Array mit der Länge von 16 bytes. Die meisten Business Objects im System verwenden eine einzelne GUID als Primärschlüssel. Hierdurch können die Verwendungen dieses Primärschlüssels als Fremdschlüssel in andere Business Objects einfach und uniform abgebildet werden.

3.4.3          BLOB

3.5               Valueset

3.5.1          Valueset

Ein Valueset ist eine Werteaufzählung. Die zugehörigen Valueset-Elemente ent-halten dabei die konkreten Ausprägungen der Aufzählung. Ein Element besteht aus einem positiven short-Wert, einem Konstantennamen und einer übersetzbaren Bezeichnung. In der Regel wird zu jedem Valueset eine Java-Klasse „generiert“, in der die Konstanten definiert sind. Der Name eines Elements wird dabei als Konstantenname und der short-Wert als Konstantenwert benutzt.

3.6               Zeit und Datum

Im Rahmen der Behandlung von Zeit- und Datumsangaben existiert eine Reihe von besonderen Datentypen. Die Grundlage für die aufgeführten Unterscheidungen ist der logische Datentyp eines Wertes.

Grundlage für die Abbildung und Behandlung von Zeit- und Datumsangaben ist die Zeitzone. Zusammen mit weiteren Angaben definiert sie einen Kalender. Dieser ist die Grundlage für Operationen, die mit Kalenderwochen arbeiten.

Zusätzlich haben folgende Fragestellungen Einfluss auf die Wahl des Datentyps:

• Ist der Wert eine absolute Zeitangabe (Datum, Datum und Tageszeit), eine relative Zeitangabe (Dauer, Tageszeit) oder ein symbolische Zeitangabe (jede Woche)?
• Hat der Wert einen Bezug zu einer Zeitzone?
• Hat der Wert die Genauigkeit Datum oder die Genauigkeit Zeitstempel?

Für die Fälle, in denen die vom Persistenzdienst „generierten“ Attribute „validFrom“ und „validUntil“ verwendet werden, bestehen weitere Wahlmöglichkeiten bei der Einstellung der Zeitabhängigkeit im Entwicklungsobjekt „Business Object“.

folgende Möglichkeiten bestehen:

• Keine
• Immer neuen Datensatz einfügen
• Immer aktuellen Satz schreiben
• Gesteuert durch Anwendung
• Gesteuert durch Anwendung, Datum mit Zeitzone
• Gesteuert durch Anwendung, Zeitstempel mit Zeitzone

In diesen Fällen wird

• zusätzlich das Attribut „_timeZoneGuid“ „generiert“,
• das Attribut „validFrom“ und das Attribut „validUntil“ als Zeitstempel „generiert“,
• das Attribut „validFrom“ als lokales Gültig-Ab-Datum oder als lokaler Gültig-Ab-Zeitstempel interpretiert,
• das Attribut „validUntil“ als lokales Gültig-Bis-Datum oder als lokaler Gültig-Bis-Zeitstempel interpretiert.

Die Bestandteile von Gültigkeitsintervallen werden mithilfe der Standardfelder visualisiert. Die Hilfeklasse „com.cisag.pgm.gui.ValidFromUntilSupport“ ermöglicht zwei Felder zu einem „Von-Bis-Feld“ zusammenzufassen.

3.6.1          Zeitzone

Eine Zeitzone (technisch „TimeZone“) definiert die Zeitverschiebung bezüglich Greenwich Mean Time. Die effektive Verschiebung ist dabei im Allgemeinen von den Sommerzeitregeln dieser Zeitzone und somit vom Tag innerhalb eines Jahres abhängig. Im System sind die verfügbaren Zeitzonen fest vorgegeben. Referenzen auf Zeitzonen werden in Form einer GUID des zugehörigen Business Object „TimeZone“ gespeichert. Das Business Object „TimeZone“ befindet sich auf der Repository-Datenbank. Der Ursprung einer Zeitzone ist praktisch immer ein Kalender. Daher existiert kein spezielles GUI-Feld und existieren keine speziellen APIs zur Behandlung einer Zeitzone außerhalb eines Kalenders.

3.6.2          Kalender

Die Angabe einer Zeitzone ist ausreichend, um eine Zeitangabe in ein Datum und eine Tageszeit umzurechnen. Um die Grenzen einer Kalenderwoche (KW) zu berechnen, sind zwei weitere Angaben notwendig. Dies sind die Festlegungen welcher Wochentag als der erste Tag der Woche angesehen wird (Attribut „firstDayOfWeek“), in Frankreich im Allgemeinen der Sonntag, in Deutschland der Montag) und ab wie vielen Tagen die KW 1 als KW 1 und nicht mehr als KW53 interpretiert wird (Attribut „MinimalDaysInFirstWeek“). Die Zeitzone plus diese beiden Werte zusammen bilden im System einen Kalender (technisch „Calendar“, in Java das Interface „com.cisag.pgm.datatype.CisCalendar“). In der Anwendung „Customizing“ kann auf der Ebene des Systems ein System-Kalender definiert werden. Für jede Organisation wird ebenfalls ein Kalender festgelegt. Durch die Auswahl einer Organisation als Kontext in der Standard-Symbolleiste kann der aktuelle Kalender der Session umgeschaltet werden. Die Umstellung der Organisation hat unterschiedliche Auswirkungen in den verschiedenen Anwendungen. Der Tooltip zum Feld für die Auswahl der Organisation gibt Auskunft darüber. In der Regel hat der Organisationswechsel Auswirkung auf die Darstellung von Zeitangaben. Bei Zeitstempeln wird der dargestellte Wert neu berechnet, bei lokalen Zeitangaben wird die Zeitzone angezeigt, wenn sie von der Zeitzone des Kontextes abweicht. Ist in der Session keine OLTP-Datenbank aktiv, so gilt der System-Kalender.

Der jeweils aktive Kalender und seine Zeitzone werden in der Statuszeile angezeigt. Im Tooltip zur Zeitzone werden die Eigenschaften der Zeitzone und des Kalenders dargestellt.

Tooltip zu den Kalender-Einstellungen in der Statuszeile

Die aktuelle Tageszeit in der Statuszeile wird immer bezogen auf den aktiven Kalender aufbereitet. Neben dem aktuellen Datum wird im Tooltip die Tageszeit dargestellt, ob die Zeitzone über eine Unterscheidung zwischen Sommer und Winterzeit verfügt und welche Zeitverschiebung aktuell aktiv ist.

Tooltip zu den Zeiteinstellungen in der Statuszeile

3.6.3          Zeitstempel

Ein Zeitstempel (technisch „TimeStamp“) ist ein Wert, der einen Punkt auf der UTC-Zeitachse definiert. Die Genauigkeit eines Zeitstempels ist immer Millisekunde. Der Wert eines Zeitstempels ist absolut und von der Zeitzone unabhängig und wird technisch als long-Wert innerhalb einer Instanz der Java-Klasse java.util.Date repräsentiert. Die Aufbereitung eines Zeitstempels als menschenlesbarer Text erfordert immer eine Zeitzone. Der gleiche Zeitstempel hat abhängig von der Zeitzone, die für die Aufbereitung verwendet wird, eine andere Text-Darstellung. Bei der Aufbereitung sind auch Sommer- und Winterzeit zu berücksichtigen. Sie führen unter anderem dazu, dass nicht jeder Wert in jeder Zeitzone darstellbar oder eindeutig ist.

Alle Zeitstempel auf der Oberfläche (z. B. die Zeit in der Statuszeile) werden bzgl. der Zeitzone des aktiven Kontexts aufbereitet. Die Zeitzone für Zeitstempel wird nur ein Mal in der Statuszeile angezeigt. Ändert sich die Zeitzone durch den Wechsel der Organisation, so werden die Darstellungen aller Zeitstempel aktualisiert. Bei Anwendungen erfolgt dies standardmäßig mit dem Aufruf der Methode taskSwitch() durch das System und das damit verbundene erneute Setzen der Werte in den Feldern. Möchte eine Anwendung selbst auf das Umschalten der Organisation reagieren, um beispielsweise eine Sicherheitsabfrage anzuzeigen, dann kann sie eine eigene Action für dieses Ereignis setzen. In diesem Fall wird taskSwitch() nicht automatisch aufgerufen und die Anwendung muss die Feldinhalte vor und nach dem Anzeigen des Dialog-Fensters die Felder selbst aktualisieren.

Im Wertebereich des Zeitstempels bestehen folgende symbolische Werte und Intervalle:

• UNDEFINED_TIME_STAMP

Dieser Wert repräsentiert den nicht angegeben Zeitstempel.

• MIN_TIME_STAMP

Dieser Wert repräsentiert minus unendlich, d. h. den Zeitstempel, der kleiner ist als alle anderen angegebenen Zeitstempel. Auf der Datenbank wird er gespeichert als „31.12.0001 23:02:00.000 GMT“.

• MAX_TIME_STAMP

Dieser Wert repräsentiert plus unendlich, d. h. den Zeitstempel, der größer ist als alle anderen angegebenen Zeitstempel. Auf der Datenbank wird er gespeichert als „31.12.4712 00:00:00.000 GMT“.

Daneben bestehen folgende Werte, die nicht direkt von Anwendungen erzeugt oder auf die zugegriffen werden. Sie werden bei der Umrechnung einer Eingabe bzw. bei der Ausgabe der oben genannten symbolischen Werte verwendet.

Hinweis:

Die nachfolgend aufgeführten Werte dürfen nicht persistent gemacht werden. Die zugehörigen Prüfklassen müssen verhindern, dass diese Werte innerhalb einer Transaktion gespeichert werden.

• MIN_TIME_STAMP_LIMIT

Alle Werte kleiner als dieser Wert werden als MIN_TIME_STAMP interpretiert. Aktuell „01.01.1800 00:00:00.000 GMT“.

• MAX_TIME_STAMP_LIMIT

Alle Werte größer gleich diesem Wert werden als MAX_TIME_STAMP interpretiert. Aktuell „01.01.4000 00:00:00.000 GMT“.

• MIN_TIME_STAMP_EXTERNAL

Dies ist der Wert für die menschenlesbare Darstellung von MIN_TIME_STAMP. Aktuell „01.01.1000 00:00:00.000 GMT“.

• MAX_TIME_STAMP_EXTERNAL

Dies ist der Wert für die menschenlesbare Darstellung von MAX_TIME_STAMP. Aktuell „31.12.9999 00:00:00.000 GMT“.

• Ungültige Zeitstempel

Falsche Benutzereingabe für ungültige Zeitstempel führen zu ungültigen GUIDs, ähnlich wie bei EntityFields. Diese werden verwendet, um in entsprechend typisierten Variablen die Werte bis zur Prüfung zwischenzuspeichern.

Gültige Werte für Zeitstempel.

Rechenoperationen auf Zeitstempeln müssen die symbolischen Werte beachten. Beispielsweise ergibt „MIN_TIME_STAMP + 1 s = MIN_TIME_STAMP“.

Hinweis:
Der Wert „null“ ist kein gültiger Zeitstempel. Der leere Zeitstempel ist UNDEFINED_TIME_STAMP. Die Verwendung von „null“ als Wert für einen Zeitstempel ist ein Programmierfehler.

Hinweis:
in Crystal Reports und im ODBC-Treiber weicht der Wertebereich für Zeitstempel von den hier dagestellten Werten ab.

Alle Angaben von Gültigkeiten, z. B. bei der Zeitabhängigkeit von Business Objects im Persistenzdienst, sind im Allgemeinen Zeitstempel.

3.6.4          Lokaler Zeitstempel

An allen Stellen, an denen eine Zeitangabe unabhängig vom Kontext gleich aufbereitet werden soll (lokale Zeitangabe), muss außer dem eigentlichen Zeitstempel auch noch die Zeitzone gespeichert werden. Dies ist die Zeitzone bezüglich derer der Wert aufbereitet wird. Bei der Eingabe wird immer diese Zeitzone verwendet, um die Eingabe zu „parsen“. Die Zeitzone des aktuell aktiven Kalenders hat, anders als bei Zeitstempeln, keinen Einfluss auf den Wert einer lokalen Zeitangabe. Einzig die Anzeige der Zeitzone entfällt, wenn bei der Ausgabe einer lokalen Zeitangabe ihre Zeitzone mit der Zeitzone des aktuell aktiven Kalenders übereinstimmt.

Zur Laufzeit werden lokale Zeitangaben als Objekte vom komplexen Typ „CisDate“ repräsentiert. Ein „CisDate“ besteht aus einem Zeitstempel und einer Referenz auf eine Zeitzone. Für die Speicherung der Zeitzone von lokalen Zeitangaben bestehen zwei Möglichkeiten. Entweder besitzt ein Attribut vom Typ „CisDate“ eine eigene Spalte für die Speicherung der Zeitzone oder das Business Object stellt eine gemeinsame Zeitzone für seine Attribute zur Verfügung. Ein Business Object kann auch beide Arten von lokalen Zeitangaben gleichzeitig enthalten. Die Verwendung einer gemeinsamen Zeitzone für eine Teilmenge der Attribute reduziert die Anzahl der in der Datenbank benötigten Spalten.

Bespiel:

• _timeZoneGuid: Generiertes Attribut
• attributeDate: CisAttributeDate
• date: TimeStamp
• timeZoneGuid: GUID
• objectDate1: CisObjectDate
• date: TimeStamp
• objectDate2: CisObjectDate
• date: TimeStamp

Der Zugriff auf die Attribute liefert in allen drei Fällen ein „CisDate“. Hierbei verwenden die Attribute „objectDate1“ und „objectDate2“ die gleiche Zeitzone. Diese wird im Attribut „timeZoneGuid“ abgelegt und ist nach dem ersten Speichern des Business Objects unveränderbar. Bei transienten Business Objects wird beim Setzen eines „CisDate“ in eines dieser Attribute auch die Zeitzone des Business Objects gesetzt.

Die Behandlung von lokalen Datumsangaben unterscheidet sich technisch nicht von der Behandlung lokaler Zeitstempel. Jedoch werden Datumsangaben bei der Ein- und Ausgabe besonders behandelt.

• Bei der Ausgabe wird der Tageszeit-Anteil nicht visualisiert
• Bei der Eingabe wird der Tageszeit-Anteil als „00:00“ angenommen

Bei Datumsangaben, die einen „Bis-Zeitpunkt“ repräsentieren, wird zudem die Ein- und Ausgabe um einen Kalendertag verschoben durchgeführt. Die Eingabe „31.12.2003“ bei einem „Bis-Datum“ wird als „01.01.2004 00:00:00.000“ gespeichert. Hierdurch wird erreicht, dass die Angabe „01.01…-31.12…“ tatsächlich einem ganzen Jahr inklusive dem letzten Tag entspricht.

Hinweis:

Sowohl lokale Zeitstempel als auch lokale Datumsangaben werden als Instanzen von „CisDate“ interpretiert. Nur im Zusammenhang mit einem logischen Datentyp kann entschieden werden, wie die Ein- bzw. Ausgabe erfolgen muss.

3.6.5          Lokales Datum

Die Behandlung von lokalen Datumsangaben unterscheidet sich technisch nicht von der Behandlung von lokalen Zeitstempeln. Jedoch werden Datumsangaben bei der Ein- und Ausgabe besonders behandelt.

• Bei der Ausgabe wird der Tageszeit-Anteil nicht visualisiert
• Bei der Eingabe wird der Tageszeit-Anteil als „00:00“ angenommen

3.6.6          Lokales Bis-Datum

Bei Datumsangaben, die einen „Bis-Zeitpunkt“ repräsentieren, wird zudem die Ein- und Ausgabe um einen Kalendertag verschoben durchgeführt. Die Eingabe „31.12.2003“ bei einem „Bis-Datum“ wird als „01.01.2004 00:00:00.000“ gespeichert. Hierdurch wird erreicht, dass die Angabe „01.01…-31.12…“ tatsächlich einem ganzen Jahr inklusive dem letzten Tag entspricht.

3.6.7          Lokales Gültig-Ab-Datum

3.6.8          Lokaler Gültig-Ab-Zeitstempel

3.6.9          Lokales Gültig-Bis-Datum

3.6.10       Lokaler Gültig-Bis-Zeitstempel

3.6.11       Tageszeit

Eine Tageszeit (technisch „TimeOfDay“) ist ein Spezialfall eines lokalen Zeitstempels. Hierbei ist die Zeitzone auf „GMT“ festgelegt und nur der Zeitanteil des Zeitstempels am 1.1.1970 wird betrachtet. Dadurch dass die Zeitzone festgelegt ist, entfällt die Notwendigkeit sie zu speichern. Die Angabe „00:00“ wird somit als „01.01.1970 00:00 GMT“ verwaltet und gespeichert. In Java entspricht somit „00:00“ dem Wert „new Date(0)“ und „23:59.59.999“ dem Wert „new Date(86399999)“.

3.6.12       Technische Dauer

Eine technische Dauer (technisch „Duration“) ist eine Anzahl Millisekunden oder Nanosekunden. Beispiele hierfür sind die Laufzeit eines Application-Servers oder eines Verarbeitungsauftrages oder auch die Angabe eines Timeouts. Die Darstellung einer technischen Dauer erfolgt unabgängig von einem Kalender als „w Wochen t Tage h Stunden m Minuten s Sekunden mm Millisekunden“. Zusätzlich existiert eine kurze Darstellung und das Weglassen von „0“-Bestand­teilen am Ende.

3.6.13       Fachliche Dauer

Die fachliche Dauer speichert im Gegensatz zur technischen Dauer keine exakten, sondern einen symbolischen Wert, z. B. „1 Quartal“.

3.6.14       Zeitintervall (zwei Zeitstempel)

Ein Zeitintervall (technisch „TimeInterval“) ist ein nach oben offenes Intervall von Zeitstempeln „[from, until)“. Abhängig von der konkreten Anforderung werden beide Grenzen oder nur eine der beiden Grenzen gespeichert. Hierbei werde im Datenmodell entsprechende Einzel-Felder vom Typ Zeitstempel verwendet werden, da auf diesen Indizes definiert werden können.

3.6.15       Symbolisches Intervall

Ein symbolisches Intervall (technisch „SymbolicInterval“) beschreibt eine Regel für eine Menge von wiederkehrenden Zeitpunkten, z. B. „Jeden 1. Tag im Monat um 01:00“. Zusammen mit einem Kalender, einem Startzeitpunkt und einer Anzahl kann hieraus die Sequenz der nächsten Zeitstempel berechnet werden, die der Regel genügen.

3.6.16       Termin

Ein Termin (technisch „PointInTime“) ist eine Zeitspanne, deren Beginn mit einer vordefinierten Genauigkeit (Jahr, Quartal, Monat, Kalenderwoche, Tag) und einem vordefinierten Kalender festgelegt wird.

Beispiele:

Kalenderwoche – „24/2004“, Tag – „01.02.2004“

Zusätzlich enthält der Termin einen Offset, z. B. „+3 Tage“, „-1 Kalenderwoche“. Dieses Offset stellt eine Terminverschiebung dar und wird verwendet, um einen Zeitstempel zu berechnen, der die Grundlage für die Suche nach Terminen und die Sortierung von Terminen darstellt.

3.7               Rechnungswesen

In den Business Objects des Rechnungswesen-Servers werden keine besonderen Datentypen verwendet. Auf die zugehörigen Business Objects im Namensraum „com.varag.app.database.obj“ bieten der Persistenzdienst, die OQL-Suchen und der ODBC-Treiber lesenden Zugriff. Da keine schreibenden Zugriffe erlaubt sind, existieren auch keine Prüf- oder Hilfsklassen.

3.7.1          Rechnungswesen-Boolean

3.7.2          Rechnungswesen-Valueset

3.7.3          Rechnungswesen-Objekt-Identifikation

3.7.4          Rechnungswesen-Datum

3.7.5          Rechnungswesen-Zeitstempel