Помогите посчитать количество дней которые товар был на складе

← →
mvgfirst (2003-05-16 17:14) [0]

Есть таблица "Обороты товара":
CREATE TABLE [RA219] (
[IDDOC] [char] (9) COLLATE Cyrillic_General_CI_AS NOT NULL , --Идентификатор документа
[DATE_TIME_IDDOC] [char] (23) COLLATE Cyrillic_General_CI_AS NOT NULL , -- Дата+Время+Идентификатор документа
[SP290] [char] (9) COLLATE Cyrillic_General_CI_AS NOT NULL , -- Идентификатор Контрагента
[SP291] [char] (9) COLLATE Cyrillic_General_CI_AS NOT NULL , -- Идентификатор Товара
[SP292] [numeric](18, 3) NOT NULL , -- Количество прихода товара
[SP294] [numeric](18, 3) NOT NULL , -- Количество расхода товара
) ON [PRIMARY]

Нужно получить количество дней во время которых товар находился в организации (Количество_Прихода-Количество_Расхода <> 0). Т.е. нужно подсчитать количество дней в промежутках когда товар был на складах орагнизации. и не считать те промежутки когда товара небыло.

← →
NickBat (2003-05-16 17:21) [1]

Ну а в каком поле эти даты записаны?

← →
mvgfirst (2003-05-16 17:48) [2]

[DATE_TIME_IDDOC] [char] (23) COLLATE Cyrillic_General_CI_AS NOT NULL , -- Дата+Время+Идентификатор документа

← →
mvgfirst (2003-05-16 17:49) [3]

Структуру базы придумывал не я - это 1С :) Поэтому сильно ногами не пинайте :)

← →
mvgfirst (2003-05-16 18:17) [4]

Никто не поможет?
А может тогда скажете какой SQL конструкцией можно получить итого по товару сгруппированные по датам но с дискретизацией по одному дню?

← →
kaif (2003-05-16 20:48) [5]

>А может тогда скажете какой SQL конструкцией можно получить >итого по товару сгруппированные по датам но с дискретизацией по >одному дню?

Найди функцию, которая из даты-время, которой 1С поклоняется, просто дату делает (без времени), и в SELECT-е суммируй количество товара, группируя по результату работы этй функции.

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

← →
Serginio (2003-05-16 20:57) [6]

Одним запросом количество дней не получишь. Нужно сначала проверять начальные остатки а затем отслеживать все движения по дням. Когда остаток обнулится подсчитывается количество дней
текущаядата-датапоявлениятоваранаскладе+1. Если был приход а до этого остаток был равен 0 то датапоявлениятоваранаскладе=текущаядата.
И после окончания расчета если остатки >0 ДатаконцаРасчета-датапоявлениятоваранаскладе+1; Разумеется все ссумируется. Кстати в какойто типовой есть такого рода анализ.

← →
Serginio (2003-05-16 21:16) [7]

Ухожу. Задай этот вопрос на
http://www.kuban.ru/cgi-bin/forum/forum9.cgi
А у меня сейчас нет времени да и желания. Подумай сам
Есть чудесная вещь называется Group By [DATE_TIME_IDDOC]
Но еще раз повторю тебе нужно получить два запроса а затем програмно отрабатывать.

← →
mvgfirst (2003-05-17 14:03) [8]

2 kaif
Если делать так как ты говоришь то я получу итоги только по тем датам по которым были движения. А я спрашивал каким образом получить итоги на каждый день (не зависимо от того были ли движения в этот день) Т.е. нужно получить итоги на все даты в течении определенного периода

← →
mvgfirst (2003-05-17 14:05) [9]

2 Sergino
То что ты говоришь на MS SQL можно сделать только используя курсоры. А это очень медленно. Так как такую операцию придется проводить для каждого товара а их может быть десятки тысяч.

Нужно решение которо можно выполнить одним запросом SQL и не использовать курсоры.

← →
kaif (2003-05-18 01:03) [10]

