Иван АбрамовИнтересно, что с другими системами интеграция посредством ADO и VBA делается станадртно без проблем (тот же MS Outlook или MS CRM к примеру с его БД SQL Server)
и только в 1С свой язык, уже воспитавший класс спецов, не допускающих мысли использования БД 1С из вне.
Тут просто дело в том, что разработчикам 1С не пришло в голову сделать отдельное API для возможности интеграции без запуска 1С. Скажите спасибо, что есть возможнось запуска через OLE - ведь могло и этого не быть :) С другой стороны "прямая запись в таблицы" - не очень удачный путь для интеграции (если, конечно, от производителя нет точного описания такого метода). Ведь базу того же outlook (файлик *.pst, например) вы напрямую тоже не модифицируете, а используете вызовы функций MAPI. Или вызов самого outlook-а через тот же CreateObject("Outlook.Application"). То есть используете только те методы, которые предусмотрены разработчиком, Вас же это не коробит в случае с outlook? :)

С другой стороны, просто создать документ в 1С - это действительно достаточно просто и через прямую запись в базу 1С (особенно если база SQL и не вдаваясь в подробности парсинга dds или md). Но для 1Са этот документ будет иметь статус "непроведен". Для его корректного "проведения" Вам уже будет мало знать структуру таблиц, Вам еще надо будет знать алгоритм проведения. А эти алгоритмы модифицируется 1Сом гораздо чаще, чем структура таблиц.

В свое время ходил по тем же граблям - интеграция с 1С методом прямой записи в таблицы :) В результате пришел к выводу, что либо экспорт\импорт через пользователя, если это какая-то регламентная процедура, ежемесячная заливка учетных данных в Бухгалтерию, например. Либо некий сервис, который при старте поднимает 1Ску по OLE для каких-либо онлайновых транзакций.

С дургой стороны, онлайновые транзакции с 1Сом нужны только тогда, когда основной учет ведется в самой 1С, а та же выписка счетов - во внешней программе. У Вас, как я понял, основной учет ведется в собственной программе. В связи с этим вопрос, в какую именно 1С (с точки зрения вида учета) Вам надо переночить счета и почему это надо делать обязательно онлайн? Если онлайн не особо и нужен, что мешает сделать наоборот - стандартизировать интерфейс выгрузки счетов из Вашей системы и нагенерить кучу ert-шек под каждую типовую конфу?

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

"общественно-полезный и востребованный труд" не должен быть бессмысленным. Иначе этот труд никто не захочет оплачивать, ибо к "деланию денег" он, обычно имеет весьма отдаленное отношение.

У меня есть рабочий перенос Торговля (практически самописная) -> Бухгалтерия (практически типовая). Методом "прямой записи". :) Перенос строго односторонний, вся первичка и справочники заносятся в Торговле. Справочники обновляются онлайново через триггеры и синхронизируются через доп. таблицы по ID. Документы переносятся регламентной обработкой в бухии через прямую выборку из вьюх, в которых структура Торг-документов приведена в соответствие с Бух-структурой и через "прямую запись" в Бух-таблицы и штатным запуском Док.Провести(). Так же связаны по IDDOC. Получен выигрыш в скорости переноса примерно на порядок, "правила переноса" - суть скрипты TSQL, который лично мне нравится больше, чем язык 1С :) и регламент переноса свелся в нажатию единственной кнопки в единственной программе ().
Это как бы плюсы. Теперь считаем, из моего отчета боссу:
» во что это обошлось конторе, получилось:
» стоимость внедрения:
» 25000/24*17=17708р
» стоимость владения:
» 35000/24/8*2 = 364,58 р в месяц.
» стоимость сопровождения:
» 25000/24/8*0,5 = 65,11р - подключение 1-го нового
» документа\справочника
» 25000/24/8*3,5 = 455,73р - проверка изменений при обновлении
» конфигурации 1С:Бухгалтерия
» Проверка изменений производтся автоматически, и не требует участия
» человека (при условии, если элементы метаданных не удаляются, а
» только изменяются\добавляются), иначе - доп. 25000/24/8*3,5 = 455,73р
» на проверку.
А теперь минусы. Новые релизи конфы 1С и "хотелки" бухов практически убили начальный "конструктор" (обработка в Торговле, генерирующая скрипты TSQL) - мне проще напрямую в EM модифицировать полученные объекты TSQL, чем постоянно отлаживать "конструктор" и поддерживать его актуальность. Но самый большой минус - попытка посмотреть как этот перелив поведет себя на конфигурации, например УСН, потребует практически заново заплатить 17708 :)

