Идея взята отсюда Книга знаний: Нетипичное использование компоненты УРБД в системе 1С:Предприятие 7.7
Задача:
Требуется настроить обмен между базами типа "Снежинка". Стандартный УРБД неудобен, т.к. нет возможности отбора при выгрузке в периферию.
Проблема: на многих точках установлена однопользовательская версия программы, т.е. запускается база всегда насколько я понимаю в монопольном режиме и не будет возможности читать/изменять нужные файлы.

Как можно обойти это ?

Поправьте тему плз в 7.7

(0)
1. "нет возможности отбора при выгрузке в периферию." Это не так.
2. "Как можно обойти это ?" не пускать базу монопольно. Или закрывать на время обмена.

Хм. А разве однопользовательская может работать в качестве центра распределенки? (в т.ч. и по условиям лицензии)

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

MOD

(2) 1. Каким образом можно отоборать выгрузку в периферийную базу по значению склада в шапке ? (перед выгрузкой пройтись по фалу 1SUPDTS.DBF ? Но вдруг кто из пользователей что-то поменял (всех выгонять на время обмена не вариант) выгрузится документ во все базы.
2. Обработка обмена будет своя и написана на языке 1С, т.е. не запускать базу в которой нужно произвести обмен не получится. Можно запустить базу не в монопольном режиме в однопользовательской платформе ?

(5) Нужно по сабжу. МОД не подходит по определенным причинам.

А разве УРИБ на однопользовательскую встанет?

(7) Причины в студию

(4) я про систему регистрации и говорю...
(6) выгонять _всех_ из однопользовательской версии? :-)

(9) Нужно своими средствами и без денег.

(11) на краденой УРБД? :-)

(11) А за работу деньги заплатят или для души работаем? Просто МОД стоит копейки.

(8) Читайте внимательно: однопользовательские на периферии.
(13) Хотелось бы оставить стандартную систему регистрации + МОД в модули пишет свой код, да и нагроможден уж больно. Неизвестно как будет работать с большими объемами. Вобщем не лежит душа к нему.

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

(14) У меня регистрация от УРБД а обмен от МОД и весь МОДовский код из модулей убран (кроме доп.функций в глобальнике), поскольку эта куча кода нужна лишь для регистрации.
Можно вообще инсталлятором МОДа базу не обрабатывать - только добавить общий реквизит в доки и в каждый справочник :( + еще по мелочи.
Большие объемы - это сколько?

(15) "промежуточные центры" "снежинки" по идее тоже должны быть центральными.
Ну и читать модифицированным фокспрошным драйвером можно, а вот писать - проблемы (с индексами)...

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

(18) работало таким образом 50 магазинов:-)))эх были времена приходилось извращаться не то что сейчас))

(17) Я значит неверно истолковал слово "Снежинка". Одна база в центре и штук 20 периферийных.

(20) это - обычная типовая звезда.
обработка нужна только в ЦБ.

(18) Так и засада в больших файлах обменов, сидят на "свистках" мегафоновских. +Если объем большой то и загрузка в базу может идти целый день - без шуток.

(21) перед выгрузкой пройтись по фалу 1SUPDTS.DBF ?

(22)"большие" - это сколько?
и, собственно, что "нетипичного" при звезде?

(23) типа того.
Хотя работать с файловыми на запись я б не рекомендовал.

ТекущаяИБКод()
ИБСозданияОбъекта
ЦентральнаяИБКод()
PS файл выгрузки не судьба править ? и отсылать...
ЗЫЫ фигня это все , все в пределах - работает если обмениваться по 1-2 мега за раз ...
ЗЫЫы похоже с урбд да и с модом мало работали ...

а еще смущает
как и сам автообмен в УРБД, работает только в разделенном (не монопольном!) режиме 1С:Предприятие 7.7
а однопользовательская запускается в монопольном,
Кстати МОД работает отлично

(14) Всё бред. УРБД на перефирийку не встанет и никаких изменений регистрировать не будет.

(23) Можно добавить в справочник "Склады" код ИБ и удалять в UPDTS документы с "чужим" для этой ПБ складом. Это если однозначное соответствие ПБ - склад. Не знаю, как в ДБФ, а на скуле -в 2 счета.

(28) уже определились, что имеем дело с обычной "звездой"

(23) в периферийках создаются болванки нужных документов, в ЦБ заполняются, миграция "место создания - центр" и никаких плясок с бубном

(31) Лучше в одном месте поплясать, чем в сотне по всей стране :)

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