2 mvgfirst (17.05.03 14:05)
Курсоры в MS SQL вовсе не медленная вещь. Я юзал курсоры и очень мне это дело понравилось, хоть это и плохой тон в SQL. В IB я обхожусь без всяких курсоров, но в MS SQL их приходилось использовать достаточно много и проблем больших я не видел. Кстати и создаются они в MS SQL очень легко.

Согласен, что я неточно понял твой вопрос о группировке.
В IB я обычно делаю так: у меня есть генератор набора дат (но это только в IB возможно, так как там существует SUSPEND внутри хранимых процедур и можно делать выборки, объединяющие результаты работы ХП с таблицами). На MS SQL можно сгенерить временную (или постояннцю) таблицу всех дат подряд, сделать объединение LEFT OUTER JOIN с таблицей движения товаров и суммирование с группировкой по дате из первой таблицы. Тогда ты получишь график по всем датам. Кстати, если ты в таблице дат заведешь еще пару колонок (неделя, месяц), то сможешь получить группировку и по таким классным промежуткам ремени. Подумай, так как это очень хорошая идея. Единственно, что в ней плохо - сам LEFT OUTER JOIN, который не знаю, насколько корректно в MS SQL сочетается с агрегатными функциями. Но попробовать стоит.

← →
Serginio (2003-05-19 15:27) [11]

Делаешь всего два запроса 1. Остатки товаров 2. Второй движение товаров желательно в формате товар дата приход расход продажа сгруппированные по товар дата а затем на клиенте обсчитываешь. Можно остатки загнать в память и обсчитывать каждый товар. Я правда обсчитываю ДБФ но например около 500 000 записей движений товара и всего за 6-12 сек на АМД 900.

← →
Danilka (2003-05-19 16:07) [12]

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

← →
mvgfirst (2003-05-19 16:18) [13]

2 Serginio
Обсчитывать на клиенте - абсолютно неприменимо. Все это я делаю на 1С, а любые операции над большми объемами в 1С - жто смертоубийство. Почему и пытаюсь сделать все одним запросом, что бы максимально уменьшить время отклика на больших отчетах.

2 Danilka
Вообщето я не первый год замужем. И что и как 1С хранит у себя в базах знаю, и если вы прочитаете внимательно весь топик то поймете что мне нужен отчет по каждому дню, не зависимо от того были в этот день движения или небыло. А насчет научится брать остатки - я могу вас и сам научить :). Опыт имеется.
Во вторых - точка актуальности в 1С придумана для того что бы не перещитывать итоги на момент "актуальности" - а если мне необходимо получить итог за нестандартный период - то 1С начинает все пересчитывать и делаеть она это НЕПРОСТИТЕЛЬНО ДОЛГО!!!!!

← →
mvgfirst (2003-05-19 16:23) [14]

2 kaif ©
Вот именно так и собираюсь делать. Но на всякий случай ищу альтернативы. :)

← →
Danilka (2003-05-19 16:30) [15]

mvgfirst (19.05.03 16:18)
>научится брать остатки - я могу вас и сам научить :). Опыт имеется.

Если забесплатно, то почему-бы и нет, было-бы интересно. Можете лекции слать мне на мыло. :))

← →
Serginio (2003-05-19 16:48) [16]

>>mvgfirst (19.05.03 16:18)
А зачем в 1С существуют ВК и обычные СОМ объекты. Я только через них и обрабатываю сложные задачи. Еще раз повторю 1 запросом не получится у тебя. Смотри >>Serginio (16.05.03 20:57)

← →
mvgfirst (2003-05-19 16:56) [17]

http://www.sql.ru/forum/actualthread.aspx?bid=1&tid=32270
Посмотри - тут вот говорят что можно :)

← →
Serginio (2003-05-19 17:10) [18]

Тогда объясни мне глупому как можно найти количество нахождения товара на складе не зная конечных или начальных остатков. Причем остатки будут прыгать от 0 и больше и обратно взависимости от движения товара?????

