Андрей Ж. если интересно "с позиции разработчика", то:

1. В финансовом документе нал/безнал делается ссылка на "связанную" товарную накладную - некий код.

Наиболее оптимально перекрытие оплат и отгрузок расчитывать автоматически в разрезе контрагентов (или варианты контрагентов/договоров/сделок). Жесткая привязка оплат к отгрузкам через ссылки усложняет работу пользователей, но иногода требуется. Поэтому у нас используется комбинированный вариант.
Андрей Ж.
2. В товарной накладной имеется реквизит "отсрочка платежа".
Аналогично, иначе невозможно будет построить план платежей.
Андрей Ж.
1. В КИС к одной накладной можно привязать несколько платежей, но user требует иногда, что-бы к нескольким накладным привязывался один платёж.
Это частая ситуация.
Андрей Ж.
2. Нужно вводить понятие "виртуальной оплаты", т.е. денег НЕТ, но необходимо указать, что накладная оплачена. В "КИС Lack" это решается через ж...
Если я правильно понял, то это сделано для подгонки фискальной отчетности (факт реализации товаров), т.к. с точки зрения оперативного учета нонсенс. У нас делается иначе. Вначале расчеты выполняются полностью по принятым правилам, затем, если расходная часть не устраивает, то пользователь может создать корректировочные записи, которые накладываются на основной расчет. Разумеется, в этом случае ему придется самостоятельно объясняться с налоговой по поводу завышения расходов, т.к. проверочные формы программа не выдаст.

Андрей Ж.
- существуют отдельные таблицы накладных (приход-возврат, отгрузка-возврат) и финансовых документов (касса/банк) следовательно в общем случае денежные операции учитываются независимо от накладных. Кроме этого существуют операции не относящиеся прямо товарообороту, например затратные операции или расчёты с бюджетом. При независимой работе с таблицами задачи дебиторки/кредиторки решаются:

1. Просто как долг клиента (перед клиентом) на некоторую дату;
У нас может быть долг по расчетам с контрагентом в разрезе разделов расчетов. Раздел расчетов - это аналог бухгалтерских счетов (60, 62, 76 и т.п.). Можно смотреть долг как целиком по контрагенту, так и в разрезе разделов расчетов. Но итоги сохраняются всегда в разрезе раздела расчетов. Если контрагент выступает и покупателем, и поставщиком, то для него в определенный момент нужно делать зачет. Для отдельных разделов расчетов может быть определено ведение долгов в разрезе договоров и сделок. Тогда итоги будут сохраняться с этими разрезами. Автоматическое отнесение оплат к отгрузкам выполняется также в рамках разделов расчетов/договоров/сделок.
Андрей Ж.
- для достижения гибкости учёта и анализа (да и упрощения алгоритмов построения отчётов) в "КИС Lack" можно сопоставить накладную (любого типа) финансовому документу, а именно в фин.документе указать уникальный код накладной (понятно, что имеется индекс по данному полю). В этом случае при сканировании накладных доступна инфа по финансам и наоборот. Сложно пользователя минимальны, т.к. программа предлагает при вводе и привязки платежа допустимый список накладных, ограниченный по клиенту, типу оплаты, дате накладной, торговой точки клиента и т.д.
У нас существует отдельная таблица, в которой хранятся ручные перекрытия документов отгрузки и оплаты. Таким образом, один платеж может быть отнесен к нескольким накладным и наоборот. Но ручные отметки оплат рекомендуется применять только, если это необходимо. Как правило, такая необходимость возникает при работе с бюджетными организациями. Сложности работы с ручными отметками оплат возникают при возвратах и исправлениях задним числом. Отследить корректность привязок, не мешая пользователю, в этом случае довольно сложно. Приходится делать специальный контрольный отчет, выявляющий возможные некорректности (в основном - превышения суммовых итогов ссылок над суммой первичного документа). Чтобы не было разночтений - у нас ручные отметки оплат можно комбинировать с автоматическим распределением. Если для первичного документа ручное распределение задано, то используется оно, если нет, то документ перекрывается автоматически другими "свободными" документами.
Андрей Ж.
- Виртуальная оплата . Может быть несколько бизнес ситуаций когда необходимо сделать платёж не отражая его в списке финансовых операций (задача решается плохо - предложите более красивый способ), например:

