Перезапись движения зависимого регистра сведений. #593146

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

а зачем перетирать? и зачем именно второй тоже в начало дня?

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

так в ТЗ было, уже думаю забить. Там важно чтобы цены при установке в начало дня падали. Считаю неправильным, но заказчик платит :) Регистратор целиком удалить не получится, они не обязательно полностью совпадают по составу, часть надо оставить. Этот вариант как раз понятен: пройтись по всем регистраторам у которых в записи такой же период и удалить строки с пересекающимися ключевыми измерениями. Но думалось что есть что - то попроще.

еще вариант - записать в конец предыдущего дня, пробую

На конец дня тоже самое

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

а вот если: провели 1-й док, он установил цену Товар1 25р провели 2-й док, он установил цену Товар1 30р перепровели 1-й док, он установил цену Товар1 25р кто последний тот и папа?

даже так не получится, пишу запрос на удаление строк из 1го док.

муторно както все, смутно...

Посмотреть типовые конфигурации.

ну и как такое реализовано в типовой?

Регистр Цены. Документ ИзменениеЦен.

это где? в УТ 10 такого не обнаруживаю

Что к словам придираешься? БП, УПП: РС: ЦеныНоменклатуры, Документ в УПП: Установка цен номенклатуры.

+ УТ под рукой нету, но там думаю то же самое есть. Суть от точного названия не меняется.

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

Регистр и документ такие есть, но задачу ТС они не решают. Второй документ тупо не проводится ("такая запись уже есть"). УТ 10.2, УТ 10.3.

это есть, но проблема не решается, так что плюсую к

у регистра сведений периодичность интересно какая?

Читай . Не надо документ проводить началом дня. Надо просто задавать в нём, что цена действует с начала дня.

+ Точнее :)

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

Вопрос "нужно предусмотреть возможность *переписывания* цены в пределах начала / конца дня" Ответ "Посмотреть типовые конфигурации" Затем .

А кто мешает поставить по позиции регистратора?

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

Ну невнимательно я сначала прочитал :))) Поэтому и написал про типовые. Но смысл понятен. ИМХО цель какая? установить цены с начала дня. Так? Тогда добавляем в регистр цен реквизит ДатаНачалаДействияЦены и от него пляшем. И периодичность у регистра ставим "по позиции регистратора" - и хоть 100 документов в день клепай :))

>>Тогда добавляем в регистр цен реквизит ДатаНачалаДействияЦены вот этого точно делать не надо, есть и так регистре Период

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

Ты, наверное, имел в виду измерение ДатаНачалаДействияЦены (не реквизит)

а ты не в курсе, что Период регистра может отличаться от даты документа?

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

ну и молодец, я к тому, что твое решение тоже ответа не дает на вопрос

Почему же не даёт? Меняй цену хоть 100 раз на дню, и действовать она будет с начала дня. Ведь этого хотел ТС?

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

С точки зрения программиста - конечно удобнее. Но программа существует для кого? Для удобства программиста, чтобы ему меньше отборов и условий писать, или всё-таки для удобства заказчика?

При чем здесь заказчик? Результат один.

ну и как определить из какого документа брать цену?

Ну я так что понял что типа МАКСИМУМ(Период) + ГДЕ ДатаНачалаДействияЦены=&НачалоДня или моментВремени вместо периода

а может ПЕРВЫЕ 1 ;)

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

Если честно, то идея эта не моя. У нас была конфигурация "альфа-авто" переписанная вдоль и поперёк, так что мне трудно сказать, придумал это Рарус или наши программисты, но идея вполне откатанная и рабочая :)) У нас вообще система ценообразования была довольно нестандартная. Да, были конечно некоторые неудобства при получении цены, но результат себя оправдывал.

+ А цена получалась как-то так: МоментВремени=?(Ссылка.Пустая,Новый МоментВремени(КонецДня(Дата)),Новый Граница(?(обЗначениеНеЗаполнено(ДатаНачалаДействия),МоментВремени,ДатаНачалаДействия),ВидГраницы.Исключая));

период будет совпадать с датой, т.е. будет не 0 (в общем случае). Вот если дату установят в начало, тогда засада.

+ Я описываю, как я понял Фишера :) Возможно все не так ;)

*Fish'a (прошу прощения, переврал ник)

Я сам уже, если честно, не помню точно как всё это работало. Я просто изложил основную идею :)))

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

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