УТ 11.1 Программное создание документа установка цен и автоматический расчет цен #763136

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

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

Есть конфигурация с  кодом, могу скинуть.

скинь пожалуйста, надо на файлобменник, на почту не зайдет cf. fantomrik@gmail.com

Вопрос еще актуален, если кто сталкивался с задачей автоматического расчета цена при проведении поступления.

Я не понимаю - тебе цены установить надо или документ создать? Если создать документ "Установка цен номенклатуры" - достаточно сделать ввод на основании поступления - цены рассчитаются в соответствии с настройками видов цен. А если нужно только цены установить - никакой документ создавать не надо, достаточно сделать записи в регистр сведений "Цены номенклатуры".

"достаточно сделать записи в регистр сведений "Цены номенклатуры"" // путем создания и проведения документа установки цен

я так и хочу, но не могу понять, как в моем созданном документе рассчитать цены не руками, а запустив типовые механизмы расчёта

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

Всё это настраивается в видах цен.

да ты ч0. А в чем основное назначение документа, просвети, плз

Интересно какой регистратор будет у твоей записи? Корректировка регистров?

Придется либо сэмулировать клиентский код (добиться его выполнения), либо переносить логику клиентского кода на сервер

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

Ну ты знаток. Такую чушь пишешь

Откуда вылез?

вот это и пугает ( не знаю как правильнее сделать

Чем не устраивает формирование нового документа Установка цен программно и без форм?

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

Захожу тут в регистр сведений "Цены номенклатуры" и вижу, что режим записи у него - подчинение регистратору, а  регистраторами могут быть либо "Установка цен номенклатуры" либо "Корректировка регистров". Нужно с поддержки снять и добавить в регистраторы "Поступление товаров и услуг"?

Чувак может путает с ценами номенклатуры контрагентов (поставщиков)

Хотя исходя из его ответов про формулы расчета цен, не путает...

Ну да ладно, ответы вроде даны, всем спасмбо

*спасибо

Нее, просто дятел =)

Если тебе мои ответы не нужны, то нефиг и спрашивать. А с поддержки снимать вообще нет никакого смысла - для доработок конфигурации это не требуется. И если автор что-то дописывает типа , то добавление в регистраторы поступления - сущий пустяк, и недоумевать тут не о чем.

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

Попробуй описать всю задачу в целом. Для описанного в есть вполне рабочий типовой механизм, непонятно чем он тебя не устраивает.

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

Я не хочу * Опечатка

Тогда чем тебя не устраивает ввод установки цен на основании поступления?

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

Собственно подумал можно пойти таким путем. На сервере создать (просто создать, не открывать) форму объекта Установка цен, вызвать процедуры (скопировав из модуля типовой формы к себе в модуль) заполнения, полученные данные перенести в объект и объект записать. Начал это делать, наткнулся на следующее - процедуры в форме работают с данными УправляемаяФорма, а на сервере кодом я получаю просто форму. Какие то элементы недоступны и процедуры не работают. Как получить программно Управляемую форму? И как после ее заполнения, перенести данные в объект? p.s. Все заполение вызывается из процедуры ПриСозданииНаСервере, и все вложенные процедуры исполняются на сервере, поэтому предположил, что такой вариант прокатит.

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

Если типовыми средствами сделаю, у документа есть номер в пределах дня же, и когда руками создаешь установку, хоть 100 раз в день меняй цену.

либо Вы чего-то недопонимаете, либо все остальные

Да бог с ним, с нумерацией в пределах дня. Как решить   задачу? Так получится решить? Уже подумал, может возможно в объект записывать доп свойство свое, открывать форму типовым механизмом и если есть мое доп свойство, записывать заполненные данные в объект из формы.

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

