ТиС, центральный офис + точки.
Центральный офис = (Фирма0, склад0)
Точки = (ФирмаN,СкладN), где N=1..M
.
товар на точку передаетс япосредством реализации(поступления) с центрального офиса на точки.
.
Вопрос: как сделать штатно так, чтобы на точку мигрировали только документы , предназначенные для этой точки..? С УРБД работал мало, и мне кажется что штатно не сделаешь - придется обрабатывать файлы обмена...?

Можно обрабоатывать 1supdts перед обменом...

(1) примерчик обработки какой-нить простенький - можно? - мыло в личке. спсб.

я просто видимость ограничивал, там на месте спецов нет, которые бы расковыряли этот механизм..

(3) "видимость ограничивал"..????

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

(4)отбор

(5)это приколы типовых

(2) не сказать, что примерчик простой, но есть выслал.

Возможный вариант.
1. Создаем доп.точку - только получатель ("ТП")
2. Интересующий вид документа правило миграции "Место создания и центр" и галочка "Дополнительно" + "ТП".
3. Создаем каким-то образом соответствие Склад-Периферийная база.
4. Перед обменом просматриваем updts по базе "ТП" и в зависимости от склада меняем базу назначения. Для SQL это будет одна инструкция Update.

В ПБ ПриНачалеРаботыСистемы создаём кучку новых документов нужного вида, таким образом, что бы их весгда было определенное количество. Штук сто, например. Дату докуменов ставим сильно прошлую или сильно будущую.
В ЦБ, когда нужно сделать поступление ПБ не создаём новый документ, а берём готовый.
Аналогично можно "наделать заготовок" для партий.

(5) чего??? у меня всё закрывается. пример приведи.

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

1. Справочник "Информационные базы", структура: dbsign, Наименование, индекс миграции (число)- по сути, бит, признак миграции в эту базу.
2. Справочник "правила миграции", структура: "тип" - "вид "-"реквизит"-"значение реквизита"-"индекс"
При записи документа в зависимости от соответствия реквизит-значение делает "бинарное или" с индексом миграции документа.
По-идее, надо это делать через перехват, но у меня типа память потекла, пришлось вручную везде вызывать.
3. Индекс миграции - общий реквизит с отбором в общем журнале.
4. триггер (на даунлоадс) или DTS-пакет, который удаляет из апдейтса записи об объектах, которые не имеют установленного для базы бита.
дополнительно - кнопка и обработка в документах и справочниках, позволяющая юзверю самостоятельно установить нужную миграцию.
-----------
преимущества - настройка "на лету", гибкость.
недостатки - связаны с исправлениями докуиентов таким образом, что меняется правило миграции. в таких случаях "неправильные версии" остаются в периферийках.

(0) УРИБ
Правда у меня так и не дошло до внедрения. Клиент передумал

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

(12) Как-то не совсем комильфо - безопасность.

вы говорите про безопасность в 7.7 ;)

(15) это хорошо, если упадет центральная ;) ну если у вас все так сложно, тогда лучше не использовать 7.7. выбрать соответствующую задачам платформу.

(17) Молчу-молчу.

(17) Да, а что? :-)
(18) про бекапы - в курсе? :-)
платформа 7.7 вполне соответствует задачам. :-))

(20) То, что любой юзер с любыми ограничениями прав доступа может просто грохнуть все данные и об этом даже в логе не будет никаких записей, не мешает говорить о безопасности в 7.7?

То, что первая ссылка в поисковике "Как обойти пароль в 1С7?" рассказывает об удалении users.dbf, а втроая содержит ссылку на специальный 1Cv7.exe, который позволяет войти в 1С под любым пользователем без пароля, тоже не мешает?

Да уж, безопасность на уровне 2011 года...

+(21) users.usr конечно, утренний бес путает

++(21) Кстати да, то, что можно поддельным сообщением от дочернего узла полностью убить базу центрального узла, это тоже нормально?

(21) удаление users.usr решаемо -) То что вы позволяете запускать левые 1Cv7.exe это таки проблемы админские а не 1Ские -)
(23) "Поддельным сообщением" это каким? Правда не знаю -)

(21) вы в курсе, что удаление users.usr в сиквельных базах приводит к некоторым неожиданным для дятлов последствиям?
вы в курсе, что можно запрещать юзверям устанавливать приложения?
зы. дыр в 7.7 достаточно, однако многие затыкаются. весь вопрос - в соотношении радиусов.
(23) ровно это же я могу организовать и на "новой прогрессивной платформе"™

(24) например, отправить кривой md. Или команду на удаление объектов.

Кстати - слегка в сторону отошли. Сделать можно многое, вопрос в квалификации противника, трудозатратах и результате.
Полная копия базы, разосланная по всем филиалам, фактически делает базу достоянием общественности. Плюс увеличивает объем филиальной базы многократно. При этом все равно надо что-то дописывать. Не лучший путь.

(27) про "достояние общественности" - некотрый перегиб. Но и видеть "чужие" документы людям нефиг.

(28) В сотне филиалов крыса всегда найдется. И не поймешь потом, кто базу слил. И ломать ничего не надо - универсальные отчеты с ИТС все покажут.

(29) логично. только "универсальные отчеты с ИТС" тоже еще надо запустить...
безопасность не решается одной платформой. Это комплекс.
технологически,программно, организационно, административно...

(30) ИТС - любой студент франчевый. По крайней мере мере на порядки вероятней, чем что файл обмена будут курочить хитрючим образом.
Все имеет свою цену. Например, у моих клиентов конкуренты неоднократно сведения покупали. У самого низкооплачиваемого менеджерского звена. Потому что купить эти же сведения у программиста будет дороже в 3 раза.

(31) для того, чтобы запустить обработку с ИТС и поиметь данные - нужно
1) засунуть куда-то диск с ИТС, или флешку.
2) достучаться до этого места.
3) запустить оттуда.
4) куда-то сохранить результат.
5) как-то его изоткудато заполучить (на флешку-почту-диск)
6) остаться при этом незмеченным.

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

(33) ну, во-первых, такая инфа тут не приветствуется.
во-вторых, эти инструкции проканают в конторе "полтора землекопа".

(34) Давай сойдемся на том, что не передавать лишние данные правильнее, чем их прятать :)

(35) а что "сходиться". это и ежу понятно. основной закон безопасности - "отсутствующие данные нельзя украсть" :-)

+(36) пардон, "отсутствующие данные нельзя увидеть". Ну а уж украсть - тем более.

(25) 1. Сиквельных семерок видел в работе на порядок меньше, чем восьмерок. В основном потому, что требования к аппаратным ресурсам тоде отличаются на порядок.
2. 1Cv7.exe  не нужно устанавливать :-D. Запрешать флешки / сидюки / инет (даже http)? Запрещать скачивать файлы с равширением *.exe? Потенциальных возможностей получить этот файл у меня очень много, всего не предусмотришь...
3. Как на "новой прогрессивной платформе" заставить ЦБ принять изменения конфы от дочерней, имея доступ только к дочерней? Хотя бы в двух словах, по шагам. Хотя командой на удаление объектов можно конечно, это да.
4. Про запуск любой внешней обработки через "Файл-Открыть", которая сносит все справочники без контроля ссылочной целостности что сделаете? Вообще запретите пользователю скачивать любые файлы с интернета плюс запретите флешки и сидюки? Проще уж коммутатор выкинуть нахрен, и инфой через бумажки обмениваться)

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

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

(38) То, что в 1С7.7 сложно обеспечить безопасность данных - не повод выставлять их на всеобщее обозрение.

(38) угу, снеговик гораздо прожорливей клюшек. поэтому там, где снеговик без сиквела просто дохнет напрочь - клюшки пыхтят себе.
то, что ты видел сиквельных семерок меньше - говорит лишь о том, что _ты_ их видел меньше.
запрещать флешки, сдюки, скачивание *.exe нужно обязательно. Это азбука безопасности.
принимать изменения конфы в снеговике не пробовл, хотя когда копался в кишках - такую возможность обнаруживал (ну или по крайней мере, так мне показалось).
"файл-открыть" - проблема настолько давно известная, насколько давно известно и ее решение. Я, наверное, еще 1 раз 1с увидел, а решение уже предлагалось.
в принципе, действия по выполнению кода тоже можно предотврращать. Но проще минимизировать возможность выполнения.
(39) ага. Но можно разрешить сидюки-флешки, разрешить прием файлов, в т.ч. по аське и скайпу, отключить антивирь, дать всем админские права, убрать ограничения на доступ к сиквелу и гордиться "новой прогрессивной платформой"... правда, недолго...

(40) упадет центральная - после бэкапа полетят обмены. а вообще там много проблем, все не закроешь. на это потребуются такие бабки, что проще будет купить что-нибудь получше 7.7.

(41) Перевожу: все равно 7.7 УГ, поэтому можно делать что угодно и как угодно.

(41) "упадет центральная - после бэкапа полетят обмены" - это у вас, батенька, руки кривые...

5 лет работает урбд на рарус нефтебаза - ручной (только) обмен. Тут у друга замутил на 8.2 - постоянно траблы - поставили загрузку/выгрузку и автоматом обмен при закрытии программы - ладно бы при обновлениях все накрывалось - с этим поборолись - теперь вот бух жалуется что не видит половины доков и изменений в них - говорю - перепроводите почаще и там и там перед обменами.

(43) нет, чисто теоретические измышления... у меня ни разу не было. у соседа было, он мне жаловался, но я хз че у него там стряслось ;)

(44) кривизной твоих рук я уже восхищался...
(45) у меня падала ЦБ (давно, правда - и поднимал я). И ПБ падала. Недавно совсем. Подняли админы, без моего вмешательства. правда, чуть-чуть накосячили (пустили в базу раньше, чем надо, до обмена - и получили дублирование номеров у 2 документов) - но никаких проблем с "полетом обменов" не было.
зы. я устраивал проблемы - но это был мой, личный, рукотворный косяк :-)))

(46) В чем кривизна моих рук? За 5 лет НИ РАЗУ база не косячила при ручных обменах.

С умом надо к работе подходить  - а с 8-2 я только только начал разбираться -литературы ноль - кого ни спроси - все на терминале удаленно юзают - где ж опыту набраться то? Вот и домысливаю - что раз у меня "лечиться" в 7.7 путем перепроведения или изменения конфы - то значит и в 8-2 должно так же все выправиться .

Попытаюсь подитожить (извиняюсь перед ТС, что ушли в сторону).
Основные варианты:
1. Делать пустые заготовки документов в ПБ.
Преимущества: ничего не надо менять в конфигурации, только аккуратно выполнять инструкции. Недостатки: с виду не совсем красиво, но потом все привыкнут.
2. Передавать все документы, на точках запрет на открытие "чужих".
Преимущества: минимум кода. Недостатки: точки содержат не предназначенную для них информацию, представляющую коммерческую ценность. Объем базы, в зависимости от количества точек, может быть неоправданно увеличен.
3. Ручная регистрация изменений путем навешивания триггеров.
Преимущества: отстуствие недостатков п.1 и 2.
Недостатки: по-видимому, требует SQL и ВК. Также при смене склада-получателя остается документ в предыдущей точке.
4. Править updts перед обменом.
Преимущества: не требует изменения конфигурации (можно внешней обработкой) + преимущества п.3.
Недостатки:недостатки п.3 + меньший автоматизм = человеческий фактор.
5. Править файл обмена

Наколхозил сабж на основе обработки от Mikeware, причем и на скуле и на дбф. Т-т-т - вроде работает.

(50) с индексами апдейтса в файловой версии проблем не было?

(51) не на всех базах и не всегда, но бывает

1. Делать пустые заготовки документов в ПБ.
ИМХО самый правильный вариант.
"Пустышки" можно держать хоть всех видов док.
В ЦИБ при проведении документа поджлежащего отправке в ПИБ, дергать "пустышку" заполнять ее и она (бывшая пустышка) уже штатно отмигрирует в ПИБ где создаст нужные движения.

В общем случае нужно
1. Справочник ИБ
2. В каждом таком документе нужны два реквизита (ИБ источнк ИБ назначения)
3. Справочник свободных пустышек
4. Доработать модули проведения доков

Через незаполненные документы-"болванки", получаемые из другой(-их) ПБ.

(53)(54) а если миграция в несколько баз?
Или по нескольким условиям?

Спасибо всем кто откликнулся, буду изучать и мыслить..

варианты с пустыми болванками в ПБ/ЦБ - не катят, просто не катят ввиду приумножения ненужных сущностей

(57) Ну почему же сразу "ненужные сущности"? вариант вполне рабочий, только куцый. И гибкость значительно ниже.

(55) ? Смысл отправлять один! документ в разные ПБ? Поясни.
(57) ИМХО Допиливание штатного механизма обменов прямыми запросами - ненужная сущность.
(58) нашет гибкости и куцости - зря! можно малой кровью реализовать очень гибкий+надежный+прозрачный механизм

