iscrafm,
iscrafmЕгоров Александр,
насчет интерфейсных таблиц...
внешняя программа выполняет выгрузку требуемых данных в таблицы на SQL сервере. 1С при помощи обработки читает данные из этих таблиц, создает необходимые объекты в своей БД, выполняет их проведение... Это просто шлюз о структуре которого договариваются две стороны. При массовых загрузках, имхо, более живучий вариант, чем общение с объектами 1С через OLE

1) В топиках Александра Егорова нигде и не говорится, что OLE механизм используется для общения с объектами 1С (в этом случае действительно тормоза да еще какие). Внимательно читаем топики.
2) Зачем нам нужны какие либо промежуточные таблицы, в которые внешнее приложение грузит данные? А напрямую к этим данным обратится нельзя, без промежуточных таблиц? По моему лишнее.
Промежуточные таблицы имеют смысл для хранения связей объектов база 1 - база 2.

Enot5467Про прямую запись в базу 1С: так же как и с SQL, пишите без проблем. Просто когда встанет вопрос по стоимости сопровождения, поймете, чем чревато. Любое изменение в конфигурации может ненароком разрушить всю базу. К сожалению такие моменты наблюдал лично.


Ага и изменение прям таки любое может разрушить тебе базу!
имхо очень сильно преувеличенно.
Опять же прошу факты: из-за чего произошло крушение.



Enot5467
Ну а по существу:
- Зависимость от платформы (ни кто не знает, что будет со следующим релизом 1С)

Ага а любые другие виды обмена платформонезависимы?

Enot5467
- Зависимость от версии SQL

Здесь зависимость минимальная.

Enot5467
- Зависимость от версии конфигурации

Оказывает самое сильное влияние на все виды обмена.

Enot5467
- Сложность разработки разработчиком

А что ждать всей бухией пока данные перенесуться,
а потом работать по ночам и по выходным будет ЛЕГЧЕ (дешевле)?

Enot5467
- Сложность найти помощника/замену разработчику


Согласен. Найти 10 вменяемых бухгалтеров легче чем 1 вменяемого разработчика.

Enot5467
В итоге как только подойдет руководитель с архиважным планом по изменению каких-нибудь контрагентов, разработчик от бессилия начинает обвинять 1С.

Разработчики бывают разные. Но а такого, который не свои руки кривые выпрямлять будет, а головой на платформу кивать - гнать надо. И выявлять таких до появления архиважных планов.
ИМХО вопрос качества подбора персонала.

Enot5467
Руководитель смотрит на это пару месяцев и вызывает самый задрипаный франч, что бы тот поставил что-то стандартное.

Мудрость и опыт руководителя была определенна еще на этапе подбора персонала;)
-----------------

Enot5467
Про скорость в 1С: при помощи промежуточного хранилища у меня работает связка баз 1С на одном предприятии. Скорости удовлетворяют на 100% всех. Работают не зависимо от активности сотрудников. Бухи даже не понимают, что есть где-то обмен. Вообще скорость зависит не от 1С (можно и на асме и на С# таких тормозов написать...), а от того кто туда руки прикладывал.

И где здесь:
1) не зависимость от релиза 1С?
2) не зависимость от версии SQL?
3) не зависимость от версии конфигурации 1С?
4) простота в разработке?
5) простота в замене вас на нового разработчика?


И еще уважаемый Enot5467 оцените стоимость приведенных ниже решений:

Считаем, что в абстрактной компании торговых операций очень много, потому как для небольшого количества операций актуальней будут другие средства обмена. В абстрактной компании существует какая либо торговая система на базе 1С или западная (искрафарм учитываем сюда же) или самописка.
Задача иметь актуальную бухгалтерскую и налоговую отчетность на основе данных торговой системы.

Итак с точки зрения трудозотрат в целом для компании будет дешевле - поддерживать актуальные механизмы быстрого обмена (с прямой записью в таблицы) но бухгалтерию иметь стандартную от 1С или поддерживать в актуальности бухгалтерскую подсистему в самописке?

А, что будет дешевле в целом для компании - поддерживать обмен на .XML между западной системой и 1С бухгалтерией или поддерживать обмен на прямых запросах (в том числе с ипользованием промежуточных хранилищ) между этими системами?

Только оценивайте пожалуйста не только стоимость разработки/подержки отделом ИТ. Учитывайте какие буду затраты со стороны смежных отделов использующих решение.

iscrafmvitkhvЗачем нам нужны какие либо промежуточные таблицы, в которые внешнее приложение грузит данные? А напрямую к этим данным обратится нельзя, без промежуточных таблиц? По моему лишнее.

может и можно. я имею ввиду самый простой и незатратный способ. Обратный способ, конечно же, возможен, в теории. Но владелец информации гораздо эффективнее подготовит ее для обработки.

а если нет возможности что либо изменять в конфигурации владельца информации?
а при наличии возможности, что либо менять надо еще иметь и разработчика чтобы мог что ли бо менять.
т.е. нужен 1С ник, SQL щик и Искрафармщик (Абапер, X++ сник и т.д.).
а без подготовки информации на владельце нужны только 1С ник и SQL щик + профайлер.
При этом 1С ник со знанием SQL гораздо более частое явление - чем 1С ник со знанием Искрафарм(абап, Х++).

iscrafm,
ну так я и говорю, чтобы готовить информацию на владельце информации, нужен человек который умеет ее готовить.
Поэтому можно и без человека такого обойтись, напрямую долбя таблицы владельца информации.
А если вообще нет возможности готовить данную информацию на владельце?
В обоих случаях нужен только 1С, SQL щик и профайлер.
Хотя к вам это не относится, готовить у вас возможность есть.

iscrafm,
Я не говорю про онлайн обмен из 1С обратно в Торговую систему.
Я говорю про обмен Торговая система -> 1C.
Нет у тебя доступа к конфигурационным слоям Торговой системы или нет спеца который умеет ее конфигурить, а данные в Бухию грузить надо, что делать будеш?

iscrafmvitkhvЯ говорю про обмен Торговая система -> 1C.
Нет у тебя доступа к конфигурационным слоям Торговой системы или нет спеца который умеет ее конфигурить, а данные в Бухию грузить надо, что делать будеш?
заменю бухгалтерский модуль. Серьезно. Или, если нужно, найду спеца.

Вот вот, а если живешь где нибудь в Хабаровске.
На предприятии развернули Западную систему (вторую на весь город), а бухгалтерского модуля к РСБУ к ней вообще нет.Что будеш спецов с Москвы заказывать?

И на какой бухгалтерский модуль ты собираешся 1С менять?

iscrafmvitkhv,

на самом деле такие ситуации маловероятны.

Т.е.маловероятны ситуации когда дешевле иметь одного спеца в лице 1С ника и SQL щика, чем двух в лице 1С ника и искрафармщика (абапера, x++ сника)?

iscrafmЕгоров Александр, хороший пример.
Ну Александра я лично знаю.
Работали даже вместе :)

Егоров АлександрiscrafmС необходимостью он-лайн не встречался, пока.
Я делал возможность получать на КПК результат проведения заявки покупателя в 1С (она была системой оперативного учета). Онлайн был актуален, ибо дефицит товарных запасов при множестве удаленных торговых представителей, едином складе и схеме работы "два профильных ТП - один клиент", приводил к необходимости оперативно изменять заказ при его непроведении.
Собсно, почему и хочется услышать автора топика - в чем необходимость онлайна...

/topic/478881&hl=