Подскажите неграмотному: есть документ ПеремещениеТМЦ с основного склада центральной базы (фирма=центр, склад=Центр) на розничную точку (периферийная база, фирма=Периферия1, склад=периферия1). Возможно и обратное перемещение. Перемещение  между точками, минуя ЦБ - нет такого. Перифериек несколько.

Как (в конфигураторе/программно) сказать, что миграция документа ПеремещениеТМЦ должна осуществляться по такой схеме:
- документы из всех ПБ должны попадать в ЦБ.
- документы из ЦБ должны попадать только в ту ПБ, на которую осуществляется перемещение.
- в ЦБ возможно выполнение перемещения из периферийки в ЦБ - этот документ также  должен мигрировать в свою ПБ.
..
????

никак, как ты понимаешь.
Только ручной чисткой файла обмена

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

(2) опять же - чистить файл обмена...

итого получается что:
(если все делать штатными методами)
.
1) если есть документ по которому при проведении идут движения по регистрам и в регистре есть списание с ЦБ и оприходование на ПБ - то никак списание не вычеркнуть из миграции на ПБ? - так?

????

2) если есть документ: то никак не зарегистрировать например миграцию на ПБ1 если складприемник=ПБ1, а на другие ПБ - миграцию не проводить? - так???

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

"Место создания и центр"

По моему, единственный штатный вариант, без чистки файла обмена, создавать на ПБ заготовки документов, на ЦБ вместо создания нового документа брать заготовку.

я повторяю в третий раз - чистить файлы обмена. Или покупать МОД

+(7) только придется иметь "заготовки" документов в перефирийках...

(10) не подходит.

Тогда свое писать...

Тогда такой вопрос:
В центральной базе есть пара документов:

одна сторона пары:
Реализация с центральной фирмы на точку клиента или
Реализация с перфиерийной фирмы на точку-центральный клиент
- эти доки никуда не мигрируют, т.е. место создания.
.
вторая сторона пары:
Поступление с клиента-центр на фирмуПериферийнаяТочка или
Поступление с клиента-точки на фирмуЦентральнаяБаза
- эти доки должны мигрировать только из центра на СВОЮ ПБ или
из ПБ в ЦЕНТР (при этом исправления в центре периферийных доков должны мигрировать в свои ПБ)
.
я так понимаю, что такую схему реализовать штатной УРБД - нельзя?
в чем тогда ценность УРБД - сорри но я не понял....
?????

Все просто. Средствами платформы определить куда передавать документ из ЦБ нельзя.
Студенты пользуют 2 варианта.
1. Область миграции все ПБ. В ПБ ограничивают видимость "чужих" документов.
2. Используя внешние флаги создают документы с нужными реквизитами в ПБ с областью миграции "Место создания и центр".

(14)
п.1 понятно, не подходит.
п.2 - не понял... какие внешние флаги?
в пб я ничего создать не могу - я сижу в ЦБ. я могу сделать документ ВМЕСТО оператора ПБ в центральной базе - он должен уйти в свою ПБ.
.
???

Все в (14) реализуется штатными возможностями платформы.

(16) непонятно.
как из п(13) сделать "вторую сторону пары".?

(17) Без "извратов" не обойтись.
Сценарий примерно такой :
1. В ЦБ создается документ например "Запрос на перемещение" с областью миграции "Место создания". В ПБ используя метод ТекущаяИБЦентральная() ввод таких документов запрещаем (если нужно).
2. На ПБ отправляется файлик (TXT, DBF, XML ...) с описанием создаваемого документа.
3. НА ПБ в соответствии с описанием создается документ нужного вида и указанием реквизитов запроса.
4. В ЦБ после обмена с ПБ имеем нужный документ. Все его изменения будут ездить только ЦБ<->ПБ (Место создания). Если нужно исходный запрос можем удалить или отметить его выполнение.

918) хреново, п.2 - вне схемы типовой УРБД. получается до обмена/после обмена придется делать допдвижения туловищем...

