Помогите плиз разобраться с запросом.
Нужно вывести с группировкой по складам следующие данные:
- перемещено на склад
- продано
- перемещено со склада

Ломаю голову, можно ли получить эти данные в одном запросе?
Пока у меня не получается.

Сейчас запрос такой:
    "//{{ЗАПРОС(Сформировать)
    |Период с ДатаНачала по ДатаКонца;
    |Фирма            = Регистр.ПартииНаличие.Фирма;
    |ЮрЛицо         = Регистр.ПартииНаличие.Фирма.ЮрЛицо;
    |Номенклатура    = Регистр.ПартииНаличие.Номенклатура;
    |Склад          = Регистр.ПартииНаличие.ТекущийДокумент.ПоступлениеТМЦ.Склад,
    |    Регистр.ПартииНаличие.ТекущийДокумент.ПеремещениеТМЦ.Склад,
    |    Регистр.ПартииНаличие.ТекущийДокумент.ПеремещениеТМЦ.СкладПолучатель,
    |    Регистр.ПартииНаличие.ТекущийДокумент.РеализацияРозница.Склад,
    |    Регистр.ПартииНаличие.ТекущийДокумент.ПоступлениеТМЦРозница.Склад;
    |    //Регистр.ПартииНаличие.ТекущийДокумент.Сторно.СторнируемыйДокумент.Склад;
    |
    |КодОперации    = Регистр.ПартииНаличие.КодОперации;
    |Док            = Регистр.ПартииНаличие.ТекущийДокумент;
    |Количество = Регистр.ПартииНаличие.Количество;
    |
    |Функция ПриходК = Приход(Количество)Когда(НЕ(КодОперации в КодыПеремещений));
    |Функция РасходК = Расход(Количество)Когда(НЕ(КодОперации в КодыПеремещений));
    |Функция ВозвратК = Приход(Количество)Когда(КодОперации в КодыВозвратов);
    |Функция ПеремещеноНаСклад = Приход(Количество)Когда(КодОперации в КодыПеремещений);
    |Функция ПеремещеноСоСклада = Расход(Количество)Когда(КодОперации в КодыПеремещений);
    |
    |Группирока Склад;";


Но что-то не то он мне выдает.
Как правильно написать?

не проще по регистру ОстаткиТМЦ вытащить? там со складом извращаься не надо

"|Склад          = Регистр.ПартииНаличие.ТекущийДокумент.ПоступлениеТМЦ.Склад," - партии и перемещения несовместимы.

(1) нужны еще продажи, поэтому приходится по регистру партий делать

(2) не понял почему несовместимы?

(4) Партии формируются поступлениями и оприходованиями, а вот перемещения не создают партии.

Автор - дятел.

Товар продает не склад, а фирма.

Поэтому продажи по складам - в общем случае - нецензурный вопрос.

Поэтому в типовой ТиС штатно без извратов такую инфу не вытащишь.

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

(5) создают. в услвоиях разных мол на разных складах или при перемещении с оптового на розничный

(6) >> Товар продает не склад, а фирма.
Но фирма ведь продает товар со склада

(7) В ТИСе?

(8) нет. Продажа - это взаимоотношения Продавца и Покупателя.
а не офиса продавца и склада продавца. Поэтому Товар продает ФИРМА - откуда - совершенно ПОКУПАТЕЛЮ пофиг с точки зреняи ведения взаиморасчетов между Продавцом и Покупателем

(9) А то ж!

(8) В ТИСе фирма и склад между сабой не связаны.

(12) обобряю!

(11) Код в студию. Я давно не смотрел ТИС, но не думаю что справочник партий должен изменятся при перемещениях товара с оптового склада в розничный. Жду.

(8) Я не знаю твоей эадачи, но можно привязаться к складу документа, сделавшего движение по регистру партий.

(15) Дык я так и сделал в (0), все равно ерунда получается,
вернее в одном запросе не получается правильно данные сгруппировать.

Наверно надо сделать запрос с группировкой по документу, потом результат выгрузить в таблицу, и потом обрабатывать эту таблицу. И отчет рисовать по таблице

ТС: заведи в базе ОДИН склад "Основной склад".
Заведи ОДНО юрлицо свое.
Заведи столько ФИРМ сколько у тебя ОТДЕЛЬНЫХ объектовучета(складов).
Пипл оперирует ФИРМАМИ.

