1C 7.7 ТиС Групповой программный перенос документов на новую дату.

"Здравствуйте. Клиент захотел, чтобы необработанные заявки (за состояние заявки отвечает новый реквизит) переносились с прошлых чисел на текущее. Сделал следующим образом:<br><br>Дат = ТекущаяДата();<br> <br> Док = СоздатьОбъект("Документ.ЗаявкаПокупателя");<br> Док.ВыбратьДокументы(Дат-ДнейПереноса-1,Дат-1);<br> <br> Пока Док.ПолучитьДокумент()=1 Цикл<br> Если Док.Стадия = Перечисление.СтадииЗаявки.НеОбработана Тогда <br> Если Док.Проведен()=1 Тогда<br>        Док.СделатьНеПроведенным();<br>                   Док.ДатаДок = Дат; <br>                   Док.Записать();<br> ИначеЕсли Док.ПометкаУдаления()=0 Тогда<br> Док.ДатаДок = ТекущаяДата();<br> Док.Записать();<br> КонецЕсли;<br> КонецЕсли;<br> КонецЦикла;<br><br>Если попробовать провести документ, который был проведен до этого, но с новой датой, то 1С ругается: Документ не проведен! :<Объект не найден>. Если сделать как написано, то переносит, но ... цикл не работает. Т.е. перенес один док, прекратилась обработка, снова нажимаешь Выполнить, еще один. И так далее. Как я понимаю проблема с ссылками на доки. <br><br>Подскажите, пожалуйста, как обойти эту проблему и возможно ли. А то в голову лезут совсем уж безумные способы реализации ... заранее спасибо."

Нельзя внутри цикла "Пока Док.ПолучитьДокумент() = 1" менять дату или номер документа. Выборка при этом рушится.<br>Надо сначала сохранить ссылки на все обрабатываемые документы, например, в таблице значений. А затем уже проходить по таблице значений, получать документы и обрабатывать их.<br>

Спасибо, помогло <br>

зачем новый КО "необработана" ?

Для выделения цветом строки документа в журнале. Серый - необработана, красный - отдана на склад, зеленый - собрана. Для этого и сделал реквизит "Состояние" и перечисление этих состояний. И клиенту надо, чтобы все серые с прошлых дней переходили на текущий.

> Для выделения цветом строки документа в журнале. Серый - необработана, красный - отдана на склад, зеленый - собрана. Для этого и сделал реквизит "Состояние" и перечисление этих состояний. И клиенту надо, чтобы все серые с прошлых дней переходили на текущий.<br><br>странно<br><br>а ему не надо видеть историю состояния ?

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

> Нет. Это исключительно для удобной навигации по заявкам. Там может за день у каждого менеджера быть не по одному десятку и им надо беглым взглядом видеть, отдана ли эта заявка на склад или надо распечатать, собрана ли она уже и т.п.<br>> <br>> как я понимаю, вы намекаете на доведение этого до способа оценки эффективности работы складовщика? У них такой проблемы не стоит. Он один, крупных заявок не так много за день, а вот небольших достаточно много для небольшого количества персонала..<br><br>я имею ввиду, что можно было всё сделать на "штатных механизмов"<br><br>пример была заявка покупателя<br>введи док<br><br>потом оплатили эту заявку<br><br>на основании дока заявки делаем заявку на склад (жёсткий резерв)<br><br>потом отгрузка или отмена заявки<br><br>=> я вижу все состоянии заявки от "заявлении" до момента отгрузки/отмены (т.е. история и будут доки)

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

"двигать" надо заявку, а не отгрузку