Получить форму на сервере 1с #790823

Перейду сразу к задаче: Нужно разработать регламентное задание для ЗУП что бы пересчитывать документы начисления. У 1С в последних типовых так принято что все серверные функции расположены в модулях формы Соответственно что бы вызвать нужную процедуру по расчету и заполнению документа начисления на клиенте проблем нет, получил форму, вызвал экспортную серверную процедуру которая в модуле формы и все прекрасно. Но вопрос как это сделать со стороны сервера. Можно все сделать на сервере но нужны данные формы, может их можно как то получить на сервере без использования клиента, форма то все равно при открытии заполняется на сервере. Поделитесь опытом, пилить типовую не предлагать, представим что она закрыта и трогать ее нельзя :)

Что конкретно из той статьи я должен был узнать? Я в курсе существования функций РеквизитФормыВЗначение ЗначениеВРеквизитФормы ДанныеФормыВЗначение ЗначениеВДанныеФормы только как они помогут с решением вопроса?

Еще раз: 1. Нет клиентского вызова (так как регламентное задание) 2. Нет данных формы (как их получить на сервере)

Форму можно передать в качестве параметра процедуры в серверный модуль. Если же в модуле формы находишься есть такой прием как объявлением директивы &насерверебезконтекста.

Не вижу проблем вызвать с сервера экспортную серверную процедура модуля формы. Получаешь форму и вызываешь...

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

что значит пересчитывать документы начисления? Почему это не сделать на сервере? Берешь адаптируешь функции для сервера и помещаешь в общий модуль или в модуль менеджера.

кОкОй-то бред. переходишь с клиента &НаСервере и юзаешь/передаешь свою форму как хочешь/куда хочешь

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

форма не хранит никакие данные, а только их отображает. Скопируй все процедуры в свой модуль и рассчитывай там что нужно

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

А. Еще вспомнил как приходилось делать. Получал форму через ОткрытьФорму и передавал ее в функции. Но это конечно вообще изврат.

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

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

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

на досуге посмотрите как-нибудь формы и их модули типовых конфигураций erp, зуп 3 или ут 11, и Вы для себя многое откроете, что форма хоть и не хранит в себе данные но при работе большую часть использует свои реквизиты  а не объекта, поэтому и все процедуры и функции построены вокруг них.

Хорошо что поняли, только не ОткрытьФорму, а ПолучитьФорму, открывать ее не обязательно и да, дальше можно вызывать экспортные процедуры формы, но я Вас разочарую что ОткрытьФорму что ПолучитьФорму это функции вызова клиентской части а не серверной. Поэтому прежде чем рекомендовать читаем топик и мат. часть.

Неужели до сих пор находятся те, кто так и не усвоил, что можно (и нужно) делать на клиенте, а что - на сервере? Имхо, это же азы. Форма ТСу не нужна от слова совсем.

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

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

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

что бы дать тебе возможность заработать денег :)

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

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

Еще раз резюмирую, что бы новым участникам не читать все что выше, там нет полезной информации: Есть обработка которая получает форму документа начисления из ЗУП 3 и вызывает экспортную процедуру этой формы по перезаполнению и перерасчету Так как это длительная процедура, хотелось бы ее поставить выполняться на автомате в регламентном задании, но проблема в том, что весь расчет построен на реквизитах Управляемой формы (желающие предложить переписать могут заглянуть в функцию формы ПерезаполнитьДанныеФормыНаСервере, и увидеть что переписывать нужно еще и функции в общем модуле расчета) Возможно решения нет, но это самый простой ответ :)

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

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

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

создай структуру с теми же полями какие у формы. И ее подсовывай в общий модуль этот. Что ты паришься из-за ерунды?

А зачем в массовом порядке пересчитывать документы начисления?

какой-то наплыв дерзких, весна видать близко :) учи мат.часть или запили свою 1С с параметризуемыми блекджеками и куртизанками

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

напиши "робота" Бендера :), будет тебе доки открывать на клиенте и кнопки нажимать там же

Не у всех мир ограничен возможностью заработать, заработать можно по разному, но можно еще от этого получать удовольствие, я  как раз на этом уровне :) поэтому если на вопрос какой смысл мне отвечают: что бы больше зарабатывать, в ответ звучит симметричное высказывание, поэтому не обязательно те кто думают не как Вы являются "дерзкими" (так можно и в философы податься) как то писал, и дорабатывал разработку (вроде бы xUnit1C) но там костыли были еще те а заказчику нужно было что бы все было обложено тестами, в целом получилось не плохо, однако это было на 8.2 УПП в которой все можно было дергать через модуль объекта

Многие молятся на типовые 1С, не допуская мыслей сомнения в их идеальности. А чем не устраивает планировщик винды?

Не жди от 1с того, что в ней нет, а используй то, что есть)

