Андрей Ж. FinSoft И нафига? Система не может определить, какая накладная оплачена, на основании долга и хронологии отгрузок/оплат? Как показывает практика, в подавляющем большинстве случаев документы перекрываются в хронологическом порядке, а не выборочно. Логично придерживаться такого-же правила, оставляя явную привязку документов друг к другу как дополнительную и необязательную опцию.
Практика оптовок действительно подтвеждает "жесткую хронологию" при обычной работе через торговых агентов, но имеется довольно много ситуаций, где не так:

1. Отгрузка "зависшего" товара на полную реализацию, но продажа "нормального" по принятым правилам;
2. Наличие предоплаты за конкретный контракт, который не зависит от текущих операций;
3. Фонящая экзотика типа виртуальных поставок, взаимозачетов и будущих платежей...

Кроме этого "на меня" давят ограничения ф/с архитектуры и жестких требований пользователей по быстродействию. Например (сейчас посмотрел): Сетевой клиент имеет больше 12000 отгрузок. По Вашей технологии (была в другой системе такая, но там ещё был гемор с пересчётом курса валют) для расчета "долга" по последним накладным должен был активно сканировать десятки тысяч записей (есть в одном отчёте, т.е. имеется реальная оценка времени), что на рабочей станции заняло бы около 10 минут. Данная инфа оперативная и допустимая задержка, при работе с документами д.б. не более 0.5 сек... Впрочем своего мнения не навязываю!
Файл-серверную архитектуру есть смысл обсуждать для небольших инсталляций на 2-3 компьютера. Для более крупных можно использовать терминальный сервер (не знаю, как оно там будет с кучей досовых окон) или, в случае нашего проекта, ip-доступ или первасив. 12 тыс документов считать на терминале - это менее секунды. Кроме того, они же оплачиваются, читать нужно только неоплаченные...
Андрей Ж.
FinSoftPS. Скриншоты - жесть. :-))
Не понял - да? Вы достаточно серьёзный человек и Вам не подобает такой категоричный детячий базар. Обосновали бы хотя бы!

P.S. Испаряюсь на несколько часов - нужно партнёру помочь из салона забрать авто. Завидую... такую машинку себе позволить не могу.
А причем тут базар? Разница в юзабилити win и dos интерфейса очевидна. Конечно, писать под win намного сложнее. И переехать с dos на win не так быстро. Помню, когда переходил в 1999 г, первая программа была "dos в win-обертке" - думаю, понятно, о чем говорю. Только спустя несколько лет стал прорисовываться нормальный образ. Кстати, а зачем Вам вообще переходить на win? С точки зрения бизнеса важно отличаться, куда уж большие отличия, чем предложение dos-программы. У конкурентов точно нет. Достоинства сохраняются - простота, отсутствие неизлечимых для win глюков, малый размер дистрибутива, быстрое внесение изменений за счет более простого кода и быстрой компиляции. Пользователям в конечном итоге нужен прикладной функционал. Если бы еще комьюнити было, развивающее подобный софт... Или есть?
Например, потребовался обмен через xml с другими программами - скачал бесплатную либу и минут за 10 прикрутил к своему проекту. Потребовался web-интерфейс или встроенный тонкий клиент - заплатил некую денежку, и получил...

iscrafm К примеру: Нужен специфичный документ учета реализации продукции. Из библиотеки берется типовой заголовок, типовые справочники и т.п. Добавляется требуемая спецификация и сервисы ее формирования. Т.е. "под заказ", по большей части, выполняется компоновка . Естественно никто типовые процедуры учета запасов, типовые формы отчетности и т.п. не разрабатывает "с нуля", все это уже много раз пройдено и в различных вариантах присутствует в библиотеке.
Несколько лет назад обсуждалось
Вопрос не только в быстрой разработке, но и в дальнейшей поддержке этих решений. Предположим, накомпоновали мы несколько десятков или сотен таких систем, затем выпустили новую версию базового функционала. Не зная, разумеется, кто и что там компоновал. Придется обновлять и тестить отдельно все конечные решения?
В целом, самая большая проблема всех заказных разработок - это их дальнейшая поддержка и развитие. Компания, решившая внедрять у себя заказную систему, должна понимать, что придется платить не только за начальную разработку и лицензии, но и за все дальнейшие изменения в этой системе, а также за обеспечение приемственности кадров, знающих, где и как в ней реализован тот или иной функционал. Как правило, далеко не все об этом задумываются, прося "сделать систему под наши требования". В секторе малых и средних предприятий большинство бизнес-процессов можно стандартизовать. Индивидуальные решения нужны бывают в очень специфичных областях производства или услуг (реже торговли). Мне как раз приходится часто разговаривать с предпринимателями на эту тему. Основная мысль, которую обсуждаем - ребята, прежде чем сказать "сделайте нам то-то и то-то", оцените в денежном выражении, сколько вы готовы за это заплатить, и через какое время вы заработаете (съэкономите) на этом деньги. Затраты должны окупаться и достаточно быстро (1-3 месяца). Иначе забейте на эти пожелания...