(22) После перепроведения в центре за последнюю неделю в перифериную базу может загружаться сутки.
(22) Нетипичтое использование УРБД, механизм обмена свой - регистрация УРБД.
(25) Смущает то, что пока будешь пробегаться по файлу, юзеры еще наколотят документов и все-таки не по адресу что-то попадет.
(26) Про правку файла выгрузки еще не думал, если ссылку подкинете по структуре был бы признателен.
(26) Не получается обмениваться всегда по малу.
(26) С МОДом не работал, установл и удалил лет 5 назад.
(33) Это как ?

(31) Возможно при создании документа в центре изменять признак места создания на другую базу ?

(33) Это в ПБ при старте создаются пустышки будущей датой и поддерживается запас? А в ЦБ запрещено вводить новые доки определенного вида - пользуйтесь пустышками?

(35) Тогда проще не регистрировать доки. А при записи/проведении вставлять запись в UPDTS для нужной базы по соответствию Склад-ПБ.

+(35) ИМХО самый бескровный вариант - в какой

+(38) таблице хранится создания объекта ?

(37) Либо так.

(0)

1) На ПБ делаешь перемещение - ПУСТЫШКУ.
2) Выгружаешь в ЦБ
3) Заполняешь документ перемещение в ЦБ
4) Выгружаешь в ПБ.

Что тебе еще надобно, старче?

(39) Уууу. Один фик ты сначала запишешь. И при этом уже будет зарегено для всех баз. Да еще и запись будет заблокирована - слишком много но. Править надо только в UPDTS - иначе намудохаешься.

(34) структура файла выгрузки более чем позрачная...

(41) Выглядит "через ж.", хочется чтоб прозрачно для пользователей все было.

(44) Зато работает "как часы" и штатными методами.

(43) Навскидку - своими средствами (в обработке 1С) сложно сформировать такой файл ?

(44) оно и так прозрачно для пользователей

(46) кому-как.
в общем, легко, но геморно. Плюс только формированием файла дело не ограничивается...

(45) Несомненный плюс. Может и правда ну нахрен всю эту свистопляску.

(46) Можно и обработкой откорректировать, можно и ручками.

Не, не пойдет обмен через УРДБ. Нужно конвертировать одни документы в другие - например перемещение в центральной должно быть поступлением в розницу в периферийной.

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

Вся проблема в том, что не могу корректировать файл UPDTS в периферии. Вариант создать еще одну базу для обмена. Закрывают рабочую, открывают для обмена.

(51) зашибись распределенка... :-)))
ты еще номенклатуру одну в другую конвертируй...

(51) А накуа?
Основной склад - оптовый
Переферийный - розничный (перемещение в розницу)

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

(55) А движения лишние зачем ? Списание с основного будет.

(51) КД2 решит твою проблему. Только повозиться придется с ее освоением. )

(58) Я и собираюсь ее использовать. Проблема встала в регистрации объектов для обмена. Либо УРБД (надежно), либо свое делать.

(56) Я каждому даю только ту номенклатуру, что нужна им. И только тех контрагентов с которыми они будут работать, из числа заведенных в базу, остальных они сами заведут и пришлют мне.

(59) УРБД понадежнее будет, там механизм регистрации изменений очень мощный. А с КД2 постоянно у меня проблемы. то она перезаписывает то что не нужно перезаписывать, то дозаписывает. )

(51)Это разбивается на 2 этапа, в ЦБ пользователь делает перемещение, затем уже автоматически, опять же в ЦБ, на основании перемещения заполняется болванка поступления в розницу для конкретной ПБ, которая и уходит в ПБ, перемещение остается в ЦБ, нехер ей в ПБ делать, только с ссылками может быть засада

(60) Выглядит так ?
Звонок в колхоз Ивановкий из центра: "Марья Ивановна, заведи-ка перемещение, товар тебе хотим отправить !"

(62) Тогда уж в периферии создается поступление в розницу, а в центре заполняется и создается перемещение между складами, которое остается в центре.

(63) перемещение у тебя делается в ЦБ, если я правильно понял (51)

(64) ну тебе на месте виднее

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

(65) Да.

(67) это уже потом будешь делать, сначала с обменом разберись

Еще вариант забить на УРБД и использовать журнал регистрации. Напривер ВК Journal.dll
http://1c.proclub.ru/modules/mydownloads/personal.php?cid=5&lid=2167

Точно, никаких проблем с монопольным запуском. Прикрутить КД2 и в путь.

(61) Буду надеяться что мне повезет больше)

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

(73) У меня центральный склад на который приходит весь товар. С него идут продажи и перемещения на другие склады/магазины.

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