+А ты не думал, что функции эти находятся именно в модуле форме для того, чтобы их и можно было использовать только на клиенте? Хошь использовать на сервере, используй то что модуле объекта(ну или в менеджере). Не подходит? Ну тогда переноси то что нужно в свою обработку ручками.. А то, понимаешь, хочется ему.. P.s. 1с не идеальна, но в большинстве случаев выкрутиться можно.

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

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

Все, кто раньше (до ЗУП 3.0 и УТ 11) работали с типовыми так говорят. И я так говорила. Каким нужно быть недалеким человеком, чтобы делать какие-то вещи через форму?! Ну неужели сложно найти серверные процедуры и их использовать? Потом мне понадобилось групповой обработкой пересчитать НДФЛ в начислении зарплаты ЗУП3. Я прокляла всех разработчиков типовой до 7го колена и написала как ТС - через клиент с открытием форм и вызовом их функций. Сначала было противно. Теперь просто злость берет. Но другого пути нет. Если переписывать себе в серверную обработку функции из формы, которые используя реквизиты формы производят расчет, то в следующем релизе будешь эту обработку переписывать, т.к. процесс расчета / перерасчета поменялся. А если открывать форму и вызывать экспортную процедуру по расчету она сама дернет нужные функции. Очень хочется, чтобы разработчики типовых пошли падаванами на какой-нибудь большой завод и поработали там годик со своим творением.

зачем изобрели ложку? в целом можно и без ложки поесть, что то из этой темы. У организации 10 расчетчиков 8 кадровиков и 5000 рассчитываемых сотрудников, может в excell собрать. Вообще никогда не понимал зачем пишут такую флудильню, но сам никогда не могу сдержаться что бы не ответить :)

Всё так

Не понял фраза "Все, кто раньше (до ЗУП 3.0 и УТ 11) работали с типовыми так говорят" ко мне это или к оппонентам, но я так же (даже не я а один из сотрудников) написали обработку которая все делает через форму, я вот решил модернизировать, что бы не нужно было кнопочки нажимать и сделать по человечески и в очередной раз уперся в эту проблему, решил выдержать все отсылы к мат части и окончательно ее добить что бы выяснить либо я "дебил" и научиться как делать правильно, либо в 1С что то перемудрили и смириться.

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

Для пример вот код который работает на клиенте, но что бы его заставить работать на сервере нужно все вверх дном перевернуть все очень элегантно и просто, но на клиенте :/

>> Очень хочется, чтобы разработчики типовых пошли падаванами на какой-нибудь большой завод и поработали там годик со своим творением Разработчики типовых должны оринтироваться только на _собственную_ целесообразность писать код и размещать его так или иначе. То, что потом какой-то Вася, Петя или Маша захотят клиентские методы дергать на сервере - это их личные проблемы (причем кстати вполне преодолимые) Так вся индустрия конструирования ПО устроена. По сути тебе предоставляют публичное API, которое ты можешь использовать, но нет гарантий, что это API не изменится со времением и твоя задача как разработчика подстраиваться под этим изменения, и именно этот процесс называется конструированием ПО, а ты в результате называешься программистом, очень неожиданно да?

Сразу допишу к для эстетов что правильней было бы

А давай теперь подумаем ПОЧЕМУ так сделано. Наверное потому что сама форма содержит достаточно большое количество разнообразных данных, которые должным образом извлекаются и обрабатываются перед ее открытием, в результате чего и получаются все данные необходимые для перерасчета.

в корне не согласен "Разработчики типовых должны оринтироваться только на _собственную_ целесообразность писать код " начиная с версий конфигураций на  управляемых формах они просто пожинают плоды доминации на рынке, решения в корне провальные которые вытягиваются за счет нас с Вами, если бы была конкуренция эти решения провалились бы. Кто внимательно следит за УТ 11, ERP и ЗУП и внедряет их решения, тот прекрасно понимает какой пласт проблем разработчики намеренно оставляют в прошлом релизе так как их не реально исправить и переосмысливают в новом релизе не совместимом со старыми, пример ERP 2.0 -> 2.1 -> 2.2 совершенно изменные концепции, а такие конфигурации внедряются и дорабатываются годами, провальная УТ 11.0 ЗУП 3.0 - работать стала только с 3.1.1 "По сути тебе предоставляют публичное API, которое ты можешь использовать, но нет гарантий, " тоже не верно, разработчики не просто дают АПИ а настаивают на его использовании, без обращения напрямую к элементам конфигурации, так как много накрутили логики которую очень сложно описать, поэтому почитайте партнёрские форумы, там одни рекомендации использовать только типовые процедуры и функции для получения и обработки данных.

