Всем привет!

Мне требуется сделать отчет, показывающий список зарезервированной номенклатуры за определенную дату. Однако в РегистреНакопления.Запасы отсутствует дата осуществления записи, а есть только период, к которому она относится, этот период определяется датой документа резервирования. Но ЗаказПокупателя, как правило, создается в один день, обрабатывается и делается резерв в другой день, а с учетом выходных это уже может быть несколько дней. Вопрос в том как можно вычислить записи именно по дате резервирования и можно ли вообще?  

Заранее спасибо за любые идеи и подсказки!

У 7.7 регистров накопления нету. Если регистры остатков и оборотов (если торговля). Вы разделом ошиблись или термином?

(1) Разделом ошибся. У меня 8.3 УНФ.

(0) Если заказ проводится не оперативно, то только через журнал регистрации, нигде в данных такое не фиксируется

(3) "..нигде в данных такое не фиксируется" Я так и предположил, что странно для транзакционной системы, почему нельзя было добавить одно стандартное поле везде "Дата транзакции"? Что абсолютно логично. Видимо, в т.ч. по этой причине криво смотрят на компании с 1С при выходе на иностранные рынки капиталов :)

"...только через журнал регистрации,..." Как до него добраться? Что-то я не нашел его в конфигурации.

Видимо, придется делать свой регистр параллельный РегиструНакопления.Запасы и постить туда транзакции по резервированию запасов с датой по подписке на событие в  РегистрНакопления.Запасы. Вот только не соображу какой регистр лучше создать: сведений или накопления?

(0) "вычислить записи именно по дате резервирования" - а чем "дата резервирования" отличается от даты документа, который резервирует товар?

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

(6) "проводит резервирование (дата резервирования Вторник, но в регистре она проходит пятницей)" - если она в регистре проходит пятницей, то у вас что-то не так с регистром. Если товар резервируют во вторник - то по логике дата резервирования это вторник.
У вас ведь могут сделать заказ в момент, когда товара на складе еще нет. И что вы будете резервировать в пятницу?

(7) В регистреНакопелний.Запасы ест только одна дата ( "период), которая относится к дате документа. По логике дата резервирования вторниr, вы правы, но ее нет в этом регистре. При этом записи в регистре упорядочены по во временной последовательность, видимо в БД есть где-то внутренний ID, который невиден для запросов. Отсюда и мой вопрос есть ли дата транзакции, где-то и можно ли до нее дотянуться?

Короче, если нельзя отказаться от муток с проведением резервирования задним числом - то лучше фиксировать в документе дату его создания и, имея эти данные, будет проще что-то вымутить в дальнейшем

(8) "По логике дата резервирования вторниr, вы правы, но ее нет в этом регистре" - она будет в этом регистре, когда в документе, создаваемом во вторник, будет указана дата, которая во вторник. А все эти мутки с проведениями задним числом только множат головняк разработчика и расходы заказчика

(8) "При этом записи в регистре упорядочены по во временной последовательность, видимо в БД есть где-то внутренний ID, который невиден для запросов" - откуда взялся вывод про "внутренний ID", если записи упорядочены во времени?
Кстати, записи, находящиеся в пределах одной секунды упорядочены по МоментВремени(), никакой "внутренний ID" для этого не используется. Более того, внутренний ID есть только у ссылочных объектов

(9) Речь о резервировании задним числом не идет.

Для резервирования нет отдельного документа. Резервирование делается в заказе покупателя. У заказа одна дата, у факта резервирования другая. Это логика работы стандартной 1С. С т.з. программиста логика кривая: резервирование должно идти отдельным документом. А если оно не идет отдельным документом, то у транзакции  резервирования должен быть свой ID и дата, чего в 1С нет. Так сделали разработчики. Для пользователя это может и удобно.

(11) Загляните в этот регистр и все станет сразу понятно.

(12) "Это логика работы стандартной 1С" - стандартная 1С это голая платформа, логики у неё нет. Я вот сейчас веду заказчика, там для резервирования есть документ "резервирование товаров", либо поступление товаров услуг может резервировать товар. Сам заказ не резервирует ничего.
Но если в колонке "Размещение" табчасти "Товары" указать либо склад, либо док закупки - будет резервировать. Просто там у человека такая модель работы, что он сперва получает заказы, потом покупает товар под него.
Если вы в размещении не будете ничего указывать - у вас тоже заказ не будет резервировать товар. Будете его во вторник резервировать отдельным документом
"У заказа одна дата, у факта резервирования другая" - так резервируйте товар отдельным документом и всё будет видно
"у транзакции  резервирования должен быть свой ID и дата" - у транзакций нет ID. У записей регистра нет ID.
Что такое вообще "транзакция резервирования"? Вы разработчик вообще? Мы просто с вами на разных языках говорим

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

(14) Спасибо, дали мне подсказку.

Итак, резервирование можно сделать 2-спосбами:

1. Через Глаз над табличной частью, в т.ч. открываются колонки со всем раскладом по запасам, что очень удобно пользователю, при этом он может сделать резервирование, которое отражается в РегистрНакопления.Запасы по дате документа ЗаказПокупателя (как я писал выше)

2. Через создание отдельного документа РезервированиеЗапасов, который проводится по РегистрНакопления.Запасы датой резервирования.  Это неудобно для пользователя, проще резервировать в глазу. Однако решает мою проблему! Поэтому в жопу пользователя! Надо будет только ему закрыть возможность резервирования в глазу.

(15) еще можно в поступлении резервировать, если в товарах есть колонка "заказ"

(15) А ты там кто, директор, что сразу пользователя в жопу посылаешь? Решить свою частную задачу без потери удобства слабо?

(15) "Это неудобно для пользователя" - если дата заказа и дата резервирования разные, то неудобства придется терпеть. Кроме того, какие неудобства у юзера вызывает два раза сделать клик мышкой? Раз на "ввести на основании" в заказе, вызвав резервирование товара, второй раз - на "Провести и записать" или "ОК" в самом резервировании?
Если это кому-то неудобно - можно посоветовать работу с лопатой на природе, там все намного удобнее, предметы труда не такие мелкие, и голову ломать не нужно

(17) Угу  . Не слабо, просто нужно здесь и сейчас. А потом, если время будет, то допилю.
(18) Я Вашу мысль одним словом выразил

(19) Мне показалось, вы выразили там другую мысль. Ну да ладно, проехано