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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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