(55) если миграция в несколько баз?
ну сделай реквизит не ИБ получатель, а список ИБ получателей, дерни нужные пустышки по ИБ создания, веерно зазойдется всем. Только зачем? Что такой документ источник должен двинуть в ЦИБЕ и какая логика формирования движений в ПИБах в этом случае?
(57) почему приумножения? держи в ЦИБе фиксированное количество "пустышек" нужных видов. Которо также посредством УРИБ и восполняй. Если у тебя тысячи РНК, не думаю, что сотня документов датированных началом времен сильно напрягут

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

(0)поставь МОД..

(61) для изменения маршрута миграции
УРИБ = одноуровневая звезда, какой маршрут миграции?
>> жесткой прописке списка - надо будет менять конфигурацию
Это реквизит - список значений, зачем менять конфигурацию?
>> лишней кучи документов
нет никакой лишенй кучи документо, мигрируют только те объект которые определил к миграции пользователь. Пустышки восполняются, т.е напрмер определили что из дожно быть 100, при очередно сеансе израсходовали 10, вот 10 и восполняться.

(62) Отдельная песня. Только ради случая в (0) явно смысла нет.

(61)
1. Триггер нажно настраивать и ПИБах?
2. В БДФном варианте не беудет работать
3. Триггер срабатывает при апдейте апдтс, смотрит в справочник и если что удаляет запись из таблицы регистрации?

Мой вариант укладывается в штатную логику УРДБ. О твоем механизме УРБД ничего не знает, получается, что 1Сина с упорством маньяка пытается, что-то отправить, СКУль ей не дает. ИМХО как-то кривовато.

(63) УРИБ может быть не только звездой.
даже при звезде - маршрут миграции может быть весьма непростой - например, документ, созданный в любой базе (например, сегодня заявки от этого клиента принял центральный офис)  должен уйти в филиал (ПБ1), непосредственно работающий с данным клиентом (для условий контроля взаиморасчетов и прочего), и _конкретно_эта_заявка_уйти в филиал ПБ2, со склада которого будет отгружаться эта заявка... Причем такое может быть несистематически.
нарисуй, какие правила миграции должны быть у документов, если в базе 6  перифериек.

УРИБ в 8 да
в 77 - штатно нет!

(67) я не знаю слова "штатно" - я знаю слово "может" :-)

(67) сорри, посмотрел в личку. Оказывается, ты - франч. камплЕксный ахтунгматизатор. все вопросы сняты...

Да какя разница 6 пибов или 100, у меня их 120, пердложенный вариант - повсеместно происходт.
Обмен подобными документами влюбом случае через ЦИБ (миграция МСЦ), да есть запаздывание, но и товар между филиалами не телепортируется.
>>например, документ, созданный в любой базе:
В документах, как я уже говорил есть два реквизита ИБУ и ИБП, если они различаются - объект должен мигрировать.
Если ПИБ1 оправляет докуент ПИБ2 то влюбом случае транзит выполняет циб! т.е. из ПИБ1 этот док ШТАТНО! придет в циб, в ЦИБЕ регламентно перед обменом запускается обработка которая по известной логике создаст и переправит док в ПИБ2

или у тебЯ ПИБы ведут файловый обмен между собой минуя ЦИБ?
:)

Основной плюс ИМХО моего предложения как раз в его штатности реализации

(69) ты - франч.

не был никогда и никогда не буду! С чего ты взял?

Сайт :) дык это не мой:) попросили разместить ссылку в качестве рекламы.

(71) а реклама франча, это что ?
Восхваление покровителя ?
:)))

(72) http://lurkmore.ru/У_моей_подруги_с_её_парнем

(74) ну пипец прям пристыдил.
Повторюсь, в связях порочащик себя с франчами замечен не был. Деятельность моя никогда никак не связана даже близко с фрачами.

(65) "...1Сина с упорством маньяка пытается, что-то отправить, СКУль ей не дает. ИМХО как-то кривовато." С чего ты решил, что с упорством маньяка??? Она даже и понятия не имеет, что ей надо что-то выгружать. Раскури тему хоть немножко и поймешь насколько это хорошо.

"Кривовато" - это в (53) и "ИМХО" упомянутое там ну оооочень большое.

(75)
Работа у франчайзи + и -

тут тоже, ради праздного интереса спрашивал ?
:)

(70) либо я тупой и не понял твоего полета мысли, либо твоя схема не работает, раз ты не можешь объяснить.
еще раз задаю вопрос: нарисуй схему создания заготовок для 6ПБ, если типичный вариант - заявка создается в ПБ1, отгружается с ПБ2, но _внезапно_возможен вариант, когда заявка клиента базы ПБ1 (которая ведет клиента) принимается в ПБ2, но отгружается с ПБ3.
---
(65)фраза  "1Сина с упорством маньяка пытается, что-то отправить, СКУль ей не дает" лишь констатирует твое непонимание механизма работы УРБД

(77) Тебе интересен мой жизненный путь?
тема от 2007 в тот момент работал в холдинге, который перекупал более крупный холдинг, ясности с друдоустройством не было вот и ислледовал возможные варианты.

(77) Чел спросил 4 года назад. 7.7 давно померла, а народ еще спорит :)

(80) насчет "померла" - явное преувеличение. Убивают - и то убить не могут...

(78) давай без сарказма типа полет мысли, ит.д. я тупой и т.п. не надо - еще раз задаю вопрос, я не на допросе.

Схема работает работает много лет, если есть интерес могу пояснить без проблем.

Твой пример:
нарисуй схему создания заготовок для 6ПБ

1. количество ПБ не имеет значения.
Поясняю:

В конф есть справочник, например "ПустыеДокументы", три реквизита: КодИБ (Строка(3)),ВидДокП (Сктрока),ДокП (Документ) - ссылка на пустышку. Миграция МСЦ

ЦИБ
Поскольку транзиный обмен выполняется в ЦИБе, регламентно перед выгрузкой, обработкой, которая дергает, заполняет нужные пустышки (расходует). Израсходовав пустышку элемент в спр (напрмер) помечает на удаление. С обменом в ПИБ отмигрируют и элементы этого справочника.

ПИБ
В процедуре ПриНачалеРаботыСистемы срабатывает прцедура, которая смотрит в справочник, видит, что в ЦИБе израсходовли n пустышек и помечает к отправке нужное кол-во док.

(82) Прикольно. Регистр с измерениями ПиБ и ВидДок и с ресурсом Кол-во пустышек надо заводить :)
Верю, что работает годами с минимальными доделками. И некрасиво только с точки зрения программиста. А привыкшим менеджерам поф.

заявка создается в ПБ1, отгружается с ПБ2

ПБ1
В документе ИБУ(ПБ1) И ИБП(ПБ2) различаются, т.е. документ должен отмигрировать

В ПБ1 выполняют обмен с ЦИБ, документ приехал в ЦИБ

ЦИБ
запускается обработка обработки мигрирующих документов
Она (обработка) дойдя по этой заявки видит - по реквизиту документа ИБП в справочнике ПустыеДокументы по связке  реквизитов КодИБ + Вид, дергает по ссылке (реквизит документ) нужню  пустышку, заполняет ее проводит (если нужно).
Выгрузка обмена

ПБ2
при загрузке обмена получает заявку из ПБ1
При входе в 1с в режиме предприятия помечает к миграции пустышку нужного вида

(81) Скажем так - развитие прекратили и 7.7 отмирает естественным путем. Сотни предприятий еще несколько лет проработают с управленческим учетом на 7.7, а фискальный через пару лет только на 8 будет. Наверное.

>> Регистр с измерениями ПиБ и ВидДок и с ресурсом Кол-во пустышек надо заводить

Можно, но зачем? проще определить констнту - кол-во пустышек для всех видов (подобные миграции ПИБ1 - ПИБ2) все же не имеют массового характера у нас при 120 филиалах, опытным путем выявили, что максимум!!! это 200 документов пустышек на каждый вид документов для которых возможна горизонтальная миграция.

(85) эту песню поют все франчи со времён появления 8.0

>>И некрасиво только с точки зрения программиста.
Обоснуй

ИМХО, очень даже красиво, гибко, правильно

(87) ну прямо франче ненавистник
Какой-то из франей тебя уволил? без выплаты ЗП?

(84) Я опять не понял.
1. какие правила миграции пустышек? Место создания и центр?
2.Если "пустышка" заполняется - получается _два_ документа?
нахрена "обработка обработки мигрирующих документов"?

(85) фискальный учет - согласен.

(88) Открываю общий журнал за 01.01.1913 и вижу 100 тысяч пустых непроведенных документов (100 точек * 10 видов документов * 100 пустышек на каждый вид про запас).
Я же не говорю, что это плохое решение. Просто непривычное.
К тому же наверняка при вводе документа сначала в обработке заполняется шапка, затем находится пустышка, заполняется ее шапка и открыватся уже эта пустышка.

(92) а ты не открывай - и мешать не будут :-)

1. какие правила миграции пустышек? Место создания и центр?
- Место создания и центр

>>Если "пустышка" заполняется - получается _два_ документа? - Да но создаются они в ЦИБЕ. Ты загрузил обмен из ПБ1, объект источникпоявился в ЦИБЕ, как ЦИБ должен заполнить пустышку? При загрузке обмена этого сделать невозможно.
>>нахрена "обработка обработки мигрирующих документов"?
Для заполнения пустышек из документа источника

В какой момент должна заполниться пустышка? В ЦИБ!?
Кто ее (пустышку) должен заполнить?

Пустышка заполняется в ЦИБЕ! Документ (ПБ1-ПБ2) создается в ПИБЕ, в ПИБЕ с пустышками ничего (кроме из пересылки в ЦИБ) не выполянется.

(92) Можно определить свое кол-во пустышек для каждого вида

Можно.... Но ПРОЩЕ определить констнту

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

(94) пардон, и нахрена мне _два_ документа?
Если после создания изменили первый - второй так и останется неизмененным. я уж не говорю про сквозной контроль изменений, отслеживание статусов и тому подобное.
Ну и так далее...
Решение как минимум - кривое.

+(97) в данном случае даже без исправлений задвоение документа, скажем, реализации, в ЦБ как минимум сделает двойные движения.

(97) По-моему, Вы недопоняли (или я - такое тоже бывает).
Пустые непроведенные документы создаются в "дочках". По правилу миграции "место создания - центр" отправляются в центр. Там редактируются и отправляются обратно в "дочку". "Дочка" только отслеживает оставшееся количество пустышек и при необходимости создает.

(97) пардон, так у тебя для всех объектов миграция ВСЕ ИБ?
Так это твое решение кривое.

+ поясни как ты реализуешь проведение при горизонтальной миграции

Пример: ПБ1 отправил деньги в ПБ2

В ПБ1 -
В ПБ2 +
В ЦБ Что должен двинуть твой документ?

Как ты планируешь генерить НОВЫЕ ПИБ? при миграции ВСЕ ИБ?
Сгенерил ПИБ, потом в нем убиваешь все документы других филиалов? Или как любитель всего нештатного правишь файл с первичной выгрузкой в которую, так уж сложилось, что попадут ВСЕ объекты с миграцией ВСЕ ИБ?

И я так и не увидел ответа? В ПИБах твой триггер+справчник нудно настраивать?

(99) - аллллилуйяяя

(101) Похоже, самый глупый тут я? Что Вы имели в виду?

(99) но в ЦИБе действиельно будет два документа

(99) по его схеме для миграции из одной ПБ в другую необходимо заполнить "пустышку" из "другой" данными документа, пришедшего из "первой".  Итого получаем в ЦБ два одинаковых документа.
(100) пример- сделали заявку в ПБ2, для отгрузки с ПБ3. все документы эти (заявка+реализация) нужно отправить для контроля в ПБ1. Сколько документов будет в ЦБ, и сколько движений будет по складу?

(100) если схема - "звезда", то в ПБ ничего трогать не нужно.
Впрочем, там и так ничего трогать не нужно - все триггеры создаются автоматически.
Если снежинка - то, триггер нужен. Но создается он автоматически.

(105) все триггеры создаются автоматически
кто интересно самописный триггер создаст автоматически?

одну "пустышку" из "другой"

не так - не происходит заполнения пустышки из пустышки, это как минимум не логично?

В ПБ1 создали документ, он отмигрировал в ЦБ
В ЦБ на основе этого документа и пустышки ПБ2 создан клон документа ПБ1, но уже с ИБ создания ПБ2

Документ из ЦИБ отправился в ПБ2

Резюме:
ПБ1 - один документ
ПБ2 - один документ
ЦБ - два документа

(103,104) Тогда извиняюсь. Я рассматривал только узкую постановку вопроса - как спросил ТС. А Вы стали обсуждать обмен между "дочками". В такой постановке решение DenIv сильно притянуто за уши - правка UPDTS будет намного "кошернее".

(100) все ИБ генерятся клонированием. для 55Г базы - это 10 минут.
удаление документов - по правилам (справочнику) миграции. как правило, 20-40 минут.
"правила миграции 1С" - все ИБ.

АКУЕТЬ!!!