Значит, ты изобретаешь травмоопасный велосипед. Решение о том, какими должны быть цены, принимают люди, а не программа. Именно для этого в УТ и предназначен документ "Установка цен номенклатуры", который во всех случаях проводится пользователем, и никакой автоматической установки цен не предусмотрено. Предусмотрено, что автоматически могут быть рассчитаны цены и заполнен документ, но решение провести именно такие цены (или не проводить их) принимает конкретный человек с соответствующими полномочиями и ответственностью (для него и поле "Ответственный" предусмотрено). И если вдруг возникают какие-то вопросы по ценам, то это конкретное ответственное лицо и даёт ответы, почему именно такие цены. В противном случае, если люди не участвуют в решении изменить цены, если всё происходит автоматически, то рано или поздно в этот порядок попадают ошибочные исходные данные и устанавливаются ошибочные цены, а когда никто за этим не следит, это обнаруживается слишком поздно - уже после того, как произошли непоправимые неприятности. И в этом случае вместо вразумительного ответа о происхождении цен всё понимание сводится к тому, что "программа почему-то так посчитала" (и в конечном счёте, "ответственным" в такой ситуации оказывается разработчик конфигурации). Ну и если всё же велико желание исключить людей из процесса назначения цен, то документ "Установка цен номенклатуры" теряет всякий смысл - в типовом учёте он предназначен для утверждения людьми. И если он заполняется и проводится при каких-то других событиях (документах), то все его движения могут выполняться в рамках тех исходных документов без создания лишнего документа установки в базе. Здесь не совсем понятен механизм поступления и установки цен. Что должно происходить при повторном проведении поступления: создаваться новая установка цен или перезаписываться ранее созданная? Если будет делаться новый документ установки цен, то тогда вся польза от этих документов сводится к хранению истории расчёта цен (какие были при первом проведении, при втором, при третьем...), а для этого было бы достаточно табличной части (новой) в самом документе поступления - хранить это в отдельном документе (документах!) будет излишним. При таком варианте, как уже говорилось, нужно продублировать в поступлении процедуры расчёта вычисляемых цен (из процедур установки цен), дописывать специальную табличную часть и обновлять записи в регистре сведений - и всё это не выходя за пределы документа поступления. Если же при повторном проведении поступления будет перезаписываться одна и та же установка цен, то тогда выходит, что этот документ будет просто повторять в себе содержимое регистра сведений, никаких уникальных данных храниться не будет, и для этого достаточно всего лишь делать записи в регистре документом поступления (без излишних документов и табличных частей). Но, разумеется, для всего этого придётся в документе поступления продублировать процедуры расчёта цен и доделать запись в регистр сведений. И если уж ОЧЕНЬ НЕ ХОЧЕТСЯ с этим возиться, то можно, конечно, и создавать установку цен: делать программный ввод установки цен на основании, открывать форму, после чего либо записывать и проводить эту установку цен (и она сделает движения), либо брать через её форму табличную часть с рассчитанными ценами и использовать их в проведении поступления для записи в регистр (а форму установки цен просто закрывать без записи). Но надо понимать, что это означает дополнительное время на открытие формы, дополнительную запись документа (если сохранять установку) и сам дополнительный документ в базе (опять же, если записывать).

Хотя, если всё заполнение (расчёт цен) выполняется в процедуре "ПриСозданииНаСервере" (я просто не помню), то можно и не открывать форму (это по поводу последнего абзаца в ).

Ты пытаешься получить форму методом объекта, а нужно общим методом: ПолучитьФорму("Документ.УстановкаЦенНоменклатуры.Форма.ФормаДокумента") Как-то так...

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

При создании управляемой формы это должно случиться, см. .

Есть такое понятие - руководство хочет. Раз хочет, сделаем, это "их" решение :) В любом случае спасибо за ваши комментарии. Собственно победил я эту задачу. Послушал умного совета и скопировав целиком модуль "УстановкаЦенСервер" немного поправил под нужды задачи. Думаю подобная задача может еще раз всплыть, у меня ушло уйма времени на решение, поэтому ниже выложу "код". В первом серверном модуле сама процедура создания установки установке цен на основании документа поступления. Второй типовой модуль расчетов, с моими корректировками. Конечно много не оптимально, но работает :) Надеюсь кому то пригодиться!

И Не ЗначениеЗаполнено(ТекущийОбъект.Ссылка) Тогда                                  Для Каждого ТекСтрока Из ТекущаяФорма.ВыбранныеЦены Цикл #КонецОбласти

в ЛЗ_УстановкаЦенСервер 5000 строк, не влазит сюда) Сохранил в тхт

Тема закрыта, решена, всем спасибо!

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