Уверен, что у Вас точно так же прекрасно фиксируются метаданные. Но только не для ошибок. Посмотрите другие события: добавление, проведение, изменение документов

Судя по скрину, Ваш основной источник ошибок - модуль формы Документа.Славсант_Отгрузка. Поставьте запись Журнала регистрации при открытии формы (Пользователь открыл документ № такой-то), потом посмотрите, какой документ открывал Пользователь перед ошибкой, а потом попробуйте попытать его на предмет того, чем он там занимался

kipkoalex @ Вчера, 18:52 ,

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

denis84 @ Вчера, 12:56 ,

Не уверен, что правильно понял задачу, но предполагаю, что таким запросом её не решить. У Вас должна быть группировка по ПодразделениеРодитель без группировки по Подразделению, иначе Вы неправильно получите диапазон "вредняка", в который у Вас попадет данный сотрудник.

То есть, у Вас в запросе будут переменные типа

ВЫБОР
 КОГДА ВнутреннееОборот>0 И ВнутреннееОборот<=100 ТОГДА 1 ИНАЧЕ 0
КОНЕЦ КАК Диапазон1,

ВЫБОР
 КОГДА ВнутреннееОборот>100 И ВнутреннееОборот<=200 ТОГДА 1 ИНАЧЕ 0
КОНЕЦ КАК Диапазон2,

И если Вы не сгруппируете предварительно результат по ПодразделениеРодитель, Вы не получите правильные значения ВнутреннееОборот


Но, конечно же, есть и хорошая новость. Если Вам нужен именно отчет, то СКД в данном случае всё сделает идеально. Указанные выше функции прописываете в Вычисляемые поля, а потом хорошенько колдуете на закладке "Ресурсы" (там нельзя делать ресурс СУММА(Диапазон1), а нужно повозиться с етой формулой)

Nikitaje, Немного не так. События формы срабатывают ТОЛЬКО в случае открытой формы. События объекта срабатывают при любом изменении объекта (как интерактивном, так и программном)

Если Вы открыли документ (именно форму документа), нажали "Записать" (или ОК), то срабатывают события в следующей последовательности:

1. ПередЗаписью() на форме документа

2. 2а) ПередЗаписью() в модуле документа
2б) ПриЗаписи() в модуле документа
2в) ОбработкаПроведения() в модуле документа - если проводим

3. ПриЗаписи() на форме документа
4. ПослеЗаписи() на форме документа

Если Вы записываете документ программно (или проводите его, например, из формы списка), у Вас будет только пункт 2

Еще есть момент: весь п2 - это транзакция, а п1 - это другая транзакция. Если Вы создадите в 2а) какие-то новые объекты в документе, а затем в 2в) у Вас произойдет отказ, Вы можете получите битые ссылки типа <Объект не найден>, поэтому иногда создание таких объектов есть смысл вывести в ПередЗаписью() формы документа

Nikitaje @ Сегодня, 10:29 ,

Не вполне понятно, у Вас не срабатывает ПередЗаписью() в модуле формы при вызове ? Дык, оно и не должно. В модуле формы это событие возникнет только при интерактивной записи документа из его формы
А вот ПередЗаписью() в модуле объекта, да, выполняется и при программной и при интерактивной записи объекта

Вытащил. Всё чотко. Видео-уроки, все дела. Размер 3.2ГБ
Могу постепенно куда-то перезалить

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

Vofka @ Сегодня, 10:08 ,
Тяну потихоньку, интересно взглянуть. Вытянулось немного, но по виду соответствует заявленному

Если это не запрос для получения динамического списка, то мои советы такие:
1. Попробуйте вместо вложенных запросов использовать временные таблицы
2. С временными таблицами используйте индексы по полям, которые потом будете соединять. Если есть составные поля (Документ.ПриходныйКассовыйОрдер.РасшифровкаПлатежа.Заказ итп), желательно во временной таблице их типизировать
3. Консолью запроса смотрите, сколько записей в каждой из временных таблиц и сколько времени они формируются. И пытаетесь понять, что не так. Возможно, для конкретно Вашей Базы ничего здесь оптимизацией запроса и не сделаешь: быть может, у Вас слишком много Номенклатуры и Заказов? Нужно анализировать

