soleg78, у тебя нота "капс" западает.
Тебе все уже написали, даже от "граблей" предостерегли, хотя, в сущности, здесь тебе никто ничего не должен.
Если у тебя из Конфигуратора украли СП и Отладчик - это твои проблемы.
Если из-за вывода данных, которые нужны всего нескольким пользователям, ты собираешься заставить ждать пересчета любого, сунувшегося в список - это проблемы твоего руководства.
Воспроизводить на своей конфе эту чушь, чтобы выложить тебе готовый код - нет ни малейшего желания.

Все правильно. Прошу прощения, мой пост был адресован автору... но попробуй успей вперед Вас
Он пытается обойтись с ДокументСписком как с какой-то ТЗ.

Блин, только сейчас заметил, что у автора той ветки файлы MD идентичны Исправляюсь

Для этого случая есть кардинальное решение(годится только для баз с идентичными MD!!!).

1. Выгоняем пользователей. Сохраняем бэкап ЦБ. Все делается именно на ЦБ. закрываем Конфигуратор.

2. Берем любой DBFEditor (Эксель не поможет!) и лезем в файл 1SUPDTS.dbf.
Для SQL - SQL Server Management Studio, таблица 1SUPDTS.

3. В таблице/файле находим все строки со следующими значениями полей:
DBSIGN (Код базы УРБД) - Код нашей периферийной базы
OBJID (Идентификатор объекта ИБ) - пусто (0)
Эти строки создаются при сохранении измененной конфигурации. Строки с различными TYPEID указывают на изменение отдельных объектов конфигурации.

4. Аккуратно удаляем все эти строки, сохраняем и закрываем файл(закрываем таблицу). Теперь и ЦБ считает, что конфигурации идентичны.
! Если случайно удалили строку с заполненным OBJID - все закрываем, восстанавливаем базу из бэкапа и начинаем все сначала. Это было изменение какого-то очень важного документа

5. Можно запускать обмен и работать.

Хм... тема актуальна? Тогда, наверное, есть смысл вспомнить подводные камни.
Возможно, что-то из этого списка исправлено в последних платформах, а может и нет - 1с8 тогда уже продавалась...

1. Не стОит использовать в кодах баз кириллицу. Поначалу все может идти нормально, а сюрпризы могут появиться в самый неподходящий момент.
Нпр, с одной базой нужно обмениваться каждый час, а с остальными - раз в день. Вполне логично создать два задания в шедулере и два файла параметров обмена, в одном из которых вместо * (обмен для всех баз) явно задать код... упс... тогдашняя платформа под Вин2000 просто не замечала этого кода, а коды без кириллицы отрабатывала на "ура".

2. Если у вас под УРБД работает ЗиК, комплексная с включенным участком Зарплата или любая другая с использованием ЖурналаРасчетов, то нужно любыми средствами запретить проведение зарплатных документов в "неродной" базе. Если при проведении такого "чужого" документа в ЖР будет записан хотя бы одна запись сверх их исходного количества - очень скоро обмен станет колом.
Запись ЖР - самостоятельный объект конфигурации, но его код при создании формируется на основе кода документа, а не кода текущей базы. То есть код у Записи такой, как если бы она была создана в месте создания документа. А в это же время в базе, из которой мигрировал документ, нумерация Записей продолжается своим чередом... Сможет "левая" запись (по времени и настройкам миграции) попасть в Место создания документа - никто ничего не заметит. Не успеет - "дубль в ключевом поле".

3. Не пытайтесь делать выгрузку/загрузку по сети. Это выглядит удобным и изящным, но - лотерея. Не поленитесь, пропишите: выгрузка на диск размещения каталога базы, копирование файла на диск размещения другой базы, затем загрузка в той базе "из под себя". Да, придется создавать отдельное задание на каждом сервере и сдвигать их по времени. Это лучше, чем нестись сломя голову в филиал из-за остановки обмена.


Господа, подключайтесь, продолжайте!

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

Подробности.
Когда в базе изменяется подлежащий обмену объект, в таблицу(файл) 1SUPDTS(?) пишется строчка. В ней указывается код типа объекта, код объекта, код базы-получателя.
При формировании выгрузки для какой-либо базы файлу присваивается порядковый номер, в него выгружаются объекты, для этой базы предназначенные, а в соответствующие строки 1SUPDTS вписывается номер выгрузки. Удалены эти строки будут только тогда, когда придет подтверждение (Acknowledgements) с этим самым номером.
Если выгрузить повторно - выгрузка будет со следующим номером, в строки таблицы будет записан уже новый номер, и система будет ждать подтверждения.
* Следствие. Если выгрузка идет систематически, а размер файла настойчиво растет даже при уменьшающейся интенсивности работы - это может означать, что подтверждения не приходят, что-то не так на той стороне.

Ценность УРБД - в простоте, тут просто ломаться нечему

Закачка кривоватая - не все реквизиты заполняет.
Навскидку/наугад: проверьте реквизит ОтборЗаказаКонтрагент

Все так и должно быть. Достоверные отчеты можно получить только по полностью рассчитанному ЖР Зарплата.
А бухгалтеры просто лукавят.

Хм...
Напоролся на студента.
Вместо послать - возился с ним и платил ему деньги.

Кто смешнее в данной ситуации?

