Для работы этой обработки необходимо чтобы на компьютере был установлен WinRAR, а также 1С++.
Первый запуск «Настройка УРБД.ert» стоит производить в НЕмонопольном режиме на центральной базе, так как она копирует ДБФ файл и читает из него какие периферийные базы у вас есть. После изменения настроек периферийных баз потребуется запуск этой обработки в немонопольном режиме, для того чтобы она смогла прочесть ваши изменения.
Настройка очень простая, нужно указать, при каком значении реквизита будет выгружаться (не выгружаться) тот или иной документ (справочник). Старайтесь для одного документа (справочника) создавать не более одного правила, так как программа все равно обработает только то правило, которое ей первым встретится.
URBD_2.exe лучше всего запускать из bat файла или из командной строки с передачей ему параметра, где храниться файл с настройками, сгенерированный «Настройка УРБД.ert», например
E:BaseURBDURBD_2.exe E:Base<каталог вашей базы>URBD
Часть ошибок программа пытается сохранять в файлы, один файл появляется в той же папке откуда запускался exe файл, а второй появляется в папочке <каталог вашей базы>URBD.
Добавленно 21 июня 2011г.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
тоесть это для DBF баз и это не пользуется штатным механизмом?
Это дополнение к штатному механизму УРБД. У нас ДБФ версия, работает с января месяца, пока что полет нормальный. На SQL не пробовал, у меня нет под рукой SQL версии.
EXE файл берет файл выгрузки, распакивывает его, загружает в себя, и обрабатывает согласно правилам. После этого данные обратно записываются в файл и упаковываются. Разбивка на строки в некоторых местах нарушается но в целом в файле выгрузки синтаксис полностью сохраняется.
Этот файл также может обрабатывать певоначальный файл выгрузки.
Основная задача которая решалась при написании этой обработки это разделение документов по складам. У нас центральная база стоит в центральном офисе, и в каждом магазине периферийная база. Сейчас каждый магазин имеет в своей базе только те документы которые относятся к его складу или кассе, и никаких чужих документов нет. Периферийные базы стали намного меньше, а следовательно и работают намного быстрее. Плюс ко всему даже если какой нибудь умелец скопирует базу, он получит движения только по этому магазину.
Гы… я пад сталом «Основная задача которая решалась при написании этой обработки это разделение документов по складам.» А что миграцию обектов использвать религия не позволяет…. зачем весь этот велосипед
8SiriuS8 Представь простую ситуацию. Есть 3 базы, централная база это центральный склад, 2 перифериные базы это магазины, товар поступает на центральный склад, а может поступать на прямую в магазин. Вроде бы самый простой пример. Если мне кто нибудь объяснит как можно сделать так чтобы документы относящиеся только к центру или к Магазин1 не попадали в Магазин2, то я наверно поменяю свое вероисповедание.
(4) рекомендую поменять свое вероисповедание
На вкладке «Миграция» поставь точку в нужном месте и будет счастье.
(5) Наверно слишком упростил пример.
Предположим что у нас есть Центр (Центральная база), Склад(периферийная), Фин отдел (который к сожалению находиться не в одном здании с центральным офисом) и куча магазинов. В некоторых магазинах сидят менеджеры которые управляют магазинами находящимися в его городе.
Теперь Вопрос — Какую мне галочку поставить чтобы на складе видели документы только касаемые движения ТМЦ, в фин отделе движения денег, Менеджеры видели только те документы которые относятся к их региону, а магазин только свои документы?
По началу все было сделано правами, я писал новые ограничения, народ искал возможности обхода этих ограничений. Ведь любая периферийная база имела полный набор документов, а значит любому знающему человеку не составит труда скопировать базу, зайти туда с админскими правами и посмотреть все что ему надо. А так в в периферийной базе содержаться только те документы которые касаются только этого участка работы. Правда есть куча ограничений и эта система не лишена недостатков, но все равно она решает поставленную мне задачу.
(6) Ну если любой знающий человек может скопировать базу, то это уже потенциальная большая дыра.
А так, имхо, достаточно штатного механизма и ограничения пользователей по правам (возможно даже с «привязкой» к префиксу ИБ).
(0)ну смысл понятен — решение хоть и внешнее но оригинальное…
Есть вопросы:
-что происходит если файл выгрузки содержит измененный MD?
— изменяется только файл выгрузки ? Какие файлы еще задействованы? (это к работе на sql)
— выложи исходники программы если не жалко… (это лично для посмотреть и возможно добавить некоторый функционал).
(8) Если в файле выгрузки содержится MD файл, он там и остается, уже проверенно не только в лабораторных условиях, но и на боевой базе. Так же можно обрабатывать и первоначальный файл выгрузки, они хоть немного и отличаются, но не настолько чтобы 1С потом не смогла загрузить обратно.
Меняется только файл данных в архиве, он создается заново после обработки данных по правилам. На SQL как я уже писал не тестировал, если УРБД на SQL работает с тем же форматом то думаю будет все равно DBF или SQL. Все необходимые файлы внешняя обработка создает сама в папке с базой данных. Обработка не отслеживает изменения конфигурации поэтому при изменении состава реквизитов, или их очередность у документов(справочников) советую перепроверить сохраненные правила, Сам попадал уже на эти грабли после того как удалил один реквизит и реквизит «Склад» стал не 7-м по списку а 6-м. При добавлении реквизитов в конце или переименовании ничего не меняется.
Это третья попытка реализовать задачу. В начале я попробовал редактировать 1SUPDTS.DBF, но я быстро понял что документы такие как ПеремещениеТМЦ или Перемещение денег выгружаются с движениями по складу(кассе) которые к этой базе не имеют отношения. Пришлось разобраться с форматом файла выгрузки и написать обработку в 1С которая меняла это файл, но и тут была проблема. Во первых я так и не придумал быстрого и надежного способа, как из одного батника запускать конфигуратор для автообмена и предприятие для выполнение данной обработки. Во вторых все это было настолько медленно что я взялся за изучение С++. Разница меня поразила, то что 1С делала в течении 20 минут программа написанная на С++ выполняла менее чем за минуту, при потреблении памяти почти в 2 раза меньше.
Надеюсь все кто будет пользоваться этой обработкой будут отдавать себе отчет о всех проблемах которые на него сваляться.
Меня заинтересовало.
А можно ли сделать, чтобы по правилам менять вид выгруженного документа?
Например выгружаем из ЦБ ПеремещениеТМЦ, а в ПБ загрузиться ПоступлениеТМЦ (или ОприходованиеТМЦ)?
Чтобы остатки ТМЦ на на ПБ не уходили в «-» по «чужим» складам.
Было бы очень интересно
К сожалению менять нельзя. Обработка работает с данными находящимися в файле выгрузки, она понятия не имеет о существовании 1С и уж тем более какая там конфигурация. Все что можно это удалить или оставить в этом файле какие нибудь данные. Механизм выгрузки/загрузки из 1С используется стандартный, который в УРБД.
По поводу перемещения я решил вопрос очень просто, я не выгружаю движения по регистрам того склада который мне не нужен, но при этом в конфигурации стоит жесткое ограничение на проведение или создание подобных документов. Если в этой базе запрещен один из складов то данный документ провести(перепровести) в этой базе не получиться ни под каким предлогом, а значит в этой базе не появятся движения по «паразитному» складу для этой базы.
Небольшой совет: Если есть желание разобраться побыстрее с этой обработкой, то скормите ей файл первоначальной выгрузки, еще на стадии формирования периферийной базы. Обычно я это делал так: создавал периферийную базу, делал под нее настройки, а потом в DBF файле менял этой базе признак на вновь созданную и выгружал с нуля. После обработки этого файла и загрузки в пустую базу сразу станет видно что выгрузилось а что нет.
(11) Я не совсем понял, вы удаляете часть данных документа или целиком документ? Все перемещения вводятся только в центральную базу?
(10, 11) Можно сделать, но тогда Вам надо будет фильтровать и входящий файл. Но лучше УРБД для этого не использовать.
(8) +1 и если есть, описания формата файла обмена и механизма обмена.
(6) Какую задачу выполняет региональная база (менеджер) с учётом описанных Вами ограничений?
(1) Формат файла обмена не зависит от версии 1С. Для SQL версии есть более универсальное решение — хранимая процедура, фильтрующаяя 1SUpdts по произвольным правилам.
(9) Плюс не глядя! когда я встал перед проблемой разбора *.dat файла — так и не решился реализовать.
(3,5,7) Рекомендую задуматься, зачем компания ПиБи сделала в свое время «Менеджер обмена данными», который успешно продавала.
По поводу SQL — быстрее это будет работать на триггерах.
(12) Пойду по порядку:
Удаляться может как целиком документ или справочник, но также если документ не удаляется у него могут удаляться записи о движении по регистрам. Точней проверяются у всех документов которые остаются, и также для каждого регистра по любому измерению можно настроить правило выгружать/не выгружать. Отметка о сделанном движении удаляется из файла переноса данных, и при загрузке в периферийную базу этого движения не будет. Но стоит этот документ перепровести 1С снова сделает все движения которые она должна была сделать у этого документа. Если движения ограничить в конфигураторе, то при проведении в периферийной базе документа он получит неполные движения и эти неполные движения попадут в основную базу, так что с этой проблемой я никак не могу разобраться. Пока что я ограничил проведение документов «ПеремещениеТМЦ» и «Перемещение денег» в базах которые не могут оперировать хотя бы одним из складов.
Заменить один документ на другой в файле выгрузки это из области фантастики, программа написанная на С++ понятия не имеет ни о структуре данных нового документа, и тем более она не сможет сделать корректные движения. Либо придется написать программу которая будет если и не превосходить по сложности саму 1С то не будет уступать ей.
Механизм выгрузки/загрузки полностью штатный, влезть в dll и внести туда корректировки как это делает 1C++ или Formex я не могу. Даже если случайно найдутся описание библиотек УРБД то мне потребуется не один год чтобы изучить С++ до такой степени что бы написать что нибудь стоящее. Описание формата файла как такого нет, но этот формат очень похож на XML, насколько похож я не могу сказать так как о XML имею только поверхностные представления.
В региональной базе можно выписывать любые документы принадлежащие этой базе кроме Перемещений, Хотя и их тоже можно выписывать если эта база оперирует двумя и более складами/кассами, и склад/касса принадлежат этой базе.
P.S. Думаю такое можно организовать и при передаче данных из периферийной базы в центральную, например если в периферийной базе ведется еще какая нибудь деятельность которая не должна отражаться в центральной базе. Но для этого придется немного поправить внешнюю обработку «Настройка УРБД.ert» чтобы можно было написать правила для центральной базы.
(13) В SQL на тригерах или в DBF простым удалением записи можно ограничить выгрузку документа/справочника но если документ выгружается то выгружается со всеми движениями, по всем регистрам. А используя мой метод например можно у всех выгружаемых документов выкинуть записи о движении по регистру определенного склада, и тогда в отчетах этого склада просто не будет. Да и файлы содержащие движения по этому регистру будут меньше, а значит 1С будет работать быстрее.
Ставлю плюс за изобретательность и проделанную работу. Молодец. Но nikitan правильно говорит, делается это через миграцию в свойствах документа(справочника, константы). Все это настраивается в центральной базе. Например есть переферийки L, D, M, K. Допустим документ был создан в базе K и должен попадать в базы L и D (соответсвенно в базе М его быть не должно), тогда см. скрин …..
Если же документ должен в перф. базу попадать(не попадать) по условию, это конечно здорово, но в чем смысл?
(14) полностью согласен, просто вспомнил про триггеры / хранимые процедуры…. вобщем мега-труд! респект! 😉
(15) вот такой пример: Миграция «Место создания-Центр+Доп.Коды», и тут в бухгалтерии (ЦБ) делают расходную накладную по складу Периф. базы (т.е. она должна попасть в периферику) — все кабздец… начинается «поиск остатков», звонки, выяснения, и потом наконец очередному буху или оператору является «открытие», что так оказывается делать «низзя»… можно конечно наворотить кучу запретов (типа невозможности создания накладной в ЦБ по складу из периф. ИБ), но это решение намного красивее
(15) Простой пример на одном документе «ОтчетККМ». Этот документ выписывается в каждом магазине, но зачем магазину «А» видеть продажи магазина «В», но эти документы создаются в периферийной базе, но вот например «ПеремещениеТМЦ», «Перемещение Денег», «Списание» выписывают в периферийной базе на центральном складе, но попасть эти документы должны каждый в свою периферийную базу. Они должны быть во всех базах, но разделены с учетом их принадлежности к каждой периферийной базе. Есть масса задач которые не решает стандартный УРБД. Мой только дополняет небольшими дополнениями, при этом внося дополнительную головную боль админу(программисту) который это будет обслуживать.
(16) А потом будете выяснять, из-за чего баланс не идёт 🙁 И всех собак на «кривую 1С» повесят.
(15) Настройка штатной миграции позволяет направить документы только в базы-подписчики, а их списком нельзя управлять динамически. В Вашем примере базы L и D будут идентичны центральной ч асти этого объекта. А бывает нужно ввести документ в центральной и направить его в одну из периферийных.
(14) ТИИ в периферийной базе при этом проходит нормально, верно?
У Вас движения в регистре «зеркальны», поэтому «восстановить недостающие» не многим сложнее, чем удалить лишние.
Теперь о движениях регистра. Почему не поставить запрет на миграцию сведений в регистре, и пользоваться следующим алгоритмом:
1) Ввести справочник с реквизитами «База, в которой документ перепровести» и «Документ». В него при записи документа писать ссылку на документ;
2) В документе предусмотреть движения регистров в зависимости от места проведения;
3) После обмена, обрабатывать этот справочник и проводить «новые» документы с отключённым признаком регистрации изменений?
Заодно можно обрабатывать коллизии обмена, о которых УРБД не сообщает впринципе.
(13) Точно, я ошибся, в нете действительно гуляло решение на тригерах. Но это не удобно на загруженных серверах. Но самый большой изврат который я видел на УРБД — трёхзвенка.
ставлю плюс хотя:
подобная идея уже была реализована … не помню правда кем … даже обсуждение было
сам ломал голову над использование урбд (да и до сих пор тоже)
вроде бы все правильно но … как на счет движения документов особенно по партиям
про некоторые отчеты можно забыть
(16) (17) (18) Вообщем смысл понятен, надо так надо.
А скажите Из Центральной путь
Выгрузить -куда?
В Периферийной загрузить — откуда ?
В настройки баз ,
я,делал путь, в кот. выгр. из ЦБ
в ПБ я делал путь загрузки в каталог результата ,
там было пусто .
Из описания я понял что каталог в который я делаю выгрузку из ЦБ — Исходный каталог
Загружаю в ПБ из Каталога результатов , но там пусто ?
тема интересная но сложная, должен быть простой алгоритм для работы!