← →
mvgfirst (2003-05-19 17:12) [19]

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

← →
Serginio (2003-05-19 17:19) [20]

Тебе остатки не нужны только в одном случае когда они нулевые. Но еще раз повторю остатки будут прыгать
для примера 1 января приход 1; 1 января уход 1; дней в продаже 1; затем приход 4 января 100 и 30 января товар обнулился (30-4)+1;
Итого товар находился в продаже 27 дней. Если такое возможно сделать одним запросом подскажи намотаю на ус.

← →
mvgfirst (2003-05-19 18:47) [21]

set nocount on declare @dMin smalldatetime, @dMax smalldatetime select @dMin= Convert(smalldatetime,"20020801"), @dMax= Convert(smalldatetime,"20030130") declare @tab table(dat smalldatetime PRIMARY KEY CLUSTERED) while @dMin <= @dMax begin insert @tab VALUES (@dMin) set @dMin= @dMin+1 end select sp237, count(kol) kol from ( select sp237, dat, sum(case when debkred = 0 then sp239 else -sp239 end) kol from @tab, ra210 where -- sp237 = " F4 " and left(date_time_iddoc,8) < convert(char(8),dat,112) group by sp237, dat) aa group by sp237
Здесь:
ra210 регистр остатков в 1С - если ты с ней знаком поймешь
sp237 идентификатор товара

Писал на скорую руку, над оптимизацией не думал - но работает проверял на живой базе количесвто записей в таблице RA210 30 000. Считает долго около 3-х мин.

← →
mvgfirst (2003-05-19 18:48) [22]

Забыл сказать сервер MS SQL 2K

← →
Serginio (2003-05-19 19:07) [23]

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

← →
mvgfirst (2003-05-19 19:10) [24]

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

← →
Serginio (2003-05-19 19:14) [25]

Я все могу понять но как ты без начальных остатков.
Было на 1 января было 3 7 января ушло 3.

← →
Serginio (2003-05-19 19:18) [26]

Вернее так поставим задачу. Остаток на 1 Января 3 затем 10 приход 4 а 30 расход 4. Сколько по твему запросу товар находился на складе????

← →
Serginio (2003-05-19 19:43) [27]

Предыдуший вопрос в силе, но ресурсы твой запрос конечно пожрет капитально. Просчитывать по нескольку раз то что уже расчитано на предыдущем шаге крайне не эффективно. Пока не переубедил.

← →
mvgfirst (2003-05-19 20:01) [28]

Зато это делаю не я и не руками :) А SQL запрос. И это на порядок эффективней (особенно если слегка оптимизировать SQL скрипт) чем выполнять тот же анализ руками :).

← →
Serginio (2003-05-19 20:08) [29]

Ну при таком подходе 1С вообще суппер быстрая. Зато ручками смотри Serginio (19.05.03 15:27)
Опять же твой так называемый 1 запрос справедлив только при нулевых начальных остатках, что бывает очень редко если не считать начало работы предприятия.

← →
Serginio (2003-05-19 20:13) [30]

Да еще 1 раз создав ручками будешь использовать его постоянно. Главное что бы структура возвращаемых запросов была одинакова.
Кстати обсчитывая 1С таблицы в основном в памяти и эти скорости 1С и не снились все очень бысто если не сказать мгновенно.

← →
mvgfirst (2003-05-20 10:02) [31]

Вопервых этот запрос применим всегда, а не только при нулевых начальных остатках, потому как считает конечные остатки по каждому товару. На каждую дату. Во вторых - технология клиент-сервер зачем-то была придумана? Тебе не кажется что как раз для того что бы избежать "быстрых обсчетов в памяти"??? Мне казалось что это одна из причин. И именно потому что 1С так "быстро" все обсчитывает я и занялся переводом механизмов получения данных на прямой доступ к SQL.

Помогите посчитать количество дней которые товар был на складе Найти похожие ветки