(108) ну Вы меня удивляете дружно
Как может быть решение построеннное на штатном обмене с использованием штатным механизмов - притянутым за уши?
>>
правка UPDTS будет намного "кошернее". не будет кошернее хотябы потому что вопреки здравой логике ВСЕ объекты должны быть с миграцие ВСЕ ИБ! иначе вариант Mikeware не работает для горизонтальной миграции.
Как уже говорил, 1С с упорством маньяка пытается что-то разослать, СКУЛь с не меньшим упорством 1Сине это сделать не дает + генерация ПИБов хромает + в ДБФном варианте не работает и Вы мне говорите про криво???

И самое главное гризонтальный обмен один хрен идет через ЦИБ.

Принципиально - наличие двух документов в ЦИБе? повторюсь таких документов по сравнению с общим документоооборотом менее 5%, иначе наличие ПИба ставиться под сомнение.

Изврешенное у Вас тогда представление о правильности

(106) "ты не поверишь"© - создает 1С.
(107) что и требовалось доказать. в ЦБ получаем дубли. Т.е. решение не просто кривое - оно еще и поганое.
(100) по примеру - во всех трех базах движения, сделанные документом, будут одинаковыми и в единственном экземпляре. И документ будет единый. И ШК у него будет единый. И историю работы с документом во всех трех базах можно посмотреть.

>> все ИБ генерятся клонированием.
клонированием чего??

(112) брэд

(109) кривизна на кривизне, скажи мне нах тогда вообще использовать УРБД?
принципиальная разница подходов: в моем варианте штатный механизм работает ШТАТНО без изменения заложенной в него логики.
В твоем варианте затычка на затычке, триггеры, которые создает 1с, которые не работают в дбфном варианте, миграция объектов все ИБ, создание ПИБов, клонирование чегото, с последующим удалением объектов.

И ты мне втираешь про кривизну? В твоем варианте миллион возможных точек отказа, определить источник возникновения проблем тоже ИМХО сложно будет.

(109) изнасиловали и 1С и УРБД и СКУль

(112) >>И историю работы с документом во всех трех базах можно посмотреть.

А что я гдето сказал что в моем подходе это запрещено?

ну так в итоге: создали в ЦБ документ ПоступлениеТМЦ с реквизитами (Фирма25, Склад25) - получится сделать так, чтобы этот документ попал ТОЛЬКО на точку25...?

(112) по примеру - во всех трех базах движения, сделанные документом, будут одинаковыми

Движения в трех БД в  могут быть не одинаковыми, вернее не так формироваться по разно логике в зависимости от места проведения документа.

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

(111) ты не понимаешь механизма работы УРБД. если б понимал - не писал бы такую чухню.
(114) никакой кривизны нет. просто дополняется штатный механизм, со всей своей логикой. без всяких дублированмй, "обработок обработки", работает совершенно автоматически, настраивается пользователем и т.п.
никакого миллиона точек - нет. точка всего одна. и я ее упомянул. И даже она легко контролируется - админу прилетает сообщение.

(117)Возможно  :)
читай свой пост - ассматривалось два подхода, каждый детально разжован. Выбор варианта реализации за тобой

(117) "Но инструктор - парень дока.
Деловой - попробуй срежь.
И опять пошла морока
Про коварный зарубеж"
Боюсь уже советовать :)

(117) как 2 пальца, но только учти одно -  вариант с пустышками - это для очень маленькой базы.

не.. сорри, я еще не изучил досконально.. спасибо всем, буду изучать (раз резюмировали что возможно)...

(122) с пустышками - мне принципиально не нравится такой вариант

чистить таблицу обмена - ещё не предлагали?

(122) Для (0) вариант с пустышками можно сделать без наворотов (из-за котрых сыр-бор и разгорелся). ТС обмен между дочками не нужен.

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

(125) если такое возможно для реализации поставленного вопроса - то скорее всего после изучени яподробно всей ветки - по такому пути пойду.

(122) имхо, тут размер базы пофиг.

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

(119) Завышеная у тебя самооценка
1. Твой вариант не нетленка, ничего нового или революционного в нем нет
2. Не тебе оценивать мои знания, УРБД, так же не откровение для меня и изуче вдоль и поперек.

(122) Для очень маленькой базы? Ты как вычичлил? У меня размер ЦИБ 1,5 ТБ (при 120 ПИБах), и не из-за пустышек и дублей поверь, это менее 1% на ЦИБ.

Второй вариант работает (если верить автору) на 6 ПИБах

(130) не стоит рассогласовывать движения.

(125,128) в (9) указана простейшая и наиболее элегантная реализация (потому, что моя). Можно на триггерах, можно внешней обработкой перед выгрузкой.

(130) см. (118)

(131) 1.я и не говорил, что это нетленка. и механизмы работы - я брал из публикаций.
2. Твоя фраза "1С с упорством маньяка пытается что-то разослать, СКУЛь с не меньшим упорством 1Сине это сделать не дает + генерация ПИБов хромает" - говорит о полном непонимании механизма работы УРБД. Не того, что написано в ЖКК,  а того, что происходит при работе. Впрочем, и сиквела, похоже - тоже.

(134) Таки да.

(127) достаточно подкорректировать один из них,
запещено програмно, кода 5 строк в ПриОткрытии.
пользователь отправки/приемки документа не может его скорректировать, возможно скорректировать только в ЦИБе ответственным сотрудником в чьей зоне ответственности филиал

(137)Т.е. в пределах открытого дня он не может трогать _свой_ неутвержденный документ? только через центр?  зачетно....

>>рит о полном непонимании механизма работы УРБД
В таком случае это говорит о непонимании твое реализации.

Поправь, изменения объекта с миграцией ВсеИБ в _1SUPDTS создает записей по количеству ПИБов, далее поскольку полшел апдейт таблицы, срабатывает твой триггер который на основании правил определенных в твоем служебном справочнике определяет какие записи остаются а какие то удаляются.

Что здесь свиддетельствует о моем не понимании механизмов УРБД? Ситуация когда УРБД записи создает, а твоя заглушка часть записей убивает не напоминает -

1С с упорством маньяка пытается что-то разослать, СКУЛь с не меньшим упорством 1Сине это сделать не дает ?

(137) и тебе звонят в центр 120 чортов и грят - отредактируй нам документ ?

Т.е. в пределах открытого дня он не может трогать _свой_ неутвержденный документ?

Документ, который уже отмигрировал в ЦИБ!!!!! не может быть не утвержденным.

Походу ты чета сам тупишь

(141) если его надо отредактировать, всё, привет котёнку ?
Все 120 Пибов в центр звонят ?

(138,140) Да, многовато допущений. Работать это работает, но рекомендовать другим...

(140) мне они не звонят, есть фин менеджеры по направлениям, коррекция документов их зона ответственности

филиалы обмениваются документами, но по сравнению с их дневным документооборотом количество документов с горизонтальной миграцие крайне мало! Количество исправлений то же не зашкаливает!
Еще раз повторюсь, что документы нельзя корректировать после отправки их в ЦИБ и это логично.

(143) я не рекламирую, не продаю, решение, с чего ты взял, что мне нужны твои рекомендации?

Смотри шире в 1С, тем более в 77, тем более в УРИБ огромное количество докпущений и без моего участия.

Да и что ты иммеешь в виду под допущениями? У нас например движение денег сммежду филями жестко контролируют фин.менеджеры, так что реализованные "допущения" выполненны именно по их ТЗ.

(139) 1с не пытается что-то отослать, тем более "с упорством маньяка". Она просто регистрирует документ для отсылки. триггер (можно, впрочем, после записи удалять) просто реализует дополнительный метод - "ОтменитьРегистрациюДляОтправки()", и все.
отсылает _зарегистрированные_ объекты сама 1с, совершенно штатно, без "упортсва маньяка" и без всяких помех со стороны "СКУЛя", без вмешательства операторов, без запуска "обработок обработки обработок" и прочего. И делает это у меня каждые 30 минут. уже лет 5 в режиме 24*7 с перерывом только на 1 января.
(141) документ, ушедший автообменом в центр, вполне может быть не то, что неутвержденным - а даже непроведенным. Заготовкой. Его уже записали, но еще не провели. Он открыт, и при этом в него активно вносятся исправления.
(144) это нихрена не логично.
зы.кстати, как ты определяешь, что документ ушел в ЦБ? И не просто ушел, но и получен? очередной нетленной "обработкой обработки обработок"?
ззы. и обмены у тебя, похоже, в полуручном режиме...

(145) ааааааааа - сколько раз давал себе слово не вступать в религиозные споры. Ухожу из ветки.
(0) Если (9) интересует - там работы на 5 минут (если есть 1С++ и скуль). Можешь стукнуться в аську и на копии опробовать.

(142) а ситуация когда звонит манагер и говоит, что вот вчера у меня в этом документе были другие цифры, кто его пменял???! всех порвать - не знакома?

Пойди объясни ему, что утвержденный документ поменяла в бобруйске тетя Маша, потому что период открыт, да еще проанализируй журнал (120 ПИБов ~ шлют по 7тыс док от каждого в деь) что бы выяснить что же за ПИБ породил изменения...

(145) нет там никаких "допущений". Простой и вполне понятный механизм. Достаточно простой. Да, активно не хватает некоторых функций. вот их и реализовали.

(148) а у меня менеджер давит на кнопочку "история", и видит - какая "тетя маша" с этим документом "что", "когда" и "где" делала. а если документ в закрытом периоде - то еще и "почему".

(148) как ты определяешь, что документ ушел в центр и там принят ? Как ты ставишь флаг, что изменять документ в ПБ нельзя уже ?

(151) сделать триггером - легко :-)

(146) регистрация объекта в таблице регистрации изменений - в моем понимании и есть попытка отправки
С упорством маньяка, потому что при миграции все ИБ и большем кол-ве ПИБов породит множество записей, тогда как твои правила могут быть справедливы только для одного получаля. Т.о. 1С создаст 120 записей, триггер убьет 119, ну разве не маниакальная борьба механизмов?
>>отсылает _зарегистрированные_ объекты сама 1с, совершенно штатно, без "упортсва маньяка" и без всяких помех со стороны "СКУЛя",

не нужно передергивать про отсылку я слова не говорил, ты мне еще вмени непонимание работы зип архиватора и почтового клиента и скажи, что я сказал, о том что СКУЛь им мешает

>>
И делает это у меня каждые 30 минут. уже лет 5 в режиме 24*7 с перерывом только на 1 января.

горжусь тобой, только и мой механизм без сбойно работает с тех же времен (на большем кол-ве ПИБов) и так же без сбойно

(152) автор же этим не пользуется, у него всё "штатно"..
вот и хочу узнать, как он делает запрет на правку, если "документ уехал в ЦБ"

(150) думаешь сложно у меня по другому?
Только вот - если документ в закрытом периоде, и тетя Маша без ведома манагера изменила документ в ПИБе - уволят и меня и тетю Машу, не должно быть таких возможностей!
На вопросы Почему моя кнопка не ответит ИИ я еще не осилил

(155) еще раз, как ты делаешь запрет на правку документа?
Как ты определяешь, что документ улетел в ЦБ ?
Как определяешь, что он там принялся ?

+156 хранишь всё ЭТО в своём справочнике и всегда его опрашиваешь ?
Или что ?..

(152) Что плогхого в этом подходе? Если ты думаешь что я ограничен только штатными методами - заблуждаешься! Твой подход- уперся во что-то давай латать дыры прямыми запросами накачаем кучу ВК, а подумать, может ничего и не нужно лишнего уже мозга не хватает?

(158) мот на (156,157) ответишь ?

(153) не вижу никакой маниакальной борьбы.
я даже говорил, что знаю способ сделать "наоборот", чтоб регистрировала 1С. Когда-то у меня не получилось, а сейчас переделывать лень. в принципе, периодически возникающая лишняя сотня записей в апдейтсе - это сравнимо с сотней "пустышек", лежащих в базе - за маленьким исключением - им не нужны ресурсы идентификации 1С, база имеет меньше телодвижений при записи, не блокируется журнал, да и размер поменьше (26 байт :-D).
(158) я не "латаю дыры", я делаю нормальный инструмент. Мне не хватало функции - я ее сделал (точнее, там несколько функций). Не творю чрезжо-пицу (по крайней мере, в этом конкретном случае :-D). А уж через ВК или не через ВК - вторично. К тому же, если есть механизм - почему им не пользоваться? ты ж не пользуешься ручным разбором xml, если есть тот же v7plus? Однако, тоже ВК....

(160) я не "латаю дыры", - я не обвиняю тебя в этом, тот пост касался наездов Ёпрст3 и адресовался ему.

>>база имеет меньше телодвижений при записи, не блокируется журнал

Я же говорил, что операция проводиться перед отправкой обменов регламентно, на период под регламент ЦИБ мы забираем у пользователей (выгрузка загрузка обменов занимает при таком размере ЦИБ и кол-ве филей с 18-00 до 8-00 и только в притык). Поэтому блокировки Journ в данном случае не принципиальны т.к. ночью пользователей нет.

>>тот же v7plus? Однако, тоже ВК....
говорил про бездумное использование не штаных ср-в и ВК

Давайте завершим спорить, уже все ньюансы обоих методов обсудили.

Я не говорю о том, что один хуже другой лучше, плюсы и минусы есть и там и там. Принципиальную разницу разъяснил в

