SatimПросто гуглил информацию по системе, и натолкнулся на нее.
1) Идея хороша тем что, хорошо продуманна схема документооборота, весь путь проведения документа можно разбить на мелкие отрезки, тем самым распределив нагрузку по персоналу. Что то вроде прогона документа по состояниям (Составлен->передан на утверждение->утвержден->товар в пути->принято складом->оприходовано)
Не "что-то вроде", а оно и есть - прям даже наименования состояний из системы переписаны ;)
Satim2) Реализация почему не нравится, потому что все документы сидят в 1 таблице то есть, заголовки в 1 таблицы спецификация в другой, но по типам документов по таблицам не разнесены, то есть 1 таблица для всех заголовков и 1 таблица для всей спецификации. + всяческие таблицы по остаткам партиям и т.д. Соответственно очень часто возникают блокировки в базе. Когда весь офис начинает приходовать то очень долго проходит проведение документа может доходить до 10-15 минут на 1 док. Спецификация в среднем 15 строк в документе.
Судя по этим строкам, вы ещё не до конца разобрались, как устроен сервер Firebird. Firebird - многоверсионный сервер, и блокировок в терминах блокировочных серверов в нём вообще нет. И уж точно блокировки не вызваны хранением шапок всех документов в одной таблице (Firebird никогда не блокирует все записи в таблице - только обновляемую, и только от повторного обновления в параллельной транзакции). Впрочем, судя по тому, что ответов на замечания о вашей неосведомлённости в обсуждаемой теме не последовало, тема как таковая вам и не очень-то интересна.

Тем не менее скажу еще пару слов в "защиту" системы, т.к. использую ее сам.
В общем, что касается бизнес-логики - совершенно верно, документы проводятся по состояниям, что позволяет реализовать достаточно сложные бизнес-процессы и их цепочки, причём эти состояния (а значит - и цепочки) гибко настраиваются. Что касается механизмов хранения - тоже всё правильно, все шапки документов лежат в одной таблице, все строки - в другой. Это позволяет легко разрабатывать универсальные алгоритмы (применяемые к разными типам документов), не менее легко разрабатывать новые типы документов, если это необходимо для каких-то специфических бизнес-процессов (мы это делали). При этом, что важно, хранение всех документов в одной таблице не приводит к дополнительным тормозам, т.к. используемая СУБД Firebird умеет работать в конкурентной среде и работает с блокировками на уровне конкретных записей, а тут уже неважно, лежат записи в одной таблице или в разных. Скорость доступа также не страдает от такого решения, т.к. индексы в FB работают как надо. Ну и от теории к практике - я пользуюсь Авардой (ранее - Миром торговли) уже 8 лет, и указанных выше тормозов смог добиться только один раз - когда наш начинающий программист написал триггер, приводивший к тормозам на любом обновлении любой строки таблицы строк документов. В обычном же режиме работы документ со спецификацией в 15 строк проводится секунды (конечно, зависит от типа операции - резерв происходит быстрее, чем, например, списание товара, т.к. при резерве выполняется меньше операций). Да, у меня нагрузка до 100 пользователей одновременно в офисе (остальные в магазинных базах), но есть примеры компаний, у которых в одной базе Firebird работает одновременно 300-400 пользователей. Знаю и примеры коллег по цеху, которым удавалось "положить" сервер кривыми запросами и безумно длинными транзакциями. Однако если прислушиваться к рекомендациям "как не надо делать", то проблем возникает минимум.

Конечно же, производительность напрямую зависит от ресурсов сервера (железа) и правильности его настройки. Если у вас сервер нормальный, смотрите на его настройки в плане железа, ОС и СУБД.
Если есть вопросы – пишите в личку, чем могу – помогу. Знаю еще, что IBASE.RU (kdv) берется за решение вопросов настройки Firebird.