(0) У творения Саши Орефкова SQLite есть замечательный побочный эфект - умение работать с файлами базы, когда она запущена в монопольном режиме. Так что можно реализовать любые извраты фильтрации и изменения принадлежности объекта к БД.

(34) http://pro1c.org.ua/index.php?showtopic=352
Файл 1Cv77Chs.dat и вовсе
***
***,
{"Acknowledgements",
{"****"}},
{"Constants"},
{"References"},
{"Accounts"},
{"Documents"},
{"Template Operations"},
{"Deleted References"},
{"Deleted Documents"},
{"Deleted Accounts"},
{"Deleted Template Operations"}}

(76) а с записью и индексами там проблемы решены?
читать-то несложно....

(24) +1 ^)

(76) Похоже то что надо по сабжу, спасибо.

Всем спасибо, предложили много вариантов.

(15) В 7-ке УРБД это отдельная компонента с отдельным ключом, который стоит денег и не маленьких. У вас оно тоже куплено?

(76) Только чтение, без записи в БД

(82) Лови скрин лицензии http://www.idinahui.net/
Коли топик в который раз лень прочесть.

А ЦБ у тебя скуль или дбф?

(85) ДБФ

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

Если бы еще подсказали как в центральной базе изменить признак в какой базе был создан документ.
Чтобы пересоздать периферийные базы по новой (сейчас они практически клоны центральной).

(87) Если бы еще подсказали как в центральной базе изменить признак в какой базе был создан документ. - признак этот 3 символа в ИД объекта, подменять их я бы не стал, может случится так что ПБ создаст объект с уже существующим ИД, последствия понятны?

(88) Ясно, спасибо.
Тут либо менять вместе с признаком ID, т.е. делать по порядку для каждой ИБ.
Либо создавать клоны документов в периферийных и удалять предыдущие в центре.

(88) Это еще все ссылки надо на этот ИД вовремя отследить и заменить. Короче - ну его.

(87) Если есть желание, то любой документ, созданный в любой базе, можно перенести в любую базу - ручками.
Одно НО изменения в документе не будут передаваться.

(51) запросто. у меня так и есть, но пришлось помучиться..

короче - была тема по большой файл, открытие периода и ПБ.
.
ситуация была такая,
центральный офис и куча точек-магазинчиков.
изначально схема УРБД была сделана так что
- каждый магазинчик = отдельная фирма
- все фирмы (в т.ч. и ЦБ) - одно юрлицо.
- приход на оптовый ЦБ фирма-склад; зашибись
- перемещение с оптовый ЦБ фирма-склад на розничный ПБ фирма-склад;
.
соответсвенно в каждую ПБ уходили все перемещения для всех точек.
в ПБ получалсиь висящие остатки по ЦБ фирма-склад.
.
в итоге рано или поздно нас тупил капец - периоды открывались все дольше (по нескольку часов уже), файло регистров расло безмерно.
.
в итоге схему пока оставили как есть, а на ПБ тупо запускаем обработку, которая удаляет все доки где нет пары ПБ фирма-склад, а там где такая есть пара - для этого документа удаляем движения регистров по чужим парам Фирма-склад.
.
в итоге все стало почти "шоколадно" - размеры регистров упали от около 2Гбразмеров до сотни мегабайт 9а то моет и меньше, навскидку не помнюЮ на ПБ не залезть посмотрть), период открывается секунд 5-7

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

(94) Только если ЦБ на скуле

(95)
а) почему?
б) да, ЦБ на скуле.

(96)
1. Потому что до сих пор нет нормальной возможности редактировать dbf файлы напрямую, без риска "поломать" индексы
Для Скуля такой проблемы нет, ибо нет индексов. Там хоть триггер повесь на изменение таблички и оно само будет автоматом чиститься (пишу по рассказам, а не по опыту)

Теорию можно почитать тут http://pro1c.org.ua/index.php?showtopic=5683
или такой вариант http://www.1cpp.ru/forum/YaBB.pl?num=1243496545/all

(93) Все решается элементарно с помощью пустышек

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

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

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

(100) Нормально работает с пустышками

(98) спсаибо за ссылочку вторую - практически на 100% то что надо.. еще бы там живой кто в ветке был.. ;-)

(103) я не возражаю... я уж лучше хирургическим методом.. а то вся эта нетрадиционная мыдыцына...

Ну там вроде бы Eprst засветился и он живой вроде бы

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

..единственное, что не понял - регистрируются изменения документов, а движения регистров по зарегенным докам идут "паровозом"..?

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

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

