powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Бухгалтерия проводки и счета
2 сообщений из 102, страница 5 из 5
Бухгалтерия проводки и счета
    #38909177
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boobyПри взгляде из космоса, бизнес-приложение специального назначения должно поддерживать "правильность" ведения бизнеса. Некоторый набор утверждений по отношению к данным должен быть всегда истинным.
Эти две фразы не имеют ни малейшей логической связи друг с другом, по крайней мере при осмысленном выборе "некоторого набора". Более того, задача "правильного ведения бизнеса" довольно слабо связана с задачей "корректного ведения бухучёта".

По сути Вы говорите следующее: "Я привык, что целостность проверяется определённым образом, мне так комфортно, поэтому я объявляю это обязательным требованием и на основании этого буду утверждать, что это единственный вариант". Закольцовываете логику.

Просто для примера - попробуйте сформулировать такой вот "набор утверждений" например, для бизнес-приложения учёта показаний счётчиков ЖКУ. Думаю, мигом обнаружите, что ничего подобного балансовому уравнению там нет и быть не может, а бизнес ведётся и вроде даже иногда правильно.

boobyСобственно двойная запись изначально изобреталась как механизм, максимально облегчающий проверку такого утверждения
Двойная запись изобреталась в условиях, когда некий купец вёл свой учёт следующим образом:

- было триста рублей
- отдал за товар сто рублей
- продал товара на двести рублей
- отложил в карман зипуна пятьдесят рублей.

Она отлично защищает от двух типичных ошибок такого учёта: арифметических (было триста, сто пятьдесят отдал, двести получил, итого двести пятьдесят на руках) и половинчатых (пятьдесят в зипун отложил и забыл про них). Проблема в том, что такие ошибки характерны для ручного ведения бухгалтерии, а автоматизированному, мягко говоря, не свойственны. Настолько не свойственны, что этой самой двойной записи на самом деле почти никто не делает 1 .

1 Что самое смешное, двойная запись в её классическом понимании - это как раз полупроводки. Записываем в левую сторону источника - одна полупроводка. В правую сторону адресата - другая.

В компьютерной бухгалтерии можно отойти от принципа двойной записи, перейдя к полной проводке. При этом делается одна запись, которая за счёт бизнес-логики дважды учитывается. Баланс, соответственно, технически не может разъехаться; если он разъехался, это означает всего лишь ошибку в SQL, который его показывает.

В компьютерной бухгалтерии можно реализовать двойную запись, делая полупроводки и контролируя их попарную сочетаемость. Проверку при этом можно делать классическим образом - подсчитывая баланс, можно обеспечить ограничениями целостности (скажем, организовав между дебетовыми и кредитовыми полупроводками связь один к одному по ключу, включающему в себя сумму).

Превосходство компьютера над человеком проявляется в том, что ему не обязательно контролировать две полупроводки. Это человеку, чтобы не ошибиться, нужно правило типа "вижу сто синих - ищу сто красных". Компьютер с тем же успехом может выполнить и сложное для человека условие, типа "сложи сумму пяти чисел и проверь, что результат ноль". Как следствие, двойная запись может быть реализована и использована не только опираясь на симметричные пары полупроводок, но и на более сложные группы, вот и всё.

boobyРечь идет о штатном заполнении данных через стандартные интерфейсы конечного пользователя. Фактически существуют такие системы, построенные на полупроводках,
которые разрешают "пожурнальный" ввод данных полностью без контроля
И что из этого? Для любого подхода существуют больные на голову решения, это недостаточная причина критиковать подход.

Реальную проблему в любом случае представляет не развалившийся баланс, а отлично сходящийся, но не соответствующий ни реальности, ни документам, ни требованиям контролирующих органов.

boobyЗаявление о простоте проводочной реализации против полупроводочной означает, что заявляющий полагает, что если это утверждение гарантировано для каждой отдельной
"элементарной" проводки, то оно автоматом гарантировано для всего набора счетов
С этой точки зрения между ними нет никакой разницы.

boobyУтверждения подобной степени универсальности невозможно сформулировать для полупроводочных систем, т.к. в них способ формулировки определяется индивидуальной механикой поддержки понятия "финансовая транзакция".
Это верно, но совершенно никак не относится к "простоте реализации". Вы почему-то считаете, что "универсальное" просто, а "индивидуальное" заведомо сложнее. На самом деле запросто может оказаться наоборот.

В частности, реализовать контроль полупроводок можно несколькими строками. Скажем, для Оракла примерно так:

Код: plsql
1.
2.
3.
create materialized view mv_check_проводки 
refresh fast on commit as
select 1/0 from проводки group by транзакция having sum(деньги) <> 0;



Всё. Готово отныне и навсегда. Попробуйте обосновать, что это сложнее, нежели в каждый SQL-запрос вставлять case-ы со смыслом "если источник, то с минусом, если адресат, то с плюсом". Что-то мне подсказывает, что Вам придётся изобрести очень специфическое определение для "сложнее" :)

boobyДля полнопроводочной системы развал баланса - всегда ошибка программиста. Для полупроводочной - почти наверно - ошибка пользователя.
Ложно. Показано выше.

boobyСторонники полнопроводочных систем, считают, что в том месте где они не допускают возможности совершить пользователю такую ошибку - это самостоятельная ценность их систем.
Это не есть особенность таких систем. Ваше высказывание звучит примерно так: "Сторонники самолётов по сравнению с вертолётами полагают самостоятельной ценностью самолётов то, что они летают".

boobyДля полупроводочных систем базовое бизнес правило невозможно поддержать уровнем ниже надстройки такого сорта. Отсюда мое утверждение о разной сложности.
У Вас здесь используется не инженерное понимание сложности. Я бы сказал, глубоко философское. Попробую снова аналогию: Вы утверждаете, что перевезти тонну кирпичей на автомобиле на расстояние километра сложнее, нежели по одному отнести их пешком. Аргументация: автомобиль надо загружать, разгружать, уметь водить, а пешком просто взял и понёс.
...
Рейтинг: 0 / 0
Бухгалтерия проводки и счета
    #38909199
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer,
что-то вас в поэзию потянуло на ночь глядя.

не надо мне приписывать того, что я не говорил и додумывать того, что не подразумевал.

Если вдруг вам показалось, что я с чем-то к вам навязываюсь, или тем более (не дай бог) в чем-то убедить, то вы глубоко ошиблись.
...
Рейтинг: 0 / 0
2 сообщений из 102, страница 5 из 5
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Бухгалтерия проводки и счета
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]