1. Накладная предполагает оплату "по банку", а оплачивается частично по кассе, частично по банку. Но нужно установить чёткую привязку!!! Конечно можно было "заложить" независимость привязки от формы оплаты, но тогда бы я лишался возможности "управлять документами одного типа из списка документов другого типа". Сейчас решается - делаются два "левых" документов приход/расход денег на одну сумму, но с разными типами оплаты, одна из которых "закрывает" накладную и данные документы не отражаются в финансовой отчётности.
Извините, Андрей, но я не понимаю, каким образом фактическая оплата по банку или кассе требует таких решений. Если у вас анализируется план/факт поступления денежных средств раздельно по банку и кассе, то такую "пересортицу" можно легко отследить в соответствующей отчетной форме.
Андрей Ж.
2. Накладная и долг имеется, но нужно "простить" клиенту данный долг и что бы он не отражался в оперативной дебиторке/кредиторке, но сам факт долга не был бы "утерян". Решение описано выше.
3. "Финансовое" погашение бартерных операций - так же решается "левыми" документами. И так далее...
Думаю, что вышеобозначенные ситуации возникли в связи с отсутствием в системе понятия разделов расчетов. "Простить" долг - это перенести его на другой раздел расчетов. Например, с расчетов с покупателями на расчеты по отложенным платежам. Бартерные операции - акт взаимозачетов с контрагентом по двум разделам расчетов, как покупателем и поставщиком. На самом деле тут все просто - все подобные схемы давно проработаны в стандартном бухгалтерском учете, остается провести аналогии в оперативном.
Андрей Ж.
- Что касается "налоговой"... Моя система изначально предполагалась для черно-белого учёта и каждоая внешняя (налоговая, учредители, контролёры) или внутренняя служба (бухгалтерия, отдел закупок/продаж, управление) получает только ту информацию, которая им полагается.
У нас аналогично, только не для "черно-белого" учета, а для оперативного и фискального. Сорри, конкретно ссылку на сайт проекта пока давать не буду. Скажу только, что это локальным проект, имеющий клиентскую базу в одном из регионов, под Windows, модульный, не sql (варианты со встроенным форматом файл-сервер/терминальный сервер/ip-сервер или первасив), тематика - оптово-розничная торговля и небольшие производства.

vill_ager"живая" тема, несмотря на выходные дни :)

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

а у мну на все дела одна таблица - проводок, в ней суммы приходов, отгрузок, списаний, оплат и перекрытий и всех прочих хоз.операций.

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

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

Last1CmenFinSoftvill_ager"живая" тема, несмотря на выходные дни :)

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

а у мну на все дела одна таблица - проводок, в ней суммы приходов, отгрузок, списаний, оплат и перекрытий и всех прочих хоз.операций.

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

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

очень интересно а за какое время "закрывают" период при отсутствии какого-то нибыло контроля в оперативном режиме ?
В принципе, закрывать период можно любой датой. Из практики обычно - последней датой каждого месяца. Мелкие конторы порой не закрывают период в течении года. Если необходимо внести изменения в документы в закрытом периоде, то закрытие отменяется, а затем устанавливается снова. Можно откатываться и повторно закрывать несколько периодов за раз, останавливать работу других пользователей не требуется. Разумеется, те, кто в это время формируют отчеты, несколько просядут в скорости. На современных серверах это уже не так критично.

Last1Cmen вы не поняли сути проблемы а именно сокращение времени для "закрытия периода" для того чтобы система функционировала актуально происходящим процессам а не по истечении нескольких месяцев "выравнивать" что либо

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