(110) а как я из документа могу запретить миграцию только половины движений?

(111) никак.

(103) А ты возражал.   С тебя пиво!

(113) Я? Я к Злопчинский не имею отношение

(114) Пиво пожалел на мыло скинуть   ;-(((

(0) Че за хня - а префиксы то зачем тогда??? У меня уже 6 лет как я на фирме перемещения и складские доки с ПБ 771 не могут попадать в ПБ 881 - только в ЦБ

милай - делая так - перемещения должны делаться в самих
ПБ

(117) дадада, особенно когда инициатором перемещения является центральный офис... хвост виляет собакой

На самом деле, необходимость создания документов в периферийной базе связана с тем, что мы не можем создавать документ с произвольным ID, так как в каждой базе ID идут по порядку. А хвост префикса определяет принадлежность документа к базе.
Однако, можно использовать для каждой периферийной базы два префикса - один для отправки документов из центральной базы, в другой - для получения из периферийной.
В этом случае, будет возможность фильтрования по префиксу в ID и ничего лишнего куда не надо не попадёт.
Вот только файлы обмена придётся немного править.

(118) Не пудри мозги молодежи. И выполни свое желание:- "хотел бы пойти падаваном на 8-ку... "

(118) Не обращай внимания. Это завсом.

(119) имхо, ты пьян....

Ромиксовая компонента для регистрации изменений + своя выгрузка/загрузка на 1спп - все работает отлично, монопольный режим не нужен, все правила настраиваешь в центре, на стороне филиалов работает само

(0) Можете сформулировать задачу в терминах пользователя (предметной области) без использования терминов 1С?

(124) Александр, ранее ты был более хорошим телепатом :-)

(125) остался таким :-) Подозреваю, у (0) есть первичное требование, решаемое штатными средствами, но догадки хочется проверить после ответа на (124).

(120) кто ж мну возьмет...

(124) формулирую: надо чтобы в точки-магазины попадала только предназначенная для этих-точек магазинов информация.

(123) это какая?

(128) Первичное требование будет, или тут конкурс телепатии среди прогов? :-)

(128) Для тех, кто невкурил тему "пустышек", как сейчас реализую:

1. При запуске периферийной базы создается условно-необходимое количество "документов-пустышек", назовем их "Приход" - с датой "апокалипсиса", дабы не видеть их в журналах нашего времени.
2. Соответственно эти документы попадают в центр (правила миграции "Место создания-центр".
3. В центре создается пользователями документ "Перемещение", который так же может создаваться и в другой периферийной базе.
4. Проводится и формируются движения только РАСХОД (поскольку к примеру при партионном учете строки могут разбиваться, то движения ПРИХОДА пишутся в дополнительный оборотный регистр.
5. Регламентная обработка заполняет "Пустышку - "Приход" и проводит, которая делает движения ПРИХОД согласно дополнительному регистру.
6. Документ "Приход" попадает в периферийную базу.
7. Профит.

Поправьте, если можно упростить.

(124) Пользователям нужен шустрый обмен и (128)

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

Гемор. куча ненужных сущностей, плюс переписывание типовой, причем не в 1-2 строчки. все-таки проще чистить периферийную базу или файл обмена/регистрацию обмена.

(131) Хороший пример для иллюстрации http://www.informat.name/humor/project.htm

(134) У меня самописка (два десятка документов) + дбф + обмен "звезда", потому проще конечно. Но на мой взгляд в варианте (41) преимущества в надежности и времени на отладку/тестировании очевидны.
(135) Не уловил юмора. Поддержите своими предложениями.

(135) во-во.. ;-)

(137) Очень похоже на поддержку медвепутов на выборах.

(138) а мну по барабану...

(139) По барабану тоже больно бывает. А обосновать поддержку поста (135) хотелось бы увидеть объективную.
Судя по посту (75) я много пропустил (может и еще кто) и уверен, что ветка кому-то поможет.

(140) Хотите ? хотите дальше! ;-)
каждый выбирает сам какое решение применять.

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

(142) Далеко не претендую на удобное решение, но в (131) раздвоение документов решает эту проблему в контексте поставленной задачи в (0).

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

(144) Технические нюансы есть конечно, не все так гладко.

+(144) Но из двух зол как говорится выбирают меньшее.

(102) Жесть!

(143 ) а зачем при раздвоении документов пустышки вообще?

(147) А каким образом обмениваться документами только с определенной ИБ ?

(147) иначе будут мигрировать на все ПБ

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

(150) Как в периферийной базе создастся приход ?