ТС - акцентировал вопрос :
Вопрос: как сделать ШТАТНО так, чтобы  ....

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

(161) Ёп на тебя не наезжал. он всего лишь задал вопрос.
зы. никто тебя (да и вообще кого-либо) не призывают использовать что-то "бездумно" Наеборот, как правило, пердлагают _подумать_...
ззы. странно - две ВК, созданные по одной и той же технологии, описанной в одном и том же документе, и вдруг одна "штатная", а вторая -  "нештатная" :-))

(162) ты о каких двух ВК и одном документе?

(161) 18 до 8..
Не, не катит.. у нас 24 нонстоп, выходной иногда - воскресенье и празднички, и то, не всегда.
:)

+164 на сколько я понял, в течении дня, пб с цб у вас не меняются, токма ночью..

(163) о ВК, которые ты обвинял в "нештатности", о v7plus.dll и о документе "Технология создания Внешних компонент" от ЗАО 1С.
Ответ на вопрос Ёп'а - будет? :-))

(164) Ну так у нас филиалы во всех часовых поясах и поддержка + оперативная работа тоже 24*7, только ЦИБ то тут причем?
(165) Да, по другому никак, не реально загнрузить обменов от филиалов на 200 (сжатых) на ЦИБе так что бы еще и пользователи работали, да еще и за 15 минут. Это не возможно! Прирос БД в сутки 2,5ГБ

(166) да я очень рад что она от ЗАО 1С, ты то ее как используешь при реализации своего мехханизма?
>>Ответ на вопрос Ёп'а - будет?
Кучи вариантов один из них он предложил Сам. Только не вижу смысла городить еще одну подсистему регистрации подверждений обменов, аналогичную УРБДшной.

У меня вариант административный, один создал, другой подвердил корректность и провел, если документ должен мигрировать горизонтально с момента проведения  считаем что он ушел в ЦИБ.

Ты мне тоже скажи как ты документы подверждаешь? Кнопочкой и изменением статуса в каком-то реквизите?

И в чем тогда разница с моим?

(168) Кучи вариантов ШТАТНЫХ, можно и не штатных наворотить, все ограничиватся только фантазией.

(165) У них ЦБ - не для работы. архив.

(168) т.е. фактически механизма подтверждения - нет. И если юзверь банально ошибся - исправления документа он получит через сутки (сегодня в ЦБ ушло, завтра там исправят и послезавтра оно в периферии). замечательно, ничего не скажешь...
Да, у меня подтверждение - изменением реквизита. С сохранением истории (и тайминга) - видно время обработки, пиковые нагрузки и тому подобное.

>>И если юзверь банально ошибся
Ну конечно, один банально ошибся другой банально подтвердил, третий банально не проверил.

Решай вопрос с неквалифицированными кадрами!

) т.е. фактически механизма подтверждения - нет.

Реализовывать не стали, не увидив в нем особого смысла, вернее трудозатраты выше чем польза от реализации

>>исправления документа он получит через сутки
ну почему же обнаружив ошибку выполняем вне регдаментный цикл обменов с уведомлением финменеджера ГО, иначе  получаем -
один банально ошибся другой банально подтвердил, третий банально не проверил.

Решай вопрос с неквалифицированными кадрами!
>>
С сохранением истории (и тайминга)  все есть в журнале регистрации, какой еще тайминг нужен?

(172) Вопросов нет можно реализовать и подсистему регистрации и хранение истории и черта лысого, не вижу НИКАКИХ сложностей, вопрос зачем?

в 10 раз повторяю это не основной функционал! межфилиальны взаиморасчеты - горизонтальная миграция несоизмеримо мала с основной опер деятельностью филиала - если филиал в день делает 10тыс. РНК и 10 документов горизонтиально мигрирующих
отправляя товар из Краснодара во Влалдивосток, и в 1-м документе ошибся у нас будет минимум 10 дней на исправление ситуации. Ну и скажи мне нах. я буду наворачивать еще функционал регистрации изменений/подтверждений утежеляя конфу в целом? Где логика?

(172) 1.когда второй подтвердил - третй у тебя уже не нужен.
квалифицированные кадры, конечно, - больной вопрос. но и обыкновенные ошибки (или несвоевременную регистрацию исправлений) никто не отменял, и избавиться от этого крайне сложно.
2. если у тебя нет механизма - так и говори.  не "мой механизм регистрации", а "нет механизма регистрации".
3. "внерегламентный цикл обменов" сколько займет? :-)
4. простой тайминг - Например, для товарного документа: во сколько документ поступил, кем первичная обработка, когда отдан  на склад, когда собран, когда подготовлен, когда отгружен, когда вышел с территории, когда вернулись документы, когда внесены финальные исправления.
(173) так и говори - "моя схема применима для частного случая, с кучей допущений": требует квалифицированного персонала, работает при обмене раз в сутки.

>>когда второй подтвердил - третй у тебя уже не нужен.
третий в ГО контролирует первых двух. В крупных организациях так куда деваться. он же третий в случае чего корректирует ошибки.

>> или несвоевременную регистрацию исправлений
Запрос финменеджеру ГО / исправление / сеанс обменов
не вижу проблемы. Невозможно написать универсальную и всемогущую защиту от дурака ошибки все равно будут.
>>если у тебя нет механизма - так и говори.
не припомню что бы я сказа где-то что он есть. не наговаривай. Штатный есть механизм регистрации пакетов УРБД и журнал регистрации 1С + подтверждение со сменой стуса + сохранение Автора в документе- ИМХО вполне достаточно на все случаи жизни.

>>"внерегламентный цикл обменов" сколько займет?
с одним филиалом - не много порядка 10 минут

>>так и говори - "моя схема применима для частного случая, с кучей допущений
ты вывод сдела на основании чего? Задача реализовать горизонтальную миграцию. Мой метод позволяет сделать штатными методами УРБД с минимумом доработок в 1С. Работат в промышленной эксплуатации. Никаких! Подчеркиваю никаких допущений ограничений не имеет.

Квлификация персонала вопрос риторический, твоими решениями пользуется кто алигофрены, кот. не отвечают за проделанные действия,нажимая на одну кнопу!? Или же нет есть универсалтная супер кнопка СдалатьВсе/ОтветитьНаВсе вопросы?

>>обмене раз в сутки.

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

уменьшая дельту времени между сеансами обменов ты какую цель приследуешь? Приблизиться к on-line? нУ ТАК ПРИ 6-ТИ ПИБах организуй всем RDP и забудь про УРБД. Тем более что штаный механизм тебе подходит только с кучей допущений.

(128) корректировка updts не впечатлила?

(175) 1.а кто контролирует третьего? четвертый? :-)
2. "не припомню что бы я сказа где-то что он есть. не наговаривай" - в (137)ты русскими буквами написал: "пользователь отправки/приемки документа не может его скорректировать, возможно скорректировать только в ЦИБе ответственным сотрудником в чьей зоне ответственности филиал", после чего тебе и начали задавать этот вопрос.
3. если цикл обмена с одним филиалом занимает 10 минут, то 120 филиалов займут 20 часов. У тебя ЦБ только на обмены работать и будет.
4. не олигофрены, но требования к квалификации несколько снижаются. поэтому и с подбором персонала проще, и с оплатой их труда тоже. Квалифицированных сотрудников надо меньше, а некритические ошибки может исправить сам пользователь в пределах компетенции. Или ответсвенный человек в филиале в течение дня - что, собственно, и происходит. никакого трехступенчатого утрерждения не нужно.
5. В общем случае чаще обмены - меньше размеры - быстрее обмены.  конечно, все нужно в пределах здравого смысла.
(176) Предлагаешь РДП? Ты когда-нибудь слышал про отказоустойчивость, не? поддержание резервных каналов связи, резервных серверов, резервных источников питания и т.п. - требует денег. при распределенке достигается меньшая вероятность отказа системы в целом.
А что касается штатного механизма УРБД, так он у меня и работает. просто с некоторыми дополнениями (добавлением двух функций, которые, в общем, могли бы и 1совцы добавить, но им влом), и все. И выбран штатный механизм именно из-за его устойчивоти и практически безглючности.

(178) удивляешь! нигде не видел схемы: оператор создал, менеджер подтвердил, руководитель проверил. Это слишком запредельная схема для тебя? не поверю что ты работал только в организациях только с операторами.
>> отправки/приемки ... провел считай отправил. Где здесь сказано, что разработана система подтверждений?
>> 20 часов ....
Да на регламент тратим 15 часов, 10 минут усредненное время, в чем наврал. 120 ПИБов не твои 6ть. Тем не менее 8-00 до 18-00 пользователи гарантированно работают с ЦИБ, а в оставщшееся время мы гарантированно выполняем регламент обменов. Что поделашь не расчитана 77 на такие объемы БД и кол-во узлов.

по п.5. согласен но не на больших БД и большом кол-ве филиалов

>> Ты когда-нибудь слышал про отказоустойчивость .....
не этим тайным знанием владеешь только ты видимо. Ты не внимательно прочитал  мой пост. речь шла про on-line режим. Гоняй тогда обмены не раз 30 мин а раз в 2-е, они еще меньше будут. Ты анализировал, нужны ли пользователям твоим данные из пиб-ов с такой частотой. У меня ПИБы есть по под 80 ГБ с 100-ней пользаков, как считаешь смогут они работать если я раз в пол-часа буду гонять обмены, да еще и с нарастающим размером файла и увиличением времени от сеанса к сеансу? РДП приводилось какраз в пример того что если наличие информации от ПИБов нужно практически в on-line, то варианты с УРБД вообще не катят. Ипох на затраты на отказоустойчивость.

>> добавлением двух функций..
ВК + триггеры во всех ИБ + Миграция для всех ВСЕ ИБ? и прямое удаление данных из БД?

них..евая пара функций

кроме тебя то в логике миграции в такой конфе так на вскидку посмотрев на конфигурацию кто-то сможет разобраться?

(180)
>>>
да любой вминяемый..там запрос то на пару строк всего для удаления лишнего.

(181) речь не про запрос.Уважаемый. ясен пень сам запрос элементарный.
Речь про то, что открыв конфу посмотрев на вариант миграции, нужно долго вкручивать почему он не попадает в файлы обменов и не мигрирует во все ПИБы, т.к. нужно догадатья, что может быть триггерочек который без ведома УРБД убивает "ненужные записи"

(182) ну дык что мешает его посмотреть ?
А думаешь, глядя в твою нетленку, кто-то догадается, что она плодит пустышки, потом какая-то поделка их заполняет и регистрирует для обмена ?

(180)1) через ВК - 1с++ - сделано очень многое. и отдельные формы выбора, и журналы со всякими отборами, и всякие привязки-сплиттеры-быстрые подборы-ограничения выборов, обработки с драг-н-дропом, олап-подобнве анализы данных, не говоря уж об отчетах. Это фактически уже стандартный инструмент для любого более-менее грамотного разработчика.
2)Триггер должен быть только в ЦБ. И создается автоматически, если его нет в базе и база - центральная. Никакого участия программиста или админа не нужно.
3)настройка правил миграции - в пользовательском режиме. Если при "беглом взгляде" на конфигурацию есть справочник ПравилаМиграции, есть справочник ИнформационныеБазы, связанный с ним, и у некоторых метаданных есть реквизит ИндексМиграции (ну, и функция УстановитьПравилоМиграции(), оперирующая с ними) - вменяемый разработчик скорее всего заподозрит, что это как-то связано с миграцией данных, не правда ли? :-)) А если найдет процедуру СоздатьТриггерДляМиграции - увидит и текст этого триггера.
если до него это не дойдет, то - извиняюсь - нахрен он нужен? Ну и я умирать пока не планирую. Даже если запланирую уходить - буду кому-то передавать дела (с документированием - да, у меня слабовато. ленивый я)
4)"навскидку" - скорее всего, никто не разберется. ровно так же, как и в твоей конфе. Но при вдумчивом подходе грамотный сотрудник - как показала практика - разбирается.

(184) Хреновая система. Ненадежная. Уйдещь в отпуск, придет разносчик ИТС и обновит до типовой. И кирдык твоим обменам.

(185) программист оборонять будет. вместе с админами...

(186) Я к тому, что DenIv одним из преимуществ своего метода аявил, что ничего править в конфе не надо. При этом конфа у него все равно переписана вдоль и поперек, так что это можно не считать серьезным преимуществом.

(185) чепуха какая-то. Это где ж разносчики конфу обновляют?? ДА ещё и клюшки!!  )))
(187) это выстрел в голову разрывной пулей, а не решение.

(187) я понял его заявления.
только он не говорил, что "править не надо" - у него как минимум одна константа добавлена :-)
ну, и проведение исправлено, "в зависимости от базы" :-)
(188) да пару дней назад тема была.... v7: При установке типового обновления затер чьи-то незнакомые изменения, как быть?