Временные таблицы:
ВТНоменклатураДополнительныеРеквизиты
ВТВложенныйЗапрос
ВТВложенныйЗапрос1
ВТВЗВозвраты
и финальный запрос, где все они соединяются с ПриходныйКассовыйОрдерРасшифровкаПлатежа

Что-то как-то Вы неправильно с вложенными таблицами в Запросе работаете. Рекомендую почитать, например, вот ето

Выражение

РезультатВыбора.Товары.Columns.КодНоменклатуры

вернет Вам колонку результата запроса, которая в Вашем случае будет COM-объектом

Вам нужно что-то вроде

...
  Пока РезультатВыбора.Следующий() Цикл
        
  // здесь должна быть выборка по строкам таб. части Товары - обходим строки данной таб. части
    ВыборкаТовары = РезультатВыбора.Товары.Выбрать();

    Пока ВыборкаТовары.Следующий() Цикл

      КодНоменклатуры = ВыборкаТовары.КодНоменклатуры;  // вот ето значение примитивного типа, по нему можете осуществлять поиск в текущей Базе

      НоменклатураCOM = ВыборкаТовары.Номенклатура;  // а ето Номенклатура из COM-базы. То есть, COM-объект

      НоменклатураНаименование = НоменклатураCOM.Наименование;  //  ето также значение примитивного типа, по нему можно осуществлять поиск

      НоменклатураUID = НоменклатураCOM.УникальныйИдентификатор();  //  а вот по етой позиции лучше всего искать ссылку, если у Вас идет синхронизация обмена по внутреннему идентификатору

      ...

    КонецЦикла;

    СчетчикДокументов = СчетчикДокументов + 1;
  КонецЦикла;

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

Если ничего хорошего, то интересно бы посмотреть полный текст ПередОбработкой в правиле конвертации группы свойств
Если там нормальное число, ничуть не хуже, чем цена или сумма, значит что-то происходит при загрузке, а не при выгрузке. Тогда интересно, что у Вас там за модули ПередЗагрузкой, ПриЗагрузке, ПослеЗагрузки в объекте-приемнике

Гм. Могу предположить "по приборам" (не зная Конфигурации), что проблему можно решить таким образом:
Объект.ПодготовитьТаблицы() вызывает ОбщегоНазначения.СформироватьЗапросПоТабличнойЧасти(), где формируется запрос к документу

...
    Запрос.Текст = "ВЫБРАТЬ 
                    | Док.НомерСтроки " + ТекстЗапроса + "
                    | ИЗ 
                    |      Документ." + ДокументОбъект.Метаданные().Имя + "."+ СокрЛП(ИмяТабличнойЧасти) + 
                    " КАК Док 
                    |     ГДЕ Док.Ссылка = &ДокументСсылка";
...

Вот если ету конструкцию дополнить

...
                | УПОРЯДОЧИТЬ ПО 
                |         Док.НомерСтроки
...

, то, как мне думается, это должно помочь в большинстве документов

А вот о причине такой сортировки при смене СУБД мне трудно судить: знаний не хватает. Если мне не изменяет память, у меня была подобная ситуация после перехода с файловой БД как раз на MS SQL. Но в другом запросе УТП. Где-то в УправленииЗапасами емнип. Но смысл был тот же самый: вылечилось сортировкой по НомеруСтроки

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

Схемку бы посмотреть. Странно как-то у Вас получилось


Эти 2 набора данных. Вы их объединяете? Или связываете левым соединением? Или никак не связываете? Можете приложить скрины закладок "Набор данных", "Связи наборов данных" и "Настройки"?

Навскидку, я бы делал так: 2 набора данных = 2 запроса. В обоих "Номенклатура". Добавляем "Набор данных объединение" и запихиваем под него оба запроса. Всё должно сработать, отбор по Номенклатуре будет один

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

В общем, хотелось бы посмотреть на схему. Хотя бы без конкретики, издалека, на указанных закладках. Без этого трудно помочь: с СКД проблемы могут быть там, где их не ждешь

Немного запутанно. Уточните пожалуйста, Вы хотите изменить дату на форме, чтобы она попала в Параметр СКД?
Тогда, вроде, в ПараметрыДанных_Заполнить() всё чотко, должно сработать. Естественно, когда Вы нажмете "Сформировать"

