kanalexА системы документооборота укладываются в тематику этого форума?
Угу - укладываются, куда же без них родимых. Кстати вопрос к знающим - насколько все таки сложен в реализации документооборот ? С первого взгляда особо ничего сложного не видится, однако первый взгляд всегда обманчив. Хотелось бы услышать мнения, мне в июне предстоит к проекту сделать "мини-документооборот", было бы интересно прикинуть, стоит ли потом развивать его в отдельный продукт или же лучше не связываться.

Я так понимаю сложности реализации документооборота можно описать следующими пунктами:
1. Множество форматов документов, где система должна идентифицировать в зависимости от типа документа и соотвествующе правильно организовывать загрузку/выгрузку документов, вызов соотвествующего ПО для получения, просмотра и редактирования документа, желательную возможность сканирования и индексирования документа для дальнейшего поиска и т.д.
2. Бизнес-логика движения документов, включающая в себя блок-схему описания движения, поддержку свободного числа параметров, условных и безусловных переходов, может быть даже циклов.
Собственно хранение документов сложности в современных РСУБД не представляет. Пункт 2 для меня например, в ASA тоже никакой сложности не представляет, все прекрасно реализуется на динамическом SQL, оффлайн репликации и поддержка КПК позволяют разворачивать схему документооборота на любое множество удаленных точек (филиалы, ноутбуки, КПК) без выделенных каналов связи и централизованным управлением с консолидированной БД - в общем тут сложностей реализации для ASA я не вижу.

Так что мне кажется единственный проблематичный пункт - это первый, где основная часть нагрузки ложится не на РСУБД, а клиентское приложение. В связи с этим возникает дополнительный вопрос выбора платформы - я видел множество документооборотов на веб-интерфейсе, но честно говоря выглядит все это достаточно убого, на уровне присоединенных файликов. Явно нужна мощная, хорошо интегрируемая с DLL, OLE, COM и .NET ООП платформа, на которой можно описать интерфейсы получения (сканирования), обработки (индексирования), изменения и управления (редактирование, печать, преобразование через OLE/COM сервер). Пока только в голову приходит C# и VC, все остальное (Java, Delphi, PowerBuilder, VB) будут иметь различные ограничения в реализации функциональности пункта 1. Однако вне зависимости от выбора, все равно проблем я думаю было бы немало.

Urri MainFrameМне, кажется, мини-документооборот не сложен. Вот чуть в сторону - например, делать слияние документов по сотрудникам, потом слияние по подразделениям, потом вверх по иерархии и наконец суммарный (план или отчет), затем в обратную сторону - (после изменений в обобьщенном), разибиение до сотррудника. Обычными ручными средствами - это уже морока. Опять же подписи. Если серьезные ограничения на безпоасность, то нужны серьезные системы.Что такое мини-документооборот? Все остальное тоже непонятно, но этот термин - особенно.
Будет задача для определенного департамента холдинга, ведущая учет некоего потребления денег в удаленных филиалах и имеющая консолидированную БД в центре. Соотвествующе планируется вдогонку к этой задаче привязать для данного департамента документооборот, позволяющий центру спускать и поднимать обратно офисные документы, испольщующиеся в данном подразделении, но не попадающий под ТЗ самой задачи. Соотвествующе круг типов документов ограничен офисом, логика их движения достаточна проста. Я думаю, это можно назвать мини-документооборотом :)