Иван АбрамовПри этом часто 1С используется только для бухучета и сдачи отчетности, а основной системой ведения бизнеса (работа с клиентами, договора, услуги...) - другая система.Именно поэтому онлайновый обмен с 1С только для БУ не имеет смысла - гораздо проще (и дешевле!) регламентная загрузка документов средствами самой 1С, с прямым доступом к данным именно основной системы ведения бизнеса.
Иван АбрамовДолжен быть где-то поднят Application Server (или подозреваю, что в терминах 1С он называется как-то по-своему). Но это уже сложности. Я не хочу, чтобы мне задавали вопросы "как поднять 1С коннектор" и прочими не по моему ПО.
Это-то как раз и будет "Ваша пробелма". Так как в 7-ке сервера приложений вообще не существует, а в 8-ке прямое соединение с сервером приложений точно так же закрыто, как и прямая запись в базу - подключиться к 8-му серверу штатно можно только штатной же 1Ской или ихними штатными "web-расшиерниями". В любом случае именно со стороны Вашего софта должен быть некий "коннектор 1С", который обеспечит минимальный API для передачи данных в 1С.
Иван АбрамовДорабатывать эту интеграцию уже более правильно будет специалист клиента.
Последующие апгрейды 1С врят ли сильно затронут структуру этой таблицы. Всегда будут такие общие поля как "Наименование контрагента", "ИНН", "Адрес" ... Да даже, если и сломается INSERT потом, когда-нибудь - это не страшно. Мне важно, чтобы был пример взаимодействия. Еще хочется синхронизацию контрагентов потом прикрутить...
Это уже говорит, что сильно внутрь 1Са вы не заглядывали. Подумайте, почему до сих пор не существует каких либо универсальных средств интеграции с 1С? Дело в том, что общие поля как "Наименование", "ИНН", "Адрес" в разных конфигурациях могут лежать в разном виде, в разных таблицах, в периодических реквизитах, в регистрах и прочее. И узнать это без чтения метаданных (для 77 - вообще не имеющих штатных средств расшифровки структуры БД) невозможно. И даже зная "принцип хранения" не всегда можно гарантировано корректно записать в 1С информацию напрямую.

Иван АбрамовАлександр, вы можете связаться со мной
Ушло письмо.

nicktcher,

За возможность запуска 1С по OLE ж вроде даже спасибо сказал :) Но давайте разберемся.
И чтобы не было путаницы в терминах: под API я понимаю некий отделенный от самого приложения документированный функционал, позволяющий работать с данными без вызова самого приложения. Пример - тот же MAPI, позволяющий работать с данным Outlook без вызова outlook.exe. Замечу, что MAPI при этом не распространяется как отдельный пакет.
У автора задача по событию своего приложения передать счет в 1С - это загрузка всей 1Ски со всеми ее обработками при загрузке. Долго и требует наличия 1Ски на этом же компьютере. (говорю сейчас только про 77, если в 8-ке это не так, поправьте). Далее, если я пишу в своем приложении что-то типа
то... откуда я узнаю структуру этого документа в данной конфигурации? откуда я узнаю, что такой документ в этой конфигурации вообще есть? Сделать базовый скрипт под какую-либо типовую конфигурацию и у каждого клиента его рихтовать? Либо ограничить интеграцию только с теми клиентами, которые сидят на типовых конфах?

nicktcherМодель доступа OLE Automation Server/Client - это, вообще говоря и есть API Согласен. Но к 1С это применимо лишь как API платформы . К конкретным же конфигурациям, увы... на мой взгляд далеко им до "промышленных стандартов". А ведь существуют еще и штатные обновления типовых конфигураций, которые не гарантируют от появления у документа новых реквизитов (которые, кстати, все обязательные), и ваш скрипт тоже потребует дополнительной рихтовки.

Enot5467,

Это возможно только для 8-ки, установленной с сервером приложений. Для 77 "сервер 1С" придется писать самому. Или забить на время запуска 1Ски по OLE при каждом обмене. Можно прикрутить и какую-нить Консолидацию или ОбменДанными. Но... смысл в том, что инициатором обмена всегда будет 1С. И от конфигурации 1С будет зависеть структура требуемых данных. Так же как и структура выгружаемых данных. Двухступенчатый же обмен, когда таже CRM выгрузила, а 1Ска потом подобрала (и наоборот) очень подходит для обмена данными с Бухучетом - там онлайн не нужен. А если внешняя система - это компонент Оперативного учета, то без онлайна не обойтись. А тормознутость обмена с 1Ской через OLE\COM и отсутствия альтернативы постоянно провоцирует желание читать данные напрямую из таблиц 1С. И даже писать в её таблицы. :) И, думаю, без дополнительного погружения в конфигурацию все-таки не обойтись. Построение cущности "Клиент" во внешней CRM может существенно отличаться от построения этой же сущности в конфигурации 1С, и наоборот. 1Су может требоваться какие-то классификаторы, напрочь отсутствующие в 1С, и наоборот.