(185) бредятину-то не неси про разносчиков ИТС.
(187) где ты это вычитал? Я говорил о том, что все реализовано штатными методами 1С и без кромсания УРБД, без использования ВК и прямых запросов к СУБД. Конфа у меня управленческая самописная, нико ее не обновит до типовой поверь. Одноко, ничто не мешает добавить эту реализацию к Типовым никаких проблем нет в том числе и с обновлениями. Хотя искренне удивлюсь если ТиС еще поддерживается 1С. Ты не попутал ничего часом?
(188) ну предложи свое, "не разрывное решение", задним умом каждый горазд умничать...

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

(191) - > (189)
(189) Справочников у тебя должно быть не меньше двух.

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

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

(193) раз уж такая пьянка, то можно вообще и без запроса обойтись, нах...? давай прям из файла строчки резать (или добавлять кому что нужно), вообще ничего дорабатывать не придется!

(190) моё "неразрывнОе" решение - это правка файла updts. Решение внедряется в ЛЮБУЮ конфу ГОРАЗДО с меньшими усилиями, чем твои бредовые "штатные варианты". Безо всяких административных изменений в штатном расписании, когда изменить документы могут только выделенные начальники. Автообмен идет несколько раз в день БЕЗ какой либо привязки к ритму и логике работы в БД. НИЧЕГО не меняется в работе фирмы и БД. Какими буквами тебе написать, что все изменения ни на что не влияют?

з.ы. впрочем, что-либо тебе объяснять бесполезно. Дитор-2 детектед )))

(194) Кто мешает внешнюю обработку для редактирования таблички в нужном виде прикрутить?

"и вновь продолжается ср@ч...."
-------------------
(191) Не "кромсание", а "дописывание" - это разные вещи.
Добавляется два справочника и один реквизит, структура справочников, необходимая функция и логика работы описана в (13).

у меня база "в девичестве" была ТиСом. Но от типовой тоже осталось немного. Добавлено порядка 80 справочников. так что плюс-минус два справочника - особой роли не играют. :-)

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

такс.. вариантс пустышками - отметается нахрен. нежизненно в моих условиях.
.
остается модификациz 1Cupdts

(196) ты то  откуда нрисовался? мне твои объяснения без надобности. Свое "неразрывнОе" решение можешь засунуть себе же куда-нибудь глубоко.
Регламент обменов, кол-во доработок, административные действия. Тут не при делах! Т.к. относились к конкретному внедрению!
Для реализации общего решения требуется:
0. Два справочника
1. Доработка глобальной процедуры проведения документов
2. Доработка процедуры ПриНачалеРаботыСистемы

Второе решение требует также введения в конф. не менее двух спр.!!!

Горизонтальная миграция МОЖЕТ менять логику проведения документов по регистрам!!! Второе решение этого не учитывает! Либо так же потребуется доработка п.1

Бредовые решения не бредовые - вопрос веры и не тебе давать подобного рода оценки!

(200) странная логика? не важно какой вариант использовать с пустышками или с updts. Если документ в ЦИБ должен двигать одни регистры с одним знаком а ПИБ другие и с другим. не все ли равно как документ поал в ПИБ?

(201) При появлении в речи оппонента "анальных" мыслей можно констатировать его, оппонента, успешный слив. :) Продолжай бредить.

(0) Элементарные действия!
1) На перефирийке создается пустышка накладной
2) Делается выгрузка в центр
3) В центре заполняется и проводится
4) Делается выгрузка на перефирийку

Я так делаю простое премещение товара

+(204) Со склада на склад

(204) не поверишь, но многие считают это бредом! Бытует мнение что нужно обязательно апдэйтить updts.

(201) У ТС ДРУГОЙ вариант обмена. Вы, по-видимому, за 10 лет на своей самописке зациклились. Пора менять работу.

(203) Уважаемый "анальные" мысли возникли у тебя. Я ни слова не обранил на эту тему. Видимо больная  для Вас тема.

+207 Я не считаю Ваш алгоритм бредовым. А вот столь категоричное неприятие альтернативных решений гоаорит не в Вашу пользу.

(207) В процессе обсуждения задачи ТС вышли на обсуждение более сложного варианта.

(208) )))) Напиши ещё что-нибудь. Мы всем отделом смеёмся, ты такой прикольный! )))

(209) а где я говорил о принципиальном не приятии?
см. (161) цитирую:

Я не говорю о том, что один хуже другой лучше, плюсы и минусы есть и там и там.

(206) Использую и второй вариант
1) Написал обработку для ввода документа в виртуальный документ
2)ввожу его и передаю в нужную базу
3) Там он в автомате принимается и создается нужный документ - на клиенте!
4) Выгрузка в центральную базу.

Также создаю и элемонты справочников

(202) забавный ты... "окумент в ЦИБ должен двигать одни регистры с одним знаком а ПИБ другие и с другим." - это лулз. Грубо говоря, если в ЦБ принимают деньги по приходнику, то в кассу приходуется вся сумма, а если в ПБ - то половина? :-)
Я уж не говорю, что при этом при перепроведении документа в ЦБ - в периферию улетят движения, совершенно отличные от первоначальных...
ню-ню...

(214) Речь про горизонтальную миграцию между ПИБ1 и ПИБ2 через ЦИБ! млин. ну сколько можно объяснять!? Регистры одни и теже, виды движений разные.

Примеры уже приводились!

Ты можешь обсуждать, что либо без обсуждения личных качеств моей скромной персоны? Забавный я или нет к сути обсуждаемой темы не относится!
Да и кстати (209) по ходу в большей степени отностся к тебе.

(214) Один филиал отправил деньги другому.
В ПИБ1 должен быть расход.
в ПИБ2 приход.
В ЦИБе должна быть общая картина (и расход по одному филиалу и приход по другому)

можно не разделять движения конечно но тогда нужно городить некий (е)  доп регистры которые будут учитывать подобные движения. и один хрен требуется доработка логики проведения документов! только в этом случае нужно добавлять еще и новые объекты метаданных!

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

(217) см. (62)
:)

+218 будет всё, что ты хочешь и как хочешь.

(217) А есть ещё круче варианты, когда в одной базе ПБ движения одни, а в другой ПБ не то, что движения, но и документ должен быть другой, типа как в (216). А в ЦБ должны быть два документа но с движениями по другим регистрам или без движений. Только для экономии операторского времени они должны формироваться автоматически, так как это накладные на сотню позиций. А МД-ники (сами конфигурации)в ПБ и ЦБ разные, опять же для решения решения задач скрытности и уменьшения объемов записей в ПБ и ЦБ.
Так что думай очень-очень сильно.

(220) мне только не ясно почему варианты описанные(215)-(220),   Mikeware с сарказмом (забавный, нюню, - это лулз ...) не приемлет впринципе, для него эти ситации не возможны! ИМХО при 6-ти пибах и простейшем учете - да, что-то чуть сложнее -  - это лулз. как так?

(221) Да и не переживай ты так. Каждый знает, что ничего "универсального" в жизни нет. И что-нибудь "специальное" гораздо лучше "универсального". Далай скидку собеседнику на то, что он не владеет полнотой информации твоего случая.

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

варианты с пустышками - они претят моему чувству прекрасного... однако, если что и это - покатит.. тошнотно, но покатит...

(0)Т.е. а остатки они смотрят на одном складе (ЦБ) или во всех точках (других ПБ)?

Есть еще один способ.
Обмениваться всеми данными, но при старте программы просто очищать объекты по какому либо признаку. Например, по общему реквизиту (префиксу документов). Если документов немного и обмен раз в сутки, то в транзакции работает довольно шустро.

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

не претит твоему чувству прекрасного? может начать с выравнивания изначальной кривизны с постановкой учета? и уж только потом вернуться к этой теме

(223) а какого "фей-хоа" документы определяющие сущность операций одной ИБ (читай - участка учета) делаются в другой? Даже на основании какой-то заявки поставщику (или что-то типа плана поступления) из ЦБ реальное поступление должно делаться на месте реального приходования.

Именно подобные виртуальные операции и дают неразбериху, когда центр делает что-то за переферию, а потом всё это должно корректироваться по факту. Причем все это связано с кучей условностей, согласований и т.п. Или я неправильно ситуацию понял?

(225) на ЦБ - остатки по всем складам смотрят. на ПБ - ясен пень нужны СВОИ остатки.

(227) ясен пень претит моему чувству прекрасного.
я ж написал выше - выбранная схема (когда-то давно) привела к куче траблов.
.
В ПРИНЦИПЕ: на данный момент устраивает почти все, кроме длительного открытия периодов на точках и пересчета данных/первоначальной загрузки ПБ.
.

(228) ЦБ за периферию ничего не делает.
ЦБ документами перемещения с (ФИРМАЦБ, СКЛАДЦБ) передает товары на точки-ПБ (ФирмаN,СкладN). Точка по факту прибытия товара на точку проверяет его по перемещению (фиг с ним  считаем что перемещения не правятся, отклонения факта оформляются списаниями и оприходованиями).
.
в такой (изначально выбранной схеме) штатно без извратов правильный обмен построить не вижу возможным...

(231) Согласен, без извратов не получится.
Я ещё не встречал контор, которые работали бы на 1с и использовали только "штатные" механизмы. (Штатные - это те при которых ни одной строчки кода писать не приходится? Или какие?) Все считают себя самыми умными и придумывают собственные схемы работы. А менеджеры и бухгалтера, гуляющие из одной компании в другую, только усугбляют "неразбериху" документооборота.

(231) Тебе ещё не ставили задачу спрятать закупочные цены на ПБ, но при этом они должны сами следить за эффективностью своей работы?
Выведывай у них сразу всё, чего хотят добиться.

Вариант (53) - полная ерунда. Не буду описывать почему, тут уже достаточно написали, хотя и не все.

А вот вариант с правкой 1supdts более интересен, но: как при ведении партионного учета в ТиС будут мигрировать записи о партиях? Ведь есть партиобразующий документ принадлежащий другой ПИБ.

(216) 1.Если в одной точке для денег "только расход" - это уже не "перемещение", некое "списание денег"
2. если при перепроведении в ЦБ документ сделает два движения - эти же движения разлетятся и по пеиферийкам. "выборочная миграция движений" УРБДшкой не предусмотрена. Только МОД, либо самостоятельный обмен, например, через универсальный обмен данными в XML
(217) см.выше - МОД иди универсальый обмен XML. А вообще, один документ должен давать одинаковые результаты проведения.
если результаты должны быть разные - это надо реализовывать через дополнительный признак документа (вид операции, статус и т.п.)
(223) в этом случае лучше использовать транзитный склад, либо доп.регистр (типа, товары в пути) и отдельные операции (что методологически вроде правильней)
(220) опять же, МОД иди универсальый обмен XML
(233) "спрятать" - не проблема. Вопрос в объемах работ. ну и в методике "прятанья" - т.е. "не иметь" или "не видеть"

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

(236) Бесспорно, если у тебя "один кладовщик должен видеть, а другой - не должен", тут разруливать только правами. У меня сделано через роли - некий аналог восьмерочных. Хотя они тоже имеют привычку плодиться...

(237)Да так и есть, пытаюсь рулить правами. Только права это не те права, которые задаются в конфигураторе, а некоторые  справочники в программе (или базе данных, как угодно).

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

(235) Mikeware (234) - это тебе.

(232) - "штатные" - без использования ВК и прямого доступа к данным.
(239) - ничего против добавления новых объектов метаданных я не имею, и нигде об этом не верещал. Я говорил о том, что в твоем случае, что в моем минимум добавлений - это два справочника и в этой части решения абсолютно аналогичны.
Все!
Уважаемый... ну не передергивайте... Читайте (190) цитирую себя же:
Конфа у меня управленческая самописная, нико ее не обновит до типовой поверь. Одноко, ничто не мешает добавить эту реализацию к Типовым никаких проблем нет в том числе и с обновлениями. Хотя искренне удивлюсь если ТиС еще поддерживается 1С. Ты не попутал ничего часом?

(234) Еще один вершитель судеб! Истина в последней инстанции. Открою тебе секрет, метод эизнеспособен и обратного, нкто здесь не докузал. Только субъективные мнения - типа претит чувству прекрасного...
(235) Перепроведении ЦБ - ты меня пугаешь! Что случиться с ГП в перифериях! Да еще и при твоих Миграция все ИБ!!!!

(240) Ты опять хочешь их завести?
(239) Да нам завести ещё несколько справочников как два пальца ... Мы легких путей не ищем.
Я вполне допускаю, что вариант DenIv рабочий (он же на нем работает), но для ТС советую сначала получить побольше информации о том, что в итоге должно получиться. Во время разговоров с постановщиками (бухгалтерами, менеджерами, кем угодно) они и сами начинают маленько задумаваться над тем, что же они хотят. Во всяком случае, будут предупреждены о некоторых сложностях и последствиях.

(240) Ничего страшного не происходит.
ну, есть в партии ссылка на документ, а документа нет - какие проблемы-то? это только в украинских типовых, да в ТиС 8.7 сортировка для списания была по дате партиеобразующего документа. сейчас - партиеобразующий док - не более, чем свойство партии.
сейчас гланул - да, минрируют все партии. (ну, раздувается справочник, ничего особо криминального) при автообрезке партии, не имеющиие движений - удаляются.

