Вот тут скрин журнала регистрации, который я нашел в интернете, где фиксируются метаданные:
Уверен, что у Вас точно так же прекрасно фиксируются метаданные. Но только не для ошибок. Посмотрите другие события: добавление, проведение, изменение документов
Судя по скрину, Ваш основной источник ошибок - модуль формы Документа.Славсант_Отгрузка. Поставьте запись Журнала регистрации при открытии формы (Пользователь открыл документ № такой-то), потом посмотрите, какой документ открывал Пользователь перед ошибкой, а потом попробуйте попытать его на предмет того, чем он там занимался
Посмотрел в свой Журнал регистрации и с удивлением обнаружил, что ошибки выполнения регистрируются точно так же, как у Вас. То есть, без метаданных и данных. У Вас ведь на скрине фильтр событий по ошибкам выполнения? Видимо, придется номер документа выяснять у Пользователя и, засучив рукава, уничтожать ошибки
Не уверен, что правильно понял задачу, но предполагаю, что таким запросом её не решить. У Вас должна быть группировка по ПодразделениеРодитель без группировки по Подразделению, иначе Вы неправильно получите диапазон "вредняка", в который у Вас попадет данный сотрудник.
То есть, у Вас в запросе будут переменные типа
ВЫБОР КОГДА ВнутреннееОборот>0 И ВнутреннееОборот<=100 ТОГДА 1 ИНАЧЕ 0 КОНЕЦ КАК Диапазон1,
ВЫБОР КОГДА ВнутреннееОборот>100 И ВнутреннееОборот<=200 ТОГДА 1 ИНАЧЕ 0 КОНЕЦ КАК Диапазон2,
И если Вы не сгруппируете предварительно результат по ПодразделениеРодитель, Вы не получите правильные значения ВнутреннееОборот
Но, конечно же, есть и хорошая новость. Если Вам нужен именно отчет, то СКД в данном случае всё сделает идеально. Указанные выше функции прописываете в Вычисляемые поля, а потом хорошенько колдуете на закладке "Ресурсы" (там нельзя делать ресурс СУММА(Диапазон1), а нужно повозиться с етой формулой)
Nikitaje, Немного не так. События формы срабатывают ТОЛЬКО в случае открытой формы. События объекта срабатывают при любом изменении объекта (как интерактивном, так и программном)
Если Вы открыли документ (именно форму документа), нажали "Записать" (или ОК), то срабатывают события в следующей последовательности:
1. ПередЗаписью() на форме документа
2. 2а) ПередЗаписью() в модуле документа 2б) ПриЗаписи() в модуле документа 2в) ОбработкаПроведения() в модуле документа - если проводим
3. ПриЗаписи() на форме документа 4. ПослеЗаписи() на форме документа
Если Вы записываете документ программно (или проводите его, например, из формы списка), у Вас будет только пункт 2
Еще есть момент: весь п2 - это транзакция, а п1 - это другая транзакция. Если Вы создадите в 2а) какие-то новые объекты в документе, а затем в 2в) у Вас произойдет отказ, Вы можете получите битые ссылки типа <Объект не найден>, поэтому иногда создание таких объектов есть смысл вывести в ПередЗаписью() формы документа
Не вполне понятно, у Вас не срабатывает ПередЗаписью() в модуле формы при вызове
Цитата
Записать(РежимЗаписиДокумента.Запись);
? Дык, оно и не должно. В модуле формы это событие возникнет только при интерактивной записи документа из его формы А вот ПередЗаписью() в модуле объекта, да, выполняется и при программной и при интерактивной записи объекта
Похоже, это расплата за широкие возможности вычисляемых полей (внешние функции, хитрые вычисления итп). Видимо, нужно пихать такое в основной запрос. Хотя, лично меня это и несколько удивляет (зачем тогда колонка "тип" в вычисляемых полях?)
Если это не запрос для получения динамического списка, то мои советы такие: 1. Попробуйте вместо вложенных запросов использовать временные таблицы 2. С временными таблицами используйте индексы по полям, которые потом будете соединять. Если есть составные поля (Документ.ПриходныйКассовыйОрдер.РасшифровкаПлатежа.Заказ итп), желательно во временной таблице их типизировать 3. Консолью запроса смотрите, сколько записей в каждой из временных таблиц и сколько времени они формируются. И пытаетесь понять, что не так. Возможно, для конкретно Вашей Базы ничего здесь оптимизацией запроса и не сделаешь: быть может, у Вас слишком много Номенклатуры и Заказов? Нужно анализировать
Временные таблицы: ВТНоменклатураДополнительныеРеквизиты ВТВложенныйЗапрос ВТВложенныйЗапрос1 ВТВЗВозвраты и финальный запрос, где все они соединяются с ПриходныйКассовыйОрдерРасшифровкаПлатежа
Что-то как-то Вы неправильно с вложенными таблицами в Запросе работаете. Рекомендую почитать, например, вот ето
Выражение
РезультатВыбора.Товары.Columns.КодНоменклатуры
вернет Вам колонку результата запроса, которая в Вашем случае будет COM-объектом
Вам нужно что-то вроде
... Пока РезультатВыбора.Следующий() Цикл
// здесь должна быть выборка по строкам таб. части Товары - обходим строки данной таб. части ВыборкаТовары = РезультатВыбора.Товары.Выбрать();
Пока ВыборкаТовары.Следующий() Цикл
КодНоменклатуры = ВыборкаТовары.КодНоменклатуры; // вот ето значение примитивного типа, по нему можете осуществлять поиск в текущей Базе
НоменклатураCOM = ВыборкаТовары.Номенклатура; // а ето Номенклатура из COM-базы. То есть, COM-объект
НоменклатураНаименование = НоменклатураCOM.Наименование; // ето также значение примитивного типа, по нему можно осуществлять поиск
НоменклатураUID = НоменклатураCOM.УникальныйИдентификатор(); // а вот по етой позиции лучше всего искать ссылку, если у Вас идет синхронизация обмена по внутреннему идентификатору
Попытайтесь определить, косяк при выгрузке или при загрузке? Если универсальным обменом выгрузить в файл обмена какой-то документ по Вашей схеме, в поле Количество в этом файле что будет?
Если ничего хорошего, то интересно бы посмотреть полный текст ПередОбработкой в правиле конвертации группы свойств Если там нормальное число, ничуть не хуже, чем цена или сумма, значит что-то происходит при загрузке, а не при выгрузке. Тогда интересно, что у Вас там за модули ПередЗагрузкой, ПриЗагрузке, ПослеЗагрузки в объекте-приемнике
Гм. Могу предположить "по приборам" (не зная Конфигурации), что проблему можно решить таким образом: Объект.ПодготовитьТаблицы() вызывает ОбщегоНазначения.СформироватьЗапросПоТабличнойЧасти(), где формируется запрос к документу
... Запрос.Текст = "ВЫБРАТЬ | Док.НомерСтроки " + ТекстЗапроса + " | ИЗ | Документ." + ДокументОбъект.Метаданные().Имя + "."+ СокрЛП(ИмяТабличнойЧасти) + " КАК Док | ГДЕ Док.Ссылка = &ДокументСсылка"; ...
Вот если ету конструкцию дополнить
... | УПОРЯДОЧИТЬ ПО | Док.НомерСтроки ...
, то, как мне думается, это должно помочь в большинстве документов
А вот о причине такой сортировки при смене СУБД мне трудно судить: знаний не хватает. Если мне не изменяет память, у меня была подобная ситуация после перехода с файловой БД как раз на MS SQL. Но в другом запросе УТП. Где-то в УправленииЗапасами емнип. Но смысл был тот же самый: вылечилось сортировкой по НомеруСтроки
Схемку бы посмотреть. Странно как-то у Вас получилось
Цитата(Constantus @ 20.07.20, 9:39)
В СКД есть два набора данных запроса, они независимы по структуре и смыслу. У обоих наборов есть общее поле "Номенклатура". Отчет выводится двумя таблицами.
Эти 2 набора данных. Вы их объединяете? Или связываете левым соединением? Или никак не связываете? Можете приложить скрины закладок "Набор данных", "Связи наборов данных" и "Настройки"?
Навскидку, я бы делал так: 2 набора данных = 2 запроса. В обоих "Номенклатура". Добавляем "Набор данных объединение" и запихиваем под него оба запроса. Всё должно сработать, отбор по Номенклатуре будет один
Есть вариант, что у Вас в Регистрах Номенклатура называется по-разному. Например, в одном - НоменклатураПриход, в другом - НоменклатураПоставщика. Вы ставите в финальном запросе и там и там псевдоним "Номенклатура", но при этом, если в Ваших наборах данных установлен флаг "Автозаполнение", в отборах виртуальных таблиц СКД будет называть эти Номенклатуры по-разному. Выход - снимать "Автозаполнение" и прописывать отборы на закладке "Компоновка данных" каждого запроса
В общем, хотелось бы посмотреть на схему. Хотя бы без конкретики, издалека, на указанных закладках. Без этого трудно помочь: с СКД проблемы могут быть там, где их не ждешь
А все что нужно это просто вставить эту несчастную указанную дату в это несчастное поле даты на форме.
Немного запутанно. Уточните пожалуйста, Вы хотите изменить дату на форме, чтобы она попала в Параметр СКД? Тогда, вроде, в ПараметрыДанных_Заполнить() всё чотко, должно сработать. Естественно, когда Вы нажмете "Сформировать"
Что у Вас должно происходить в ГодПриИзменении() и МесяцПриИзменении(), не совсем понятно. Почему-то Вы передаете в правильную процедуру ПараметрыДанных_Заполнить() все время одинаковый интервал: с начала веков по текущую дату. Возможно, там имеется в виду что-то вроде
Татьяна92 @ 14.07.20, 13:44
, Что-то тут не то. Скажите, какая у Вас Конфигурация хотя-бы. Возможно, запасы съехали где-то в управленческих регистрах, поэтому и формируется неправильная проводка
Е.Ю.Хрусталева в "Разработка сложных отчетов в 1С:Предприятии 8" приводит пример такого задания отбора во вложенной Схеме. Если кратко, то над вложенным отчетом добавляется группировка основного отчета (чаще всего, Детальные записи). И после этого во вложенную схему добавляются отборы типа "Номенклатура Равно ОбъектНастройкиВладелец.Номенклатура". Все работает, но результат не будет выведен в одну таблицу. На каждую группировку основного отчета будет выведена отдельная таблица из вложенной схемы. Если Номенклатура одна, то и ничего страшного, а если их много, то куча маленьких табличек выглядит не очень (как по мне). Можно ли это поправить и исхитриться вывести вложенный отчет в одну таблицу, мне неведомо, но у меня не получилось. Поэтому, попробуйте. Если устроит - здОрово. Не устроит - переносите вложенную схему в запрос основной
Цитата(Constantus @ 15.07.20, 10:14)
ПС: так, мимоходом, а как сделать так, чтобы "верхний" отчет по вложенной схеме был в спойлере, сворачиваемый?
Дык, в настройках уберите флажок с этого отчета и всё, его нет. Можно какой-то флаг на форму добавить и перед формированием отчета программно изменять СКД
из приведенного вами примера можно попросить скриншоты Конструктора настроек компоновки данных по шагам?
В топку Конструктор. Создаете запрос в "Наборы данных", прописываете "Ресурсы" на соответствующей закладке. На закладке "Настройки" по отчету тыцкаете правой клавишей мыши - "Новая диаграмма". Получаете чудесную заготовку, которую и настраиваете
Цитата(Orion-PS @ 14.07.20, 13:40)
Как Вы получили поле "ПериодМесяц"? В параметрах виртуальной таблицы периодичность "Месяц", конечно, задается, но в поля это значение само не попадает...
Поставьте в параметры виртуальной таблицы "Авто". Можно поставить и "Месяц", тогда поле будет называться "Период"
В УПП есть прикол, связанный с документом "УстановкаПараметровУчетаНоменклатуры". Вот если он у Вас в системе заведен, то Ваши настройки счетов в регистре до лампочки. Некоторые подробности - ТУТ. Общий смысл: "С даты первого проведенного документа «Установка параметров учета номенклатуры» будет действовать режим определения счетов при проведении документов.". Причем, в этом документе нет схемы реализации, но Система считает, что она её и так определит (в указанной Вами процедуре) В модуле СчетаУчетаВДокументах ето зашито примерно тут:
Функция ПолучитьСчетаУчетаНоменклатурыИзНастроек(Организация, Номенклатура, Склад, Дата, ХозяйственнаяСитуация = "") Экспорт
Если ИспользоватьОпределениеСчетовПриПроведенииДокументов(Дата) Тогда
Нужные нам счета из регистра сведений получаются, если не срабатывает "ИспользоватьОпределениеСчетовПриПроведенииДокументов"
Лично я считаю эту фишку вредной и никогда не использую
Совет такой: 1. Убедитесь, что у Вас в системе есть документ "УстановкаПараметровУчетаНоменклатуры". Перенесите его на какую-то дату, которая больше даты Вашего документа 2. Перезайдите в Базу(!это нужно сделать, параметр кэшируется). Попробуйте в документе перевыбрать Номенклатуру. Должна подставиться нужная Вам схема реализации 3. Если нет такого документа или не подставилась схема, тогда я не знаю
Вы эти запросы используете во вложенных схемах? В них можно передать параметры из основной схемы. У Вас сложности в передаче параметров во вложенную схему? Или я неправильно понял вопрос?
А что у Вас за Конфигурация, в которой ведется учет топлива? Или учет топлива ведется в одной конфигурацией, а затем выгружается в Бухгалтерию? Ведется ли партионный учет? Возможно, цену топлива в конце месяца у Вас призван выравнивать какой-то регламентный документ, который забывают провести?
Если у Вас обычная Бухгалтерия, тогда Вам придется выравнивать остатки. Вдумчиво. Этапы примерно такие:
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. Получаем то, что хотим: СуммаПересчитаннаяВВалюте = СуммаУпр*КурсУпр/КурсПересчитываемойВалюты
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!