CX_GENERAL_TERMS

CX_GENERAL_TERMS

Class hierarchy

Description:

Terms and conditions are accompanying data/data/information.
The most common are, for example, payment or delivery terms, but also.
Billing address, reminder recipient, packaging instructions or costs.
fall under this heading. Also manufacturing instructions, work instructions or
internal implementation rules can also be regarded as (marginal) conditions.
can be considered.

The main characteristics of such conditions or agreements are:

1. they may be defined at different levels. Agreements
can, for example, be defined at the level of a single order, generally for a single
customers or generally for all customers.

> CX_BUSINESS_OBJECT holds data field CX_GENERAL_TERMS* generalTerms
This makes it possible to define different or the same terms for different business objects. Business objects different or same
conditions for different business objects. Of course, it is still possible to assign
directly, i.e. without adding a CX_GENERAL_TERMS object data.


2. a general agreement can be modified for a specific case.
be changed. For example, in the case of a special order, a different delivery condition is
than would otherwise apply generally to all orders.
Nevertheless, all other terms (payment term, shipping method, etc.) are
also apply unchanged to this special order.

> Successive search for an information necessary. CX_CONDITION tries
for all its own dynamic data fields (slots) to find the information it is looking for.
for all its own dynamic data fields (slots) - also by passing it on to these objects -, CX_GENERAL_TERMS searches through
also the list conditions.
CX_CONDITION/CX_GENERAL_TERMS overload GetDataField, PlugSlot for this, whereas.
CX_BUSINESS_OBJECT does this only because of the function Condition().
With CX_CONDITION/CX_GENERAL_TERMS one can use any function/data field
if nothing is found, invalid returns. (From IV
Distinction between 0 and invalid necessary !)


A data field/access expression/object can be called in three different ways as an
processable information in three different ways:

1. the name directly defines the information
(e.g. itemPrice)
2. information in the object defines the information
(e.g. classID == IDX_PAYMENT_CONDITION && enum = 3).
3. a wrapper holds the information by means of a data field
(e.g. addressTypeEnum = 2 -> deliveryAddress; bit patterns also possible).

Fetch the information (function CX_BUSINESS_OBJECT::Condition() ?).
to 1. GetData however should be searched further in the PlugSpace !!!
to 2. query via formula and via search in PlugSpace
to 3. can be treated like 2.


Examples:
A delivery address is specified by sending it either directly to
a POINTER slot "deliveryAddress", or via a DESCRIPTIVE
or OVERWRITING reference with (addressTypeEnum & DELIVERY_ADDRESS).
is.

A payment instruction is specified by using a POINTER
slot "payment", or via a DESCRIPTIVE or OVERWRITING
reference in which the slot "paymentTypeEnum" occurs, or
the referenced object is of type CX_PAYMENT_CONDITION.


CX_CLASS* CX_BUSINESS_OBJECT::Condition(CX_FORMULA* _formula)
CX_CLASS* CX_BUSINESS_OBJECT::Condition(short _classID).
CX_CLASS* CX_BUSINESS_OBJECT::Condition(char* _name)

ConditionByFormula(ByQuery)
ConditionByType
ConditionByName


Examples of classes derived from CX_CONDITION as pseudo-classes:

Payment condition CX_PAYMENT_CONDITION
Pricing CX_PRICING_CONDITION
Packing CX_PACKING_CONDITION
Shipping method CX_SHIPPING_CONDITION
Warranty CX_WARRANTY_CONDITION
Delivery time CX_DELIVERY_CONDITION
Binding period CX_BINDING_CONDITION

Code example:

^* MA = member access function,
greyed out = inherited function

^* I = Indexable data field,
greyed out = inherited data field.