(241) механизм создания внешних компонент - совершенно штатный, описаный самой фирмой 1С. Чего нештатного в применении ВК?
Прямой доступ - да, фирмой 1С не санкционирован. Но по сути, это исправления косяков 1с. При грамотном и вменяемом подходе - не несет никаких отрицательных эффектов - только положительные.

(244) Использование ВК сторонних разработчиков - претит моему чувству прекрасного :) Про свои я ничего не говорил, я их классифицирую как "штатные"
(243) т.е. актуальность итогов не зависит от ГП?

(243) себестоимость не расчитывается в твоем ТИСе?

(241) перепроведение документа в ЦБ у тебя и так происходит - у тебя же "специально обученные люди"™ исправляют документы периферийных баз, сделанные с ощибками - поэтому у тебя "Что случиться с ГП в перифериях!" - тоже самое. только добавляется неожиданный эффект - движения документа становятся другими.

(243) а филиалы ГП в ПИБах не восстанавливают?

(248) они что, долбанутые на всю голову?
(246) расчитывается. И что?

(245) использование программных продуктов сторонних разработчиков (1с, SQL server, операционные системы) - не претит твоему чувству прекрасного?

(247) "специально обученные люди"™ = ответственные сотрудники. Именно поэтому, что бездумное перепроведение/исправление документов в ЦИБе сносит ГП по филиалам. ЦИБ у меня в большей степени аналитическая/эталонная БД - отчеты, точечные исправления, регламент обменов.

(249) = актуальной информации по остаткам в ПИБах нет.

(251) я ничего не говрил про "бездумное исправление". Просто в описаной тобой ситуации, когда набор движений зависит от места проведения, порождает ситуацию, когда исправление документа в  ЦБ даст совершенно иной набор движений. И создаст точно такие же проблемы с последовательностями.

(250) ты часом не иеговист? как-то уж больно настойчиво свою веру навязываешь?
(250) нет.
(251) не так, поскольку в моем мехаизме если помнишь как раз в ЦИБе два документа, каждый со своим набором движений, и исправление документа в  ЦБ НЕ даст совершенно иной набор движений.

(250) сторонних разработчиков = не рекомендованных 1С, не являющися  собственными разработками 1С.

Лично я нигде не видел, что бы 1С не рекомендовало использовать  SQL server. У тебя другая информация?

(247) >> ЦИБ у меня в большей степени аналитическая/эталонная БД.

По другому с БД 1.5 ТБ и 120-ю ПИБами работать впринципе не возможно!

(243) есть в партии ссылка на документ, а документа нет - какие проблемы-то

- Проблемы с физической и логической целосностью

(250)
1.я не навязываю. Это ты навязываешь свою веру, что все должно делаться только методами, описаными в ЖКК. Я утверждаю, что применение тех средств, механизм действия которых ты понимаешь, которые ты умеешь применять и т.п. - вполне допустимо.
3. Еще раз - ты утверждал, что движения документа зависят от места его проведения.  Поэтому выражайся ясно и однозначно.
(255) еще раз, для альтернативно одаренных: фирма 1С выпустила документ, описывающий механизм создания и работы ВК. Выпустила его для того, чтобы создавать ВК. ВК нужно создавать для того, чтоб расширять возможности 1с - реализовывать функционал, который сама фирма 1С не реализовала по тем или иным причинам. Поэтому применение ВК вполне допустимо. Остается вопрос доверия создателям ВК. (точнее, выбор - создавать ВК самому, либо использовать сторонние)лично я считаю большинство создателей  ВК достаточно грамотными людьми, порядочными людьми и т.п. Реализация ВК аналогичных возможностей своими силами, несомненно, возможна - но потребует совершенно неадекватных трудозатрат. Поэтому лично я не вижу никакой разницы для применения ВК типа v7plus и v7ftp от ЗАО 1с, и formex и 1cpp от сообщества...

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

(241) "..метод эизнеспособен и обратного, нкто здесь не докузал. "
Ну кто бы спорил, наверное работает.

И, да, это претит моему чувству прекрасного.

(243) Да нет, сортировка для FIFO/LIFO никуда не делась. Элементы справочника с битыми ссылками в реквизитах это как бы - FAIL. Значит при проектировании системы об этом просто не думали.

А движения у тебя тоже полностью переносятся? Тогда как быть с незакрытими регистрами?

(244) (258)>> Прямой доступ - да, фирмой 1С не санкционирован. Но по сути, это исправления косяков 1с. При грамотном и вменяемом подходе - не несет никаких отрицательных эффектов - только положительные.

я не против, большинство "тяжелых" отчетов у меня реализовано имеено так. Причина в (256). И качество запросов гораздо сложнее обсуждаемго апдэйта апдтс.

и с чего ты взял, что не умею и не понимаю? У тебя прям мания величия, гаписал запрос на изменение, все могу!!! Не льсти себе особо.

(259) ну все возрадовался! поймал на неточности! Признаю, насчет физической целосности погорячился. Хотя... в твоем случае я бы руку на отсечение недал, что у тебя все впорядке с физической целостностью.

(258) слушая я на китайском пишу или ты тупо отказываешься меня понимать.
1. Я не против ВК, я против "чужих" ВК "чужие" = не мои, не 1С, без исходников. Так понятнее? (ВК твое реализации например я бы не рискнул использовать.)

2. Я не против прямого доступа к данным, если: Используется для выборки данных и повышает быстродествие построения отчетов.

>> Но по сути, это исправления косяков 1с.

да ты сам косяков породил (как минимум с логической целостностью, с актуальностиью данных в ПИБах) исправленец.

(260) Сортировка для FIFO/LIFO никуда не делась, только партиеобразующий документ к этой сортировке никаким боком не относится (во-первых, для списания фильтуются имеющиеся партии, а во-вторых, сортируются партии по реквизиту ДатаПартии, учитывая купленый это или комиссионный товар), и поэтому его наличие/отсутствие никаким образом на сортировку не влияет
Движения переносятся полностью. В некоторых случаях незакрытые регистры присутствуют - по тем объектам учета, котрые не учитываются в текущей базе. Но в этом случае непроотиворечивость движений данных в разных информационных базах важнее.

(264) и ты мне втирал про ограничения, гибкость, и т.д.?

(263) Я твои ВК тоже не рискнул бы использовать. Точнее, не стал бы использовать ни в коем случае. а вот исходники 1С++, например - лежат в открытом доступе.
у тебя косяков не меньше. а то и больше. когда один и тот же акт описывается двумя слабосвязанныит документами..

(0) Простыню не читал.
В свое время расширенные правила миграции в 7.7 реализовывали в SQL-версии путем доработки хранимой процедуры, которую вызывает 1С для вставки строки в 1supdts (слышал, и триггером реализовывали аналогичное). Расширенные правила миграции описывались в отдельной табличке.
Работало без сбоев несколько лет. Нужно было только не забывать восстанавливать хранимку после реструктуризации.
Чтобы не провтыкать - крутилось регламентное задание, каждые 5 мин проверяющее целостность хранимки и восстанавливая её при необходимости.

(267) а почему не поставил автоформирование хранимки при необходимости при запуске?

(266) >>  а вот исходники 1С++, например - лежат в открытом доступе - соответствено ничто не мешает мне ее использовать.

о каких "косяках" речь, ни одного нет. у Всех пока только религиозные убеждения  и субъективные суждения были озвучены.

(268) Не дотумкали на тот момент. Сделали в лоб, как проще, а потом так и оставили.

(264) Это - косяк. Что по-первому, что по-второму.

(266)>> двумя слабосвязанныит документами..

они неразрывно связаны, т.к. по наполнения различаются только одним знаком в номере и ИБСоздания().
Взаимосвязи (распр. док. может быть основанием) элементарно отслеживаются.
Да, еще, не припомню что бы предлагал тебе свои ВК или еще что либо.

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

(273) простите ГУРУ, сделайте одолжение что же вы вложили в сокральное понятие, цитирую: "акт описывается двумя слабосвязанныит документами"? Если не затруднит поясните простым смертным, в чем вы измеряете силу связи документов в конфигурациЯх 1С? а так же чем эта "сила" характеризуется?

(273) а насчет "нецензурщины", что сказать - относись спокойнее к критике в свой адрес.

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

(275)
1. т.е. на Ваш взгляд
Метод НайтиДокумент() более сильный нежели НайтиПоНомеру().
Ранжирование обоснуйте?

2. констатирую у Вас проблемы с вниманием или способностями воспринимать текст, читайте внимательнее (272) - "различаются только ОДНИМ ЗНАКОМ В НОМЕРЕ", а не "различаются одним номером в знаке"!!!!!!
ХХХ-000001 и ХХХ=000001, различаются одним символом(знаком), а не номером, так понятнее ?

"кагбэ намекает, что ты врешь" - ни о чем!

(275) да, и признайте наконец уже как минимум (271)

Дано:
1. Документ ХХХ-000001
2. Документ ХХХ=000001, того же вида что и п.1.
3. Наполнение документов различается только реквизитом НомерДок, одним символом, вместо "-" исп. "="

Задача:
Получить ссылку на Документ ХХХ=000001.

Связь документов не очевидна?
Метод НайтиДокумент() работает сильно медленнее нежели НайтиПоНомеру() с указанием всех! входных параметров?

(271) Это не "косяк", это недостаток. который компенсируется тем, что документ делает одинаковые движения во всех базах.
целостность документа важнее.
а вот "что по первому, что по второму" - не понял этой фразы.

(276) Да, признаю свобю ошибку - то, что можно менять "минус на плюс" - не дотумкал. Хотя тоже решение - гамно, ибо номер не отражает место создания.
(278) связь документов совершенно неочевидна. Я ж не глазами смотреть буду на все эти документы.
Поиск документа по номеру с указанием вида немного медленнее поиска документа по идентификатору. - смотри трассу.

(280) номер не должен отражать место создания (хотя почему по префикму документа не понять что за ИБ?) Место создания отражает метод 1С ИБСоздания(), а откуда документ движится и куда отражают Реквизиты документа! В документе в ЦИБ есть кнопка "найти пару" использование символа "=" в номере для документов не подлежащих миграции запрещено програмно.

(279) Что тут непонятного? Первое - по партиям, второе - по остаткам.

Это два самых первых вопроса возникающих при проектировании УРБД для ТиС и по обоим у тебя "незачет".

(281) Хм. Кто именно сказал, что номер _не_должен_ отражать место создания? например, фирма 1с считает по-другому... и кое в чем она права :-)
"кнопка Найти пару" - безусловно, гени[т]альное решение, ибо можно знать пару без всякого поиска, да еще и видеть на этапе просмотра документа либо программного доступа. И в т.ч. в структкре подчиенности, например...

(283) ты цепляешься к частностям "гени[т]альное" в твоем случае с 6-тью пибами и тремя документами, в случае когда в ЖД тысячи документов а скролирование и "штатный" поиск занимают значительное время возрадуешься и кнопке!

Заметь, ты красноречив только при описании моего решения (не идеального, но ИМХО более надежного), при этом свои гени[т]альные реализации и недоработки пытаешься преподнести как самосабой разумеющееся, хотя налицо явные баги в архитектуре

см. (246)(252)(272)(282)

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

(285) >> Просто недостатков у него гораздо меньше.  смешишь!? меньше чем чего и где? В мем случае нет "недостатов" с
1. (282)
2. с логической целостностью
3. с незакрытими регистрами


пользователи как по твоему работают с документами? не в ЖД? или у тебя не используются ЖД?

(286) 1.иметь на один акт два документа вбазе, причем с разными движениями - это не недостаток? :-)
Иметь несвязанные документы (или по крайней мере проверять - а есть ли "логически связанные" кнопкой) - это не недостаток?
иметь разные движения по месту проведения - это не недостаток?
не иметь единой истории изменений документа - это не недостаток?

2. пользователи у меня работают в разных журналах документов. в зависимости от функционала. С различными отборами, видимостью реквизитов и т.п.
поиск по номеру - не "штатный", а достаточно расширенный. точнее, их несколько разных.
и используют в т.ч. и сканеры ШК - каждый документ со штрихкодом.

(287)
1. Нет. Пилять! сколько объяснять. Филиал отправил деньги в другой филиал - это горизонтальняа миграция. Актов два Расход денег в одном филале и приход денег в другом, оба акта зафиксированы соответствующими документами! Регистры везде и в ПИБах и в ЦИБЕ закрыты корректно Твой механизм НЕ ПОЗВОЛЯЕТ это реализовать корректно! Так понятнее?
2. нет необходимости ничего проверять кнопкой! Кнопка для пользователей, функционал облегающий навигацию по ДЕСЯТКАМ ТЫСЯЧ документов в БД!!!!
3. История изменения документа фиксируется в журнале регистрации 1С. Этот фунционал не реализован отдельно, поскольку надобности в моем случае в нем нет! А реализация его 1. не трудоемка, а вот нагрузка на обмены и быстродействие проведения документов возрастает!!!! при прочих равных было принято историю отдельно не хранить! Все это уже рассказывал.
4. движения по месту проведения - это норма! см.п.1 нельзя в ПИБ1 сделать сразу и приход денег которые он отправил в ПИБ2 - это и будет кривизной, ПИБ1 не видит прихода ПИБ2, он оправил деньги от себя ВСЕ нет их у него на балансе!