(14) в рознице в регистре партий фигурирует ПРОДАЖНАЯ ЦЕНА. Поэтому при перемещении с опта в розницу будет два движения по партиям - списание партии с нулевой продажной цена с оптового склада и приход партии с продажной ценой (ИЗМЕРЕНИЕ!) в розницу

(10) это понятно,
но все равно розничный склад - то есть магазин - он торгует товарами разных фирм,
у руководства есть желание видеть какой магазин сколько продает товаров

(16) дятел он дятел и есть.
тогда смотри вариант1 в моем пояснении - каждому складу ПОСТАВЬ В СООТВЕТСВИЕ УНИКАЛЬНОГО МОЛ.
дальше отчет ПРОГРАММИТЬ - выцеплять оборот ПО РАСХОДУ (условие на кодоперации) с нужного МОЛ.
.
даже штатно можно посмотреть нужное - достатоно включить в штатном отчете по партиям галку "детализация по операциям"

(16) Что это: "Регистр.ПартииНаличие.ТекущийДокумент.ПеремещениеТМЦ.Склад,
    |    Регистр.ПартииНаличие.ТекущийДокумент.ПеремещениеТМЦ.СкладПолучатель,"
Какой будет переменная Склад?

(19) ваще бред.
магазин торгует товарами СОБСТВЕННОЙ ФИРМЫ. Которые находятся в собственности фирмы. А не "товарами разных фирм".

(17) так не могу, потому что уже:
- есть несколько своих юрлиц,
- есть около десятка складов,
- на каждое свое юрлицо есть фирма,
- учет ведется несколько лет в таком формате,

Нужно сделать отчет как я писал.
Неужели его нельзя сделать?

(19) ТИС заточена на ОПТ
если у вас РАЗНЫЕ МАГАЗИНЫ РОЗНИЧНЫЕ - то сам бог велел сделать по варианту-2.

(23) дятел*3
можно
можно сделать все.
в твоем случае можно сделать даже НЕ ПРОГРАММЯ, вообще. ни чтрочки - используй вариант 2 или 1

у тя ваще тараканы в бошке.
Магазины - как правило - ведут самостоятельную хоздеятельность (можно так считать даже если магазин не является обособкой). Поэтому каждый магазин - логично выделить в отдельную фирму.

(21) это я разнес:

Склад =  Регистр.ПартииНаличие.ТекущийДокумент.ПеремещениеТМЦ.Склад;
СкладПолучатель =  Регистр.ПартииНаличие.ТекущийДокумент.ПеремещениеТМЦ.СкладПолучатель;

(23) Для непонятливых. Что это:"
   |Склад          = Регистр.ПартииНаличие.ТекущийДокумент.ПоступлениеТМЦ.Склад,
    |    Регистр.ПартииНаличие.ТекущийДокумент.ПеремещениеТМЦ.Склад,
    |    Регистр.ПартииНаличие.ТекущийДокумент.ПеремещениеТМЦ.СкладПолучатель,"
Ты для документа перемещения не можешь создать вторую переменную со значением склада?

(27) нафейхоа это????
если влом делать правильно по вариантам описанным выше:
запрос к регистру партий, с выборкой оборотов, отфильтровать по коду операции = Продажа (если надо то и продажа розница)
к складу адресоваться

СкладПродажи = РегистрПартииНаличие.ТекущийДокумент.Реализация.Склад,РегистрПартииНаличие.ТекущийДокумент.РеализацияРозница.Склад,
.
Все.
.
нафейхоа вам перемещения, пля, если речь о ПРОДАЖАХ?

штатный отчет по партиям, то что тебе надо - выделено зеленым
http://content.screencast.com/users/Che66/folders/Jing/media/0f77c133-4712-4871-a1fe-3f4692187de9/2015-06-29_2305.png

(22) Почему это бред? Может и бред, но тем не менее уже почти 10 лет учет ведется в таком порядке.

Вот такой учет у нас, в целом по компании:
1) ФирмаГлавная получает товар на ОсновнойСклад
2) От Фирмы1 товар передается в Магазин1
3) От Фирмы2 товар передается в Магазин2
4) Товар продается из Магазина1 или Магазина2 по соответсвующей фирме

Вопросов с продажами не возникает - запрос срабатывает, возвращает правильные данные.

Возникает вопрос с перемещениями, так как в перемещении указаны два склада. И не понятно как в запросе сгруппировать одно движение по складу1, а второе движение по складу2.
В этом вопрос, а не в методике учета