Что у Вас должно происходить в ГодПриИзменении() и МесяцПриИзменении(), не совсем понятно. Почему-то Вы передаете в правильную процедуру ПараметрыДанных_Заполнить() все время одинаковый интервал: с начала веков по текущую дату. Возможно, там имеется в виду что-то вроде

&НаКлиенте
Процедура ГодПриИзменении(Элемент)
ДатаСКоторойПолучаемОтчет = Дата(РеквизитГодНаФорме, РеквизитМесяцНаФорме, 1);
ПараметрыДанных_Заполнить(ДатаСКоторойПолучаемОтчет, ТекущаяДата());
КонецПроцедуры

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

Татьяна92 @ 14.07.20, 13:44 ,
Что-то тут не то. Скажите, какая у Вас Конфигурация хотя-бы. Возможно, запасы съехали где-то в управленческих регистрах, поэтому и формируется неправильная проводка

Е.Ю.Хрусталева в "Разработка сложных отчетов в 1С:Предприятии 8" приводит пример такого задания отбора во вложенной Схеме.
Если кратко, то над вложенным отчетом добавляется группировка основного отчета (чаще всего, Детальные записи). И после этого во вложенную схему добавляются отборы типа "Номенклатура Равно ОбъектНастройкиВладелец.Номенклатура". Все работает, но результат не будет выведен в одну таблицу. На каждую группировку основного отчета будет выведена отдельная таблица из вложенной схемы. Если Номенклатура одна, то и ничего страшного, а если их много, то куча маленьких табличек выглядит не очень (как по мне). Можно ли это поправить и исхитриться вывести вложенный отчет в одну таблицу, мне неведомо, но у меня не получилось.
Поэтому, попробуйте. Если устроит - здОрово. Не устроит - переносите вложенную схему в запрос основной


Дык, в настройках уберите флажок с этого отчета и всё, его нет. Можно какой-то флаг на форму добавить и перед формированием отчета программно изменять СКД

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


Поставьте в параметры виртуальной таблицы "Авто". Можно поставить и "Месяц", тогда поле будет называться "Период"

Кто-то Вас ввел в заблуждение.

В УПП есть прикол, связанный с документом "УстановкаПараметровУчетаНоменклатуры". Вот если он у Вас в системе заведен, то Ваши настройки счетов в регистре до лампочки. Некоторые подробности - ТУТ. Общий смысл: "С даты первого проведенного документа «Установка параметров учета номенклатуры» будет действовать режим определения счетов при проведении документов.". Причем, в этом документе нет схемы реализации, но Система считает, что она её и так определит (в указанной Вами процедуре)
В модуле СчетаУчетаВДокументах ето зашито примерно тут:

Функция ПолучитьСчетаУчетаНоменклатурыИзНастроек(Организация, Номенклатура, Склад, Дата, ХозяйственнаяСитуация = "") Экспорт

    Если ИспользоватьОпределениеСчетовПриПроведенииДокументов(Дата) Тогда
        
        УстановленныеСчета         = ПолучитьСчетаУчетаНоменклатурыИзДокумента(Организация, Дата, Номенклатура);
        СтруктураСчетовУчета    = ПолучитьСтруктуруСчетовУчета(Номенклатура, УстановленныеСчета, ХозяйственнаяСитуация);
        
    Иначе
        
...            
            УстановленныеСчета     = ПолучитьСчетаУчетаНоменклатурыИзРегистраСведений(Организация, Номенклатура, Склад);
            
...
    
    КонецЕсли;
    
    Возврат СтруктураСчетовУчета;
    
КонецФункции

Нужные нам счета из регистра сведений получаются, если не срабатывает "ИспользоватьОпределениеСчетовПриПроведенииДокументов"

Лично я считаю эту фишку вредной и никогда не использую

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

Вы эти запросы используете во вложенных схемах? В них можно передать параметры из основной схемы.
У Вас сложности в передаче параметров во вложенную схему? Или я неправильно понял вопрос?

Татьяна92 @ Сегодня, 12:31 ,

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

Если у Вас обычная Бухгалтерия, тогда Вам придется выравнивать остатки. Вдумчиво. Этапы примерно такие:

1. Выбираем месяц, с которого хотим жить по-новому (с корректными остатками и движениями)

