Добрый день - всем!
Сейчас обмен есть и фурычит, НО медленно. Настроен через самописные обработки с использованием XML и FTP.
Может, есть что-то более продуктивное для моего сабжа?
Да, центральная ИБ очень большая - с 2007-го года. Еежедневный дкументооборот огромный - порядка 1000 новых доков. Посему УРИБ изначально не был пригоден...

+ в филиальных ИБ должны быть только свои доки - центра быть не должно.

вместо иксемеля используй текст или dbf - объем обмена уменьшится на порядок. загрузка вообще быстрее пойдет.

>> Еежедневный дкументооборот огромный - порядка 1000 новых доков

:-)

У меня УРИБ бегает на 60-80 тыщах доках в день.
Так что зря ты свои самописки поперед штатных методов ставишь...

+ и да...
"Резать к чертовой матери!"(С)

(3) ок. а можно ли выгружать из ЦБ только некоторые справочники и некоторые виды доков???

(3) правильно настроенный штатный УРИБ в 7.7 вполне летает
вот настроить его проблеммно и потом можно интересные глюки отловить или невозможность кое что исправить когда дубли грохаешь а они снова из другой периферии лезут ))

1000 доков - это ниочем.

Нужно, что бы:
1. Из ЦБ в Филиальные уходили только некоторые виды справочников и доков;
2. Из Филиальных в ЦБ вылетали сделанные доки.

(6)У нас и на 77 летает и на 8 впринципе норм:-) за ночь 50 филиалов успевает обменяться с центром 77, оттуда перетечь в 8 торговлю и отттуда в бух

(7) выгрузить образ из ЦБ сейчас не представляется возможным - не влазят все данные в файл выгрузки из конфигуратора...

(6) работал и штатный без всяких проблем, и почти штатный ("снежинка").

(5)Штатными планами обмена- что там зарегистрируешь в онфе как состав- то и будет обмениваться

Не проще 1 сервер и всех по RDP

(10) Ну и не выгружай штатно. клонируй базы (методика описана мной лет 5 назад)

(12) в 7.7 есть планы обмена?)))))))

(13) проще, а печатать как?

бамажки

(14) подскажи, плиз, где почитать?

(15)а... 77:-)

(19) хехехе)))

(16)>> а печатать как?
файл сохраняют себе на комп и печатают:-)

не кул)

(20)Все равно тот же документооборот у нас сначала из 77 стекается по штатному УРИБ

(16) 7.7 не умет печатать через терминал? Интересная новость.

(17) в чем проблема с печатью?

(24) должна мочь, была бы Связь ОК...

Заменять на терминал не лучшая идея. Нет связи - нет работы.
Отладчик в руки и смотреть где тормозит. Дальше переписывать что бы не тормозило.

(26)  у меня 2 склада в полях работают через мегафон модемы уже больше 5 лет.

(0) почему самописки? чем вам штатное УРБД не подходит. Зачем такой гемор с хмл?

(8) еще раз спрошу. Почему не штатная УРБД от 77? там все это есть с минимальным головняком и 100% гарантией от потери данных

(0) Переходи на восьмёрку, там это реализовано. (с)
там штатно и фильтровать выгрузки, красота, одним словом

(18) тут, в мизде

(30) потому что штатная урбд от 77 без мозголомных извратов (суть которых надо ПОМНИТЬ когда что-нибудь пишешь программно в центре) не позволяет организовать нормальную схему обмена

дарю http://catalog.mista.ru/public/16687/

(30) см. (8)

еще дарю
Книга знаний: FAQ по Менеджеру обмена данными (МОД)

(35) это настраивается совершенно штатным образом

(37) что это??? В 7.7 ли???

(38) потребность типа
-------
Нужно, что бы:
1. Из ЦБ в Филиальные уходили только некоторые виды справочников и доков;
2. Из Филиальных в ЦБ вылетали сделанные доки."
-------
настраиваается в штатной урбд 7.7 штатным образом

(39) да, но при этом в ПБ должны уходить только доки, предназначенные для этих ПБ. А это без извратов - не реализуется...

(40) это - да. Хотя для сиквельной версии -  реализуется очень просто.

(41) для "не сиквельной" тоже не сильно сложнее, через "объекты пустышки"

(42) ага.

(42) которые надо создать на стороне ПБ?
а потом в какой-нить обработке в ЦБ вместо Док.Новый() (который предназначен для ПБ) писать поиск пустышки? а если получилось что надо сгенерить 50 доков, а пустышек всего 40? а если обработка заказывается фрилансеру?
- да ну нахрен такие извраты.