(23) ну и дятлы.
прежде чем рисовать структуру упр.учета - надо смотреть на сущности, а не названия сущностей

(31) там у вас стадло непуганых дятлов
.
товар с ФирмаГлавная никаким образом в этой схеме не попадает на Фирму1 и Фирму2

(29) да блин, это ты что-то не понял,
я же написал что надо: по каждому складу надо три числа:
- перемещено на склад
- продано со склада
- перемещено со склада на другой склад

Продажи работают, с перемещениями проблема

(30) в том то и дело, что в ведомости по партиям нету группировки по складам

(35) мозг включи.
читай выше
повесь на каждый склад МОЛ - МОЛЫ назови точно так же как склады.
проведи регламентную операцию - раздачу партий без молов на молы.
все.
будет группировка по МОЛАМ-складам

(34) Одним запросом не получится. Можно разделить на два первый формирует таблицу значений, второй формирует итоговую таблицу.

но есть засады - склады с МОЛАМИ надо сделать другими чем старые склады. Иначе умрете в работе задним числом - там где молов не было

(33) Да, товар из ГлавнойФирмы не попадает в Фирму1, поэтому учет ведут "в целом по компании".
На мои предложения делать как положено реализацю из ГлавнойФирмы Фирме1 - не приняли.

Но не в этом суть....
Как написать запрос по партиям, чтобы перемещения по складам отражались?
Чтобы запрос выдал:

Склад       ПеремещеноНаСклад    ПеремещеноСоСклада    Продано
"Магазин1"    10                      20               5
"Магазин2"     5                       3               2

(34) ой блин
не надо работать с документами

вы там вообще разулись в сущность вещей смотреть?
открой любон перемещение - посмотри КАКОЙ КОД ОПЕРАЦИИ СТОИТ в перемещениях между складами.

ВКЛЮЧИ МОЗГ

перемещение-расход со склада и перемещение приход на склад - идут по одному коду операции.

все что надо
завести в конфиге два кода операций ПеремещениеРасход и ПеремещениеПриход

Подправить глДвижениеПоПартиям - в регистр писать соответствующий код операции для прихода и для расхода.

модифицировать глДвижениеПоПартиям пв части:
там где по партиям НЕ ФОРМИРУЕТСЯ ДВИЖЕНИЙ - прописать формирование с отражение ПО РАСХОДУ и ПО ПРИХОДУ.
все.
после этого штатный отчет по партиям будет показывать - СМ ВЫШЕ - на мой рисунок - то что столбцы "ПРОЧЕЕ" движение ПРОЧЕЕ РАСХОД И ПРОЧЕЕ ПРИХОД - это и будут движения по складам

(36) МОЛы тоже не будем делать - не хотят менеджеры,
сейчас же рынок, всем менеджеры рулят.
Разве может какой-то программист из-за одного отчета убедить менеджеров изменить весь порядок учета?

(39) вы там вообще йопнулись?
в твоей схеме "От Фирмы1 товар передается в Магазин1 "

Магазин1 - это склад?

(40) и все перепроводить за 10 лет??

(42) да, Магазин1 и Магазин2 - это склады.

Правильнее будет так:
1) ФирмаГлавная получает товар на ОсновнойСклад
2) От Фирмы1 товар передается с ОсновногоСклада в Магазин1
3) От Фирмы2 товар передается с ОсновногоСклада в Магазин2

внятный человек фразу "От Фирмы1 товар передается в Магазин1 " - трактует однозначно что Магазин1 - ЭТО ФИРМА. Потому что ОТ ФИРМЫ ПЕРЕДАЕТСЯ !!НА!! ФИРМУ.

я например сильно подозреваю что у вас Магазин1 - это СКЛАД.

Поэтому то что ты написал по передачу от Фирмы1 на Магазин1 - скорее всего бред несусветный

(37) можно примерчик?

(44) молодец, поправился ;-)
.
Излагай ясно, тогда будет ясность в том что надо делать ;-)

Не надо перепроводить 10 лет
С новыми кодами операций просто движения В НОВЫХ документах будут

(45) разве фирмы передают между собой товар?
они его продают друг другу,
а перемещать можно только между складами в пределах фирмы

(48) но отчет хотят смотреть по крайней мере с нового года

(49) неверно. Если фирмы на ОДНОМ СОБСТВЕННОМ юрлице - то перемещение запросто. Вы изначально построили кривую УЧЕТНУЮ СХЕМУ - а теперь маетесь