2. Выравниваем сумму остатка топлива на начало етого месяца. Основные критерии, на которые обращаем внимание:
- количество не должно быть отрицательным
- если количество 0, то сумма тоже должна быть 0
- цена остатка топлива должна соответствовать ценам в партиях закупок. Если партионный учет, то чотко соответствовать. Если средняя цена, то плюс-минус от текущей цены топлива (если не имеет места такая ситуация, что машина давно простаивает и в ней числится топливо еще 2000-какого-то старого года)

Например, на Вашей картинке по А-92 цена в машинах более-менее похожа на правду (кроме Основного склада, где к-во 0). А вот по ДТ что-то не то: по Komatsu-500 на начало месяца цена 58.64грн. Вроде топлива по такой цене у нас (еще?) не было

Все эти остатки нужно выравнивать для всех аналитик 203 счета: Номенклатура, Склад, Партия (если есть)

Лучший способ выравнивания - инвентаризация. Но это крайний способ. Нужно как-то выровнять суммы без количества. Например, ручной операцией

3. После выравнивания остатков на начало месяца, перепроводим все документы по ГСМ за месяц. И смотрим на критерии, указанные в п. 2 внутри месяца. Например, на 15 число. Если нет, на более ранее. То есть, формируем оборотку с 01 числа по 15. Если суммы косячат, с 01 по 10 итд. Вплоть до интервала с 01 по 01. Задача - найти дату, где начинаются косяки. Внутри этой даты ищем документы, которые списали (оприходовали) топливо по неправильной цене и пытаемся понять, в чем дело. Часто, дело в последовательности документов внутри дня - во времени приходных и расходных документов

4. После того, как получим результаты анализа п. 3, будут примерно понятны основные причины возникновения некорректных остатков. Например, можно будет установить правила: все приходы внутри дня проводить со временем 09:00, все перемещения 11:00, все списания - 17:00
И дальнейшая отладка остатков 203 счета (в последующих месяцах) пойдет значительно проще

Указанной конфигурации под рукой нет, но общие соображения такие:

1. Курс валют содержит отношение указанной валюты к валюте регламентированного учета.
Обратите внимание на Сервис - Настройка параметров учета - Валюты (или как-там оно называется в Альфа-Авто?). В типовых, которые у меня есть под рукой, подробно написано:

Подчеркиваю: "По отношению к этой валюте указывается курс других валют"

2. Если валюта упр учета у Вас USD, то СуммаУпрОстаток - это сумма в долларах. СуммаГрн = СуммаДол*КурсДол. Как у Вас и получилось в первом подзапросе из объединения

3. Исходя из п.1, курс валюты регламентированного учета (грн) всегда должен быть равен 1, то есть, во втором подзапросе "КурсыВалютСрезПоследних.Курс" всегда будет 1 и Вы просто получили СуммуУпрОстаток, то есть, сумму в долларах

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

СуммаРуб = СуммаГрн/КурсРуб = (СуммаДол*КурсДол)/КурсРуб
СуммаЕвро = СуммаГрн/КурсЕвро = (СуммаДол*КурсДол)/КурсЕвро (да-да, сумма в Евро будет меньше, чем сумма в Дол, поскольку курс Евро больше, чем курс Дол, а у Вас получилось наоборот)

В некоторых валютах (обычно, для Рубля) кроме курса указывается еще и кратность, не равная 1. Поэтому, там, где написано КурсРуб, КурсЕвро итд, следует иметь в виду, что это КурсСУчетомКратности = КурсыВалютСрезПоследних.Курс/КурсыВалютСрезПоследних.Кратность

То есть, при пересчете обычно поступаем так:

1. Проверяем, что у нас за валюта упр. учета? Если она совпадает с валютой регл. учета, то КурсУпр = 1, если нет, то находим КурсУпр в курсах валют
(желательно забыть, что мы знаем, что это доллар и передавать &ВалютаУпр и &ВалютаРегл в параметрах, мы же делаем обработку на все случаи жизни, вдруг примените свою обработку на Базе, где упр учет ведется в Евро?)
2. Находим КурсПересчитываемойВалюты по отношению к ВалютеРегл по переданному параметру &ВалютаПересчета
3. Получаем то, что хотим: СуммаПересчитаннаяВВалюте = СуммаУпр*КурсУпр/КурсПересчитываемойВалюты

И, да, не забываем про кратность

Ерунда какая-то имхо. Попробуйте начать с малого: почистите кэш. Кэш бывает причиной многих непонятных ошибок