Каким образом закрытие периода связано с контролем ввода данных и актуальностью процессов? У нас есть дополнительно оперативные остатки по товарам в разрезе складов, которые используются для ускорения расчетов. Остальные параметры считаются от ближайших зафиксированных остатков (границы закрытого периода). Например, чтобы получить текущий долг контрагента, в открытом периоде читаются все документы, влияющие на взаиморасчеты с ним. Обычно это несколько записей в базе данных, получить которые составляет доли секунды.
Last1Cmen
при построении системы на одних документах (наборах данных движения объектов) без механизма получения и хранения данных о остатках и вспомогательной информации служащей для отслеживания актуальности и "правильности" состояния БД мы рискуем получить продукт не только не помогающий в работе но ещё и наткнуться на проблему "автоматизации ради автоматизации"
Как раз все наоборот. Любой актуальный параметр можно сохранять в базе данных, затем брать оттуда, а можно рассчитывать динамически. В первом случае всегда существует проблема актуальности сохраненных значений. Например, в вашей парадигме (судя по нику), после корректировки прихода задним числом потребуется перепроведение всех последующих документов, чтобы получить актуальное значение наценки с продаж. В альтернативном варианте значение наценки всегда остается актуально.

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

да конечно но тут палка о двух концах
при "динамическом" подходе будем иметь проблемы при большой транзакционной нагрузке
при "статическом" - проблемы с той же последовательностью регистрации событий

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

Last1Cmen
т.е. дело в разумном балансе этих подходов к учетным задачам НО в любом случае какие-то статические даные для контроля будут присутствовать... нельзя сказать что фиксируя только движения наборов учетных объектов можно построить толковую систему... только накопительную для неких анализов основанных восновном на оборотах - возможно а остальное - врядли

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

Динамические расчеты выполняются в открытом периоде и частично в закрытом, кроме случаев ресурсоемких отчетов. Я с вами согласен, что обработка всех движений за период может сильно просаживать производительность (причем именно обработка, а не чтение из базы). Только обычно это относится к товародвижению, а не расчетам с контрагентами. Поэтому в закрытых периодах у нас используются сводные итоги в некоторых разрезах. Например, для быстрого получения информации по наценке сохраняются итоги в разрезах товар+склад, товар+поставщик, товар+покупатель, а также итоговые наценки в разрезе накладных. Структурно это напоминает регистры в вашей системе, но записи там итоговые за период, их намного меньше, формируются они при закрытии периодов и их обновление никак не тормозит работу других пользователей.
Если отчет далее будет формироваться по нескольким периодам, то программа выполнит декомпозицию, где можно, возьмет готовые итоги, где нельзя (открытый период или неполный закрытый) пересчитает динамически, результаты объединит. В результате, к примеру, отчет по движению всех товаров за год будет сформирован в пределах 1-2 минут со всеми сортировками и группировками.

