СисойФакты:
1) 1С в России и многих странах СНГ де-факто стала ведущим поставщиком учетных решений;
2) Многие ранее известные отечественные системы вытеснены с рынка или влачат жалкое существование за счет старых клиентов;
3) Многие отечественные учетные системы по идеологии хранения близки 1С (иерархические справочники, аналитический учет в разрезе справочников на плане счетов, встроенные среды разработки).
4) В России в самом расцвете фаза централизации бизнеса (средние и крупные холдинги).
4) Основная проблема 1С- слабая масштабируемость.

Так какого черта все изобретают велосипеды, но никто не напишет хорошо масштабируемую оракловую (или MS SQL-ную) ИС, способную легко интегрироваться с типовыми решениями 1С в топологии "звезда" и выполняющую функции центральной БД для планирования и отчетности?
ПРичем в ней не нужно повторять все функции 1С:Бухгалтерии, интересуют в первую очередь регламентные процедуры и консолидационные механизмы.

Потенциальный спрос же огромен (я знаю минимум 3 крупных холдинга).
И проекты внедрения будут денежными, т.к. это крупные клиенты.

Неужели таких героев отлавливают киллеры из SAPа и ликвидируют заранее? :-)



А вы перечислите какие есть механизмы в одинэс для взаимодейсвтия с внешними системами? А какие механизмы одинэс предоставляет внешним системам для взаимодействия с собой? Все в конечным счете упирается в COM ил попытку работать с одинэсовской БД напрямую, щас вот появились веб сервисы, но они больше подходят на модную фенечку - простой глупый вопрос - они stateless или statefull, а если stateless - то не поплохеет ли серверу приложений если я захочу вытащить одним вызовом всю номенклатуру (100k позиций), а если я не хочу их вытаскивать всю а хочу организвать что-то типа курсора? Хотя нет,еще один всеми любимый способ - выгружать файлы.

Вы не правы - такие системы разрабатываются скорее всего, но как внутренние не универсальные проекты. Мы, например, писали JDBC драйвер по схеме: (JDBC API<->Клиент на жабе)<->(Сервер на дельфях<->1C через COM)
В результате можно делать запросы на чтение (1CQL) и на запись (по сути скрипт на внутреннем языка одинэса). Но вот про надежность или производительность лучше не спрашивайте и на универсальность такое решение явно не тянет - 1CQL должен возвращать таблицу значения в которой сведены до примитивных типов. И если поискать в нете, то можно увидеть что такие системы разрабатываются уже давно (по крайней мере JDBC ваириант где-то видел). Но применять его массово не получиться - периодически вылезают ошибки из COM. К тому же вы представьте как будет работать такая схема скажем на 100 клиентах и сколько 1c через COM надо поднять, учитывая что каждое соединение должно выполняться в своем контексте, к тому же доступ к одному экземпляру одинэс-через-COM из разных потоков это мягко говоря плохая затея. Хотя для единичных служебных случев все