А)
softwarerПроще программный код
Да

Б)
softwarerSQL-запросы без постоянных OR/UNION-условий, лучше оптимизируются и быстрее выполняются.
Да


НО

softwarer соответственно, в нём меньше ошибок.

Никак не соответственно.


softwarer Ну и, наконец, "несимметричные" входы-выходы типа той схемы с тремя полупроводками, которую описал Кабальеро.
Сами по себе, за рамками А) и Б), в этом месте никакой дополнительной привлекательности полупроводки не несут.
Но точно являются обстоятельством, усложняющим схему поддержки балансового уравнения. (если речь идет о бух. учете).
А в случаях, когда ввод полупроводок проводится в "журнальном" режиме - т.е. независимыми вручную вводимыми записями
в "журнал учета операций по счету" - в отдельном окне журнала по поставщику, окне журнала по складу и окне журнала по НДС - прямым источником ошибок учета.
Не говоря уже о вводе висящей полупроводки в журнал по кассе с забытой навсегда второй стороной.

Но есть и правда другой стороны. Даже при наличии полнопроводочной записи и хранении, люди периодически умудряются так нарисовать свои программы, что балансовое уравнение все равно не сходится.

softwarer,
по поводу супермаркета можно вяло подискутировать на тему, является ли переход от трех чеков к одному заменой архитектуры, или может быть интерпретирован в терминах инструментовки неизменной архитектуры. Такой цели у меня нет.

касательно увеличения/уменьшения сложности.
При взгляде из космоса, бизнес-приложение специального назначения должно поддерживать "правильность" ведения бизнеса. Некоторый набор утверждений по отношению к данным должен быть всегда истинным.
Для бухгалтерских приложений - самое общее утверждение такого рода, выраженное в наивной форме - равенство суммы остатков на активных счетах сумме остатков на пассивных счетах. Этот assert statement должен выполняться как до начала любой бухгалтерской операции, так и после ее завершения.
Т.е. - это абсолютный инвариант, нарушение которого однозначно свидетельствует об ошибках в бухгалтерских записях.
Собственно двойная запись изначально изобреталась как механизм, максимально облегчающий проверку такого утверждения.
Многие (предполагаю, что все) разработчики бухгалтерских учетных систем считают необходимым тем или иным способом гарантировать поддержку такого утверждения.

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

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

Касательно ручного ведения журнальной записи. Речь не идет о том, что кто-то полез в таблицы прямыми инсертами, написанными на SQL.
Речь идет о штатном заполнении данных через стандартные интерфейсы конечного пользователя. Фактически существуют такие системы, построенные на полупроводках,
которые разрешают "пожурнальный" ввод данных полностью без контроля и даже формулировки понятия "финансовой транзакции".
Контроль целостности данных при этом уходит на отдельно стоящие и отдельно запускаемые процедуры/отчеты.
Основная проблема с таким заходом состоит в том, что выявленный факт расхождения баланса в общем слабо помогает с поиском и разбором детальной информации.

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

Сторонники полнопроводочных систем, считают, что в том месте где они не допускают возможности совершить пользователю такую ошибку - это самостоятельная ценность их систем.
А в том месте, где приход в журнале поставщиков должен быть показан одной суммой, то это принципиально достигается группировкой набора элементарных проводок в надстройкой (усложнением) в виде финиансовой транзакции как группы полных проводок.
Такое усложнение само по себе не отвечает поддержку базового бизнес-правило, т.к. оно поддержано уровнем ниже.
Для полупроводочных систем базовое бизнес правило невозможно поддержать уровнем ниже надстройки такого сорта.
Отсюда мое утверждение о разной сложности.

caballero,

вы бы не кидались всякими словами, которые когда-либо слышали.

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

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

Корреспонденция счетов существует не для фиксации замшелости, а есть форма формулировки специального поднабора правил ведения информации в области бухгалтерского учета бизнес-операций.
Т.е. - есть специальная форма констрейнтов, которые чужими руками написанные программы могут поддерживать автоматически.

А сама "замшелость" говорит не о преимуществе компьютеров перед костяными счетами, а о том, что метод учета надежно и правильно работает пятьсот лет.

Упоминание "замшелости" свидетельствует не просто об отсутствии образования, а специально об агрессивном публичном ламеризме.

как-то так.

caballero,

Для вашего просвещения:
Двойную запись, баланс, вместе с балансовым уравнением, отчет о прибылях и убытках
придумал и опубликовал в учебнике математики "Summa de arithmetica, geometria, proportioni et proportionalita" итальянский математик конца 15го века Лука Пачоли.

С тех пор в бух. учете 500 лет ничего не менялось и работает в первозданном виде до сих пор.

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


удачи в несении тяжелого флага воинствующего ламеризма.

caballero
речь была о том что изза кореспонденции неудобно применять полупроводки.

милейший - это ваша речь.
Именно вы выдвинули это лишенное содержания утверждение.


caballeroПачоли не придумывал фиктивные (контрарные и прочие) счета чтобы любой ценой уравнять равенство остатков по счетам.

Не придумывал. И я не предлагал выдумывать.
Более того - такие счета не являются обязательным атрибутом полнопропродочных систем, отличающих их от полупроводочных, даже если у кого-то из реализаторов оказались внедренными.

PS
про итоги счетов и равенство остатков - это ты мощно задвинул.