как например передать в ПБ документ перемещения с ЦБ на ПБ - но только чтобы были движения только по получению товара на ПБ, но не было движений по списанию товара с ЦБ? а если такой документ исправят в ПБ - как без извращений получить чтобы на ПБ при перепроведении были движеняи только по ПБ, а при загрузке такого дока в ЦБ - чтобы все было и по ЦБ и по ПБ..?

(44) ну ограниченная архитектура семерки, и что? зато быстрее этого монстра  http://cs5.pikabu.ru/post_img/big/2015/12/10/11/144977100919388254.jpg

..тьфу...

когда-то мод вроде был

(0) автор, при прямых руках, холодной голове и определенной доли лени - все, в той или иной мере, делается штатными методами

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

>> порядка 1000 новых доков.
на каждом из 15 узлов?

(33) (35) и что.. из пб в центр как раз все доки. из центра в ПБ некоторые ВИДЫ а не конкретные доки. это как раз и реализует УРБД.

если надо какие-то доки конкретные, например у меня поступления в филиал делаются автоматом в центре на основе отгрузки этому филиалу любой базой. Для этого филиал поддерживает 15-20 пустышек поступления в невидимой дате. А цб их заполняет. Все работает прекрасно, гемору тут не больше, чем с планами обмена в 8ке.

(40) Никаких извратов.

(52)  ну и как это реализовать? Оговоримся сразу что пустышки это изврат

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

(53) у меня делается через промежуточный документ, он ходит везде, а реальные документы создаются только там где надо на основании промежуточного

(53) почему "изврат"? Ну и уж по крайней мере, не бОльший изврат, чем МОД.
Если б в 1спп сделали перезват записи в апдейтс - вообще бы сказка была.

(55) То есть когда "создать", пользователи работают с одним документом, а когда "редактировать" ищут другой, который должен будет создаться по промежуточному? А если пользователь проводит промежуточный документ и через небольшое время понимает, что сделал в нём ошибку, он что как и где ошибку исправлять должен?
(53) А чем вам не нравятся пустышки? На мой взгляд, в 7.7 выбора немного. Либо вы делаете свой изврат типа пустышек, либо вы берёте чужой изврат типа МОДа.

(53) это не изврат. это нормальная система.

(56) тогда это была бы 8ка, да еще в джорнал раздельные записи..

(57) 1. а это как настроить. если сделаешь так, что при изменении источника док в нем стоит метка перезаполнить приемник - то поправит в центре. все в твоих руках. Главное связь есть между доками.

(53) МОД кстати приблуда, это аналог 8ных планов обмена. По сравнению с УРБД штатной изврат еще тот

(57) ты программист или где? )))

(45) эх, срачик начать, что ли?..

(62) Я гордая птица 1Сник! И нечего тут программистами всякими обзываться! :)))

(64) Ты птица... Главное, клюв свой не выкладывай на стол...
А то будешь не птица, а ёжик...

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

(66) перехвата момента записи в апдейтс вполне хватит для того, чтобы отменить запись или добааить лишнюю. И надо это не на уровне конфигуратора, а на уровне выполняющей системы.
Триггерами вполне можно решить, коннчно. Но это для среднего 1сника - слишком сложно. Ну и только для сиквельной версии. А перехват сработает на любой. Хотя написать генератор триггеров - неплохая идея:-)

У мну есть обработка доя урбд
Которая по сделанным настройкам из файлов обмена для каждой пб вычищает чужие объекты
Но я с ней не разбирался
Ибо пока не сильно актуально

(67) периферийная база по урбд может отправить документы только в ЦБ - тут фильтр совсем не нужен.  в ЦБ документы создаются при загрузке в режиме конфигуратора,- тут 1сpp никак не поможет.
так что либо триггеры,  либо обработка упдейтса в ЦБ перед каждой выгрузкой из ЦБ.
у меня через триггеры несколько конф работает на 10+ периферий.

(68) у Шемякина есть для тойскл

(66) (69) да ладно.
1. Конфигуратор только загружает пакеты от ПБ
2. Запускается сессия 1с с 1срр или тойурбд вычищает апдейтс табличку в соответствии с миграцией дока.
3. конфигуратор выгружает пакеты согласно апдейтса.

п.2 работает в 2х режимах.
1. миграцию объектов ставим (все) и тогда из апдейтса вычищаем записи к докам для баз, которым этот док не положен.
2. обратный процесс. миграция только пб/цб, но в апдетс добавляем записи с ид доков в опр базы.

и не надо никаких триггеров. Все настраивается фактически языком 1с

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

(73) поддерживаю. все должно делаться автоматом и не зависеть от интерактивных действий.