(151) Из расхода выгружается в xml файл, сжимается раром под паролем, и отправляется на мыло (записывается на переносной носитель).

В базе приёмнике, по поступлении товара с бумажным носителем, загружают его электронную копию, сверяют наличие... всё, круг замкнулся.

(152) Исключительное желание остаться при средствах обмена самой платформы.

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

(136) Скажите мне, чего хотел пользователь, тогда, возможно, предложу решение с использованием штатных средств УРБД. До сих пор:
(0) -> 1-3 с картинки (135)
(131) -> 4-5 с картинки (135)
Основная мысль - при правильно организованном учете достаточно штатных средств УРБД.

(155) Ну подскажи как. Только безо всяких доп.приблуд типа пустышек и (желательно) без подчисток регистрации изменений и файлов обмена.

Есть фирмаО+складО = Оптовый; есть N точек ФирмаN+складN - розничные.

Все фирмы принадлежат одному юрлицу, так что необходимости перепродаж между фирмами центра и периферии - нет.

Конфигурация - типовая ТиС.
Товар из оптового склада-фирмы на розничный склад-фирмы перемещается обычным Перемещением ТМЦ между фирмами-складами.

Вот такой УЧЕТ. Правильно или неправильно - какой есть.

Как это сделать штатными средствами УРБД?

Как это рассказать дрругими словами, без привлечения "предметки 1С" - я затрудняюсь... ;-)

(156) А что тут мудрить? Миграция для ПеремещениеТМЦ = "Все ИБ".

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

(158) а зачем на точке1 перемещения для точки2..?

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

(131) Ох и любите вы ходьбу по граблям...
(152) чрезжопица полная...
(159) а почему "похоже?"?

Еще идею подкинуть? Как обойтись без пустышек?
Только я так справочники гоняю.

(160) Странный вопрос, с учетом (161) :-) В любой точке состояние склада должно отражать реальную картину, поэтому все перемещения должны быть во всех базах. Показ документов можно ограничить, но лишено смысла. Лучше ограничить в правах на изменение документа, созданного в чужой базе.

(164) это подгонка под действительность.
с точки зреняи "бизнеса" - точка/магазин - самостоятельная единица. и состояние склада = состоянию точки.
.
пока что незачет...

(163) давай.

(161) кросафчег

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

(166) По правилам, установленным мною, на ПФ пользователь имеет право вводить только контрагентов.
Возникла необходимость вводить МНОЮ элементы некого справочника от имени ПФ (миграция переферия-центр)
Я в обработке ввожу эти элементы в файл XML и отправляю его на ПФ по почте. Одновременно в ЦБ ввожу идентификатор в спец справочник временных элементов, который, периодически этой же обработкой, очищается. Там в автомате, при заходе в базу под определенным пользователем, считывается этот файл и вводятся эти элементы в справочник на ПФ. При следующем обмене это все приходит ко мне.
В дольнейшем на данной ПФ документами изменяю реквизиты элементов данного справочника. И это все идет ко мне!

(169) однако мсье знает толк в извращениях! ;-)

(165) Понятно, каша в голове :-)

(171) каша. но не у него... :-)

(170) Я тут вчера нахамил - извиняюсь. Был нетрезв. Но ты правда нудный :)

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

(165) (168) При твоей концепции:
Покупатель: "Дайте эту штучку..."
Продавец: "У нас нет".
Покупатель: "А где есть?"
Продавец: "Не знаю, звоните в центральный офис".

При моей концепции:
Покупатель: "Дайте эту штучку..."
Продавец: "На нашей точке отсутствует, но есть на точке 2 и точке 3. Где вам было бы удобнее забрать, в нашем магазине через 2 дня или самостоятельно в точке 2 или 3? Поставлю в резерв, заберете гарантированно!".
Покупатель: "Удобнее в вашем магазине".
Продавец: "Хорошо, заказал, зарезервировал. Приезжайте через 2 дня".

Какая концепция для бизнеса правильнее? :-)

(174) Про "закрытие регистров" что-нибудь слышали?

(175) офигительно, особенно когда между точками "0", "2" и "3" расстояние пару сотен километров (при том, что вместо дорог между ними "направления")...

(170) Поработай с мое, не до того дойдешь.   ;-)))

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

(175) информацию по остаткам можно передавать не используя механизм УРБД, например поднять вэбсервер откуда периферийка через вебсервис будет подтягивать данные по остаткам интересующих товаров

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

+(180) это про остатки в других периферийных базах и ЦБ

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

(179) м-дя.. знаете толк в извращениях...