5. ШК это супер! ты предлагаешь мне 10 000 (а документо оборот по части филиалов именно такой) документов рапечатать и сканировать! акуительный подход! Нет сканировать с экрана!?

(288) п.5 10 000* 100 - это дневной документооборот!

(242) да все просто что они хотят. еще раз описываю, ибо углубились в сторону, и у меня полная суматоха в голове.
.
Опишу типовую схему работы как есть сейчас:
.
ТИС 7.7.
.
Есть ЦБ, принадлежность товаров на ЦБ лежит на кортеже (Фирма0, склад0); в ЦБ также видны остатки по всем точкам продажи-ПБ (ФирмаN, складN). Все фирмы принадлежат одному СобственномуЮрЛицу.
.
Задача: в ЦБ должна быть вся информация по ПБ, на каждой ПБ - только информация по товарам этой ПБ.
.
ПоступлениеТМЦ: штатный документ, в ПБ не мигрирует, здесь вопросов нет. Поступление ТМЦ приходит ВСЕГДА на центральный склад (ЦБ) на (Фирму0,Склад0).
.
Товар на точки попадает посредством создания в ЦБ документа перемещения товара из (Фирма0,Склад0) в (ФирмаN,СкладN).
.
После создания доков перемещения - инфа выгружается в ЦБ ручками и загружается в ПБ ручками. ПБ в конце дня выгружает ручками данные в ЦБ, ЦБ загружают данные. все.
.
Такая схема была выбрана давно,  всех все устраивает, наверчено кучу доп.функционала, завязанного на эти перемещения и прочего сопутствующего (доп.функционал не трогает основу - все по регистрам отсалось штатное). Мне это все досталось в "наследство".
.
Кроме: на точках открытие периода идет непозволительно долго...

(290) в ПИБах остатки ЦС видят (склад0)?

..это раз.
2. на точки-ПБ попадают все перемещения. на ПБ1 оказываются перемещения, предназначенные для ПБ2, ПБ3... ЗАДАЧА: этого быть не должно.
3. При попадании на ПБ перемещения - в базе ПБ тотально висит незакрытым регистр Остатков ТМЦ и партий ТМЦ по !центарльному складу!- ибо перемещение списывает с центрального склада и приходует на точку ( точка - розничная). - задача ТАК БЫТЬ НЕ ДОЛЖНО.
.
еще раз: досталось в наследство, быстро мпоменять не получится.
.
вот и все задачи, если их решить - в принципе все остальное устраивает.
.
ПОСЕМУ ЖЕЛАТЕЛЬНО ОБСУДИТЬ ИЗЛОЖЕННЫЙ ВЫШЕ ВАРИАНТ А).
.
Предвидя, что без извратов реализовать вариант А - затруднительно, в ТС изложидл схему, на которую готов перейти:
.
Морально готов перейти на другую схему работы: когда товар на точку попадает через продажу от ЦБ на ПБ. При необходимости вернуть товар из ПБ на ЦБ - такая же продажа в обратном направлении. Требования остаются  те же самые: на каждой ПБ должны быть только "свои" документы.
.

(291+) А хотят видеть остатки этого товара на соседних складах, если у них такой товар закончился? Где делают заявки на поставку или перемещение?

(291) видят, в тотально минусовом количестве, как результат ухода товара с центрального склада в перемещениях.

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

(294) жесть. т.е. как такового контроля отрицательных остатков нет?
2. на точки-ПБ попадают все перемещения. на ПБ1 оказываются перемещения, предназначенные для ПБ2, ПБ3... ЗАДАЧА: этого быть не должно.

Что мешает выбрать вариант миграции для ПРМ МСЦ? каждое ПРМ будет идти только в свою точку?

3. При попадании на ПБ перемещения - в базе ПБ тотально висит незакрытым регистр Остатков ТМЦ и партий ТМЦ по !центарльному складу!- ибо перемещение списывает с центрального склада и приходует на точку ( точка - розничная). - задача ТАК БЫТЬ НЕ ДОЛЖНО

здесь нужно думать концептуально :)

(292) А морально готов написать собственную систему обмена?

(294) а товар телепортируется со склада0 на складыN?

(297) зачем?

(296) нконтроль отрицательных остатков - ЕСТЬ И ЖЕСТКИЙ. и в ЦБ по своему центральному складу и по ПБ - все чисто!!! на ПБ - ПО СВОЕЙ ТОЧКЕ: все чисто!!! а то что на ПБ - висят отрицательные остатки по ЦБ - ну так ПБ с ними никак не работает!

трыззззта

(299)На 293 будет ответ?

(296) > Что мешает выбрать вариант миграции для ПРМ МСЦ?
- вариант миграции МСЦ - это значит что перемещения придется создавать заранее пустышками в ПБ ???? - если да - то это самый последний вариант исправления ситуации, если никак иначе не получится

(296) > здесь нужно думать концептуально
- а то! чего бы я здесь тусился ;-) ..с УРБД мало работал...

И если не секрет про какую отрасль и какие товары идет разговор?

(293) нет, такого функционала не надо.

(304) торговля видеодисками. есть еще весьма интересная задача в 'nqj области...

(305) Ну хоть, здесь по проще будет.

на (298) ответ будет?

(298) > а товар телепортируется со склада0 на складыN?
нет, не телепортируется.

в ЦБ при проведении делаются штатные движения по регистрам
- минус (Фирма0,склад0)
- плюс (ФирмаN,складN)

в ПБ приходят эти же самые движения, но ввиду того что на ПБ центральный склад "отсутсвует" - на нем получаются тотальные минуса

В принципе, если в файле обмена для каждой точки Вычеркнуть движеняи по минусам по ЦБ - то по идее должно быть все ОК, кроме того, что на ПБ нельзя перепроводить такой документ - иначе кирдык снова получится... или надо в модуль проведени ятсавить анализ где проводится документ в ЦБ (полные движения) , в ПБ - только по своей ТОЧКе - это не хочется делать..

(309)Почему не хочешь модуль проведения поправить?

(297) можно, но только в том случае если не удастся сделать ни вариантА, ни вариантБ

(309+) Без расходной части, они будут довольно быстро проводиться.

В момент обмена можно вообще подрезать все движения по регистрам, а после приема просто перепроводить принятые документы.

(310) потому что я ленивый и старый, выбираю путь минимального сопротивления ;-) надо будет - поправлю. Но по УРБД мало работал, поэтому надо "вьехать" в тему...
.
этого клиента подхватил только по причине чистого интереса 'nqj области бизнеса - очень короткие продажи, весьма интересна задача поддержания товарного состава на точках.
.

(309) я имел в виду, товар на склады попадает физически как? Его кто-то везет? если да то этот кто-то МОЛ? этот акт как-то отражается у тебя? Т.е. товар в пути учитываем?

(314) Тогда понятно.

(313) крайне желательно все "подрезки" делать исключительно в ЦБ, т.е. в ПБ уходит уже готовая инфа (так хочется).
.
в принципе, опасность перепроведения на ПБ документа, пришедшего из ЦБ, можно считать "несущественной"

(288) еще раз: если "деньги отпралены", то они не должеы просто уменьшать количество денг на счету/в кассе. они обязаны где-то на такую же сумму их увеличить. Для контроля. Элементарный принцип двойной записи.
Да, у меня регистр по одному из измерений не закрыт. Но у меня видно, откуда он ушел, и куда. И эти движения одинаковы во всех базах. ибо это _один_ документ. Если делать два документа, то нужен отдельный объект хранения, либо связывать их так, что ри изменеии одного документа автоматически меняется другой. Иначе это все отдается на откуп оператору.
2. догадываюсь, что "кнопка - это для пользователей". Только у меня они обходятся без кнопки "найти документ с похожим номером".
3. "История изменений в документах хранится в журнале регистрации" - это тоже "пять".
4."движения по месту проведения - это норма" - более чем сомнитетельное утверждение. Если я отдал деньги - я что-то получил. независимо, отдал я их из правого кармана, или из левого.  
"он оправил деньги от себя ВСЕ нет их у него на балансе" - замечательно. возмите меня туда кассиром....
5. у меня документы распечатываются. Все документы. И на документах ставятся подписи лиц, подтверждающие, что операция, зафиксированная документом, действительно произведена. у тебя на экране расписываются?

(315) Это путь к появлению новых сущностей, а он ленивый.

(315) товар физически перевозится из ЦБ в ПБ "курьером". Товар в пути не учитываем - ибо это ПОКА нафиг нужно не было. Товар с ЦБ на ПБ - попадает быстро - в течении часа-двух.

Если требуется концептуальное решение Вашей задач, то могу предложить следующую схему (несколько лет в такой работают клиенты).
ИБ главного офиса, каждая торговая точка в ней - отдельный склад. Рядом (в этом же офисе) лежат ИБ торговых точек, выступающие в качестве ЦБ, периферийные - на соответствующих точках. Обмен между ИБ главного офиса и ЦБ точек осуществляется через OLE только нужными документами.

(317) Так у тебя так и будет. В ЦБ перед обменом всё лишнее подрежешь, а ПБ после обмена новые документы перепроведешь.

(318) > Если делать два документа, то нужен отдельный объект хранения, либо связывать их так, что ри изменеии одного документа автоматически меняется другой. Иначе это все отдается на откуп оператору.
- да, именно этого и хочется избежать, ибо придется наворачивать сверху над парами документов интерфейс-обработку, что мне нахрен не хочется - ибо на 12 лет нанаворачивался уже ;-) есть поинтереснее задачи.
.
ПРОСЬБА: обсуждения по схемам УРБД - ПРОСЬБА отложить пока. попробуем сосредоточиться конкретно?

(321) OLE - это ещё тот геморой. Я бы не стал связываться с такой схемой.

(321) учтем, но не нравится принципиально. Куча ненужных сущностей, не имеющих адекватного отражения в реальной жизни.
.
я сторонник того, чтобы работа в базе максимально близко соответсовала функционально выполняемым работам в физической действительности: это залог успеха и стабильности функционирования.

(322) если в ЦБ в файле обмена (или в соот.таблице ИБ) - все подрезать - то зачем перепроводить доки в ПБ?

(322) Чтобы получить только плюсовые движения у перемещения.

(327) это к 326

(318)  утомл уже....Элементарный принцип двойной записи.
В одном ПИБ расход, этот акт отражен соответствующим документом, который увидели в ЦИБ и переправили в другой ПИБ где произошел приход!!!!!!!!! Где нарушение принципа двойной записи?
2. Только у меня они обходятся без кнопки "найти документ с похожим номером. рад за тебя искренне, повторяю, все мои ограничения обусловлены ИСКЛЮЧИТЕЛЬНЫМ размером БД и огромным документооборотом.
3. ну ты же у нас любиттель всего нештатного,  ЖР и тот нужен крайне редко, при форс- мажерных разбирательствах и его волне достаточно. Поэтому никто ничего ЛИШНЕГО не городил.
4. более чем сомнитетельное утверждение - исключительно для ТЕБЯ!
5. Атличнег! У меня так же но только в ПИБах, ты речь завел про поиск и позиционирование в ЦИБе

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

размышляя попутно: если взять например вариантБ, то его штатно в УРБД тоже не получится реализовать?
.
в ЦБ (передача товара из ЦБ на ПБ)
1.
- реализация с ЦБ на ПБ;
- поступление от ЦБ на ПБ
в ПБ (передача товара из ПБ на ЦБ - есть такая необходимость):
- реализация с ПБ на ЦБ;
- поступление от ПБ на ЦБ;
.
и какая схем миграции для Реализации и ПоступленияТМЦ должна быть в таком случае - чтобы в ЦБ было всё, а в ПБ - только "родные" доки?

(330) не понял.

(318, 329) горячие финские парни! ;-) давайте ПОТОМ обсуждение разовьем в отдельнйо ветке (ПРИ НЕОБХОДИМОСТИ).

(317)Он же сказал, что его в ПБ не волнуют остатки по ЦБ в ПБ и также не волнуют остатки в других ПБ

(333) Спорим, каждый останется при своем.

(334) меня смущают минусы и при такой тяге к прекрасному ТС, его равнодушное отношение к ним!
не должны видеть и видеть минуса не одно и тоже. считаю что либо в ПИБах должны видеть остатки ЦС либо видеть 0, но никак не -

(329)
1. для особо выдающихся - деньги не должны исчезать. пардон, "списываться с баланса". Если деньги ушли у меня из кармана - у меня должна появиться материальная ценность, либо документ, подтверждающий то, что она у меня появится...
2. нет, это обусловлено исключительно твоим представлением.
3. ЖР нужен достаточно часто. раз в месяц точно. Знание конкретных изменений нужно тоже достаточно часто. Не зря, допустим, в снеговике ввели версионирование.
4. еще раз - на примере: если я заплатил деньги в размере 100 рублей - ф должен поиметь что-то на эти 100 рубле независимо от того, из какого кармана я заплатил эти деньги.

