САПFinSoftС точностью до наоборот
разговор за то, что если отпуск товара только списывает товар со склада и не формирует никакой корреспонденции -- то это проблема
Из этого не следует, что в программе должна генериться проводка Дб 90.2 - Кр 41 для УУ. Но я согласен, что понимание принципов двойной записи, организации плана счетов очень помогает при проектировании системы. Для УУ я придерживаюсь таких правил.
1. Пользователи при работе с программой должны оперировать теми понятиями, которые отражают специфику их бизнеса.
2. В базе данных должен храниться необходимый минимум информации, без дублирования, с максимальным контролем состояния и минимизацией возможностей внесения некорректных изменений со стороны пользователя.
3. Бизнес-логика должна быть сосредоточена в откомпилированных dll-модулях, что позволяет отсекать часть багов на уровне компилятора, легко развивать проект и обновлять версии у клиентов, исключать множество дополнительных вычислительных операций в процессе эксплуатации.
Это идеология построения специализированных систем, развивающихся по схеме "лучшая практика". В "платформах" идеология противоположная.

TervFinSoft
Бухучет - это отдельная тема. Там использование проводок и двойная запись (в России) зарегламентированы. Со временем, видимо, бухучет станет областью приложения сил специализированных бухгалтерских фирм. В повседневной работе нужен УУ, а там использование проводок, на мой взгляд, смысла не имеет. Это мое глубокое убеждение, но я с интересом почитаю и про другие взгляды...
двойная запись появилось задолго до появления РСБУ, фактически вы сейчас пытаетесь доказать, что римские цифры удобнее использовать в работе, чем арабские.
Фактически двойная запись в учете, отражает главный закон в Физике - закон сохранения энергии (ничто неоткуда не берется и в некуда не исчезает).
В теории все так. Речь о практической реализации. Например, наличие отгрузочной накладной отражает факт уменьшения остатков товаров на складе и возникновения задолженности у покупателя. Чтобы программа понимала это, нужно ли писать в базу проводки? Я думаю, что нет, и при этом я не нарушаю закон сохранения.

Terv а причем тут проводки и практическая реализация, мы же вроде говорили о моделях?
вопрос в том, как вы будете гарантировать корректность данных в "базе", каким образом проверяется валюта баланса?
Это делает бизнес-логика на основании первичных документов, если я правильно понял вопрос. А у Вас как?

iscrafm Да уж. Причем настолько противоположная, что найти пару отличий невозможно.
Идеология платформ:

1. Пользователи при работе с программой оперируют теми понятиями, которые отражают специфику их бизнеса.
Извините, я не знаком с Вашей системой. Поэтому предлагаю посмотреть на примере самой распространенной и известной всем "платформе". Прокомментируйте термин "субконто".
iscrafm
2. В базе данных хранится необходимый минимум информации, без дублирования, с максимальным контролем состояния и минимизацией возможностей внесения некорректных изменений со стороны пользователя.
Прокомментируйте, пожалуйста, использование регистров.
iscrafm
3. Бизнес-логика не сосредоточена в откомпилированных dll-модулях, что позволяет легко развивать проект и не требует при изменениях обновлять версии у клиентов, исключает множество дополнительных вычислительных операций в процессе эксплуатации.
Успехов :-)

Сисой FinSoftВ теории все так. Речь о практической реализации. Например, наличие отгрузочной накладной отражает факт уменьшения остатков товаров на складе и возникновения задолженности у покупателя. Чтобы программа понимала это, нужно ли писать в базу проводки? Я думаю, что нет, и при этом я не нарушаю закон сохранения.