(184) А что делать...

(185) строить работу так, чтобы не требовалось регулярного вмешательства человека... "работать должны роботы"©

(183) в доке больше 9999 строк делать не рекомендуется и табличка ТЧ дока будет пухнуть

(183) док будет один?

(188) у меня их 48 (по одному на каждый обмен) соотвественно, переписывается "самый последний" - становится "самым первым"...
ну и остатков товаров немного - не более 2000 на каждом складе, но я отправляю только остатки ЦБ...

(186) Жить хорошо, когда есть инструменты для работы. У Вас скуль, у нас нет такой роскоши.

(190) это да...

(180) (183) ...и понеслась "звезда по ухабам..."! :-)
(177) моя концепция решает задачу (156) штатными средствами.
Для вашей задачи у меня есть другое решение, использующее только штатные средства УРБД без всякого рода программистских заморочек (триггеры-шмиггеры :-) http://new.abelov.com/contacts/about/reviews/354/

(181) Только программист может настоять на замене правильного решения кривым, пугая пользователя страшилками об отсутствии безопастности :-) И для задачи (0) есть первичное требование пользователя, решаемое штатными средствами УРБД. Программисты легко увлекаются, забывая о том, чего хотел пользователь (135) :-)

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

(174) траблы простые - распухание файлов итогов, открытие месяца по нескольку часов.

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

(192) > На основе 1С:Бухгалтерии 7.7 организована распределенная информационная база, с настроенным обменом между узлами в условиях отсутствия интернета
.
блинаааа.. это как? почтовыми голубями?

(192) Для вашей задачи у меня есть другое решение, использующее только штатные средства УРБД - и что там?

(196) Флешкой

+(197) И тишина, типичное бла-бла, с битьем копытом в грудь.

(200)

(195) А чего ты хочешь НОВОГО от 7.7+УРБД? Свое решение для условия (156) озвучишь?
Моему решению (192) уже более 7 лет и оно работает даже без программистов и интернета!

(201) в (192) нет ничего чтобы позволило оценить "решение"

(202) Вы считаете, что мне необходима ваша оценка моего решения? :-)

(203) ахах, ну конечно нет, вы ведь здесь просто пальцы раскинули, что здесь оценивать?

(203) а это никакое не "решение" - просто установленная и настроенная распределенка. И не более того.
Так, уровня начинающего внедренца, или младшего сотрудника-стажера франча...

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

(206) Инструмент гибкий в пределах своих ограничений и достаточно старый, чтобы пытаться открыть в нем для меня что-то новое.
(204) (205) Ну, как? ЧСВ выросло после таких оценок? :-)

(207) кроме вас тут никто свое ЧСВ не пытается поднять, выдыхайте

(207) Ограничений при грамотном использовании умелыми руками  - мало.

Господа, чтобы прекратить все кривотолки - замечу: Д'Артаньян здесь один я...

(210) нетипичное лечение головной боли http://youtu.be/s73GjbSw5xY или как руководитель предприятия наказывает программиста за нетипичное использование компоненты УРБД :-)

(211) это из собственного опыта управления проектами? не пойду я к вам! ;-) рекомендую данный ролик пустит бэкграундом на выступлении ИнофтартЭвент... ;-)

Саша на инфостарте будет делиться опытом по выставлению счетов на многие десятки тысяч рублей за запуск восстановления последовательности у клиентов?

(213) а почему бы и нет? если клиент не способен найти других исполнителей - то такая цена вполне себе обоснована...

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

(214) так я разве в укор, молоток наоборот, жизнь по принципу "без лоха и жизнь плоха" вполне себе имеет право на сущетсвование

№все крупные сотсояния нажиты нечестным путем.."...?

А что бы сказал народ если бы можно было создавать документ с заданным внутренним ID? Например в централке можно было бы создать документ перемещения в магазин с внутренним идентификатором соответствующим этому магазину. И УРБД молчаливо уносит его в эту периферийку..

(218) индексы?

(219) внешняя компонента

(218) Это пожалуй решило бы часть проблем.

(220) я не против, но как при этом поддерживать целостность базы на уровне индексов? и надо ли это делать с индексами?

(221) при этом надо взвести "флажок" изменения этого перемещения для УРБД - иначе не унесет..?

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

Будет серьезная проблема с нумерацией идентификаторов, не взлетит.