+(18) Сценарий №2.
1. Опытным путем определяем количество документов нужного вида, которые вводятся между сеансами обмена.
2. В ПБ (например при старте) определяем количество непроведенных документов нужного нам вида. Если недостатачно - создаем.
3. В ЦБ ищем непроведенный документ с реквизитом, где записан ИБСозданияОбъекта() переставляем даты, время, заполняем реквизиты. Все. Имеем документ который будет ездить ЦБ<->ИБСозданияОбъекта().

Соответственно заполнение заготовок в ПБ должно быть запрещено.

(19) Насчет допдвижений эт-та да. А кому сейчас легко?

+(20) Вместо фишки проведен-непроведен можно пользовать (например) реквизит "ЗаполненВЦентре".

А Ви знаете.. что-то таки не то с форумом, позвольте заметить, в последнее вгемя.. таки уже ветка ушла за 20 постов и обгатите внимание: таки еще никто не сказал, что Ви обязательно переходите на восьмерку! что там это уже сделано! :)))

(19) откажитесь от УРБД.

(24) а что юзать?

(24)Весь смысл УРБД в том, что платформа отслеживает измененные документы... ну а так свое написать между идентичными конфигами можно..

(25) Мод, например

У меня УРБД регистрирует изменения, а обмен с помощью МОДа

(28) А у меня и МОД регистрирует изменения
(25) Свои наработки. Если все на скулях - ваще проставить spdisigner на все базы, понавешать джобов, и пусть обмен фигачит сам собой.

(29) У меня тоже регистрировал. Но с увеличением объемов стал пропускать объекты время от времени. УРБД надежнее.

(30) И кроме пропуска он через одно место работает с подчинеными справочниками. Даже такая элементарная задача как группы - для него тоже проблемотично

А для УРБД. Там вопрос только как чистить таблицу изменений, если база на ДБФ?

я бы мутил в сторону разделения на расход-перемещение и приход-перемещение (миграция МСиЦ), "болванок" приход-перемещений из перифериек в ЦБ, которые между приемом обменов из перифериек и выгрузкой обменов для перифериек обработкой пакетно заполнять-проводить. методологичекски корректнее (склад "товары в пути" или даже несколько складов таких - перевозчиков укрупненно или своих ТС или ответственных за доставку - по ним остатки бывают немаловажны и факт перевозок, ну и логистику накрутить моно, или ещё чево)

(32): любой вопрос имеет ответ )))

(34) Пока что не находил ответа, кроме перехода на скуль. Вся надежда была на запись средствами 1Sqlite, но автор решил на 8-ку податься.