Все очень просто. При использовании проводок очень важным аспектом является детализация плана счетов. Как правило, хороший план счетов позволяет отразить не только те операции, которые имеют место быть в повседневной практике, но и те, которые могут возникнуть в будущем. И задача финансового работника - интерпретировать факт хозяйственной операции в терминах изменения состояния сальдо нужных счетов.
Что немаловажно, добавлять новые счета (и иерархию счетов) во всех системах можно, не изменяя код программы. Что мы имеем в итоге? Свободно настраиваемую финансовую модель предприятия, с выделением любых интересующих ресурсов и объектов учета. Есть и стандартные инструменты анализа этих ресурсов - бухгалтерская отчетность. Есть и метод отражения любых новых операций - ручная бухгалтерская проводка.
Я с этим согласен. И все хорошо до тех пор, пока с программой работают финансовые работники. Но как только программа выходит за рамки финансового отдела, встает задача жесткого контроля за работой пользователей. Которые не знакомы с понятиями бухгалтерский счет, дебет, кредит, сальдо, но которые зачастую склонны делать ошибки и вносить в систему информацию, как это им пришло в голову. Получается, чем больше "гибкости" предоставляет им программа, тем сложнее становится контролировать процесс. В этом случае система, работающая с первичными документами без проводок, получает значительные преимущества. Что-то исправили - ничего не нужно пересчитывать/перепроводить, итоги всегда актуальны. Нужно ввести новый функционал или скорректировать старый - только обновляем саму программу и вся база данных к нашим услугам. Исключения тут могут быть, но тоже легко решаются патчами, так как нет главной проблемы - необходимости перепроводить документы и возможности расхождений между содержимым первички и проводками.
Сисой Ваш пример понятен. Но предположим, нужно отразить факт хищения товара сотрудником и удержать стоимость товара из его зарплаты (или оформить фиктивный займ на эту сумму). Предусмотрена ли такая операция в Вашей программе? Обеспечивается ли связь таких операций разных модулей общей аналитикой?
В торговых конторах для этого обычно оформляется внутренняя отгрузочная накладная на недостающий товар, в которой в качестве контрагента указывается кладовщик. Затем взаиморасчеты закрываются специальным документом и вешаются на долг сотруднику. Для учета взаиморасчетов с контрагентами и сотрудниками я использую понятие "Разделы расчетов", дающее полное соответсвие субсчетам 60, 62, 75, 76, 70, 71, 73 счетов.
Сисой В модульной же системе оперативного учета, построенной на документах, разрешается отслеживание только ограниченного перечня ресурсов. В этом есть плюс - требования к квалификации персонала ниже. Но если квалификация персонала позволяет, можно строить УУ на базе двойной записи.
Отказ в УУ от двойной записи имеет много других преимуществ. Например, другой уровень производительности системы, так как практически отсутствуют длинные транзакции. При штатной работе обычно модифицируются 2-3 записи, включая лог изменений. В системах с проведением документов в транзакции могут модифицироваться несколько десятков (а то и сотен) записей. А это уже снижение затрат на оборудование, более продуктивный расход времени пользователей. Я однозначно буду утверждать, что отказ от проведения документов значительно снижает стоимость владения системой в целом.

САП dll, foxpro... вы о чем?
Насколько я знаю, foxpro очень неплохая система. К сожалению, я с ней не знаком :-(
САП2. право слово, это дело десятое, когда обсуждаются темы быть или не быть двойной записи в УУ
Тут есть простая логическая связь. Для получения двойной записи надо делать проводки, то есть проводить первичку и класть в базу дополнительный слой данных. Это не есть хорошо для УУ.

iscrafmFinSoft
Прокомментируйте термин "субконто".
Прокомментируйте, пожалуйста, использование регистров.

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

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

Garya FinSoftНапример, наличие отгрузочной накладной отражает факт уменьшения остатков товаров на складе и возникновения задолженности у покупателя. Чтобы программа понимала это, нужно ли писать в базу проводки? Я думаю, что нет, и при этом я не нарушаю закон сохранения.ПМСМ, можно писать, а можно и не писать. Когда проводки не пишутся, отчеты строятся непосредственно по массивам первичных документов.
Появилось еще одно подразделение со своей спецификой работы, нужно курочить десятки и сотни отчетов.
Появился документ, которого раньше не было - опять нужно курочить сотни отчетов.

Наличие проводок позволяет производить промежуточную внутреннюю группировку информации, и задействовать по этой информации отчеты, которые в дальнейшем остаются неизменными. Изменения вносятся только в механизм проведения конкретного документа на конкретном месте. Обычно такое изменение на порядки проще, нежели изменение сотен отчетов.
На самом деле, это не так. В системах с проведением Вы раскладываете документ по регистрам (счетам) при проведении. В системах без проведения мы обрабатываем все документы, относящиеся к регистру (счету) в одном месте. Отчеты используют результаты этого расчета. Но в обоих случаях в отчетах может выбираться информация из документов, так как все в регистры при проведении/расчете на лету не положишь. Поэтому корректировать отчеты может потребоваться при обоих подходах. У себя во фреймворке для отчетов я сделал признаки использования тех или иных типов документов. Специальный скрипт выдает нужную информацию, что облегчает внесение изменений.
Garya Одним словом, допустимо и то, и другое. Вопрос в сложности сопровождения.
Проблема, которая ранее была озвучена - дублирование информации моежт привести к ее рассогласованию - решается применением механизмов, эквивалентным триггерам.
Но это не спасает от напрягов при исправлении ошибок и вводе нового функционала для уже заполненной базы данных. По большому счету я согласен, что оба подхода имеют право на жизнь, выбор определяется теми целями, которые ставятся при разработке и продвижении проекта. Я лишь акцентировал внимание на тех преимуществах для УУ, которые получаем при отказе от привычной многим технологии проведения документов.