Телепатирую...
Кноп Изменить находится в самом низу экрана, менюшка выбора вида редактирования открывается(она всегда открывается под кнопкой), но не видна.

Пока неведомо где перегружается сервер, немного помучил УТ, затем глянул заголовки Ваших веток.

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

Итак, демо конфа УТ (давненько я не брал в руки шашки):
1. Создал новый оптовый склад, розн цену для него не указывал. Создал новый розничный склад, тип цен - розничная.
2. Создал новую Номенклатуру - указал только Вид - Товар, единицы измерения и НДС.
3. Док Оприходование на Оптовый склад, в ТЧ добавил мою Номенклатуру, указал Количество и Сумму - цена рассчиталась. Провел.
4. Док Перемещение с Оптового склада на Розничный. Изменить - Добавить из документа - мое Оприходование - Выполнить - ОК. Переоценка - во вновьсозданной Переоценке проставил Розничную цену, ОК, док провелся и закрылся. В Перемещении - ОК - провелся.
Все. В код лезть не надо, состав достаточно набрать 1 раз - в Оприходовании. А можно начать с Инвентаризации - тогда будет еще красивая бумага "с подписЯми ответственных товарисчей", а Оприходование - на основании оной. Закупочная цена будет получена из следующего поступления(поставщик цену выставит - его не волнуют ваши записки), тогда можно будет и другие типы цен персчитать/установить.

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

Начните с изучения Конфигуратора - Конфигурирование и администрирование, Руководство разработчика. Это довольно странно - пытаться применять совершенно незнакомый инструмент с неизвестными возможностями. Рано пока Видеокурс...

ЗЫ. СП - Синтаксис-помощник, ищите в Конфигураторе кнопку с головой в шляпе академика)))

Подробно - Описание встроенного языка.
Кратко - СП.

Вот теория

попробуйте СрезПоследних()

Возвращает структуру, содержащую значения ресурсов.
Период ресурсом не является

Или получать последнюю запись другим методом или писать дату в ресурсы.

А предприятие-то в курсе? Вызовите программиста, если все цивильно - откроет.
А чужие базы ломать - тут надо сразу предлагать дележ награбленного

1. Без доработки. "Единицы". Товар с правильным Полным наименованием, единицы - т и шт(коэфф 0,02, ну, или мешок). Приходуем в тоннах, продаем в штуках, в продажную цену закладываем стоимость мешка. Мешки списываем периодически на затраты.
2. "Наборы". Доработка вывода на печать Наборов(Счет, РН, НН) - отключить вывод расшифровки, проставлять данные(кво, цена и т.д.) в строке набора. Есть смысл подумать над новым видом ТМЦ - НаборБР, так сохранится имеющийся функционал по Наборам.
3. Производство(тоже, кстати, доработки не требует). Если нужен подробный учет затрат(зп фасовщиков, ремонт и электроснабжение оборудования ....) - тогда есть смысл заморачиваться. Но и в этом случае калькуляция под каждую РН, по моему, перебор - достаточно по одной на каждый товар. А вот ВыпускПродукции... лучше всего - по факту фасовки.

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

Ппц... Ну хоть немножко должно быть масла в голове? Чтобы хоть понимать, куда эту самую голову суешь?

Арди, оглашай, будем ходатайствовать перед Основателями о присуждении соответствующего титула

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

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

Остатки хранятся в регистре "Остатки...", подробнее - в "Партии...". В каком именно файле дбф или таблице скл находится этот регистр - надо читать файл *.ДД. Тогда можно вытряхнуть остатки без участия 1С и знания встроенного языка.

Если передавать в ПолучитьПериод() вторым параметром дату начала периода, то получишь итоги по этому периоду....
Из копии результата запроса получаешь список периодов в нужном порядке, и....

ЗЫ. В отпуск тебе пора.

Нет, не так. Скорее всего, у юзера, который всех блокирует, на компе стоит локальная версия. В ней НЕТ флажка Монопольно, она всегда открывает базу только монопольно.

Да, вот еще... если речь идет о ТиС или ЗиК, то там, кроме локальной и сетевой есть еще трехпользовательская. Так она четырех одновременно не пустит - что пишет при этом, не знаю.

И?
Будешь иметь по каждому товару несколько строк с остатками по разным складам? В теории - норм, а вот когда начнут работать юзеры, и появятся товары со сходными наименованиями.... порвут тебя в клочья за такую реализацию.

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

Подход стандартный...
Если через Метаданные...Реквизиты получить коллекцию реквизитов, то

Для объекта доступен обход коллекции посредством оператора Для каждого … Из … Цикл. При обходе выбираются элементы коллекции.
Возможно обращение к элементу коллекции посредством оператора [...]. В качестве аргумента передается индекс (нумерация с 0) объекта в дереве метаданных.

Объект метаданных можно получить по полному имени, а уж где и как оно хранится - дело десятое.

А еще есть чудная вещь (спасибо Вам СП):
Выполнить (Execute)
Синтаксис:
Выполнить(<Строка>)
Параметры:
<Строка>
Строка, содержащая текст исполняемого кода.
Описание:
Позволяет выполнить фрагмент кода, который передается ему в качестве строкового значения.
Нпр, так должно получиться

Выполнить("НовыйЭлемент = Справочники." + ИмяСправочника +".СоздатьЭлемент();");