Писать, апдейтить не вопрос, вопрос в том, что индексы после этого сбиваются %(

1. У документов делается общий реквизит - "ИндексМиграции"
2. Делается справочник ИБ, в котором перечислены ИБ с индексами баз
3. делается справочник правил миграции
4. в глобальнике делается процедура, заполняющщая Индекс по Правилам
5. ДТС-пакет, или триггер на 1сдаундоадс, чистящий апдейтс.
собственно, все....

(35): я в dbf Xbase-ом обхожусь.

на sql легко. на dbf - хз

(38) Мы сейчас говорим о модификации таблицы 1С (1supdts.dbf)? Просто можно добавить запись, но 1С не видет ее пока не проиндексирует эту таблицу

(39) На скуле и тригеры можно повесить, и тогда задача из (0) легко решается с помощью самого скуля

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

(40) Не задавался целью. Но легко решается внешней приблудой с нужным драйвером БД. Где-то видел указание на конкретный используемый 1с драйвер.

(43) Если писать через FoxPro-шный драйвер, то летят индексы, так как немного отличается сортировка.

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

(45) Самый последний

итого: плохо все... с извратами...

(47) Увы. Но работает

на sql никаких триггеров не над. делано уже и не раз.

кстате на dbf можно табличку изменений просто чистить перед обменом. наверное...

(47) Ну минимальное телодвижение это делать через промежуточный склад и с "балванками"

(40): см.(38).
(42): регламенты, расписание, стартер ромикса. никто и не говорит, что бардак автоматизировать возможно.

(49) Еще раз. Средствами 1С нельзя чистить табличку (нет технической возможности, т.е. нет команды. УРБД.УдалитьЗаписи()). Через XBASE тоже облом (иначе зачем 1С++, если 1С сама может свои таблицы читать). Через внешнего провайдера ... у 1С свой особый механизм сортировки и работы с индексами, поэтому тоже засада.

(50): промежуточныЕ складЫ и в каждой базе свой экземпляр - это весьма удобно (плюс контроль перевозчиков, плюс логистика).

(52): странно, а у меня не облом. наверно что-то не так делаю.

(54) Код в студию

Например
Процедура Сформировать()
  База = СоздатьОбъект("XBASE");
  Путь=КаталогИБ()+"1SJOURN.DBF";
  База.ОткрытьФайл(Путь);
  База.Первая();
  Для й = 1 По База.КоличествоЗаписей() Цикл
     Сообщить(""+База.Date);
     База.Следующая();
  КонецЦикла;
КонецПроцедуры

Выводит ошибку
База.Первая();
Перед выполнением операции нужно открыть базу!

Хотя если обратиться к журналу другой базы, то все нормально

//(55): странно. самопальная универсалка натравленная на 1sjourn тек.базы:
   тТабОбъект.ТекущийИндекс(СокрЛП(фТекИндексНаим)); тЗап=0; кЗап=тТабОбъект.КоличествоЗаписей(); тТабОбъект.Первая();
   тНачМСек=_GetPerformanceCounter();
   Пока тТабОбъект.НомерЗаписи()>0 Цикл
       тЗап=тЗап+1; Состояние("Заполнение: #"+тЗап+"/"+кЗап+" ...");
       фТЗ.НоваяСтрока(); фТЗ.ПолучитьСтрокуПоНомеру(тЗап); Если тВыб=1 Тогда фТЗ.ТекущаяСтрока(тЗап) КонецЕсли;
       фТЗ.НомерЗаписи=тТабОбъект.НомерЗаписи(); фТЗ.НеУдалена=1-тТабОбъект.ЗаписьУдалена();
       Для тСтр=1 По тТабОбъект.КоличествоПолей() Цикл
           тТабОбъект.ОписаниеПоля(тСтр,тНаим,тТип,тДлина,тТочн);
           фТЗ.УстановитьЗначение(фТЗ.НомерСтроки,тНаим,тТабОбъект.ПолучитьЗначениеПоля(тНаим));
       КонецЦикла;
       Если тТабОбъект.Следующая()=0 Тогда Прервать КонецЕсли;
   КонецЦикла;
   тКонМСек=_GetPerformanceCounter();
// http://s40.radikal.ru/i089/1009/f5/110345f4a37b.png - читается нормально.
// про 1супдтс: список удаляемых сохраняется нормально.
// и - да, "снаружи" (конфига унив.обработчик висит, мониторит и выполняет
// задания) по списку всё удаляется тоже нормально.

Кто провайдер?
1Сpp (ADO, OLE) читает без проблем
1Sqlite - тоже читает без проблем

(56) гыгыгы© додуматься до "внешнего обработчика" как отдельной, другой конфигурации на 1с я не смог :-)) Хотя это самое очевидное.
Где взять пепла посыпать голову?

(57): см.(51), первая строка.
(обрати внимание на использование "родного" индекса - сюрпрайс?))

(58): не комплексуй, я нечаянно. :))

(60) Да пофиг. Привык к сиквелу... застоялся...

(61): тогда представь себе охрененный такой большой триггер на все таблицы всех баз... )))

(59) Т.е. выгоняешь всех и работаешь с базой один?

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

(64)+: а, да! если ты про (56) а - то без выгоняний работает. выгоняю только для обработчика "снаружи" да и то не всегда - лочу 1супдтс в попытке и юзверя ждут просто сколько надо (сколько надо - им сообщение выходит про перекур).