Module 1 → Lesson 6 → Part 4 of 8
Почему платеж — это изменение связанных записей
Lesson contents
- Деньги как запись в системе учета
- Что на самом деле показывает банковский баланс
- Активы, обязательства и банковский учет
- Почему платеж — это изменение связанных записей
- Как согласуется учет между разными банками
- Как появляются безналичные деньги
- Почему денежная система требует доверия, правил и контроля
- Итоги урока
What you'll learn
Один платеж — несколько изменений
Представим простой перевод: Emma Lee → Alex Morgan, 300 €.
Для пользователя все выглядит почти слишком просто: Emma нажимает «Отправить 300 €», Alex получает 300 €.
Но финансовая система не может ограничиться одной записью — «Emma −300 €» — и забыть обо всем остальном.
Платеж должен согласованно изменить несколько связанных позиций.
Иначе деньги начнут либо исчезать, либо появляться там, где их никто не создавал.
Для бухгалтерии оба варианта — плохой сюжет.
Платеж меняет состояние системы
До операции: Emma — 1 000 €, Alex — 500 €.
Emma переводит 300 €.
После завершения: Emma — 700 €, Alex — 800 €.
Это не две случайные цифры.
Изменения связаны одной операцией: Emma −300 €, Alex +300 €.
- 1Emma Lee — до операции 1 000 €, после перевода 300 € становится 700 €. Изменяется учетное значение в рамках единой операции TX-001.
- 2Alex Morgan — до операции 500 €, после получения перевода 300 € становится 800 €. Оба изменения относятся к одной и той же операции.
Что такое транзакция
До: Emma 1 000 €, Alex 500 €.
После: Emma 700 €, Alex 800 €.
Система должна понимать: какая операция вызвала изменения; какие записи к ней относятся; в какой последовательности она обрабатывалась; завершилась ли она успешно.
Почему нельзя изменить только одну сторону
Представим техническую ошибку.
Система уменьшила счет Emma: 1 000 € → 700 €, но счет Alex остался 500 €.
Возникает очевидный вопрос: где 300 €?
Теперь обратная ошибка.
Alex получил: 500 € → 800 €, но счет Emma остался 1 000 €.
Теперь появились дополнительные 300 € без соответствующего основания.
Оба состояния нарушают согласованность учета.
- 1Правильно — Emma −300 €, Alex +300 €. Согласованное состояние.
- 2Ошибка A — Emma −300 €, Alex 0 €. Где 300 €?
- 3Ошибка B — Emma 0 €, Alex +300 €. Откуда появились 300 €?
Связь с двойной записью
В предыдущей части мы познакомились с принципом двойной записи.
Теперь видно, зачем он нужен на практике.
Платеж — это не команда «исправить одну цифру».
Это финансовое событие, которое должно корректно отразиться во всех связанных учетных позициях.
В реальной банковской системе таких позиций может быть больше двух.
Перевод внутри одного банка
Если Emma и Alex обслуживаются в одном банке, обе клиентские позиции находятся внутри одной финансовой организации.
Упрощенно: Банк A, Emma 1 000 € → 700 €, Alex 500 € → 800 €.
Банк может согласованно изменить собственные учетные записи.
Межбанковский расчет для этой операции не требуется.
А если банки разные
Теперь: Emma обслуживается в Банке A, Alex — в Банке B.
На клиентском уровне по-прежнему нужно получить: Emma −300 €, Alex +300 €.
Но теперь эти записи находятся в двух независимых банковских системах.
Поэтому возникает дополнительный уровень: Банк A → финансовое урегулирование → Банк B.
Именно здесь простой платеж превращается в задачу согласования нескольких систем.
Подробно это разберем в следующей части.
Платеж проходит через состояния
Финансовая операция не всегда мгновенно перескакивает из «ничего не произошло» в «полностью завершено».
Она может проходить промежуточные состояния.
Например: создан → принят → в обработке → отправлен → зачислен.
Названия различаются у разных банков и платежных систем.
Главная идея: состояние операции и состояние счетов должны оставаться согласованными на каждом этапе обработки.
Почему появляется статус «В обработке»
Допустим, банк уже принял распоряжение Emma.
Но операция еще не завершила все необходимые этапы.
В таком случае система может: ограничить доступность суммы; зарегистрировать платеж как ожидающий; передать его дальше; ждать подтверждения следующего этапа.
Поэтому статус «В обработке» не означает «банк потерял деньги и теперь думает, что делать».
Чаще это означает, что операция находится между двумя предусмотренными состояниями.
Идентификатор операции
Чтобы связанные системы понимали, о каком именно платеже идет речь, операции получают уникальные или иным образом однозначно различимые идентификаторы.
Упрощенно: Transaction ID — TX-84F2...
Он помогает: отслеживать обработку; сопоставлять записи; проводить сверку; разбирать ошибки; обращаться в поддержку.
Почему это важно при техническом сбое
Emma отправляет 600 €.
Приложение зависает.
Она не понимает, завершилась операция или нет.
Если просто нажать «Отправить» второй раз, могут возникнуть уже две разные операции: TX-001 → 600 €, TX-002 → 600 €.
Поэтому финансовые системы стараются различать: повторную обработку одной операции; создание новой операции.
А пользователю при неясном результате лучше сначала проверить историю платежей, а не экспериментировать с кнопкой еще раз.
Повторная обработка не должна создавать случайные дубли
В информационных системах важен принцип: если техническое сообщение пришлось отправить повторно, это не должно автоматически превращать один платеж в два.
Конкретные механизмы зависят от платежной системы.
Но общий смысл прост: система должна уметь отличить повтор той же операции от нового платежа.
Что происходит при ошибке
Представим межбанковский перевод.
Банк отправителя успешно выполнил свою часть, но следующий этап временно не завершился.
Система не должна просто забыть об операции.
Она должна иметь возможность определить: что уже произошло; что еще не произошло; какой статус имеет платеж; нужно ли продолжить обработку; требуется ли возврат или другая предусмотренная процедура.
Именно для этого существуют: статусы; идентификаторы; журналы; сверка; механизмы обработки ошибок.
Что такое согласованность
Например: Emma −300 €, Alex +300 €, межбанковский расчет 300 €.
Эти данные относятся к одной экономической операции и должны соответствовать друг другу в рамках применимой модели расчета.
А если записи расходятся
Например: Банк A — отправлено 300 €, платежная система — 300 €, Банк B — получено 0 €.
Возникает расхождение.
Теперь необходимо выяснить: платеж еще обрабатывается; сообщение не дошло; операция была отклонена; произошел технический сбой; запись отсутствует по другой причине.
Для этого и нужна сверка, с которой мы познакомились в Части 1.
Один платеж связывает несколько уровней
Удобно представить банковскую операцию тремя слоями.
Пользователь: Emma — «Перевести 300 € Alex».
Клиентский учет: Emma −300 €, Alex +300 €.
Расчет между банками, если банки разные: Банк A → 300 € → Банк B.
Пользователь видит только первый и часть второго уровня.
Остальная финансовая кухня работает за интерфейсом.
- 1Пользователь — Emma нажимает «Перевести 300 € Alex».
- 2Клиентский учет — Emma −300 €, Alex +300 €.
- 3Межбанковский расчет — требуется только если банки разные; при одном банке этот уровень не нужен для данной операции.
Почему нельзя судить о платеже только по одной записи
Если отправитель видит «−1 200 €», это еще не всегда отвечает на вопрос: получатель уже получил деньги?
И наоборот: если платеж создан, но сумма еще не окончательно отражена в одном из пользовательских показателей, это не означает, что операции не существует.
Нужно смотреть на: статус; историю; доступный остаток; информацию банка о конкретной операции.
Главное, что нужно запомнить
- Платеж переводит финансовую систему из одного согласованного состояния в другое.
- Изменения отправителя и получателя являются связанными частями одной операции.
- Нельзя корректно изменить только одну сторону платежа и забыть о другой.
- Банковские операции могут проходить через несколько промежуточных состояний.
- Идентификаторы и журналы позволяют отслеживать одну и ту же операцию между этапами обработки.
- При технической неопределенности повторное нажатие «Отправить» может создать новую операцию, поэтому сначала нужно проверить статус первой.
- Внутри одного банка связанные записи находятся в одной организации.
- При разных банках необходимо согласовать уже несколько независимых систем учета.
- Именно поэтому платежи требуют не только передачи информации, но и согласованного финансового учета.
Что дальше
Теперь понятно, почему платеж нельзя рассматривать как две независимые цифры: −300 € и +300 €.
Но если отправитель и получатель находятся в разных банках, возникает более сложный вопрос: как две независимые финансовые организации убеждаются, что их записи соответствуют друг другу?
Кто фиксирует межбанковский результат?
Что происходит, если одна система показывает одно, а другая — другое?
И какую роль здесь играют расчетные позиции и сверка?
Об этом — в следующей части — «Как согласуется учет между разными банками».
- Платеж переводит финансовую систему из одного согласованного состояния в другое.
- Изменения отправителя и получателя являются связанными частями одной операции.
- Нельзя корректно изменить только одну сторону платежа и забыть о другой.
- Банковские операции могут проходить через несколько промежуточных состояний.
- Идентификаторы и журналы позволяют отслеживать одну и ту же операцию между этапами обработки.
- При технической неопределенности повторное нажатие «Отправить» может создать новую операцию, поэтому сначала нужно проверить статус первой.
- Внутри одного банка связанные записи находятся в одной организации.
- При разных банках необходимо согласовать уже несколько независимых систем учета.
- Именно поэтому платежи требуют не только передачи информации, но и согласованного финансового учета.
One Payment, Several Changes
Imagine a simple transfer: Emma Lee → Alex Morgan, 300 €.
To the user, it all looks almost too simple: Emma taps "Send 300 €," Alex receives 300 €.
But the financial system cannot settle for a single entry — "Emma −300 €" — and forget about everything else.
A payment must change several related positions consistently.
Otherwise money would start either disappearing or appearing where no one created it.
For accounting, both scenarios are a bad plot.
A Payment Changes the State of the System
Before the operation: Emma — 1 000 €, Alex — 500 €.
Emma transfers 300 €.
After completion: Emma — 700 €, Alex — 800 €.
These are not two random numbers.
The changes are linked by one operation: Emma −300 €, Alex +300 €.
- 1Emma Lee — before the operation 1 000 €, after the 300 € transfer becomes 700 €. The recorded value changes within a single operation, TX-001.
- 2Alex Morgan — before the operation 500 €, after receiving the 300 € transfer becomes 800 €. Both changes belong to the same operation.
What a Transaction Is
Before: Emma 1 000 €, Alex 500 €.
After: Emma 700 €, Alex 800 €.
The system must understand: which operation caused the changes; which records belong to it; in what sequence it was processed; and whether it completed successfully.
Why Only One Side Cannot Be Changed
Imagine a technical error.
The system reduced Emma's account: 1 000 € → 700 €, but Alex's account stayed at 500 €.
An obvious question arises: where are the 300 €?
Now the reverse error.
Alex received: 500 € → 800 €, but Emma's account stayed at 1 000 €.
Now an extra 300 € has appeared with no corresponding basis.
Both states break accounting consistency.
- 1Correct — Emma −300 €, Alex +300 €. Consistent state.
- 2Error A — Emma −300 €, Alex 0 €. Where are the 300 €?
- 3Error B — Emma 0 €, Alex +300 €. Where did the 300 € come from?
The Link to Double-Entry Bookkeeping
In the previous part, we learned about the principle of double-entry bookkeeping.
Now we can see why it matters in practice.
A payment is not a command to "fix one number."
It is a financial event that must be correctly reflected across all related accounting positions.
In a real banking system, there can be more than two such positions.
A Transfer Within One Bank
If Emma and Alex bank at the same institution, both customer positions sit inside a single financial organization.
Simplified: Bank A, Emma 1 000 € → 700 €, Alex 500 € → 800 €.
The bank can change its own records consistently.
No interbank settlement is required for this operation.
What If the Banks Are Different
Now: Emma banks at Bank A, Alex at Bank B.
At the customer level, the result still has to be: Emma −300 €, Alex +300 €.
But now these records sit in two independent banking systems.
So an additional layer appears: Bank A → financial settlement → Bank B.
This is exactly where a simple payment turns into the task of reconciling several systems.
We'll look at this in detail in the next part.
A Payment Passes Through States
A financial operation doesn't always jump instantly from "nothing has happened" to "fully completed."
It can pass through intermediate states.
For example: created → accepted → processing → sent → credited.
The names differ across banks and payment systems.
The main idea: the state of the operation and the state of the accounts must stay consistent at every stage of processing.
Why the Status "Processing" Appears
Say the bank has already accepted Emma's instruction.
But the operation hasn't yet completed all the required stages.
In that case, the system may: restrict the availability of the amount; register the payment as pending; pass it on further; wait for confirmation of the next stage.
So the status "Processing" doesn't mean "the bank lost the money and is now figuring out what to do."
More often it means the operation is between two states the system provides for.
The Operation Identifier
So that the related systems understand exactly which payment is meant, operations are given unique or otherwise unambiguously distinguishable identifiers.
Simplified: Transaction ID — TX-84F2...
It helps: track processing; match up records; carry out reconciliation; investigate errors; contact support.
Why This Matters When There's a Technical Glitch
Emma sends 600 €.
The app freezes.
She can't tell whether the operation went through or not.
If she simply taps "Send" a second time, two separate operations could result: TX-001 → 600 €, TX-002 → 600 €.
That's why financial systems try to distinguish between: reprocessing the same operation; creating a new operation.
And when the outcome is unclear, the user is better off checking the payment history first, rather than experimenting with the button again.
Reprocessing Should Not Create Accidental Duplicates
In information systems, an important principle applies: if a technical message had to be resent, that should not automatically turn one payment into two.
The specific mechanisms depend on the payment system.
But the general idea is simple: the system must be able to tell a repeat of the same operation apart from a new payment.
What Happens on Failure
Imagine an interbank transfer.
The sending bank has successfully completed its part, but the next stage hasn't finished yet.
The system must not simply forget about the operation.
It must be able to determine: what has already happened; what hasn't happened yet; what status the payment has; whether processing needs to continue; whether a reversal or some other provided-for procedure is required.
This is exactly what statuses, identifiers, logs, reconciliation, and error-handling mechanisms exist for.
What Consistency Is
For example: Emma −300 €, Alex +300 €, interbank settlement 300 €.
This data relates to one economic operation and must correspond to each other within the applicable settlement model.
What If the Records Diverge
For example: Bank A — 300 € sent, payment system — 300 €, Bank B — 0 € received.
A discrepancy arises.
Now it's necessary to find out: whether the payment is still processing; whether the message never arrived; whether the operation was rejected; whether a technical failure occurred; or whether the record is missing for some other reason.
This is exactly what reconciliation, which we learned about in Part 1, is for.
One Payment Links Several Levels
It's convenient to picture a banking operation as three layers.
User: Emma — "Transfer 300 € to Alex."
Customer accounting: Emma −300 €, Alex +300 €.
Settlement between banks, if the banks are different: Bank A → 300 € → Bank B.
The user sees only the first layer and part of the second.
The rest of the financial machinery works behind the interface.
- 1User — Emma taps "Transfer 300 € to Alex."
- 2Customer accounting — Emma −300 €, Alex +300 €.
- 3Interbank settlement — needed only if the banks are different; with a single bank, this layer isn't needed for this operation.
Why a Payment Can't Be Judged by a Single Record Alone
If the sender sees "−1 200 €," that still doesn't always answer the question: has the recipient already received the money?
And conversely: if a payment has been created but the amount isn't yet finally reflected in one of the user-facing figures, that doesn't mean the operation doesn't exist.
You need to look at: status; history; available balance; the bank's information about the specific operation.
The Main Thing to Remember
- A payment moves the financial system from one consistent state to another.
- The changes to the sender and the recipient are linked parts of one operation.
- You cannot correctly change only one side of a payment and forget about the other.
- Banking operations can pass through several intermediate states.
- Identifiers and logs make it possible to track the same operation across processing stages.
- When there's technical uncertainty, tapping "Send" again can create a new operation, so the status of the first one should be checked first.
- Within a single bank, the related records sit inside one organization.
- With different banks, several independent accounting systems need to be reconciled.
- This is exactly why payments require not just the transfer of information but also consistent financial accounting.
What's Next
Now it's clear why a payment can't be treated as two independent numbers: −300 € and +300 €.
But if the sender and the recipient are at different banks, a more complicated question arises: how do two independent financial organizations make sure their records match each other?
Who records the interbank result?
What happens if one system shows one thing and another shows something else?
And what role do settlement positions and reconciliation play here?
That's the subject of the next part — "How Accounting Is Reconciled Between Different Banks."
- A payment moves the financial system from one consistent state to another.
- The sender's and recipient's changes are linked parts of a single operation.
- You cannot correctly change only one side of a payment and forget the other.
- Banking operations can pass through several intermediate states.
- Identifiers and logs make it possible to track the same operation across processing stages.
- Under technical uncertainty, pressing “Send” again may create a new operation, so the status of the first one should be checked first.
- Within a single bank, linked records sit inside one organization.
- With different banks, several independent accounting systems must already be reconciled.
- That's exactly why payments require not just the transfer of information, but consistent financial accounting.
Μία πληρωμή — πολλές αλλαγές
Ας φανταστούμε μια απλή μεταφορά: Emma Lee → Alex Morgan, 300 €.
Για τον χρήστη όλα φαίνονται σχεδόν υπερβολικά απλά: η Emma πατά «Αποστολή 300 €», ο Alex λαμβάνει 300 €.
Όμως το χρηματοοικονομικό σύστημα δεν μπορεί να αρκεστεί σε μία μόνο εγγραφή — «Emma −300 €» — και να ξεχάσει όλα τα υπόλοιπα.
Η πληρωμή πρέπει να αλλάξει με συνέπεια πολλές συνδεδεμένες θέσεις.
Διαφορετικά τα χρήματα θα αρχίσουν είτε να εξαφανίζονται είτε να εμφανίζονται εκεί όπου κανείς δεν τα δημιούργησε.
Για τη λογιστική, και τα δύο σενάρια είναι κακή εξέλιξη.
Η πληρωμή αλλάζει την κατάσταση του συστήματος
Πριν από τη συναλλαγή: Emma — 1 000 €, Alex — 500 €.
Η Emma μεταφέρει 300 €.
Μετά την ολοκλήρωση: Emma — 700 €, Alex — 800 €.
Δεν πρόκειται για δύο τυχαία νούμερα.
Οι αλλαγές συνδέονται μέσω μίας συναλλαγής: Emma −300 €, Alex +300 €.
- 1Emma Lee — πριν τη συναλλαγή 1 000 €, μετά τη μεταφορά 300 € γίνεται 700 €. Η λογιστική τιμή αλλάζει στο πλαίσιο μίας ενιαίας συναλλαγής TX-001.
- 2Alex Morgan — πριν τη συναλλαγή 500 €, μετά τη λήψη της μεταφοράς 300 € γίνεται 800 €. Και οι δύο αλλαγές ανήκουν στην ίδια συναλλαγή.
Τι είναι η συναλλαγή
Πριν: Emma 1 000 €, Alex 500 €.
Μετά: Emma 700 €, Alex 800 €.
Το σύστημα πρέπει να γνωρίζει: ποια συναλλαγή προκάλεσε τις αλλαγές· ποιες εγγραφές σχετίζονται με αυτήν· με ποια σειρά επεξεργάστηκε· αν ολοκληρώθηκε επιτυχώς.
Γιατί δεν μπορεί να αλλάξει μόνο η μία πλευρά
Ας φανταστούμε ένα τεχνικό σφάλμα.
Το σύστημα μείωσε τον λογαριασμό της Emma: 1 000 € → 700 €, αλλά ο λογαριασμός του Alex παρέμεινε 500 €.
Προκύπτει ένα προφανές ερώτημα: πού βρίσκονται τα 300 €;
Τώρα το αντίστροφο σφάλμα.
Ο Alex έλαβε: 500 € → 800 €, αλλά ο λογαριασμός της Emma παρέμεινε 1 000 €.
Τώρα εμφανίστηκαν επιπλέον 300 € χωρίς αντίστοιχη αιτιολόγηση.
Και οι δύο καταστάσεις παραβιάζουν τη συνέπεια της λογιστικής.
- 1Σωστό — Emma −300 €, Alex +300 €. Συνεπής κατάσταση.
- 2Σφάλμα A — Emma −300 €, Alex 0 €. Πού βρίσκονται τα 300 €;
- 3Σφάλμα B — Emma 0 €, Alex +300 €. Από πού προήλθαν τα 300 €;
Η σχέση με τη διπλογραφία
Στο προηγούμενο μέρος γνωρίσαμε την αρχή της διπλογραφίας.
Τώρα φαίνεται γιατί χρειάζεται στην πράξη.
Η πληρωμή δεν είναι μια εντολή «διόρθωσε ένα νούμερο».
Είναι ένα χρηματοοικονομικό γεγονός που πρέπει να αντικατοπτρίζεται σωστά σε όλες τις συνδεδεμένες λογιστικές θέσεις.
Σε ένα πραγματικό τραπεζικό σύστημα τέτοιες θέσεις μπορεί να είναι περισσότερες από δύο.
Μεταφορά εντός της ίδιας τράπεζας
Αν η Emma και ο Alex εξυπηρετούνται από την ίδια τράπεζα, και οι δύο θέσεις πελατών βρίσκονται μέσα στον ίδιο χρηματοοικονομικό οργανισμό.
Απλοποιημένα: Τράπεζα A, Emma 1 000 € → 700 €, Alex 500 € → 800 €.
Η τράπεζα μπορεί να αλλάξει με συνέπεια τις δικές της λογιστικές εγγραφές.
Δεν απαιτείται διατραπεζικός διακανονισμός για αυτή τη συναλλαγή.
Κι αν οι τράπεζες είναι διαφορετικές
Τώρα: η Emma εξυπηρετείται από την Τράπεζα A, ο Alex — από την Τράπεζα B.
Στο επίπεδο του πελάτη εξακολουθεί να χρειάζεται να προκύψει: Emma −300 €, Alex +300 €.
Όμως τώρα αυτές οι εγγραφές βρίσκονται σε δύο ανεξάρτητα τραπεζικά συστήματα.
Γι' αυτό προκύπτει ένα επιπλέον επίπεδο: Τράπεζα A → χρηματοοικονομικός διακανονισμός → Τράπεζα B.
Ακριβώς εδώ μια απλή πληρωμή μετατρέπεται σε ζήτημα συμφωνίας πολλών συστημάτων.
Θα το εξετάσουμε αναλυτικά στο επόμενο μέρος.
Η πληρωμή περνά από καταστάσεις
Μια χρηματοοικονομική πράξη δεν περνά πάντα ακαριαία από το «δεν συνέβη τίποτα» στο «ολοκληρώθηκε πλήρως».
Μπορεί να περάσει από ενδιάμεσες καταστάσεις.
Για παράδειγμα: δημιουργήθηκε → έγινε αποδεκτή → σε επεξεργασία → απεστάλη → πιστώθηκε.
Οι ονομασίες διαφέρουν ανάλογα με την τράπεζα και το σύστημα πληρωμών.
Η βασική ιδέα: η κατάσταση της συναλλαγής και η κατάσταση των λογαριασμών πρέπει να παραμένουν συνεπείς σε κάθε στάδιο επεξεργασίας.
Γιατί εμφανίζεται η κατάσταση «Σε επεξεργασία»
Ας υποθέσουμε ότι η τράπεζα έχει ήδη δεχτεί την εντολή της Emma.
Όμως η συναλλαγή δεν έχει ολοκληρώσει ακόμη όλα τα απαραίτητα στάδια.
Σε αυτή την περίπτωση το σύστημα μπορεί να: περιορίσει τη διαθεσιμότητα του ποσού· καταχωρίσει την πληρωμή ως εκκρεμή· τη διαβιβάσει παρακάτω· περιμένει επιβεβαίωση του επόμενου σταδίου.
Γι' αυτό η κατάσταση «Σε επεξεργασία» δεν σημαίνει «η τράπεζα έχασε τα χρήματα και τώρα σκέφτεται τι να κάνει».
Συνήθως σημαίνει ότι η συναλλαγή βρίσκεται ανάμεσα σε δύο προβλεπόμενες καταστάσεις.
Το αναγνωριστικό της συναλλαγής
Για να καταλαβαίνουν τα συνδεδεμένα συστήματα για ποια ακριβώς πληρωμή πρόκειται, οι συναλλαγές λαμβάνουν μοναδικά ή διαφορετικά με σαφήνεια διακριτά αναγνωριστικά.
Απλοποιημένα: Transaction ID — TX-84F2...
Βοηθά στο να: παρακολουθείται η επεξεργασία· αντιστοιχίζονται οι εγγραφές· διεξάγεται συμφωνία· διερευνώνται σφάλματα· γίνεται επικοινωνία με την υποστήριξη.
Γιατί αυτό έχει σημασία σε περίπτωση τεχνικής βλάβης
Η Emma στέλνει 600 €.
Η εφαρμογή κολλάει.
Δεν καταλαβαίνει αν η συναλλαγή ολοκληρώθηκε ή όχι.
Αν απλώς πατήσει «Αποστολή» για δεύτερη φορά, μπορεί να προκύψουν δύο διαφορετικές συναλλαγές: TX-001 → 600 €, TX-002 → 600 €.
Γι' αυτό τα χρηματοοικονομικά συστήματα προσπαθούν να διακρίνουν: την επανεπεξεργασία της ίδιας συναλλαγής· τη δημιουργία νέας συναλλαγής.
Στον χρήστη, όταν το αποτέλεσμα δεν είναι σαφές, συμφέρει πρώτα να ελέγξει το ιστορικό συναλλαγών, αντί να πειραματίζεται ξανά με το κουμπί.
Η επανεπεξεργασία δεν πρέπει να δημιουργεί τυχαία διπλότυπα
Στα πληροφοριακά συστήματα ισχύει μια σημαντική αρχή: αν ένα τεχνικό μήνυμα χρειάστηκε να σταλεί ξανά, αυτό δεν πρέπει αυτόματα να μετατρέπει μία πληρωμή σε δύο.
Οι συγκεκριμένοι μηχανισμοί εξαρτώνται από το σύστημα πληρωμών.
Όμως η γενική ιδέα είναι απλή: το σύστημα πρέπει να μπορεί να διακρίνει την επανάληψη της ίδιας συναλλαγής από μια νέα πληρωμή.
Τι συμβαίνει σε περίπτωση σφάλματος
Ας φανταστούμε μια διατραπεζική μεταφορά.
Η τράπεζα του αποστολέα ολοκλήρωσε επιτυχώς το δικό της μέρος, αλλά το επόμενο στάδιο δεν ολοκληρώθηκε προσωρινά.
Το σύστημα δεν πρέπει απλώς να ξεχάσει τη συναλλαγή.
Πρέπει να έχει τη δυνατότητα να προσδιορίσει: τι έχει ήδη συμβεί· τι δεν έχει ακόμη συμβεί· ποια κατάσταση έχει η πληρωμή· αν χρειάζεται να συνεχιστεί η επεξεργασία· αν απαιτείται επιστροφή χρημάτων ή άλλη προβλεπόμενη διαδικασία.
Ακριβώς γι' αυτό υπάρχουν: καταστάσεις· αναγνωριστικά· αρχεία καταγραφής· συμφωνία· μηχανισμοί διαχείρισης σφαλμάτων.
Τι είναι η συνέπεια
Για παράδειγμα: Emma −300 €, Alex +300 €, διατραπεζικός διακανονισμός 300 €.
Αυτά τα δεδομένα αφορούν μία οικονομική συναλλαγή και πρέπει να αντιστοιχούν μεταξύ τους στο πλαίσιο του εφαρμοστέου μοντέλου διακανονισμού.
Κι αν οι εγγραφές διαφέρουν
Για παράδειγμα: Τράπεζα A — απεστάλησαν 300 €, σύστημα πληρωμών — 300 €, Τράπεζα B — ελήφθησαν 0 €.
Προκύπτει απόκλιση.
Τώρα χρειάζεται να διερευνηθεί: αν η πληρωμή βρίσκεται ακόμη σε επεξεργασία· αν το μήνυμα δεν έφτασε· αν η συναλλαγή απορρίφθηκε· αν συνέβη τεχνική βλάβη· αν η εγγραφή λείπει για κάποιον άλλο λόγο.
Ακριβώς γι' αυτό χρειάζεται η συμφωνία, την οποία γνωρίσαμε στο Μέρος 1.
Μία πληρωμή συνδέει πολλά επίπεδα
Είναι βολικό να φανταστούμε την τραπεζική πράξη ως τρία επίπεδα.
Χρήστης: Emma — «Μεταφορά 300 € στον Alex».
Λογιστική πελατών: Emma −300 €, Alex +300 €.
Διακανονισμός μεταξύ τραπεζών, αν οι τράπεζες είναι διαφορετικές: Τράπεζα A → 300 € → Τράπεζα B.
Ο χρήστης βλέπει μόνο το πρώτο και ένα μέρος του δεύτερου επιπέδου.
Η υπόλοιπη χρηματοοικονομική «κουζίνα» λειτουργεί πίσω από τη διεπαφή.
- 1Χρήστης — η Emma πατά «Μεταφορά 300 € στον Alex».
- 2Λογιστική πελατών — Emma −300 €, Alex +300 €.
- 3Διατραπεζικός διακανονισμός — απαιτείται μόνο αν οι τράπεζες είναι διαφορετικές· στην περίπτωση μίας τράπεζας αυτό το επίπεδο δεν χρειάζεται για τη συγκεκριμένη συναλλαγή.
Γιατί δεν μπορούμε να κρίνουμε μια πληρωμή μόνο από μία εγγραφή
Αν ο αποστολέας βλέπει «−1 200 €», αυτό δεν απαντά πάντα στο ερώτημα: ο παραλήπτης έχει ήδη λάβει τα χρήματα;
Και αντίστροφα: αν η πληρωμή έχει δημιουργηθεί, αλλά το ποσό δεν έχει ακόμη αποτυπωθεί οριστικά σε έναν από τους δείκτες του χρήστη, αυτό δεν σημαίνει ότι η συναλλαγή δεν υπάρχει.
Χρειάζεται να εξετάζουμε: την κατάσταση· το ιστορικό· το διαθέσιμο υπόλοιπο· την πληροφορία της τράπεζας για τη συγκεκριμένη συναλλαγή.
Τι πρέπει να θυμόμαστε
- Η πληρωμή μεταφέρει το χρηματοοικονομικό σύστημα από μία συνεπή κατάσταση σε μια άλλη.
- Οι αλλαγές του αποστολέα και του παραλήπτη αποτελούν συνδεδεμένα μέρη μίας συναλλαγής.
- Δεν μπορεί να αλλάξει σωστά μόνο η μία πλευρά της πληρωμής, ξεχνώντας την άλλη.
- Οι τραπεζικές πράξεις μπορούν να περνούν από πολλές ενδιάμεσες καταστάσεις.
- Τα αναγνωριστικά και τα αρχεία καταγραφής επιτρέπουν την παρακολούθηση της ίδιας συναλλαγής ανάμεσα στα στάδια επεξεργασίας.
- Σε περίπτωση τεχνικής αβεβαιότητας, το ξανά πάτημα του «Αποστολή» μπορεί να δημιουργήσει νέα συναλλαγή, γι' αυτό πρέπει πρώτα να ελεγχθεί η κατάσταση της πρώτης.
- Μέσα σε μία τράπεζα οι συνδεδεμένες εγγραφές βρίσκονται στον ίδιο οργανισμό.
- Όταν οι τράπεζες είναι διαφορετικές, χρειάζεται να συμφωνηθούν πλέον πολλά ανεξάρτητα συστήματα λογιστικής.
- Γι' αυτό ακριβώς οι πληρωμές απαιτούν όχι μόνο τη διαβίβαση πληροφορίας, αλλά και συνεπή χρηματοοικονομική λογιστική.
Τι ακολουθεί
Τώρα είναι κατανοητό γιατί η πληρωμή δεν μπορεί να θεωρηθεί ως δύο ανεξάρτητα νούμερα: −300 € και +300 €.
Όμως αν ο αποστολέας και ο παραλήπτης βρίσκονται σε διαφορετικές τράπεζες, προκύπτει ένα πιο περίπλοκο ερώτημα: πώς βεβαιώνονται δύο ανεξάρτητοι χρηματοοικονομικοί οργανισμοί ότι οι εγγραφές τους αντιστοιχούν μεταξύ τους;
Ποιος καταγράφει το διατραπεζικό αποτέλεσμα;
Τι συμβαίνει αν ένα σύστημα δείχνει ένα πράγμα και το άλλο κάτι διαφορετικό;
Και τι ρόλο παίζουν εδώ οι διακανονιστικές θέσεις και η συμφωνία;
Γι' αυτό — στο επόμενο μέρος — «Πώς συμφωνεί η λογιστική ανάμεσα σε διαφορετικές τράπεζες».
- Η πληρωμή μεταφέρει το χρηματοπιστωτικό σύστημα από μία συνεπή κατάσταση σε μια άλλη.
- Οι μεταβολές του αποστολέα και του παραλήπτη είναι συνδεδεμένα μέρη μίας συναλλαγής.
- Δεν μπορεί να μεταβληθεί σωστά μόνο η μία πλευρά μιας πληρωμής, αφήνοντας την άλλη απαρατήρητη.
- Οι τραπεζικές συναλλαγές μπορεί να περνούν από πολλές ενδιάμεσες καταστάσεις.
- Τα αναγνωριστικά και τα αρχεία καταγραφής επιτρέπουν την παρακολούθηση της ίδιας συναλλαγής μεταξύ σταδίων επεξεργασίας.
- Σε περίπτωση τεχνικής αβεβαιότητας, το να πατήσετε ξανά «Αποστολή» μπορεί να δημιουργήσει νέα συναλλαγή, γι' αυτό πρέπει πρώτα να ελεγχθεί η κατάσταση της πρώτης.
- Μέσα σε μία τράπεζα, οι συνδεδεμένες εγγραφές βρίσκονται σε έναν οργανισμό.
- Με διαφορετικές τράπεζες, πρέπει ήδη να συμφωνούν πολλά ανεξάρτητα λογιστικά συστήματα.
- Γι' αυτό ακριβώς οι πληρωμές απαιτούν όχι μόνο μεταφορά πληροφορίας, αλλά και συνεπή χρηματοοικονομική λογιστική.