(48) не менять конфигурацию не буду,
пока попробую все-таки запросом данные выцепить

(50) если делать быстро, то ваще в полпинка делается.
Регистром партий собираешь ДВИЖЕНИЯ (с точностью до документа движения) - тупо кладешь в ТЗ. далее бежишь по ТЗ - смотришь какой док, если реализация - пихаешь в столбец продаж
если документ перемещение - раздваиваешь строку - на расход по складу и приход по складу получателю.

Плоскую таблицу подсовываешь в универсальный отчет по тЗ - возьми у меня на ИС
все.

(51) согласен насчет перемещений,
а насчет учетной схемы - не знаю, не могу судить - не обладаю таким опытом

(52) не выцепишь.
потому что в общем случае перемещения по регистру партий не порождают движений. а тебе нужны суммы - умаешься "писать запрос"

в том запросе который ты хочешь написать - регистром партий не обойдешься...

(46) Сейчас я примеры искать не буду, но в запросах 7.7 функции Сумма() позволено ссылаться на внешнюю функцию и передавать ей параметры, во внешней функции ищешь нужную строку ТЗ и возращаешь значение ячейки ТЗ.
Надеюсь понятно объяснил.

(53) я про это и спрашивал,
"до документа движения" - получается надо только одну группировку - документ?

(53) Как ты на ИС-е называешься? Так же?

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

(53) а вижу в профиле

http://catalog.mista.ru/public/14794/

(60) речь идет про суммы

.. так как у тебя отсутсвует передача сумм от ГлавнаяФирма на Фирма1.
Максимум что ты сможешь собрать запросом - количества

(60) а я не буду делать группировку по фирме,
отчет тоже будет в целом по компании, но в разрезе по складам

при этом в общем случае даже цирфы по количествам будут неверные. Потому что система а) контролирует и запрещает проведение по ОстаткамТМЦ - при этом может получится так что из-за некоректных данных (не распределилось по партиям) - в партиях движения будут отсутсвовать

(62) спасибо

(65) ты дятел*4
ДВИЖЕНИЕ - идет с точностью до фирмы. Поэтому независимо от того будеь ты делать группировк упо фирме или нет - тебе придется спускаться до документов движения - а по ним В РЕГИСТРЕ - будут кривые данные

(64) пока нужны только количества

(68) да сам ты дятел,
я же потом эти данные сгруппирую без учета фирмы,
там сложатся минусы и плюсы, получится реальный итог, который они видят в других отчетах

я могу тебе дать безболезненный рецепт как все сделать просто и правильно. без изменения схемы работы персонала. с минимальными изменениями конфиги. без массового перепроведения доков (максимум ка кты сказал - с нового года) Но ты же не захочешь так делать...

(70) по количеству - да

..при этом пользоваться можно будет штатным отчетом

если нужны только количества - тогда наплюй на регистрпартий и работй по регистру остатков. нужную инфу (перемещение, реализаци, поступление - тяни из вида документа) - в регистре остатков есть все движения по количеству - даже те, которых нет в партиях

(71) ты уже говорил как доработать конфу,
но менять не хочется,

сначала попробую сделать отчет

нужный отчет накидаю ваще с места враз - будет работать только не сильно быстро

запрос кстати тривиальный
заплатишь 2500 за час работы - налабаем сейчас и выведем в отчет.

(74) да, наверно через регистр остатков проще,

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

(78) читай конфу на сон грядущий. Продажи надо тянуть из оборотного регитсра "Продажи". но не в товем этом случае

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

ну я короче на связи всю ночь, ваяю нетленную конфу по услугам ОХ. так что стучись если что. Но после полнуочи тариф вырастет.. ;-)

если надо ПРЕДМЕТНО побазарить - стучись в скайп Zlopun

(77) не, максимум что я получу за этот отчет - это 5 тыс.,
а я сам сегодня почти весь день на него потратил, если еще и 2500 тебе - это получается за бесплатно отчет будет,

буду сам доделывать

(81),(82) ОК, спасибо за помощь

(83) ну дык... это следствие неправильной учетной схемы в ТИСе и нежелании сделать правильно. Тогда запрос строился в полпинка. а так по сути у тебя все сведется к перебору документов

Успехов!

можно тупо по документам запрос сделать, без регистров

(87) ну про то и речь, что по сути в это и выльется