(225) проблем не будет если провести некую подготовку при создании новой базы. Для новой, пустой базы принудительно создается документ с ID равным, ну например 1000000. Все последующие документы в базе автоматом пойдут инкрементом от этого ID. Таким образом у нас есть некоторое количество зарезервированных ID которые гарантированно не будут созданы штатными механизмами 1с-ки. Остается завести счетчик (константу например) и создавать документы по нему, добавляя к ID нужный суффикс периферийки.

(221) ID подсовывается 1С-ке при создании документа. Так что УРБД уносит штатно.

(227) к (223)

(226) Что-то мне подсказывает, что после попадания из центра документа с ID 100000000 в периферийную базу, там уже будут создаваться документы исходя из этого.
Поправьте, если кто знаком ближе с таким нюансом.

(229) Расскажите как вы ИД будете подсовывать?

(230) Просто теория в (218)

(230) впихнем невпиху/\емое!

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

Вернее тот самый ИД36 для документоа

(229) совершенно верно, именно это и нужно. Чтобы вся база работала с ID начиная с 1000000. А я буду себе создавать документы с ID до 1000000.

(231) эта просто теория уже лет 5 как работает

(213) не понял, завидуете, сударь, или сплетничаете, сударыня? :-)

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

(238) ну насчет быстрого исчерпания я не согласен. У меня же отложенные ID используются только документами перемещения из/в магазин. Прикинул, и отступил с очень приличным запасом, предварительно посмотрев какой вообще максимальный ID выдержит 1с.

Что только люди не придумают, лишь бы МОД не юзать. Специально же для этих случаев придуман.

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

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

(241) ну да. примерно так. Дырки не страшны, а при исчерпании отложенного диапазона всегда можно отступить еще раз.

(242) Так мне имхается - товарищ уже заикался о преобразовании типов документов и прочем. Как бы в результате за несколько лет напишет кривой аналог МОДа :)

(244) преобразование типов - имхо, идиотизм...
его задачи вполне штатно решаются штатными методами через лишний - "транзитный" -склад.

(245) Что такой ласковый-то? Ничего плохого, если перемещение с центрального склада на точку передастся как приходная накладная или что-то в этом роде. Иначе придется мириться с незакрытыми регистрами или дописывать, чтобы в ПБ перемещения только приходовали товар.
ой - сейчас меня с оном смешают. блин работы куча а я тут нарываюсь

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

(247) Ни в одной библии это не написано. Дело привычки. Открою Вам страшную тайну - когда я выдаю клиенту счет-фактуру выданную - у него она становится счет-фактурой полученной. И ни у кого крышу не сносит :)

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

(249) Размышляя в рамках точки - для них это приход. Чтобы это было перемещением - на точке должна быть полная копия базы. Перемещение со склада, на котором и так висят миллиардные минуса тоже нелогично. Вот какого лешего на точке годами висит склад с минусами?

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

(251) Я, конечно, сейчас мозги клюю, но кладовщик или продавец в рамках РБД размышлять не должен. Он за товар расписался, что ему пришло. Двойная запись его не волнует. Ладно - завяжем, меня занесло.

(252) В рамках РБД должен размышлять тот, кто систему проектирует и внедряет.
за это ему и платят больше, нежели кладовщику или продавцу...

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

(254) это вопрос философский.
вероятность устойчивость работы системы с РБД есть произведение вероятностей устойчивой работы сервера ЦБ, устойчивой работы канала связи и устойчивой работы прокси на периферии... Т.е. всяко ниже "распределенки". Ну и в "централизованной системе" есть все данные, даже которые не нужно видеть.
в случае РБД базы работают в достаточной мере независимо, выше защищенность, ниже требования к каналам связи - но возникают вопросы потери обменов, коллизий и т.п.
все решается для каждой конкретной ситуации.

+255 Еще и производительность системы надо считать. Работали в базе полста юзеров, а к ним с филиалов / розницы еще сотня подключилась - совсем другой расклад получается

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

(257) Если часы остановить - 2 раза в день они покажут точное время

(258): т.е. по сути сказать нечего - я правильно понял?..

(259) Так суть не была обозначена. Если суть в том, чтобы раз в месяц обнулять остатки, чтобы не пухли регистры - почему бы и нет. А в течение месяца белиберда по остаткам в отчетах и формах подбора так и будет. Хотя на это спокойно можно забить и сказать - так положено. А что положено на это дело программистом - не говорить :)

(260): суть обозначена - и заключается в решении указанной в (250) проблемы с накоплением отрицательных остатков на складах-источниках перемещений из-за приехавших "прицепом" к перемещениям других движений. хотя зачем я это объясняю - непонятно, как, впрочем, непонятна и причина того, что ті заявляешь, что "сути нет", и тут же єту суть формулируешь.
в течение месяца проблемы тоже особой нет - благодаря четкому разделению складов ПБ на "свои" и "чужие". подкручивается на раз-два.