Ага На мой взгляд вариант "получать остатки налету из документов" конечно же имеет право на жизнь.
Все же есть недостатки, из которых лично для меня этот способ неприемлим:
1. И основное. Ограниченная производительность системы. Все хорошо когда у нас только расходные и приходные накладные и возвраты - можно делать документы на одной таблице, или собирать в процедуре расчета остатков, всего таблички прошерстить. Далее появляются инвентаризация, акты оприходывания и списания, потребление в производство, выход товара из производства. Переписываем процедуру расчета остатков. Сколько ж у нас табличек в запросе будет? А потом (не дай бог!) введем резервирование при вводе строк документов (разумеется с проверкой актуальных остатков и резервов на непроведенные документы) - сколько ж такая процедура работать будет? С клиентами (например проверка просроченной задолженности) при наличии десятка типов документов - та же беда.
Все документы складского учета у нас собраны в две таблицы - шапки и строковые части. Точнее сказать три, но это другая тема. Новые документы вводятся достаточно редко, чаще модифицируются существующие. Например, один вид документа "Списание" используется и для списания товаров/материалов на затраты, и для перемещения материалов производство. В этих случаях несколько различается набор реквизитов заголовка документа, но с точки зрения движений материалов на складе операция одинаковая. Аналогично с приходом из производства и т.п.
По поводу резервирования ситуация следующая. Вначале был сделан динамический расчет. На сервере это работало без каких-либо заметных проблем. Затем потребовалась поддержка работы по сети, сделали все-же оперативные остатки. В данном случае их использование оправдано, т.к. текущий остаток нужно показывать много где, в подборе, строках документов и т.п. Надо заметить, что текущие остатки не являются проводками, это фиксированные записи в разрезе товар+склад.
К вопросу о производительности - сколько записей в секунду будет выбирать из кэша современный сервер? И сколько записей нужно просмотреть для получение всех операций с заданным контрагентом? Получаем доли секунды.
Ага
2. Вытекает из первого. Сложность поддержки - всегда нужно помнить какой документ как влияет на остатки - это если писать код оптимально, либо писать код универсально и генерить мегапроцедуры по расчету остатков.
Поработав с системами обоих видов, я пришел к другому мнению. Дин. расчеты, касающиеся какого-то аналитического среза (регистра) собираются в одной/двух процедурах. В принципе, объем кода приблизительно одинаков, только в системах с проведением он размазан по документам, в нашем случае - по расчетным процедурам. Все остальное производно. Когда что-то меняется в расчете, все равно придется проверять работу разных отчетов, с ним связанных. Так как затащить все в регистры проблематично и обращение к документам все равно происходит в том или ином виде. Могу сказать, как организовано у нас. Проект разрабатывается на уровне методанных и к каждому диалогу или расчету можно приписать набор "тем", которые он затрагивает. Например, складской учет или взаиморасчеты. Что-то поменяли, скажем, во взаиморасчетах, формируем список мест, где эта тема задействована, и проводим дополнительные тесты. Еще у нас существуют автотесты, в которых выполняется автоматическое сравнение некоторых контрольных показателей разных расчетов.
Посмотрите на вопрос с другой точки зрения. Предположим, нужно ввести новый функционал или уточнить старый, а это затрагивает информацию, сохраненную в регистрах при проведении. У нас такого нет в принципе, мы просто делаем новый расчет или уточняем старый, и это будет работать во всех периодах. Как быть в случае с проводками? Перепроводить все в большинстве ситуаций не выход, придется делать какие-то дополнительные служебные документы и т.п. А затем учитывать их использование во всех расчетах. Далее, вы никогда не мониторили количество звонков на суппорт по поводу того, что клиент что-то поменял не по порядку и не понимает, что произошло?
Ага
3. Достаточно сложно отследить нарушения целостности учета, к примеру при удалении приходной накладой или смене даты проведения (это ведь так просто! - считаем все по документам) могут возникнуть запрещенные отрицательные остатки, товар отгрузился раньше чем произвелся ну и тому подобные казусы.
Если разрешены корректировки задним числом, то мы никуда от этого не уйдем в обоих случаях. Вопрос цены исправления ситуации - лопатить кучу данных в базе или исправить одну-две записи. Для описанной ситуации применительно к движению товаров у нас используется понятие "фиктивный приход". Все расходы, образующие отрицательный остаток, не повисают в воздухе, а относятся к этим "фиктивным приходам". Специальная процедура контроля товарных операций позволяет легко их обнаружить и исправить, а в отчетах, где нужно, такие позиции тоже визуально выделяются.
Ага
В Вашем посте радует последний абзац - Вы уже пришли к пониманию необходимости регистров хотя бы в закрытых периодах. Осталось сделать решающий шаг - отказатся от динамического расчета по документам и построить все систему на регистрах :).
Итоги по периодам не то-же самое, что проводки. Как я написал, это сводные данные в некоторых разрезах, используемые для ускорения работы. Иными словами, программа будет работать и без них (кроме начальных остатков после среза базы данных), а их расчет не приводит к блокировке работы других пользователей. Скорость сохранения итогов за месяц обычно занимает не более минуты, отмена итогов выполняется мгновенно (изменения статуса заглавной записи). Сколько по времени будут перепроводиться накладные за месяц?
PS. От систем с проведением документов был сделан сознательный уход лет 7 назад, к сводным итогам за период пришли года 4 назад. Главная мотивация - это беспроблемность техподдержки клиентов. Это совсем разные вещи - протестить код расчетной процедуры или копаться с базой данных клиента, который что-то сделал не так, не в том порядке, либо мы и не думали, что он такое может как-то сделать, либо мы сами допустили ошибку, а клиент успел накопить неверные результаты в базе и т.п. ...

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

С этим я вполне согласен.