(336) Не путай. Минусы есть сейчас. И ТС хочет от них избавиться.

(337) п.1 а где сказано, что документ, подтверждающий то, что она у меня появится...  не появляется???? их появиться даже два!!! в ЦИБЕ именно исходя из принципа двойной записи.

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

(336) Показать 0 вместо 0 по ЦС, не такая уж и проблема, а вот куда девать лишние записи из ПБ, из-за чего страдает быстродействие.

(339) да очень просто. втородокумент

(340) В чем МОД или универсальный обмен для ленивого дешевле?

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

(336) именно. мое гипертрофированное чувстов "прекрасного" не позволяет мне мирится с текущей ситуацией, тем более что она мешает бизнесу реально.

(343) в части отсечения ненужных движений

(340) Себя тоже отношу к ленивым, поэтому тоже вначале много думаю, только потом делаю.

в ПБ по остаткам и движениям имеющим отношение к ЦБ - быть ничего не должно.

(337) ты считаешь, чтьо расход оператор у меня формирует прямым запросом к таблицам регистра?

(340) этот вопрос уже поднимался в (315) ответ был дан в (319)

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

(340) > отсечь миграцию отжельных движений кроме как правкой файла выгрузки, не получится
- правка 1Supd - допустима, если это поможет исправить ситуацию.

(348) (350) штатно, без каких либо доработок, без использования учета товара в пути и транзитного склада не реализовать! вопрос не в проблемах с товаром во время перевозки!

(343) Тогда скажи сколько работы нужно провернуть, чтобы настроить МОД и сколько, чтобы подрезать 1Supd

(352) обозначил выше - доработки возможны. Мне наиболее привлекателен путь "подправки" 1Supd

(343) С МОДом давно не работаю, так как в свое время через него не смог реализовать какую-то задачу. Давно было уже не помню. Может конечно, ситуация с ним уже и поменялась к лучшему.

(354) Думаю, для тебя это будет самый правильный и быстро реализуемый выбор.

(354) не понимаю зачем? штатная задача. Да конечно появляются дополнительные цепочки документов и сущности, но их не много раз, учитывают ВСЕ хоз.операции - два.
Филиалы не видят ничего кроме свох остатков и движений, в ЦИБЕ видят ВСЕ! ровно что ты и номинировал в задаче. Зачем МОДы и правки непонимаю?

Итого: реализовать вариант А (290,292) с использованием документов перемещения возможно, для этого придется "подправить" перед выгрузкой 1Supd.
- правильно я понял?

(357) > Да конечно появляются дополнительные цепочки документов и сущности
- резюмируй плиз, кратко: какие именно документы/сущности и их назначение?

на удивление :) здесь мы с  Mikeware едины во мнениях.
или я ошибаюсь?

Доп сущности:
Транзитный склад (курьер) и доп. перемещения на/с этого/т склад

(358) Я тоже так понял, что да, только ешё подправить модули проведения, потому как в ПБ могут тоже исправлять перемещения( или не могут?)

(362) вопрос в том, что если исправят и перепроведут перемещение в ПБ и в ПБ будут движения только по ПБ - что в результате миграции появится в ЦБ по этому перемещению?

(361) не понял. в чем неолбходимсоть транзитного склада в схеме обмена данными (не в ответственности курьера!)?

(364) в контроле исправлений.

(363) Так ты же:
1. модуль проведения поправишь
2. после приема будешь запускать перепроведение полученных документов.
Следовательно документ проведется заново.

(365) подробнее, плиз.

(364)
при перемещении (ПРМ, миграция МСЦ) на транзиный склад (смотрим на реквизит: вид склада, склад измерение обоих регистров) делать расход по регистру ПартииНаличие и Приход по регистру ТоварВПути (в ЦИБЕ учитываем товар не доехавший до склада, филиал видит остатки - путь и свои) в филиале на основании пришедшего ПРМ делать ПТО - расход по регистру ТоварВПути и приход по регистру ПартииНаличие

(363) В результате движения будут у документа перемещения ровно такие, какие ты хочешь их увидеть в принмимаемой базе.

(366) зачем мне на ПБ перепроводить полученные документы - если после подрезки файла обмена придут правильные данные?

(370) Можешь не перепроводить, если правильно подрежешь. Только в этом случае чуть сложнее алгоритм подрезки.
Скорее всего в каждой ПБ потребуется своя подрезка.
Ты же ищешь как с меньшими напрягами сделать.

(368) если у ПРМ миграция =МСЦ, то как перемещение попадет в ПБ вообще?
.
в ПБ наличие товаров в пути никак не интересует. Нет товара на точке - не надо никаких сведений о товарах в пути.
.
не нравится мне эта схема... мутная...

(371) > Скорее всего в каждой ПБ потребуется своя подрезка.
не понял... имеется в виду что В ЦБ ДЛЯ КАЖДОЙ ПБ - своя подрезка?

в (368) описана гибрид схемы вариантаА +вариантаБ. Вместо одного документа ПРМ появляется дополнительный документ ПТО (приход товара?)...
- тогда уже "проще"(?) сделать схему продажа-покупка с участием ЦБ и ПБ с обоих сторон... но тогда остается вопрос: (331)

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

(373) Я так думаю. Что если ты не будешь перепроводить документы ПРМ при приеме, то алгоритм подрезки в ЦБ будет сложенее нежели если их перепроводить и давать им на месте сделать нужные движения. А так как в ПБ тоже формируют документы ПРМ (например при перемещениях с одной ПБ на другую ПБ), то и алгоримы подрезки на каждой ПБ будут немного отличаться.
Поэтому прще вообще вырезать все движения и перепровести документы.

(372) использовать "пустышку" ПБ :)

(377)А пустышек сколько и в какой момент создаются?

(378) Опять? С начала? :)
уже было. Пустышки создаются (лежат) в  ПИБе контроль нужного кол-ва (до создать или нет) выполняется ПриНачалеРаботыСистемы() "нужное кол-во" - либо констатна, либо городим/дополняем справочник, где определяем нужное кол-во по видам документов. Повторюсь никак ситльно систему это не напрягает.

+(379) - доработок миниммум

(372) так в чем мутность, то? в ЦИБе уичтываешь, что у тебя и куда уехало. В ПИБе товар физически приехал, в два щелчка создал на основании Приходный Товарный Ордер. Путь закрылся, Склад пополнился. ПИБ видит только свой склад и то что к нему едет! никаких минусов и лишних документов. Куда помоему прозрачнее!?

(379)Не сначала не надо, идея понятна. На первый взгляд вроде всё просто. Избыточности и так хватает и сам её ввожу для ускорения каких-то операций. Почему бы ещё немного не добавить. Надо будет при случае попробовать.

(382) см (82)

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

(383)Но это я так, зная о возможности такой ситуации, можно наверное и заранее что-нибудь придумать.

(384) так если нет связи:
1. Это форс-мажер
2. не понятно, зачем что-то слать в ПБ с которой нет связи
3. Не оформлять документы в ЦБ на эту ПБ или же в ЦБ используя прмой доступ (запросом) насоздавть нужное кол-во пустышек или держать в ЦБ заведомо большое кол-во пустышек

>>заведомо большое кол-во пустышек
ну если ПБ с потенциально не надежной связью

(386)
1. форсмажор, но не такой уж и редкий.
2. На соотвествующий склад делается перемещение материальных ценностей. Следовательно, делается и документ. Следовательно, он обязан туда отправиться при восстановлении связи.
3. насоздавать пустышек от имени периферийки? замечательно, однако :-))

(388) а я против? Обязан - отправиться. Я же написал, либо заведомо избыточное кол-во пустышек, либо (удивлен, что такому знатоку прмого доступа к данным) нужно рассказывать, что болванка документа без движений - это три записи в трех таблицах (если есть ТЧ), а ИБ создания определяется постфиксом поля iddoc в этих таблицах. И на случай форс-мажера создать нужно кол-вол объектов ПИБа в ЦИБЕ грамотному специалисту не сложно. В моей практике (120 филиалов от Владика до Калиниграда) с провайдерами сами понимаете разношерстными, подобный форс мажер был пару раз за последние лет 5-ть так что недостатка в пустышках нет.
>>
насоздавать пустышек от имени периферийки? замечательно, однако :-))
т.е. убивать записи из таблицы регистрации изменений религия позволяет, а вот создать записи от имени ПБ нет? Переобуваешься прямо в процессе ходьбы!

(389) создавать записи от имени ПБ религия мне как раз не позволяет. Ибо верую я, что разумом свим постичь не могу я, каковой же ид свободный будет у периферийной ИБ. а убогий разум мой подсказывает, что создавая документы в ЦБ с таким идом, с которым придет документ из ПБ - рискую получить я коллизии, и быть покараным собственной совестью за потерю документа...
Хотя создать такой документ я, безусловно, могу без всяких сложностей.

(390)
Открою тебе тайное знание, дабы "убогий разум" твой не не подсказывал тебе, а точно говорил какой ИД будет следующий:

Хранение ID объекта

   ID может иметь 3 представления (уровня) в зависимости от длины (количества значащих символов):

9 символов – определен тип и вид объекта (например «Справочник.Клиенты»), в ID включается только порядковый номер в 36-ричной системе исчисления. Под порядковый номер отводятся первые 6 символов, последние 3 символа зарезервированы под код базы УРБД.
13 символов – определен только тип объекта, вид не задан (например «Справочник»). Первые 4 символа – идентификатор вида (как он задан в метаданных), последующие 9 символов – по аналогии с предыдущим пунктом.
23 символа – не определен тип и вид объекта. В таком случае в первых 2 символах храниться тип объекта (будет рассмотрен ниже), следующие 13 символов формируются аналогично предыдущему пункту.

Исходя из ~ суточного прироста документов прикинуть сквозной поярдковый номер с запасом, чтобы исключить возможность пересечения, перевести его в 36-тиричную систему и делов-то

http://www.metaprog.co.ua/opisanietabl.html

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

(393)
способ формирования ида я и так знаю...создавая документы в ЦБ с таким идом, с которым придет документ из ПБ - рискую получить я коллизии

не вяжется

способ формирования ида я и так знаю, и сгенерировать "далеколежащий" ид вполне могу.

какие колиизии???

Не комильфо - никто не спорит. так ведь речь про форс-мажер.

(394) вопрос в том, насколько "далеколежащий" генерить - исходя из дня - могу получить коллизии из-за длящегося форсмажора. исходя из 5 дней - получу большие дыры.
зы.
разговаривая про ид документов в частности (а вообще, любой ид объекта - 9символьный) вываливать описания различных _представлений_ ида, и утверждать, что "создавал несколько раз" - тоже вяжется слабовато....

Чем тебя напрягают большие дыры? Боишсь разрядности не хватит?

>> разговаривая про ид документов в частности... т.е. теперь ты доипался, до количества скопиашенного текста? ну извини если сильно напряг тебя, так это ж такма что бы расширить твой кргозор и навсякий случай избежать дальнейших вопросов про "описания различных _представлений_ ида", но видишь млин.. мой план не удался!

>> что "создавал несколько раз" - опять лагаешь! сплошная клевета, я написал, что подобных (длительное отсутствие связи) ситуций, при обширнейшей географии филиалов и разношерстности провайдеров за последние 5-ть лет было не более 2-х! Где там утверждения ""создавал несколько раз"?

Вариант создания тестировался на клонах ПИБ и ЦИБ,  была проверена работоспособность! Было проверено опытным путем! А не только исходя из религиозных убеждений! Что коллизии отсутствуют ! Негатвных воздействий от "дыры" в номерации iddoc не было обнаружено.

(376) перемещения с ПБ на ПБ - только через ЦБ идут.

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

(381) на ПУБе - розничная точка. Поэтому что едет на ПУБ - нахрен не надо в ПУБе знать - пока не приехало - на пубе ничего нет.
.
с транзитным складом - все равно непонятно с закрытием регистров по транизитному складу и что куда мигрирует. если "перемещение" из ЦБ на транзитный склад делается в ЦБ - то получаем точно такие же грабли - такие перемещения будут мигрировать НА ВСЕ ТОЧКИ. то есть возвращаемся нафиг к тем же граблям + доп.сущность. - без тех же самых пустышек, по всей видимости не обойтись. Сильно не думал - но навскидку - изъянов дофига.

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

(400) Ну так и набери в любом поисковике "структура 1Supdts".
Там куча ссылок.

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

(400) структура примитивнейшая -
DBSIGN (char3) - код базы, в который отправляется объект
TYPEID (integer) - тип объекта (0 - выгрузка конфигурации)
OBJID (char9)  - ид объекта (0 - выгрузка конфигурации)
DELETED (char1) - признак необходимости удаления объекта из БД
DWNLDID (char9) - ид выгрузки, в которую данная запись уже попала (если пусто, то объект еще не отправлялся). записи с непустым идом удаляются из таблицы, когда приходит подтверждение получения узлом пакета. удаляются все записи с идом обмена меньше или равным подтвержденному.

(402) скромность - не твоя добродетель. Я бы посоветовал тебе обратиться к психологу - маниня величия явно налицо!