Вставлю ещё свои пять копеек.
На мой взгляд охват всего,- слишком глобальный.
Типа сразу делаем ERP ,-это конечно круто.
Идти надо от просто к сложному.
Ну во-первых сфера применения(скорее всего) малый и средний бизнес.
Как правило Вы(я просто уже сталкиваюсь) столкнетесь с автоматизацией
HoReCa(хорька :-) ) HOtel REstoran CAfe + магазинчики+ небольшая дистрибуция.
(Возможно фитнес,частные клиники,как организация записи и т.д )
Решение ядра учёта каждый тут делает самостоятельно...НО,что общее,и что довольно трудоёмкое
Вот что например на мой взгляд .
Ну Фискальные регистраторы...Уже обсудили.

Интеграция с мобильными устройствами.
Это Терминалы сбора данных(Я внесу свою лепту..Я работаю c Honneywell Dolphin 70 android) для проведения инвентаризации.(формат решения средний бизнес,-терминал стоит дорого)
Мало написать к ним код...надо ещё нормальный нехардкодый(естественно опенсоурсный)сервис по интеграции с Вашей ИС.
Далее Мобильный торговый представитель(для небольшой дистрибуции) Опять таки решений море...но интеграция с ИС ,только для большого бизнеса стандартных систем(даже api не удосуживаются предоставить...а если и есть...то сервак мобильных устройств ходит только,- догадаетесь под какой ОС?)

PDA(Android ,IOS) решения для небольшого фастфуда.(В России есть много подобных франшиз)...(Я например скорее всего пролечу с одной из них,у меня решения толкового нет...есть онлайн решение на апексе...но нужен офлайн).
Есть решение Сенсорное для большого терминала.
https://cloud.mail.ru/public/49343a494bf9/p1010403.mov
(Видео на CentOs 6.5)
Но сенсорный моноблок 1000$
А андроид сами знаете...а для франшизы сразу 15 точек минимум надо.
И Опять таки к нему обязательно интеграция с ИС.(Нехардкодный легко настраиваемый сервис,-Именно это самое сложное)


Далее Адаптеры примитивного документооборота...
Все ходят обмениваться информацией...но не у всех есть возможность.
Многие клиенты Ваших клиентов дают допустим свою накладную в екселе(и у всез форма разная) в в rtf,html,
И есть продвинутые ,что дают в xml(но не Вашего образца).
И Ваш клиент выносит Вам мозг,-хотелось бы мне с вот тем как-то автоматизироваться по заливке его приходной накладной.

И у всех формат разный.

И вот тут нужен сервис-адаптер.
Он заглатывает документ с заранее подоговленным для этого документа xml.(В нём вы описываете если для ексела,например ,-какие поля в какие тэги)...а получаете на выходе xml стандартного образца.
Кто продвинутый и даёт Вам xml ,то сервис на вход получает xslt и та же тема.(Но попроще)

И на выходе образец Вашей ИС...Вы его заглотитли...аля накладная появилась в Вашей ИС.

MoroZ.Ru,
Да...Вы эту проблему решили,но всё же это не совсем по "продакшн"...
Это больше частное решение.
Требующая в свои зависимости продукт третьих лиц(LibreOffice)
А если у другого клиента чуть чуть шаблон координатами отличается...новый шаблон делать...
(А можно ведь во входящем xml чуть подправить разметку )...
А если у вас в html...а rtf и т.д...
а если нормальный и даёт xml...(и надо лишь xslt написать,-я думаю со временем такое будет у большинства)

Решение должно быть более универсальным.(я конечно такое буду делать..только позднее :-) и именно по- принципу подключаемого адаптера "на ходу")..

leonmbs,

либо вводить данные в форму как в большинстве программ включая самизнаетекакую.


Всё проще...я даже когда-то к фрилансу(я часто пользуюсь их услугами) спецификацию готовил
типа



И всё начало координат знает...пока не пусто...готовит данные моего xmlя
а свой родной xml ...я знаю как заглатывать. :-)

MoroZ.Ru,
Не понял, в чем разница. Все-равно править и там и там.

Разница в концепции...
На вход сервиса поступает сам файл и xml task.(в котором описана задача для сервиса.)
В этой задаче помимо разметки допустим,- есть библиотека что нужно найти и подгрузить.(Библиотека имеет соответственный сервису интерфейс ..типа файл на входе файл на выходе)...
Сервис подгружает эту либу(если необходимо...ибо возможно достаточно только задания разметки)
И эта либа обрабатывает файл и возвращает сервису.

В этом случае нам всё одно
service.get(exel ФАЙЛ,xml task)
service.get(pdf ФАЙЛ,xml task)
service.get(rtf ФАЙЛ,xml task)
service.get(html ФАЙЛ,xml task)
service.get(jpeg ФАЙЛ,xml task)(тут мы подключим решение по распознаванию текста внутри картинки :-) )

irbis_al,

В догогку...
И тогда Вы можете управлять группой(сообществом)...
Говорить...ты делаешь либо для pdf ты для html ,а ты для (крутой) jpeg

MoroZ.Ruirbis_al,

Я не буду спорить о преимуществах этих вариантов. Когда-то я на одной фирме решал эту задачу подобным вашему способом, только с помощью скриптов на Perl. Понятно, что кроме меня там никто ничего исправить в случае чего бы не смог. В этом смысле чем проще и нагляднее, тем лучше. Ведь пользователям самим нужно будет это исправлять и исправлять быстро, чтобы не тормозить текущие бизнес-процессы.
По поводу управления сообществом - почитайте текст, ссылку на который я дал выше. В случае с Open Source это иллюзия. Никто никому ничем не обязан. Никто ни во что вникать особо не будет. Всем нужно готовое решение. В сообществе будут ровно до тех пор, пока это интересно. Какой там говоришь"... ты делаешь".

Вот не путайте тёплое с мягким...
Внутренние сервисы...это для разработчиков...пользователей туда пускать не надо.
Управление сообществом должно быть не по принципу...делай вот так...
А где-то так...
Мы говорим
У нас есть сервис(можете посмотреть его код)...его можно дополнить сторонней библиотекой(по спецификации такой-то)...к нему техническая документация такая-то.

Разработчик?
О слушайте...я отлично волоку в google sprech...
Давайте я Вам сделаю
service.get(звуковой ФАЙЛ,xml task)

И по надиктованному на диктофон ассортимент товара Вам превратится в xml. :-)
Т.е это должны быть концептуальные стандарты.