1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | CashFlowMovements |
| Full Path | Catalog.CashFlowMovements / Catalogs.CashFlowMovements |
| Synonym | Cash flow movements |
| Configuration | Accounting for Kazakhstan, edition 3.0 (version 3.0.74.2) |
| Hierarchy | Hierarchy of groups and elements (folder groups are supported) |
| Navigation Link | e1cib/list/Catalog.CashFlowMovements |
| Where to find | Section "Cash" → "Cash flow movements" (also available from the "Catalogs" and "Bank and Cash" sections) |
Purpose. The catalog is an analytical classifier of cash flow for accounting in the RK. It is not a document and does not independently create entries: its elements serve as the value of analytics (subaccount/dimension) in payment, cash, and bank documents and in cash registers. Based on this analytics, the Cash Flow Statement (CFS) is constructed — using both direct and indirect methods. It is filled out by accountants and finance specialists daily when processing bank statements, payment orders, incoming and outgoing cash orders. The hierarchy of groups serves for a broad classification (operational, investment, financial activities and their articles).
2. Attributes and Table Parts
2.1 Header Attributes
Custom (user-defined) attributes are absent in the metadata. The catalog uses only standard platform attributes:
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
Code |
String | Mandatory | Unique code of the type of movement; part of the natural key of the record |
Name |
String | Mandatory | Full name of the type of cash flow movement; part of the natural key of the record |
Parent |
Catalog.CashFlowMovements | Optional | Owner group in hierarchical organization |
IsGroup |
Boolean | System | Group (folder) indicator in the hierarchy |
The natural key consists of the fields Code and Name (see NaturalKeyFields() in the manager module) — this is a key point when loading/matching data exchanges and when protecting against duplicates.
2.2 Table Parts
Table parts are absent.
3. Forms
Five forms are defined:
| Form | Purpose |
|---|---|
| ElementForm | Key form for creating and editing an element (fields: Parent, Name, Code) |
| GroupForm | Creating and editing a group in the hierarchy (fields: Parent, Name, Code) |
| ListForm | Main list form; supports bulk modification of attributes (command "ModifySelected") |
| SelectionForm | Selecting an element from the list when filling out document attributes |
| GroupSelectionForm | Selecting a group from the hierarchy |
4. Key Module Procedures
There is no specialized application logic (processing of transactions, complex validation of filling) for the classification object. In evidence, the method of the manager module is confirmed:
NaturalKeyFields()(manager module) — returns the composition of the natural key fields (Code,Name). Used by the data exchange subsystem and loading for identifying the element without binding to the internal link (GUID).
For a catalog of this type, standard platform handlers are applicable, which should be used in modifications:
FillingHandler(object module) — default filling when creating a new element;BeforeSaving/OnSaving(object module) — validation of uniqueness and business rules before saving;FillingCheckHandler— control of mandatory attributes;OnCreatingOnServer,OnReadingOnServer(form modules) — setting visibility/accessibility of form elements.
5. Posting and Movements
The catalog is not posted and does not directly create records in registers — it is an analytical dimension. Movements are formed by documents that refer to its elements:
- Accumulation Register "Cash" (managerial/operational accounting of cash balances) — the catalog element serves as the dimension "Cash Movement Article".
- Accounting Register (Cost Accounting) — cash movement is used as a subaccount for cash accounts.
Typical postings of payment documents according to the chart of accounts of the RK, in which cash flow analytics is involved:
| Operation | Debit | Credit | Comment |
|---|---|---|---|
| Receipt of payment from the customer to the current account | 1030 | 1210 | Cash flow analytics: "Receipts from customers" |
| Payment to the supplier from the current account | 3310 | 1030 | Cash flow analytics: "Payments to suppliers" |
| Sale of goods (income) | 1210 | 6010 | Reflection of revenue, VAT at a rate of 16% |
| Accrual of VAT payable | 1210 | 3130 | VAT 16% of taxable turnover |
| Cost of goods sold | 7010 | 1330 | Cost of goods sold |
Example: sale of goods for 116,000 ₸ including VAT → 100,000 ₸ income (Dr 1210 Cr 6010) and 16,000 ₸ VAT (Dr 1210 Cr 3130). Upon receipt of payment (Dr 1030 Cr 1210), the cash flow analytics substitutes the catalog element "Cash Flow Movements" — this is the basis for constructing the CFS.
The electronic support of sales is documented separately: ESF (ESF IS) and SNT — they do not refer to this catalog but are related to the same payment/sales documents.
6. Related Objects and Input Based On
The catalog is a subordinate analytics and is not input based on / does not perform input based on it. References to elements are used in:
- Bank Documents: "Receipt to the current account", "Withdrawal from the current account", bank statement (account 1030).
- Cash Documents: "Incoming cash order", "Outgoing cash order" (account 1010).
- Registers: accumulation register "Cash", accounting register in terms of cash accounts.
- Reports: "Cash Flow Statement" (direct and indirect methods), where catalog elements form the lines of flow articles.
The natural key (Code + Name) is used in exchange plans when synchronizing with other databases.
7. Extension Points
- Adding attributes through configuration extension (for example, "CFS Section", "Type of activity: operational/investment/financial", "CFS line code") for automatic grouping in the report.
- Subscriptions to events
BeforeSaving/OnSavingof the catalog — for controlling the integrity of the classifier and prohibiting the deletion of used articles. - Overriding forms (ElementForm, ListForm) in the extension — adding service fields and hints, without removing the object from support.
- Default filling rules for payment documents — pre-filling the cash flow article depending on the type of operation/counterparty.
- Manager module: when modifying exchanges, rely on
NaturalKeyFields(), not on internal links, to maintain compatibility between databases.