(236) Не поделитесь методами создания произвольного ID документа ?
(249)(251) Категоричность признак глупости и я бы не стал однозначно утверждать как нужно оперировать данными в рамках УРБД. В констексте поставленной мне задаче движения в ПБ должны попадать только их, а уж как документ назовется "Купи/продай, Оприходование, Мана небесная" глубоко пофиг.

(262): тогда лепи ещё ПБ "товары в пути"...

(263) Если понадобится, почему бы и нет.

(262) 1.а какие проблемы сгенерировать документ с нужным id'ом?
2. Признак глупости - название, не отражающее сути. Или имеющее разночтение с общепринятыми определениями.
зы. Назови у себя в базе приходный документ "списанием", ПКО - "Расходом", инвентаризацию - "платежным поручением"... пофик же? :-) пусть запоминают...
ззы.
"#define TRUE FALSE  //счастливой отладки, суки..."©

(265) 1. На вопрос вопросом ...
2. Имя документу дал не мудрствуя лукаво "Приход по перемещению" с подсказочкой снизу, о ! Теперь остается набрать даунов на работу, чтоб было кому не понять что отражает этот документ.

(266) 1. Так в чем вопрос? Имена таблиц известны, структура базы известна, форматы идентификаторов известны...
2. считай меня дауном, но перемещение - оно одно. по определению.
зы. у вас есть внктри компании словарь террминов, глоссарий, корпоративный справочник? база знаний?

(267) не, лезть в таблицы чтобы создавать с нужным ID не айс. Это отдельно для SQL, отдельно для DBF, проблемы всякие полезут.

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

(269) ну я бы не был столь категоричен. Есть такая функция в кишках системы, называется GetDefDBSign. Вот к ней и можно приклеиться и подменить вновь сформированный ID на свой.

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

(270) Возможно. не пробовал хучить самостоятельно.
Но такой способ ничем не лучше прямого доступа к базе.

(272) ну почему же, как мне кажется - лучше и универсальней. Засчет того, что с базой работает сама 1С-ка и мы ей не мешаем.

(273) И ваять отдельную компоненту?

(274) ну да

(275) возникает ТКВ...

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

(277) базу совершенно не нужно таскать по всем точкам. И более необходимой информации отправлять в ПБ тоже не нужно.

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

(278)(279) Все еще трете?   ;-))

(280) просто похоже, что ТС - франч...

(281) Троллинг откровенный пошел ?

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

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

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

Хоть как-то ж.пу прикрыть :)

+(285) еще помогает расчет затрат на реализацию "так делать нельзя" и на исправление ситуации

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

(236) А на коммерческой основе возможно поюзать вашу теорию ?

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

(289) Удачи вам в этом безнадежном деле.

(290) почему ж безнадежном? Сейчас так документы из снеговика грузятся :-)

Подниму ветку, т.к. хочу подвести небольшой итог:
Система с пустышками взлетела и радует малыми пакетами обмена данных и скоростью загрузки в ПБ.
Создавал базу таким образом:
1. Сделал центральную со всеми справочниками.
2. Перенес в нее документы, которые бегают по всем ПБ.
3. Создал распределенные, загрузил в них только те, которые якобы должны были там создастся.
4. Обменялся, провел все в центре, опять обменялся и профит.

Серьезно времени потерял из-за того, что таким образом взялся создавать всю базу с начала года, а это порядка 100тыс. документов на 25 базах. Убил время, контора в тетрадках пишет.
Пришлось свернуть базу на 1 октября и за одну ночь успел все перенести.
Если еще придется делать подобную работу, однозначно буду смотреть в сторону подмены ID в таблицах, а не копирования доков.
Еще раз обращаюсь к monitor, есть варианты приобрести компоненту ?

Надсмотрщик, спасибо за идею, готов проставиться !

(292) а мог бы сделать все гораздо быстрее, и не останавливая работу....
зы. 100 тыс документов - не так и много.

(293) Наверно мог бы, если б опыта было больше в этой теме.

(292) Можешь ему "проставиться" - OFF: Одинэсник сильно заболел. Нужны деньги на лечение если так "жаждешь"

Ветку все не читал.
А ни кто не предагал переходить на 1с82?

(295) Готово !
(296) Дорого было бы писать заново, а типовая вряд ли устроила заказчика. +Лицензий вагон покупать.

(297) Обращайся. Если что.