ACP 1. Ordner

?_ only one letter is missing with %* more than one is missing...with SQL statement LIKE!

end of this week...date

RUN runs synchron, one have to wait until its finished.

SUBMIT runs asynchron, runs in the background

105

All objects ID, INTL_ID, NAME etc. e.g. BP

105, bp, BP etc.

For the labeling of fields/groups...

Tables are named according to a hierarchical method, starting with e.g. CODE_, OBJ_ or DOC_ followed by the abbreviation code for an object type or a business type.

Code tables contain constants and can be modified via sources, both starting with CODE_

Yes the can!

Via source or via API.

2-4 letters

Namespace $ INTL_ID '_' DESCRIPTION

e.g. ACAD$PB_SSN

Avaloq ok / Oracle NOK

Avaloq NOK

Obsolet function

stop = finish the process first

kill = immediately finish the process

To define the behavior of the avaloq core engines, set the values of the applications basic parameters, define business objects attributes and code tables.

There is only one cost engine.

- to generate booking and balance sheets

- to select accounts

- to define workflow rules

- to select the appropriate custodian

- to calculate cost of a transaction

- to define default values for a field

A container holding the definition of parameterisation and/or scripting.

...compiler.

By overriding (the system knows which part of the source is changed) or overwriting if allowed by avaloq it's flagd in the CODE_SRC_TYPE table.

It's that parameterisation and scripting is stored outside of the ABS, even if it can also be found in the system.

The source type

• overrides/overwrites of Avaloq sources (if allowed)

• sources generated by the Avaloq Banking System on behalf of the user, e.g. Extn-DDIC sources

• sources that are linked to (table) items delivered by Avaloq, e.g. order validations that are linked

to a business type

• the source name part of a source connected to a master source delivered by Avaloq, e.g. a task

template of a client (TQ_SRC_LIST.CLT$MY_LIST) for a task definition (TQ_SRC_LIST) that is

delivered with the kernel.

• source types with a local validity, i.e. sources that are never part of a third party parameterisation,

e.g. printer sources

• sources that are part of a portable parameterisation, e.g. Avaloq script packages, base

parameters, or code tables

• the second part of the source name of a slave source, i.e. a source that is linked to a master

source delivered by Avaloq or another third party vendor

Indeed the name of the sources as well as the syntax is validated by the parser and the sources framework. This is the case for Avaloq source types such as code table definition, code table data, auditing, printer definition, user definition,

task and task template definition.

To check this opportunity, please check the column REV_CMPL in table CODE_SRC_TYPE.

Other Avaloq source types however rely heavily on procedural logic. This is the case for script reports,

incoming and outgoing messages and obviously for Avaloq script sources. There is also a certain

number of types of sources that can make use of procedural logic, but do not necessarily have to.

• the provision of abstract access to data, i.e. that the data is accessible logically (business view)
instead of physically
• the encapsulation of the underlying kernel routines and thus the provision of a stable interface
to the outside world

<namespace>$doc_<intl_id>

<namespace>$obj_<intl_id>

In the table CODE_TAB_DEF

Code tables are definition tables that contain predefined values in one domain. For each domain and for each context a separate code table exists.

keyword native

• Secured APIs (name often – not always - contains a #, like FORMAT#). The source of these APIs

cannot be shown, they are "wrapped" [secured by Oracle]

• Non Secured APIs (like DEF% or NETW_%) are created during the compilation of a source. The

source of these APIs can be shown.

• Client written APIs, e.g. for solving bank specific mathematical rules, following the principle

"develop once – use often".