Не указан файл внешней обработки с подключаемыми процедурами обработчиков событий
Сталкивались? Бывает необходимо, перед заполнением документа из внешней обработки, вызвать некий диалог с предварительными настройками, но к сожалению типовой функционал не позволяет сделать это без записи документа. А если у нас сложный документ с большим объемом данных, который долго пишется? Или мы просто не хотим записывать документ, а только посмотреть результат заполнения? В этой статье я попытаюсь решить данную задачу доработкой типовой подсистемы подсистемы "Дополнительные отчеты и обработки".
Доработку можно сделать через расширение или напрямую в конфигурацию.
1. Добавляем в ТЧ "Команды" справочника "ДополнительныеОтчетыИОбработки" новый реквизит "доп_РежимЗаписи" с типом Строка(50)
2. В общем модуле "ДополнительныеОтчетыИОбработки" вносим следующие доработки
2.1. Функция "СведенияОВнешнейОбработке".
Необходимо для таблицы команд добавить еще одну колонку "доп_РежимЗаписи"
Это позволит в дальнейшем указывать нам нужный режим записи, при вызове данной функции из обработки ДополнительныеОтчетыИОбработки.СведенияОВнешнейОбработке()
2.2. Функция "ТаблицаОтчетовИОбработок"
Необходимо доработать запрос, а именно добавить новый реквизит в выборку из таблицы команд
2.3. Процедура "ПриОпределенииКомандЗаполненияПодключенныхКОбъекту"
Добавим дополнительное условие для отмены записи документа
Обратите внимание как работает типовой функционал.
Если у нас вид обработки "Заполнение формы", то идет вызов команды на сервер (модуль обработки) и запись отключена.
Во всех остальных случаях режим записи - "Записывать".
Мы же добавили новое условие, что если у обработки реквизит "доп_РежимЗаписи" равен "НеЗаписывать" тогда мы устанавливаем режим записи "НеЗаписывать".
Пример вызова из самой обработки:
Часть типового кода я пропустил, думаю тут нет необходимости что либо показывать. Полное описание в документации БСП или в приложенной обработке - примере.
Как происходит заполнение:
Открывается обработка. В событии "ПриОткрытии" на клиенте, нам доступен реквизит "ВладелецФормы" - владелец этой формы.
Мы выполняем какие либо промежуточные действия. Данные берем с реквизитов или объекта формы владельца.
По окончании нужного нам действия, мы заполняем данными форму владельца и закрываем при необходимости.
PS: Доработка простая, можно обойтись реализацией через расширение. Каких либо других способов обойти запись документа без доработки типовой подсистемы я не увидел.
Можно обойтись без нового реквизита, например добавить признак в реквизит "Модификатор", но все равно нужно доработать процедуру "ПриОпределенииКомандЗаполненияПодключенныхКОбъекту", чтобы учесть нужный модификатор, например:
Такой вариант проще, но только если вы не используете типовой модификатор, например для печатной формы "ПечатьMXL".
В приложенных файлах пример подключаемой обработки и расширения с данной доработкой.
Часто замечаю, что разработчики сейчас, реализуя во внешней обработке какой-то функционал, которого нет в конфигурации, и который никак нельзя туда вставить, обходятся модулем формы этой внешней обработки.
Даже самые сложные куски кода, которые исполняются на сервере (потому что в этих кусках есть методы платформы, доступные лишь НаСервере (даже не в толстом клиенте) или потому, что там идет обращение к сторонним механизмам, доступным лишь на серверной машине) пихают в модуль формы, заполняя его (модуль формы) хитросплетениями функций и процедур.
Казалось бы, мучайте вы модуль ОБЪЕКТА вашей внешней обработки! А в модуле формы оставьте лишь код, обслуживающий интерактивные "дела".
НО! С другой стороны, обработку ведь можно открыть в толстом клиенте. И если в модуле объекта был расчет, что код будет исполняться на серверной машине, произойдет мерзкий пшик. А вот в модуле формы пшик не произойдет, потому что в модуле формы есть директивы компиляции.
Спасибо всем, кого этот принципиальный теоретический вопрос не оставит равнодушным.
(0) "обработку ведь можно открыть в толстом клиенте. И если в модуле объекта был расчет, что код будет исполняться на серверной машине, произойдет мерзкий пшик."
Вот я лично вот этого не понял. Почему произойдет пшик?
(1) >>не надо дергать РеквизитФормыВзначение
ну да.. если идет обращение из интерактивной части к методам в модуле объекта, то самый распространенный способ, и чуть ли не единственный - обратиться к реквизиту формы, в котором лежит ДанныеФормыСтруктура (объект "этой" обработки), и, преобразовав его в значение, обратиться к его методам (мама дорогая, звучит уже как извращение). Ну и что с того? Ну дернем лишний раз. Разве вендор позиционирует это как что-то нежелательное, без чего следует по возможности обходиться? Подскажите же тогда, все-таки, где про это почитать, плз.
>>меньше кнопок, чтобы добраться до кода в конфигураторе
вот тут не понял. В смысле, во время отладки или анализа кода? Так, опять же, вендор в типовых модулях еще не такие хитросплетения устраивает, перенося зачастую выполнение одной рутинной операции между четырьмя-пятью модулями разного типа. И его не смущает, что анализ или отладка такого кода несколько усложняется.
(2) >>Почему произойдет пшик
ну как же! Если в коде идет расчет на выполнение на сервере, например обращение к серверному модулю, не имеющему флага "Вызов сервера", а код выполняется в толстом клиенте, то будет ошибка при попытке выполнения. Этим граблям уже сто лет в обед.
Это "дорогая" операция в плане ресурсов. И если дергаем в цикле - то можно реально сильно просадить производительность. Сталкивался. Пришлось из модуля объекта обработки перетаскивать дубликаты функций во все формы, тогда стало шустро работать.
(4) так. дорогая операция. понял. не зря звучит как извращение, оказывается :) В цикле, конечно, делать не будем, но все равно. ценная информация, спасибо.
Вот в БП появились с некоторых пор специально созданные формы-"контейнеры" с нагромождениями клиентского функционала в своих модулях. Их, вроде, и не открывают. Объект формы получил, экспортные методы выполнил - и про форму "забыл". Но это, конечно - немножко другое. Какая-то логика есть. А с серверными методами - вообще непонятно. В модуль объекта их пихать, как мы выясняем - не комильфо по целому ряду причин, и в модуле формы тонны серверного функционала лепить - тоже странно потом лицезреть такие вирши. Ну не для того изначально существует форма, механизм для вывода информации, способ реализации интерфейса машина-человек.
Получается, мощный серверный функционал во внешней обработке неуместен. И это логично. Внешняя обработка подойдет, чтобы показать что-то, чего нет в конфигурации, какую-то мелочь, для которой дорабатывать конфу или лепить расширение нецелесообразно.
А все эти супер-пупер-обработины для, я не знаю, интеграции с яндекс-картами или там администрирования БД и программно-аппаратной связки - по сути ПРОФАНАЦИЯ!
В следующий раз когда увижу крутую обработку со всякими плюшками, буду презрительно комментировать: "понавертел-то, понавертел. "
(3)
1. "Если в коде идет расчет на выполнение на сервере, например обращение к серверному модулю, не имеющему флага "Вызов сервера""
А что в УФ можно с клиента дергать процедуры такого модуля? Причем здесь именно толстый клиент и внешняя обработка?
2. "Получается, мощный серверный функционал во внешней обработке неуместен."
Это еще почему? На безрыбье, как известно, и рак - рыба. Никакой принципиальной разницы как определить место выполнения процедуры (на сервере или на клиенте) нет. В конце оно все равно размещается либо там либо там.
"Форма не предназначена быть на сервере" - это таки да.
"Модуль объекта более логично иметь на сервере" - и это таки да. Но чем помешало разделение процедур на клиентские и серверные в модуле формы - понять не могу. Просто представь, что форма и модуль формы есть разные сущности. И все станет на место. Конечно для снобов можно было бы и модуль формы визуально разделить на серверную часть и клиентскую. Но! Буду банален. Вам таки шашечки или таки ехать?
(6) 1. >>А что в УФ можно с клиента дергать процедуры такого модуля?
Можно дергать процедуры такого модуля из методов, написанных в модуле объекта внешней обработки. При условии, что эти методы выполняются не в толстом клиенте.
Но мы уже выяснили, что размещать в модуле объекта такой серверный функционал - не комильфо.
2.>>Это еще почему?
Вроде я все разложил по полочкам. В модуле объекта - плохо, и в модуле формы - не есть хорошо. Других модулей у внешней обработки просто нет.
>>"Форма не предназначена быть на сервере" - такого я не писал. И форма находится на сервере регулярно.
>>"Модуль объекта более логично иметь на сервере" - такого тоже не писал. И оставляю юзеру право работать с внешней обработкой в том типе клиента, какой ему удобнее. Т.е. оставлять возможность, что модуль объекта будет выполняться в толстом клиенте со всеми вытекающими.
>>Но чем помешало разделение процедур на клиентские и серверные в модуле формы - понять не могу/
Нет-нет, тут прошу меня правильно понять. Разделение кода мне по душе (как программисту). Сабж-то не об этом.
>>для снобов можно было бы и модуль формы визуально разделить на серверную часть и клиентскую
да ну нафиг :) и так нормально
(7) что-то вы пессимист какой-то. Напишем так: размещать серверные процедуры в модуле формы очень хорошо. Размещать в модуле объекта тоже неплохо.
Так что вы нас не запугаете.
(8) >> размещать серверные процедуры в модуле формы очень хорошо
Вот оно! Значит, в модуле объекта - тоже неплохо, только надо помнить, что возможны ситуации, когда наш код будет выполняться не на серверной машине, а на клиенте (толстом), так что здесь все что угодно из того, что можно сделать на сервере, вы уже не сделаете. Неполноценный тут "сервер".
А
>>размещать серверные процедуры в модуле формы очень хорошо
(!!)
То есть когда люди размещают мощные серверные механизмы или тонны кода прямо в форме - это нормально, оказывается! Я же об этом и спрашивал: какие сейчас актуальные правила хорошего тона? А то вижу у людей крутые реализации - в виде внешних обработок, а сам себя ограничиваю, когда пишу в модуле объекта, и уж тем более - когда пишу в модуле формы, что б не выглядеть профаном, у которого все подряд понапихано в форму.
Какие-то же рекомендации по этому вопросу должны быть? Мнение уважаемых форумчан - это здорово, но как же мнение вендора?
(9) про толстый клиент забудьте. Помнить про него не надо. Вот я 5 лет пишу это обработки, про толстый клиент вообще ни разу не вспомнил.
ИМХО не стоит здесь сильно теоретизировать.
(Мой) здравый смысл говорит:
если обработка внешняя и предполагаются разные режимы использования (УФ/ОФ/программный вызов); то общий код в модуле объекта;
для внутренних объектов код разносим по ОМ, модулям менеджеров, объектов и форм.
(10) >>Помнить про него не надо
да нет уж, только я забудусь и напишу что-то, чему место только на сервере, так либо потом метод моей обработки используют в регл. задании, где запускается сеанс в толстом, либо юзер откроет программу в толстом.
И начинают сыпаться ошибки, в первую очередь потому, что не видны общие модули "Сервер".
Так что если Вам везет - я рад, а остальным судьба не забываться и быть внимательней.
ну там уж смотря что программно будем вызывать во внешней обработке. Бывает, нужны процедуры в модуле объекта, а бывает - экспортные клиентские методы в одной из форм обработки. Бывает также, что во внешней обработке необходимо реализовать что-то, что должно выполняться только на сервере, а обработка может быть использована в сеансе, запущенном на толстом клиенте, так что приходится вызывать экспортные клиентские процедуры из формы внешней обработки, а вот уже в этих процедурах вызвать стопудово-серверные (благодаря директивам компиляции) процедуры, расположенные в модуле этой формы.
Так что вариантов использования внешней обработки много, и все это - уже частные случаи сабжа.
(15) делайте все стопудово-серверные. Они же спокойно выполняются на толстом клиенте. ТО есть не пишите в модуль документа функции Вопрос, Предупреждение и ОткрытьФорму. А в чем смысл запуска толстого клиента? И вот это непонятно "либо юзер откроет программу в толстом". КАкого хрена вы разрешаете такие вещи юзеру?
(16) нет-нет-нет.. никто не собирается использоваться интерактивные методы платформы там, где речь идет о серверном функционале
>>делайте все стопудово-серверные
да как я их такими сделаю в модуле объекта внешней обработки? Директив компиляции же нету!
>>Они же спокойно выполняются на толстом клиенте
не соглашусь. Во-первых, не все методы платформы, которые доступны на сервере, доступны также и в толстом клиенте, хотя, наверное, примеры найти будет сложно, а во-вторых, бывает, что нужно выполнение кода на серверной машине просто потому, что только на этой машине есть какие-то сторонние программные ресурсы или хранилища.
>>А в чем смысл запуска толстого клиента?
да никакого там смысла, имхо, но вот, представьте, есть юзер, и у этого юзера нет прав на запуск тонкого клиента. По разным причинам. Запуск толстого клиента не запрещен в принципе. Кто угодно, использующий мою обработку, может открыть ее в толстом. Платформа же универсальна.
>>КАкого хрена вы разрешаете такие вещи юзеру?
Смеетесь? С каких пор это табу?
(17) И потом, я не админ.. диктовать заказчику политику использования ПО и настройки не могу. Не я "какого хрена" разрешаю. Или не разрешаю. Да, я могу давать рекомендации. И только.
(17) все должны работать в тонком клиенте. И только двое каких-нибудь гуру-администраторов, вот им надо оставить возможность в толстом. Так на всякий случай.
(19) оу. да что Вы, я Вас умоляю. В той же УТ, ЕМНИП, некоторые визуальные редакторы работают только в толстом. При попытке обратиться к ним в тонком будет предложение перезайти в базу в толстом.
По идее выбрать место где будет находится код - одна из задач разработчика.
Если код будет вызываться извне - в модуль обработки.
Если не будет или не должен - в модуль формы.
(22) ну когда переписана часть конфы в толстом клиенте и есть часть пользователей которая работает в тонком клиенте то это еще сложнее. Нужно понимать как код отработает в тонком клиенте, толстом клиенте и толстом в управляемом приложении))
(24) Пишите код под УФ сразу и все будет работать, есть только несколько нехороших мест, где надо учитывать клиент.
(23) >>выбрать место где будет находится код
ну так вот как раз сейчас разговариваем, где размещать серверный код. Выбираем-с.
>>Если код будет вызываться извне - в модуль обработки.
>>Если не будет или не должен - в модуль формы.
т.е. предлагаете всегда, когда обработка предназначена для интерактивного использования (не для вызова "извне"), ВЕСЬ серверный код помещать в модуле формы?
(24) , (25) бывает же, когда приходишь к заказчику - а у него УЖЕ часть конфы переписана под толстый. Тут уж выбирать не приходится. Соглашусь.
(26) Ну что бы попасть в модуль объекта и жить в нем надо будет делать экспортный модуль. Если к нему никак кроме формы доступа быть не должно, то и этого метода быть не должно, тогда да, все в модуль формы.
Все зависит от задачи и еще раз повторю: выбрать место где будет находится код - одна из задач разработчика.
В файловом режиме 1С работает, а в серверном не работает, клиент толстый. Пишет:
Ошибка при вызове метода контекста (ПолучитьФорму): Неизвестное имя формы. Имя: "ВнешняяОбработка.МаяОбработка.Форма.УправляемаяФорма".
Как сделать чтобы в серверном работала?
(20) Как сделать чтобы было клиент? Как я понял в файловом варианте само делается, потому что там нет сервера.
в файловом варианте есть сервер. но поскольку он крутится на твоей локальной машине, то и позволяет открыть окно настроек.
К (0). Из внешнего модуля так вызывается:
может мы чего не поняли в твоей задуме?
короче. твоя печатная форма должна быть создана по технологии внешних обработок 8.2
только тогда ты сможешь открыть ее форму.
делается это так:
Вот этого нужно тебе?
(41) Не понял как это может помочь открыть форму внешней обработки. Это для типовой УТ? Похоже не то что нужно
(47) что конкретно тебе непонятно? ты делаешь дополнительную печатную форму для какого то документа. правильно?
(44) Пишет: Ошибка при вызове метода контекста (ПолучитьФорму): Неизвестное имя формы. Имя: "ВнешняяОбработка.МаяОбработка.Форма.УправляемаяФорма"
(48) Да, но в той статье написано как сделать дополнительную печатную форму, это я сделал, работает.
Теперь мне надо открыть ее форму.
ищи в своей обработке "ДобавитьКоманду(ТаблицаКоманд,"
и пиши туда вместо ИМЯ_ТВОЕЙ_ФОРМЫ имя формы как она у тебя обзывается в обработке
(56) ровно то, что я написал. ему надо сделать внешнюю печатную форму для УТ11, которая прилепляется к нужным документам штатными средствами без изменения конфы и позволяет перед печатью открывать окно с некоторыми настройками.
но судя по тому, что ТС молчит, то предположу что он не осилил как же это сделать. видимо придется ему предложить купить эту форму ))))
(51) Этот код не работает. ДобавитьКоманду - такая процедура не определена.
(57) Вообще-то не для УТ11. Интересует как открыть форму в принципе, "с нуля"
(52) Код не работает.
Ошибка при вызове метода контекста (ПолучитьФорму): Неизвестное имя формы. Имя: "ВнешняяОбработка.МаяОбработка.Форма.УправляемаяФорма"
Почему-то в пятницу не работало. 1с перезапустил, заработало.
Вот так тоже рабюотает:
Вот так тоже теперь работает:
Что за фигня! В пятницу не работало, а сейчас работает без всяких дополнений! Всего-то платформу перезапустил
: Процедура или функция с указанным именем не определена (ПодключитьВнешнююОбработку)
(70)а давай я тебе по руке погадаю? Тыж меня в телепаты записал.
(71) твой код. Пишется ошибка.
Закомментированная строка не работает. Переделал как во второй строке, ошибку не выдает:
(67)Если предполагать, что ты используешь код из (67), дополнив его куском кода из (72), то у меня разрыв шаблона - метод Подключить имеет доступность "Сервер, внешнее соединение", хотя у тебя выставлено &НаКлиенте.
Ты занимаешься мозгоимением??
Третий косяк: Если взять другую обработку и задать ей имя "МаяОбработка", и открыть ее форму из той процедуры, то всё равно откроется форма старой обработки. Тоесть она как-то зарегистрировалась под этим именем, и не пойму когда и как она это сделала
(79)ты каким-то чудом вызываешь метод "Печать" из одной внешней обработки, а потом хочешь открыть другую внешнюю обработку "tmp.epf"??
А как ты вызываешь "Печать"?
(80) Из общего модуля вызываю:
хз, чего там у тебя как работает, но (74) не должен работать: &НаКлиенте и ВнешниеОбработки.Подключить не должны вместе дружить.
Еще раз: в (44) код достаточен для твоей задачи. "ОткрытьОбработку(Команда)" - это вызов по команде/кнопке на форме.
Открыл форму, сделал настройки, там же нажал кнопку/команду печать.
(84) Чтобы нажать кнопку на форме, нужно сперва открыть эту форму, а она не открывается. А вообще вызов внешней обработки и ее метода "Печать" нельзя менять. И почему работает ВнешниеОбработки.Подключить я не знаю. Могу выложить обработку чтобы посмотрели
(84) Вот выложил: http://ifolder.ru/29092486
Кнопка на обработке открывает такую же обработку и вызывает "Печать()". И твой код не работает.
(86)
ВнешниеОбработки не доступно в тонком клиенте
ПодключитьВнешнююОбработку это метод объекта. чтобы его вызвать, нужно сначала получить объект с помощью РеквизитФормыВЗначение. но сделать это можно только на сервере
а вообще зачем всё это нужно?
(88) У меня в ТОЛСТОМ клиенте
Этот метод вызывается в модуле объекта, тоесть получать объект не нужно, он уже есть.
Нужно просто разобраться. Почему оно не работает!
И как могут работать два метода ПоместитьФайл и ВнешниеОбработки.Подключить в одной процедуре. У них же разная доступность на клиенте и на сервере!
(90) ты для какой конфы это безобразие ваяешь?
для УТ11 я тебе дал все карты в руки. у меня все работает, подключается, открывает форму настроек и печатает.
(91) если указать имя обработки "МаяОбработка", то работает. А если поменять имя и указать там новое имя, то не работает.
Выяснил что нужно хотябы раз открыть форму обработки через меню файл, и выполнить команду:
Тогда в следующий раз форма открывается из модуля объекта нормально. Но как сделать чтобы не нужно было открывать ее в первый раз вручную?
Я не хочу быть самым богатым человеком на кладбище. Засыпать с чувством, что за день я сделал какую-нибудь потрясающую вещь — вот что меня интересует. Стив Джобс, 1996 г.
@programmist_1C
Ошибка "Внешняя обработка отладки, загружаемая из файла на диске, не поддерживается." Ошибка при отладке правил конвертации 2.1 в новых конфигурациях
Сделал я правила обмена в КД2.
Решил их отладить и получаю ошибку:
Искал решение в интернете, но как-то неудачно.
А отлаживать-то нужно.
Решение:
Обработка "УниверсальныйОбменДаннымиXML.epf". То есть та обработка, с помощью которой мы хотим отлаживать.
Идем в модуль обработки, в процедуру
Процедура ИнициализацияВнешнейОбработкиОбработчиковСобытий(РаботаВозможна, ОбъектВладелец) Экспорт
Ищем где вызывается исключение "Внешняя обработка отладки, загружаемая из файла на диске, не поддерживается".
На всякий случай скрин:
Результат:
попробовал обработку.
не все сотры переносятся, не заполняется организация сотрудника, ФИО физ лица. пробовал по разному выгружать. может я что-то не так делаю?
Выгрузка кадровых данных из ЗУП 2.5(релиз 2.5.99.2) проходит успешно, при попытке загрузить данные в БУ3.0(релиз 3.0.43.124) через обработку "Универсальный обмен в формате XML(2.1.8)" возникает ошибка загрузки:
UPD 24/02/2016
Слегка переделал обработку выгрузки данных из ЗУП 3.0 в БП 3.0.
Теперь при переносе организации, от самой организации переносятся только ее основные реквизиты: Наименование, ИНН, КПП и несколько других важных. Адреса, коды налоговых огранов и тд. и тп. не переносятся чтобы не затирать данные в базе приемнике, так как у некоторых в ЗУП 3.0 одни данные, а БП 3.0 другие.
PS
Замечено, что на БП выше версии 3.0.43.100 обновили обработку "Универсальный обмен данными XML" из-за чего та перестала корректно загружать данные (не срабатывает событие окончания загрузки параметров), 1С пока молчит, рекомендую использовать для загрузки данных, старую версию обработки "Универсальный обмен данными XML", которую можно экспортировать из БП 3.0.43.100 и ЗУП ниже 3.0.25.74.
Ошибка при выгрузке данных из зуп 2.5. Выбран только список сотрудников
Обработка выгрузки ВыгрузкаДанныхИзЗУП25130БП3059_INFOSTART.epf
Начало выгрузки: 31.08.2018 12:14:05
(3) nick_189, примеры ругательств в студию!
на счет сотрудников ничего сказать не могу, одно точно знаю, что всех она и не тянет, так как, как правило берутся отраженные в кадровых документах. Можно скопом выгрузить вообще всех и для этого есть галочка внизу.
(4) imbaZeratul, не могу согласиться с этим утверждением.
На ТЕСТОВОЙ БП 3.0.27.7 проделал следующее. Открыл регистр сведений ФИО. Нажал Ctrl+A (выделить все), подождал, жмякнул кнопку удалить, подождал. Регистр ФИО пуст. Выгрузил в своем случае кадровые документы от 01.01.2012 из ЗУП 2.5.76.1. В БП 3.0 открыл обработку универсальный обмен данными в XML 2.1.7. Выбрал вкладку загрузки данных, включил режим на клиенте, жмякнул кнопку загрузить, выбрал ранее выгруженные файл с данными. После загрузки в регистре ФИО снова появились фамилии.
В процессе загрузки возможна ругань у некоторых документов, но это вполне нормально, так как не везде учет ровный. У меня у самого один прием на работу орет так как записи в регистре получаются не уникальными (ранее запись сформировалась при загрузке свода на начало 01.01.2012).
И так на заметку, все делаю под админом, как у простых смертных не знаю, обработку не допиливаю так как идет очередной намеренный срыв перехода на БП 3.0 какой был и при переходе на БП 2.0. Хороших вам переходов и адекватной бухгалтерии.
Если в параметре учета БП 3.0 стоит расчет зарплаты "во внешней программе" то при импорте кадровые данные не записываются, а если поставить в "этой программе" то данные загружаются нормально, можно ли как то это обойти?
(8) nick_189, читайте порядок загрузки как написано в топике. Никаких шаманств с настройками, где идет учет, не нужно.
Учитывайте тот факт, что все это ИЗВРАЩЕНИЕ с данными ибо сама 1С не предусмотрела таких перегрузок и никак не облегчает процесс.
Только что проверил выгрузку ЗУП 2.5.78.1 -> БП 3.0.30.12, все работает как и задумано.
Как бы автор со мной не спорил, но у меня данные записываются только если параметре учета Сотрудники и зарплата стоит "В этой программе". А так все работает. Спасибо за обработку.
(12) nick_189, (13) blizz, ну что сказать, нужен тогда порядок как вы эту ошибку ловите в картинках, не плохо бы и выгруженные данные получить, ну хоть с демо базы к примеру
Обновил правила переноса в обработке под БП 3.0.32, ну чтобы покрасивше данные переносились.
В свете подготовки перехода на ЗУП 3.0 хотелось бы узнать у вас всех, может кто осваивал метод переноса кадровой инфы посредством планов обмена и может у кого-то есть готовый способ, который можно заюзать и может быть в последствии модифицировать под себя. С нуля как-то ленно все начинать))) Даже ленно поискать в инете)) Работы навалило выше крыши))
(19) prochka, тестировал только на ПРО версии ЗУП и потому ограничение такое.
Даже понятия не имею чем базовая от про версии отличается.
Добрый день!
Бухгалтерия предприятия, редакция 3.0 (3.0.39.67) пишет - Не указан файл внешней обработки с подключаемыми процедурами обработчиков событий
Не совсем понятно ЗУП 3 -> БП 3 нужны наверное пред настройки ?
как обработка узнает куда выгружать (где сохранить файл или где БП3)?
У меня ругается
И еще ВыгрузкаКадровыхДанныхДляБП30 для ЗУП 2 ?
нет управляемой формы ?
(28) ssn5810,
ВыгрузкаКадровыхДанныхДляБП30 - для ЗУП 2.5 -> БП 3.0
ВыгрузкаДанныхИзЗУП30ВБП30_УФ_INFOSTART.epf - для ЗУП 3.0 -> БП 3.0
Соответственно ВыгрузкаКадровыхДанныхДляБП30 нужно открывать в ЗУП 2.5
ВыгрузкаДанныхИзЗУП30ВБП30_УФ_INFOSTART нужно открывать в ЗУП 3.0
И та и та обработки на выходе дают XML файл, который вы сами загружаете в БП 3.0
Где вы запускали обработку, что она у вас дала сбой? Какая база данных?
Уважаемый автор, подскажите, пожалуйста, выгружаются ли из Зуп 3 в БП 3 документы Ведомости в Банк, Ведомости в кассу, Перечитсления НДФЛ в бюджет . Спасибо!
(35) xten, ведомости точно нет, по НДФЛ что-то было.
В общем та все можно допилить, расширив возможности обработки
При загрузке выдает ошибку скрин1 пробовал и штатной и старой из бух. Сотрудники перенеслись, но должность и подразделения не перенеслись Скрин Перенос из ЗУП 3.1 в ОБщепит 3.0 (Бухия в ней не тронута) только штатных сотрудников и кадровых документов. Справочники должности и подразделения не потянусь. В чем может быть ошибка?
(37) KOVRUS, ну судя по всему должности и подразделения у вас перенеслись, однако они же и не показываются у вас, когда вы открываете список сотрудников, колонки пустые.
По вашему скрину видно, что у вас валится с ошибкой обработчик события ПослеЗагрузкиДанных именно в нем есть такой программный код
Именно этот код и прописывает так сказать сведения о подразделениях и должностях, о чем говорит комментарий в коде
Вот регистр ТекущиеКадровыеДанныеСотрудников у вас и не обновился однако при загрузке из-за некой ошибки.
Посему, я соорудил отдельную автономную обработку для БП 3.0 которая содержит в себе аналогичный код.
Скачайте и попробуйте запустить ее, потом скажите, на какой ошибке она валится.
Спасибо за ответ! Обработку запустил,проходит без ошибок, не помогло, и справочники все таки не перенеслись. Пустые Скрин и этот тоже Скрин2 И подскажите, что нужно сделать что бы обработка загрузки завершалась корректно?
Зуп 3.1.1.98=>бп 3.0.46.16 Поможете понять в чем причина?)
Что бы делали чтобы получить такую ошибку?
Я так предполагаю, что вы пытаетесь настроить прямой обмен данными между конфигурациями и что-то идет не так.
Для начала я бы обновил обе базы данных до актуальных релизов и попробовал повторить то что вы делали ранее.
выгрузили в файл с помощью обработки и встроенной обработкой Универсальный обмен данными в формате XML пытался загрузить. После этого вылезла такая ошибка
(43) чтобы не гадать, я решил, что пора бы подкорректировать правила переноса данных внутри обработки ЗУП 3.1 => БП 3.0, так как версии конфигураций ушагали вперед, а там видно будет. Отпишусь.
(43) Столкнулся с такой же проблемой. Оказалось, что в регистре сведений "ПравилаДляОбменаДанными" загружены правила обмена и регистрации от какой-то версии ЗУП 3.0, а на дворе уже 3.2. Кто и когда их туда загрузил - неизвестно.
Я установил использование правил из конфигурации и организация стала выгружаться нормально.
(45)
Правила поправил, запилил как отдельную обработку, саму обработку выложил тут.
Проверил выгрузить данные из ЗУП 3.1.2.105 по всем пунктам, все выгрузилось.
Потом получившийся файл загрузил при помощи встроенной обработки "Универсальный обмен данными в формате XML" в БП 3.0.47.26, все загрузилось без проблем.
Добрый день.
Имеется задача выгрузить всех физ.лиц с их данными из ЗУП 3.1 в БП 3.0, какую обработку качать?
Если будут проблемы, то пишите.
Поправлю если чего не так.
Новую версию на почту кину.
Здравствуйте.
Вот с чем столкнулся.
В ЗУП 3.1 не "КлассификаторБанков", а "КлассификаторБанковРФ" (3.1.2.272). Пока так. Так уж получилось,что
БП 3.0.51, а ЗУП только 3.1.2.
Причем Правила проверяют релиз БП, а вот проверкой релиза ЗУП пренебрегают ;)
Но мне как-то неуютно следующее: "Если Не Параметры.ОтменаЗагрузки Тогда // Если в программе отключен кадровый учет, то мы сами принудительно обновляем регистр сведений ТекущиеКадровыеДанныеСотрудников (. )".
Хотя и не нашел, где этот параметр, но в любом случае хотелось бы не тащить в БП ничего личного.
Нельзя ли это дело отключить флажками формы?
Спасибо.
Ну есть такое дело.
Я в основном подгоняю обработку пот текущии версии или под тестовые, которые уже скоро появятся в релизе.
Обработка "ВыгрузкаДанныхИзЗУП3102ВБП3047_УФ_INFOSTART.epf" в вашем случае не подходит?
Но мне как-то неуютно следующее: "Если Не Параметры.ОтменаЗагрузки Тогда // Если в программе отключен кадровый учет, то мы сами принудительно обновляем регистр сведений ТекущиеКадровыеДанныеСотрудников (. )".
Хотя и не нашел, где этот параметр, но в любом случае хотелось бы не тащить в БП ничего личного.
Нельзя ли это дело отключить флажками формы?
Спасибо.
Мозги мои много чем загружены.
По памяти вроде помню, что данный блок нужен тогда когда вы переносите кадровые данные сотрудников. Этот же блок просто берет и обновляет данные регистра текущих кадровых состояний сотрудников, но уже на основании тех данных, что проведены в БП. Из ЗУП, если переносить кадровые документы, тянутся сотрудники, а те в свое время тянут за собой физиков, которые тянут за собой другие данные присущие физикам.
Под личного, что вы понимаете? Что мешает?
(53) Под "личным" я понимаю "Личные данные" физ. лиц, которые полезут в Бухгалтерию при переноске кадровых данных. Что противоречит несколько нашей политике: "Личные данные только в ЗУП.
Эмм. Как правильно этот ПКС изменить? Может, просто грохнуть? А то он и дальше гадит.
Извините за дилетантские вопросы :)
Вот поборюсь с выгрузкой, и попрошу совета: в каком месте перехватить табличную часть для некоторой трансформации в отдельном модуле. Мне важно именно при выгрузке, дабы в самой БД осталось как задумано разработчиком.
Если конкретно: в ЗУП Подразделения "деревом" (3 уровня), в БП - простой гладкий список без иерархии. Так давно повелось, и совсем не хочется губить БД (в БП3). Надо всего-то по Соответствию подменить ссылки.
(56) Можно попробовать на живую в текстовом файле правил переноса данных заменить текст ТолькоНациональныйАдрес на АдресТолькоРоссийский.
До ЗУП 3.1.3 реквизит ТолькоНациональныйАдрес назывался как АдресТолькоРоссийский.
Или же это же самое сделать в конфигурации Конвертация данных, только для этого нужно в конфигурацию Источник (она же ЗУП) закачать структуру метаданных от ЗУП 3.1.2
(57) Да, спасибо. Помогло. Файл сформировался.
Теперь для полного счастья мне надо отловить Табличные части, и поработать с ними отдельно. До свертки - и так проводок дофига.
Без этого никак: структура Подразделений очень даже разная, 1:1 переносить нельзя.
Совет не дадите?
(62) сейчас нет. Насколько память не изменяет, то есть правила выгрузки данных и там в них описаны алгоритмы выгрузки кишков документов, вот там можно и шаманить с табличными частями как вам нужно.
Под "личным" я понимаю "Личные данные" физ. лиц, которые полезут в Бухгалтерию при переноске кадровых данных. Что противоречит несколько нашей политике: "Личные данные только в ЗУП.
Тут спорно все ибо в той же БП делаются авансовые отчеты, доверенности, приходные и расходные ордера и там нужны те же паспортные данные. Выгружается и так необходимый минимум.
ФИОФизическихЛиц
ГражданствоФизическихЛиц
ДокументыФизическихЛиц
СведенияОбИнвалидностиФизическихЛиц
Контактные данные.
Могу конечно параметризировать: ГражданствоФизическихЛиц, ДокументыФизическихЛиц, СведенияОбИнвалидностиФизическихЛиц, Контактные данные.
ФИО смысла нет трогать.
Тут спорно все ибо в той же БП делаются авансовые отчеты, доверенности, приходные и расходные ордера и там нужны те же паспортные данные. Выгружается и так необходимый минимум.
ФИОФизическихЛиц
ГражданствоФизическихЛиц
ДокументыФизическихЛиц
СведенияОбИнвалидностиФизическихЛиц
Контактные данные.
Хм. Прошу не обижаться, но это совершенно неверное представление о "Личных данных". От идентификации со-трудника никак не уйти, мы еще не готовы обращаться к людям по ИНН ;)
Когда мы говорим о "Личных данных", речь идет о тех сведениях, которые вовсе не обязательны для работы. Паспорт, конечно нужен хотя бы для выписки доверенности, как и многое другое (номер банковской ПК и т.д), но каждый раз необходим вопрос: "С какой целью, гражданин, интересуетесь?". Иначе само понятие о сохранности личных данных потеряет всякий смысл. В конце-то концов, ни двери, ни заборы противотанковыми не делают, их основное предназначение - воспрепятствовать проникновению посетителям не нужным, праздношатающимся, глупым, и не дать возможности слишком ушлым сослаться на "нечаянно".
С этой точки зрения и гражданство , и инвалидность суть знания избыточные. Да и вообще, кадровики и снабженцы общаются с разными людьми, и необходимость синхронизировать Контактные данные совершенно неубедительны.
Но это я забрел в сторону, извините.
Конкретно: как этот ПКС должен выглядеть? Или вообще.выкинуть эти метаданные из обмена? Жалко же, вдруг пригодятся ;)
skype: live:di-sem
Читайте также: