Надо разделить понятия — тип счета и тип остатка по счету.
Счета могут быть активные, пассивные и активно-пассивные по типу. И у счета любого типа может быть активный (дебетовый) или пассивный (кредитовый) остаток (+ или -). Просто когда у счета «неправильный по знаку (неположенный ему по типу) остаток» — то и называют сие счет с «красным сальдо».
Валидаторы проверки остатка по типу остатка и контролируют может ли быть пассивный (кредитовый) остаток по счету например по типу — активному (при наличии признака например на этом счете «разрешенного красного сальдо»).
Говорить что «нельзя иметь активно-пассивные счета» — достаточно недальновидно. Есть системы бухгалтерского учета где они активно используются и непонятно почему ради этого надо держать два и т.п. счета. Если пользователю нужен такой счет — ну пусть объявит счет с таким типом и валидаторы будут пропускать любые проводки по этому счету без контроля знака остатка. С контролем проводок тоже нет однозначности. Во многих системах бухучета есть возможности за контролем транзакции — когда например один счет по дебету и 2 счета по кредиту (например по дебету проводка на 1000, по кредитам одна на 300, вторая на 700). Просто идет тогда контроль что общая сумма дебетов и кредитов в одной транзакции равна.
За клиента в этом плане можно не беспокоиться, а вот банк в таком случае имеет на своем счету доходов виртуальные средства. Если он их потратит на хозяйственную деятельность, то в итоге у него в балансе образуется дыра. А все потому, что на счет доходов записали средства, которых у клиента не было.
Это непонимание бухгалтерского учета в принципе. Никакого отношения начисленные доходы не имеют к хоз.деятельности банка. Все расходы банка производятся не со счета доходов, а со счета расходов. И разница образуемая между ними и есть прибыль или убыток.
Ну и далее — реально вывести можно только деньги, которые находятся на корсчетах банка или в кассе. Вы можете нарисовать хоть 1 млрд доходов, но для образования дыры вам доступны только средства на корсчете или в кассе. Упрощенная модель выглядит так — клиент вносит в кассу банка 1 млн во вклад, банк выдает другому клиенту 1 млн как кредит. Далее % по вкладу вы начисляете как расходы банка, % по кредиту — как доходы банка. Но есть разница между начисленными и реализованными расходами и доходами. Например % вы согласно правил начисляете клиенту по вкладу каждый месяц, а выплата % по договору раз в квартал. Т.е. можно спокойно показывать что у вас расходы нарастают, но реально никаких денег вам для выплат в кассе или на корсчете не нужно. Мало того — вы можете % выплачивать на счет клиента и тогда это просто «бумажное» нарастание обязательств, до тех пор пока клиент не захочет вывести деньги из банка. Вот тогда и выяснится что денег на корсчетах и в кассах может быть 0, а все деньги были выведены за счет выдачи кредитов, которые никто возвращать не собирается, или ценных бумаг, которые ничего не стоят и т.п.
Далее — на что попадет банк или другая организация, которая начислит «лишние доходы». А попадет она на «лишние налоги».
Это большая проблема: поскольку речь идет об автоматизации типовых и рутинных бизнесс-процессов, то работой с BPM-софтом занимаются низкоквалифицированные сотрудники, которые не знают английский язык. Поэтому локализация крайне важна для таких систем.
А пример приведен на английском языке, так сказать чтобы было понятно :)
Имел несторожность поучаствовать в банковском проекте в 2011 где в качестве основного сервера базы данных был HP Superdom, HP Unix, Oracle.
Удовольствие неописуемое, когда на закрытии дня (а иногда это надо делать в разгар уже следующего открытого дня) десятки длинных отчетов просто забивали CPU на 100% (это не блокировки БД) и дальше все прочие короткие транзакции от онлайн-пользователей вставали в очередь (таких было около 4000, активных сессий одномоментно около 100). Рядом была инсталляция где на риск-процессорах и солярисе от фуджитсу-сименс работала еще более нагруженная система такой же конфигурации и никаких проблем такого рода не было. Т.е. при наличии длинных транзакций в сессиях, короткие транзакции успешно проходили. Выяснилась закономерность — как только количество транзакций превышало количество ядер, то система начинала страшно тупить. В отличие от риск и соляриса не было квантования времени между сессиями и дальше начинался массовое зависание.и вся эта конструкция умирала по CPU. Закончилось все приобретением сервера от IBM на AIX, а эта конструкция на HP SuperDom стала тестовой средой банка, т.к. нарастить количество ядер в той версии уже было невозможно. Так что оно может быть и экономия, но мой личный опыт показывает, что тогда надо покупать с большим запасом по сравнению с конфигурациями на RISC.
1. тем более для банковского сотрудника использование таких терминов является неприличным, это то с чего начинается курс лекций в бухгалтерии — принцип двойной записи в бухгалтерскую книгу по балансовым счетам:)
2. «действует одна из самых продвинутых автоматизированных клиринговых систем». " По этой причине каждый из банков-участников обязуется оставлять на своем депозитном счете в Банке Англии сумму, равную или превышающую свою максимальную задолженность в качестве защиты от неплатежеспособности."
Комментарий относился к тому что невозможно считать эту систему «продвинутой», да еще и требующей держать депозит. Даже в СНГ есть клиринговые системы, которые не требуют этого. Банк сам видит сколько ему денег не хватает для окончания расчетов и привлекает нужную сумму на Money Market (межбанковском денежном рынке) или пополняет корсчет наличными и тем самым может менять лимиты в платежной системе. А не держит депозит в Банке Англии (или Центральном банке) для. Надо понимать, что такие депозиты — это деньги не приносящие дохода банку. Деньги должны работать и приносить прибыль — на платежах, на выдаче кредитов, на межбанковском денежном рынке и т.д. А на депозите в ЦБ они должны быть собраны в последний момент чтобы обеспечить требуемый коэффициент ликвидности.
Для примера, это как расцвет 90-х и «кредитные» карты с залоговым депозитом… Сейчас на такие бы клиентов и не найти. Но были же времена и это считалось «продвинутой технологией».
1) «Так происходит любое движение средств в банке, а называется такой подход «двойной бухгалтерией». „
Журналист в терминологии вообще не разбирается, а статьи переводит.
Такой подход называется “метод двойной записи бухгалтерской проводки (транзакции) в бухгалтерской книге».
А метод «двойной бухгалтерии» применяется для сокрытия налогов от государства или воровства денег клиентов:) Синоним данного метода — черная бухгалтерия.
2) То что тут описано это примитивы 70-80-х прошлого века. Даже в странах СНГ можно найти более продвинутые принципы чем описанные в статье.
Например в Казахстане есть и клиринговая система и система валовых расчетов реального времени. Отличие между ними как раз только в процедуре наличия клиринга. Т.е. в платежной системе участник получает лимит (от Центрального банка в пределах остатка на корсчете участника) и далее регулярно с учетом пула встречных платежей производится взаиморасчет между участниками (обычно 1 раз в день). Т.е. сумма встречных платежей объединяется с суммой лимита и минус исходящие платежи и рассчитывается чистая позиция участника. Если она оказалась отрицательной, то из расчета выкидывается наименее приоритетный платеж и процедура повторяется до тех пор пока все чистые позиции участников не станут неотрицательными. Это гарантирует что никто из участников «не вылетит» на отрицательный остаток. Любой участник может запросить овердрафт, если хочет чтобы его непрошедшие платежи прошли. Также любой участник может отозвать платеж если он еще не прошел процедуру клиринга. Это позволяет участнику регулировать свою платежную позицию, если вдруг срочно надо
Отличие системы реального времени что она не производит процедуру клиринга, а просто в реальном времени если текущий лимит с учетом всех ранее прошедших позволяет (работает непрерывно и круглосуточно принимает платежи любой датой, включая будущие даты валютирования) — то сразу же меняет остаток участника и гарантированный платеж уходит получателю. Этот платеж уже отозвать нельзя, только через процедуру согласования с получателем. Скорость прохождения таких платежей несколько секунд из любой точки страны в любую точку.
Счета могут быть активные, пассивные и активно-пассивные по типу. И у счета любого типа может быть активный (дебетовый) или пассивный (кредитовый) остаток (+ или -). Просто когда у счета «неправильный по знаку (неположенный ему по типу) остаток» — то и называют сие счет с «красным сальдо».
Валидаторы проверки остатка по типу остатка и контролируют может ли быть пассивный (кредитовый) остаток по счету например по типу — активному (при наличии признака например на этом счете «разрешенного красного сальдо»).
Говорить что «нельзя иметь активно-пассивные счета» — достаточно недальновидно. Есть системы бухгалтерского учета где они активно используются и непонятно почему ради этого надо держать два и т.п. счета. Если пользователю нужен такой счет — ну пусть объявит счет с таким типом и валидаторы будут пропускать любые проводки по этому счету без контроля знака остатка. С контролем проводок тоже нет однозначности. Во многих системах бухучета есть возможности за контролем транзакции — когда например один счет по дебету и 2 счета по кредиту (например по дебету проводка на 1000, по кредитам одна на 300, вторая на 700). Просто идет тогда контроль что общая сумма дебетов и кредитов в одной транзакции равна.
Это непонимание бухгалтерского учета в принципе. Никакого отношения начисленные доходы не имеют к хоз.деятельности банка. Все расходы банка производятся не со счета доходов, а со счета расходов. И разница образуемая между ними и есть прибыль или убыток.
Ну и далее — реально вывести можно только деньги, которые находятся на корсчетах банка или в кассе. Вы можете нарисовать хоть 1 млрд доходов, но для образования дыры вам доступны только средства на корсчете или в кассе. Упрощенная модель выглядит так — клиент вносит в кассу банка 1 млн во вклад, банк выдает другому клиенту 1 млн как кредит. Далее % по вкладу вы начисляете как расходы банка, % по кредиту — как доходы банка. Но есть разница между начисленными и реализованными расходами и доходами. Например % вы согласно правил начисляете клиенту по вкладу каждый месяц, а выплата % по договору раз в квартал. Т.е. можно спокойно показывать что у вас расходы нарастают, но реально никаких денег вам для выплат в кассе или на корсчете не нужно. Мало того — вы можете % выплачивать на счет клиента и тогда это просто «бумажное» нарастание обязательств, до тех пор пока клиент не захочет вывести деньги из банка. Вот тогда и выяснится что денег на корсчетах и в кассах может быть 0, а все деньги были выведены за счет выдачи кредитов, которые никто возвращать не собирается, или ценных бумаг, которые ничего не стоят и т.п.
Далее — на что попадет банк или другая организация, которая начислит «лишние доходы». А попадет она на «лишние налоги».
А пример приведен на английском языке, так сказать чтобы было понятно :)
Удовольствие неописуемое, когда на закрытии дня (а иногда это надо делать в разгар уже следующего открытого дня) десятки длинных отчетов просто забивали CPU на 100% (это не блокировки БД) и дальше все прочие короткие транзакции от онлайн-пользователей вставали в очередь (таких было около 4000, активных сессий одномоментно около 100). Рядом была инсталляция где на риск-процессорах и солярисе от фуджитсу-сименс работала еще более нагруженная система такой же конфигурации и никаких проблем такого рода не было. Т.е. при наличии длинных транзакций в сессиях, короткие транзакции успешно проходили. Выяснилась закономерность — как только количество транзакций превышало количество ядер, то система начинала страшно тупить. В отличие от риск и соляриса не было квантования времени между сессиями и дальше начинался массовое зависание.и вся эта конструкция умирала по CPU. Закончилось все приобретением сервера от IBM на AIX, а эта конструкция на HP SuperDom стала тестовой средой банка, т.к. нарастить количество ядер в той версии уже было невозможно. Так что оно может быть и экономия, но мой личный опыт показывает, что тогда надо покупать с большим запасом по сравнению с конфигурациями на RISC.
2. «действует одна из самых продвинутых автоматизированных клиринговых систем». " По этой причине каждый из банков-участников обязуется оставлять на своем депозитном счете в Банке Англии сумму, равную или превышающую свою максимальную задолженность в качестве защиты от неплатежеспособности."
Комментарий относился к тому что невозможно считать эту систему «продвинутой», да еще и требующей держать депозит. Даже в СНГ есть клиринговые системы, которые не требуют этого. Банк сам видит сколько ему денег не хватает для окончания расчетов и привлекает нужную сумму на Money Market (межбанковском денежном рынке) или пополняет корсчет наличными и тем самым может менять лимиты в платежной системе. А не держит депозит в Банке Англии (или Центральном банке) для. Надо понимать, что такие депозиты — это деньги не приносящие дохода банку. Деньги должны работать и приносить прибыль — на платежах, на выдаче кредитов, на межбанковском денежном рынке и т.д. А на депозите в ЦБ они должны быть собраны в последний момент чтобы обеспечить требуемый коэффициент ликвидности.
Для примера, это как расцвет 90-х и «кредитные» карты с залоговым депозитом… Сейчас на такие бы клиентов и не найти. Но были же времена и это считалось «продвинутой технологией».
Журналист в терминологии вообще не разбирается, а статьи переводит.
Такой подход называется “метод двойной записи бухгалтерской проводки (транзакции) в бухгалтерской книге».
А метод «двойной бухгалтерии» применяется для сокрытия налогов от государства или воровства денег клиентов:) Синоним данного метода — черная бухгалтерия.
2) То что тут описано это примитивы 70-80-х прошлого века. Даже в странах СНГ можно найти более продвинутые принципы чем описанные в статье.
Например в Казахстане есть и клиринговая система и система валовых расчетов реального времени. Отличие между ними как раз только в процедуре наличия клиринга. Т.е. в платежной системе участник получает лимит (от Центрального банка в пределах остатка на корсчете участника) и далее регулярно с учетом пула встречных платежей производится взаиморасчет между участниками (обычно 1 раз в день). Т.е. сумма встречных платежей объединяется с суммой лимита и минус исходящие платежи и рассчитывается чистая позиция участника. Если она оказалась отрицательной, то из расчета выкидывается наименее приоритетный платеж и процедура повторяется до тех пор пока все чистые позиции участников не станут неотрицательными. Это гарантирует что никто из участников «не вылетит» на отрицательный остаток. Любой участник может запросить овердрафт, если хочет чтобы его непрошедшие платежи прошли. Также любой участник может отозвать платеж если он еще не прошел процедуру клиринга. Это позволяет участнику регулировать свою платежную позицию, если вдруг срочно надо
Отличие системы реального времени что она не производит процедуру клиринга, а просто в реальном времени если текущий лимит с учетом всех ранее прошедших позволяет (работает непрерывно и круглосуточно принимает платежи любой датой, включая будущие даты валютирования) — то сразу же меняет остаток участника и гарантированный платеж уходит получателю. Этот платеж уже отозвать нельзя, только через процедуру согласования с получателем. Скорость прохождения таких платежей несколько секунд из любой точки страны в любую точку.