Давай попробуем решить твою проблему забыв вообще про разработчиков типовых. Итак, тебе требуется сделать перерасчет на сервере, при этом процедура перерасчета находится в модуле формы, которую понятно на сервере ни получить, не открыть - ок. Экспортная процедура формы наверняка вызывает определенные методы серверных модулей - ок. Ты писал, что сложность в том, что этим модули требуют именно реквизиты  формы - ок Ну так возьми объект, сформируй требуемые структуры данных и  передай в методы серверных модулей. Объект у тебя на сервере есть, методы конвертации тоже на сервере есть, о чем плачь?

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

ЗУП вообще какието индусы левой пяткой пишут

Как я понимаю сам разработчики и не понимают зачем и какие структуры нужны, поэтому везде просто форму таскают

Код типовых прекрасен! :))

читай

Конечно, абстракционизм же

Да именно так, Вы правильно пишете, потому что если эмулировать заполнение параметров формы, проще перетащить весь код формы и модуль вместе с ним.

Подожди. Пусть они не понимают (ты же написал ). Но получается, что ты хуже индуса, пишущего левой пяткой? :))

Я пишу в дргом стиле. С абстракционистами соревнаватьс не хочу

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

по логике и метадологии за расчет ЗП отвечает ЧЕЛОВЕК по этой логике и пишутся типовые, с разделением на интерактивную работу и возможно программную приведите пример неИзвратный, когда ЗП надо постоянно переколбашивать в фончике

А еще при разработке ЗУПа начальник постоянно говорил: Нужно больше общих модулей (голосом варкравт 1)

у одного расчетчика порядка 400 - 600 человек, с разными условиями труда и формами оплаты, кадровики вносят свои данные, кадровые перемещения, изменения графиков, условий и должностей, расчетчики разносят удержания, премии и прочее. С учетом текущей скорости расчета в 1С ЗУП, процедура расчета подразделения может занимать от 30 до 90 минут расчета (с железом все нормально). Поэтому логика такая. Люди разносят документы, и периодически, утром и в обед хотят видеть результаты расчета по внесенным ими данным. Это как раз логика заложенная фирмой 1С во всех последних конфигурациях, пользователи пусть разносят данные, с наибольшей скоростью, а когда захотят увидеть (движения, проводки, результат) пусть ждут расчета. Логично, что хорошо бы этот расчет выполнять не в рабочее время, что бы больше времени осталось на анализ, поэтому запуск в ночь и в начале обеденного перерыва. Сейчас это запускается вручную через обработку. Но зачем если можно сделать регламент.

в продолжение, сама мысль как аргумент не понятна "по логике и метадологии за расчет ЗП отвечает ЧЕЛОВЕК " человек отвечает, но при заполнении документа все выполняет программа, и какая разница кто нажмет кнопку, главное кто будет проверят, а это не связанно с тем кто нажимает кнопку.

а если как в и /execute.. ну не фоновое но зато ?

Тихо, не подсказывай, автору похоже не решение надо, а просто накопилось у человека.

да это вариант выполнять обработку из под командной строки, но как то это не консистентно :|'

так решение уже давно есть, разобраться нужно раз и навсегда , что бы уже не касаться этой темы.

"в 3.1.2 они уже более менее осознали что нужно" - а что там изменилось?

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

Например, добавили регистры текущих данных для регистров "ПоОкончании". По аналогии КадроваяИсторияСотрудников - ТекущиеКадровыеДанныеСотрудников. Вроде бы улучшили логику работы с документами, теперь форма не нужна чтобы рассчитать. А вообще, касательно именно ЗУП. Вот типа они сделали API который сторонние разработчики должны использовать для доступа к типовым структурам, т.е. все эти "Представление_КадроваяИсторияСотрудников", но почему нигде нет его описания? Бррр, хотя в общем-то это немудрено, раз они так берут и структуру регистров меняют.

+1. Работать с объектом в модуле формы всегда считалось дурным тоном в восьмерке. Даже процедуры печати рекомендовалось выносить в модуль объекта или даже в модуль менеджера. Но вот появились УФ, и всё сразу перевернулось навыворот. Модуль менеджера практически в типовых не задействован, модуль объекта  - тоже. Всё через модули формы. А это деградация модели программирования. Объект существует независимо от наличия или отсутствия формы, в модуль формы нужно помещать серверные или клиентские методы исключительно для интерактивной работы. Именно поэтому мы и наблюдаем дикие спагетти в БСП.

Есть некоторые проблемы при создании документов в зуп кодом, но не все так страшно. Собственно по этой причине нет правил от 1с, которые создадут документы после перехода из зуп 2.0. Вместо этого только остатки и движения по регистра.

Если нельзя пилить типовые формы, но логика вшита в них, то батник вызывающий обработку в планировщике заданий Windows единственный вариант который я вижу. Да уж, разгребал подобное добро - возненавидел тех, кто писал.

правильно, "библиотека" противоречит самой платформе. "Библиотека" подойдет быстрее к объектно-ориентированным языкам. Тут явно перемудрили.