Реально сделать автоматическую выгрузку загрузку через ТХТ или XML?
Универсальный обмен через конвертацию данных не прелагать!

реально

обработчик ожидания и файл флаг.

(0) за такой вопрос положен пожизненный бан

(0) .NET в зубки, создаешь сервис, сервис подключается к 1Ске и делает все красиво.

(0) а чего кд не катит ?

(0) Я делал через Планировщик заданий Windows

(6) + и я.. лет эдак 9 назад.

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

(3) и посмертный )

(0)кстати автоматический обмен и настройка правил обмена через кд - это не взаимоисключающие друг друга вещи .

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

(0) А в чем сомнения?

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

(0) Почему не предлагать универсальный обмен через конвертацию данных?

(13) дбф - прошлый век.

(15) Прогрессивные рюшечки вместо функциональности?

(13) Быстро будет работать, если xml-файл разбирать руками, как txt, только тогда сразу становится понятной вся убогость xml и переход на другие форматы, где не требуется по несколько раз указывать текстовые наименования полей.

(15) dbf не удобен только тем, что поля фиксированной длины и формата. А вот просто поток байт - это наше всё.

Если бы в xml закрывающий таг кодировался одним символом - уже было бы проще.

мне показалось, или тема была v7?

(13) в сабже указано что через TXT или XML, причём тут тогда DBF?

(21) в сабже написано кд не предлагать. про дбф ничего не написано.

(20) Чё курил?

(20) А это что-то сильно меняет ?
Конечно, в v7 робота немного сложнее запустить, но работать-то он будет точно также - проверять данные и писать в файл всё, что нужно.

(23) Мальборо :)

(22) первое предложение в (0) прочитай

(26) Я не понимаю что ты имеешь в виду.

Автор сам себя загнал в узкие рамки так, что теперь сомневается? КД2 - низя, из форматов - только txt и dbf... А теперь сомнения одолели и нас спрашивает "Реально?" :))

(0) Реально, пиши. Разрешаю.

Сам когда-то давно писал обмен с ИнфоБухгалтером (но через dbf). На моей стороне был полный автомат, а как "на том" конце - меня не волновало. Это другого прогера была проблема.

Чего только не сделаешь при внедрении - лишь бы упёртых юзверей уговорить.

(28) Это как в анекдоте: "Пуля из ствола вылетела? Вылетела. Проблемы на вашей стороне"

Ну, да, как-то типа так. Сказали реализовать обмен - сделал. А дальше хоть трава не расти. Мне, как 1С-программисту, не выгодно было поддерживать "конкурента".

(29) В данном случае, сравнение некорректно, если формат обмена описан, если данные выгружаются и передаются, то, как их будут жрать на той стороне - забота того, кто писал протокол обмена.
P.S. когда xml-файл переваливать за сотни мегабайт, становится очевидно, что "хотели, как лучше, а получилось, как всегда".

(31) когда xml-файл переваливать за сотни мегабайт, то в работу вступают архиваторы.

А когда архивированные XML переваливают за сотни мегабайт, то в работу вступают системные архитекторы

(офф)
И, кстати: формат обмена данными был сначала согласован "со стороны" ИнфоБухгалтера (так, как там гораздо больше ограничений). А меня, просто и незатейливо, - поставили в известность :)

Формат - безобразный, с моей точки зрения. Достаточно сказать только, что шапки документов писались в одни dbf-файлы, а их табличные части - в другие dbf-файлы, с уникальным составом полей для каждого файла.

Кончилось тем, что по моему мнению и должно было произойти рано или поздно, - у базы данных ИнфоБухгалтера "снесло крышу" от объема информации.