Собственно есть пересорт в регистре партий
Склад 1 Товар 1 Партия 1 Переданный -1 -100
Склад 1 Товар 1 Партия 1 Купленный +1 +100
Как оптимальнее написать запрос? Что бы выявить такой пересорт. Первый подзапрос по ключевым, второй по всем и полное соединение?

а что за конфа?

А как вообще отличить обычный приход/расход от пересорта? Определенный регистратор?

остатки по регистру партий полученные по всем измерениям и сгруппированные по всем измерениям кроме Куп/Переданный. по сумме и количеству - сумма.
в результате где количество сумма = 0, там и пересорт

Бешеная Нога в результате где количество сумма = 0, там и пересорт

а где

Склад 1 Товар 1 Партия 1 Переданный -1 -100
Склад 1 Товар 1 Партия 1 Купленный +3 +300
?

(1) УТ
(2) Нельзя
(3) Это такие остатки
(4) Я так и написал - первый по ключевым измерениям, второй по всем вопрос в типе соединения запроса. Полное или левое? Если левое, то первичная таблица по всем измерениям?

(5) в сабже конкретный пример был. от него и плясал

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

Дядя Вася Пересорт это когда два товара по одной цене

по разным ценам - тоже пересорт (имеет смысл только в рознице, естественно)

(8) нет у тебя глобал трабл вижен

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

(12) см (9)

(13) смотрел, у него нет глобал трабл вижен. Но если хочешь потерять время, то попробуй 9. Разбудите к 50-му посту

(12) да можно тут запросом, это же очевидно. просто запрос будет пакетным

(11) Это само собой, речь не о том. Сама проблема по сабжу явно другая. Можно перепроводить, можно в конце месяца отдельным документом исправлять, как это делается с себестоимостью в УТ11. Только если для себестоимости это имеет смысл, она там плавает из-за интеркампани, а не ошибок, то тут просто кривое ведение учета в базе. Мое имхо, разок восстановить, а в док поступления проверку вставить, если уже были движения по партии, не проводить этот док, пока не распроведут реализации этого товара, тогда больше так не ошибутся.

(15) получил запросом из 9
Слева
Склад 1 Товар 1 Партия 1 Переданный -5 -500

Справа
Склад 1 Товар 1 Партия 1 Купленный +3 +300
Склад 1 Товар 1 Партия 1 Подаренный +4 +400

что дальше будешь делать?

(16) Восстановится тупым перепроведением в правильном порядке.

(17) объедини

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

(19) объединил, получил
Склад 1 Товар 1 Партия 1 Переданный -5 -500
Склад 1 Товар 1 Партия 1 Купленный +3 +300
Склад 1 Товар 1 Партия 1 Подаренный +4 +400

дальше что?

(22) иннер джойн сделай. и всё

(23) в 22 сделал уже

(24) иннер джойн с таблицей остатков по партиям без учёта статуса партии

(25) С тем же успехом можно просто выборку без учета статуса сделать, но что это даст? )

(25) моя твоя не понимать, в 22 же иннер джойн с таблицей остатков по партиям без учёта статуса партии. Таблица остатков в 21

Дядя Вася но что это даст?

получишь список товаров, которые по искомому статусу партии имеют отрицательный остаток, а в целом - неотрицательный. т.е. найдёшь не минуса, а именно пересорт

(28) И дальше что? Исправлю партии на сегодняшнюю дату, а на вчерашнюю как был бардак, так и остался. Если что и искать, то сами реализации, которые этот минус создают и по ним проводки-то править...

Дядя Вася И дальше что?

а это вопрос к автору. я лишь отвечаю на вопрос - как выявить

в моем понимании это
(29) inner join on т1.Склад=т2.склад and т1.Товар=т2.товар and т1.Партия=т2.Партия and т1. Количество<0 and т2.количество>0

поправь что не так или объясни почему у тебя "Купленный" а не "подаренный" справа

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

sda553 (15) получил запросом из 9
Слева
Склад 1 Товар 1 Партия 1 Переданный -5 -500

Справа
Склад 1 Товар 1 Партия 1 Купленный +3 +300

что дальше будешь делать?

объедини. получи это:

Склад 1 Товар 1 Партия 1 -5 -500 +3 +300

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

(34) а "Подаренный" куда выкинул?

(36) а зачем он?

(37) пересортивать: у тебя -500 по переданному, неплохо бы его скомпенсировать +400 подаренных +100 купленных

(38) где ты вообще подаренные взял?

(39) ну типа какой то третий вариант по этому измерению где "купленные" и "переданные". Я фиг знает что там за конфа

(40) там нет третьего варианта

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

(42) верь мне

(42) В данном случае как раз не должна. Решается разовая проблема, такая обработка не должна использоваться систематически.

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

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

так а что хочешь то?