Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1) lrs, Благодарю за комментарий. Скажите пожалуйста в какой конфигурации Вы использовали запрос? Мне очень интересна причина, по которой запрос у Вас не работает, но у меня пока недостаточно информации чтобы её понять. За прикрепленные снимки экрана тройная благодарность.
Все очевидно, вы соединяете таблицы по дате, но за даты, за которые не было движений остаток отсутствует, поэтому в итоговой таблице у вас дырки (т.е. по сути нулевые остатки, которые на самом деле не нулевые)
Для примера смотрите картинку, где слева ведомомсть по товарам на складах с разворотом по дням, а справа итог выполнения вашего запроса. (например, 2,3го числа конечный остаток соответствует остатку за 1е число, но ваша таблица показывает 0 за эти дни...)
PS. Чтоб быстрее разобраться, сделайте отбор по одной номенклатуре, по одному складу. И выберите ту позицию для анализа, по которой хотябы один день не было движений.
Для примера смотрите картинку, где слева ведомомсть по товарам на складах с разворотом по дням, а справа итог выполнения вашего запроса. (например, 2,3го числа конечный остаток соответствует остатку за 1е число, но ваша таблица показывает 0 за эти дни...)
PS. Чтоб быстрее разобраться, сделайте отбор по одной номенклатуре, по одному складу. И выберите ту позицию для анализа, по которой хотябы один день не было движений.
Прикрепленные файлы:
(3) lrs, понял что Вы имели в виду. Когда тестировал у себя такой проблемы не возникало. В приложении снимок моей ведомости и консоли, в запросе разумеется ничего не менял. Движение товаров также отсутствует за некоторые даты, но строк со значением NULL не появляется. Благодарю Вас за обратную связь, постараюсь разобраться с данной проблемой.
Прикрепленные файлы:
(4) В итоге вы уже пришли ни к остаткам на каждый день, а просто к виртуальной таблице остатков и оборотов. Вы все дальше от решения поставленной задачи))
Даже на титульной картинке у вас пропущены даты (в основном это выходные), когда не было движений)))
Пропущенных дат в итоговой таблице Вы не видите, потому что делаете отбор по основному поставщику, обращаясь а элементам, которые отсутствуют в построенной таблице, либо перенесите отбор в условия таблицы остатков и оборотов (Вот сюда: РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты(КОНЕЦПЕРИОДА(&Дата1), КОНЕЦПЕРИОДА(&Дата2), День, , Номенклатура.ОсновнойПоставщик = &ОсновнойПоставщик)), или уберите его на момент проверки..
Даже на титульной картинке у вас пропущены даты (в основном это выходные), когда не было движений)))
Пропущенных дат в итоговой таблице Вы не видите, потому что делаете отбор по основному поставщику, обращаясь а элементам, которые отсутствуют в построенной таблице, либо перенесите отбор в условия таблицы остатков и оборотов (Вот сюда: РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты(КОНЕЦПЕРИОДА(&Дата1), КОНЕЦПЕРИОДА(&Дата2), День, , Номенклатура.ОсновнойПоставщик = &ОсновнойПоставщик)), или уберите его на момент проверки..
Добрый день! Решил переделать Ваш отчет так чтобы он показывал остатки по взаимозачетам на каждый месяц.
Регистр - ВзаиморасчетыСКонтрагентамиПоДокументамРасчетов, Периодичность - Регистратор.
Таблицу календаря беру Кросс-запросом.
В итоге всё получилось, но выяснился прискорбный глюк, который я не смог устранить -
Были движения по документу на НачалоПериода, то есть КонечныйОстаток и Оборот не равны нулю. То есть допустим НачалоПериода = 01.06.2016 00:00:00, и в точности в это же время прошла оплата по реализации ну скажем за апрель, то есть есть скажем ПКО или платежка за 01.06.2016 00:00:00.
В этом случае у нас получается на 01.06.2016 00:00:00 два остатка которые 1С почему то складывает! Итог получается больше на размер остатка на НачалоПериода! Заставить 1С разделить остатки мне не удалось, поэтому я просто сдвинул НачалоПериода на секунду.
В прикрепленной таблице - пример без группировки на суммы.
Регистр - ВзаиморасчетыСКонтрагентамиПоДокументамРасчетов, Периодичность - Регистратор.
Таблицу календаря беру Кросс-запросом.
В итоге всё получилось, но выяснился прискорбный глюк, который я не смог устранить -
Были движения по документу на НачалоПериода, то есть КонечныйОстаток и Оборот не равны нулю. То есть допустим НачалоПериода = 01.06.2016 00:00:00, и в точности в это же время прошла оплата по реализации ну скажем за апрель, то есть есть скажем ПКО или платежка за 01.06.2016 00:00:00.
В этом случае у нас получается на 01.06.2016 00:00:00 два остатка которые 1С почему то складывает! Итог получается больше на размер остатка на НачалоПериода! Заставить 1С разделить остатки мне не удалось, поэтому я просто сдвинул НачалоПериода на секунду.
В прикрепленной таблице - пример без группировки на суммы.
Прикрепленные файлы:
Проблема с отчетом.xls
|ВЫБРАТЬ
| Движения.Контрагент,
| Движения.ДоговорКонтрагента,
| Движения.ДокументРасчетовСКонтрагентом,
| ДНИ.ДатаКалендаря КАК ДатаКалендаря,
| СУММА(ВЫБОР
| КОГДА Движения.Период <= &НачалоПериода
| ТОГДА Движения.СуммаВзаиморасчетовКонечныйОстаток
| ИНАЧЕ ВЫБОР
| КОГДА Движения.Период <= ДНИ.ДатаКалендаря
| ТОГДА Движения.СуммаВзаиморасчетовОборот
| ИНАЧЕ 0
| КОНЕЦ
| КОНЕЦ) КАК СуммаВзаиморасчетовКонечныйОстаток
|ПОМЕСТИТЬ тВзаиморасчеты
|ИЗ
| ДНИ КАК ДНИ
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ВзаиморасчетыСКонтрагентамиПоДокументамРасчетов.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, Регистратор, , {(ДоговорКонтрагента).*, (Сделка).*, (Контрагент).*, (Организация).*}) КАК Движения
| ПО (Движения.Период <= ДНИ.ДатаКалендаря)
|
|СГРУППИРОВАТЬ ПО
| Движения.Контрагент,
| Движения.ДоговорКонтрагента,
| ДНИ.ДатаКалендаря,
| Движения.ДокументРасчетовСКонтрагентом
|;
Причина то понятна, я вам ее уже описал. В принципе наверно ее можно как то отфильтровывать отдельным запросом на началопериода...
вот таким например - если данный запрос не пуст, значит беда.
ВЫБРАТЬ
Вз.СуммаВзаиморасчетовНачальныйОстаток,
Вз.СуммаВзаиморасчетовОборот,
Вз.ДокументРасчетовСКонтрагентом
ИЗ
РегистрНакопления.ВзаиморасчетыСКонтрагентамиПоДокументамРасчетов.ОстаткиИОбороты(&НачалоПериода, &НачалоПериода, , , ) КАК Вз
ГДЕ
Вз.СуммаВзаиморасчетовНачальныйОстаток <> 0
И Вз.СуммаВзаиморасчетовОборот <> 0 Показать
(9) Прогнал запрос у себя. Да есть такое дело. Решение Вы уже описали. Если нужны остатки взаиморасчетов по дням например с 2.01.2017 по 1.27.2017 тогда параметр НачалоПериода устанавливаем на конец предыдущего дня, то есть 1.01.2017 23:59:59. В таком случае в результирующей таблице мы будем видеть корректные остатки начиная с 2.01.2017.
Это конечно не глюк, скорее специфика работы системы. Я когда-то разбирался, пытался понять из-за чего так происходит. Если память мне не изменяет, то такое поведение образуется из-за
В итоге у меня всё работает правильно и насколько я понял у Вас тоже, верно?
Это конечно не глюк, скорее специфика работы системы. Я когда-то разбирался, пытался понять из-за чего так происходит. Если память мне не изменяет, то такое поведение образуется из-за
СУММА(ВЫБОР
КОГДА Движения.Период = &НачалоПериода
ТОГДА Движения.КоличествоКонечныйОстаток
ИНАЧЕ ВЫБОР
КОГДА Движения.Период <= ДНИ.ДатаКалендаря
ТОГДА Движения.КоличествоОборот
ИНАЧЕ 0
КОНЕЦ
КОНЕЦ)
ПоказатьВ итоге у меня всё работает правильно и насколько я понял у Вас тоже, верно?
Это однозначно глюк и вот почему. есть такое понятие как Граница. первый остаток дается на границу исключая данное время, а второй - включая. Система должна точно определить, если ей дается время - она остаток должна брать либо включая либо исключая, но никак не складывая одно с другим!
К сожалению в данном случае граница в качестве периода мне не подходит, так как с ней не работают запросные функции работы с датами
К сожалению в данном случае граница в качестве периода мне не подходит, так как с ней не работают запросные функции работы с датами
Спрашивают этот запрос на каждом 2м собеседовании. Или его или срез последних на каждый день.
Задача интересная, но чисто с точки зрения алгоритмики.
Но нужно понимать что на подзапросе вылететь в Out of memory - ну очень просто.
А есть еще вопрос со звездочкой: а что делать если нам постоянно надо обращаться к остаткам (оборотам) на каждый день (например реальная задача - план закупок для большой сети который актуализируется чуть ли не раз в 10 минут).
Правильный ответ: Храните их расчитанными. Ибо как не получай эти данные - или запрос в цикле (хардкод в коде, неявные запросы в цикле при помощи СКД) или гигантские промежуточные результаты. Нельзя получить быстро, что не хранится. Да минусы у этого подхода: 1) рост базы 2) отставание актуальности данных на частоту выполнения регламентного задания. Плюс другой - при частом выполнении данного запроса будет очень сильная нагрузка на базу. И если база большая, или не большая, но период большой, то время выполнения данного запроса будет или не удовлетворительным или начнутся технологические проблемы.
Из своей практики: В реальной жизни данный запрос получается объединением данных за прошлые числа из расчитанного регистра и данные вирт таблиц за сегодня. Все работает более чем быстро.
Задача интересная, но чисто с точки зрения алгоритмики.
Но нужно понимать что на подзапросе вылететь в Out of memory - ну очень просто.
А есть еще вопрос со звездочкой: а что делать если нам постоянно надо обращаться к остаткам (оборотам) на каждый день (например реальная задача - план закупок для большой сети который актуализируется чуть ли не раз в 10 минут).
Правильный ответ: Храните их расчитанными. Ибо как не получай эти данные - или запрос в цикле (хардкод в коде, неявные запросы в цикле при помощи СКД) или гигантские промежуточные результаты. Нельзя получить быстро, что не хранится. Да минусы у этого подхода: 1) рост базы 2) отставание актуальности данных на частоту выполнения регламентного задания. Плюс другой - при частом выполнении данного запроса будет очень сильная нагрузка на базу. И если база большая, или не большая, но период большой, то время выполнения данного запроса будет или не удовлетворительным или начнутся технологические проблемы.
Из своей практики: В реальной жизни данный запрос получается объединением данных за прошлые числа из расчитанного регистра и данные вирт таблиц за сегодня. Все работает более чем быстро.
Остаток на каждый месяц по счету 02 для бух корп
ВЫБРАТЬ РАЗЛИЧНЫЕ
НАЧАЛОПЕРИОДА(РегламентированныйПроизводственныйКалендарь.Дата, МЕСЯЦ) КАК Месяц
ПОМЕСТИТЬ ВТКалендарь
ИЗ
РегистрСведений.ДанныеПроизводственногоКалендаря КАК РегламентированныйПроизводственныйКалендарь
ГДЕ
РегламентированныйПроизводственныйКалендарь.Дата МЕЖДУ &Дата1 И &Дата2
;
//////////////////////////////////////////////////////////// Показать
Для чего конструкция
когда соединение идёт
Может просто Движения.КоличествоОборот?
ВЫБОР
КОГДА Движения.Период <= ДНИ.ДатаКалендаря
ТОГДА Движения.КоличествоОборот
ИНАЧЕ 0
КОНЕЦ
КОГДА Движения.Период <= ДНИ.ДатаКалендаря
ТОГДА Движения.КоличествоОборот
ИНАЧЕ 0
КОНЕЦ
когда соединение идёт
ПО (Движения.Период <= ДНИ.ДатаКалендаря)
Может просто Движения.КоличествоОборот?
Вот простой запрос по взаиморасчетам, все работает как надо
ВЫБРАТЬ РАЗЛИЧНЫЕ
НАЧАЛОПЕРИОДА(РегламентированныйПроизводственныйКалендарь.ДатаКалендаря, МЕСЯЦ) КАК ПериодРегистрации
ПОМЕСТИТЬ ВТ_Периоды
ИЗ
РегистрСведений.РегламентированныйПроизводственныйКалендарь КАК РегламентированныйПроизводственныйКалендарь
ГДЕ
РегламентированныйПроизводственныйКалендарь.ДатаКалендаря МЕЖДУ &ДатаНачала И &ДатаОкончания
;
//////////////////////////////////////////////////////////// Показать
ни запрос из статьи ни запрос из (18) не работают в случае отсутствия товара на остатках на НачалоПериода, но его появления на остатках потом. Такой возможностью не стоит пренебрегать
вот вроде рабочий запрос
вот вроде рабочий запрос
ВЫБРАТЬ
СпрНоменклатура.Ссылка КАК Номенклатура
ПОМЕСТИТЬ ТЗНоменклатур
ИЗ
Справочник.Номенклатура КАК СпрНоменклатура
ГДЕ
СпрНоменклатура.Ссылка В ИЕРАРХИИ(&Номенклатура)
И НЕ СпрНоменклатура.ЭтоГруппа
;
//////////////////////////////////////////////////////////// ПоказатьВопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|