УТ 10.3 Вопрос пользователя. Неликвиды. #482329

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

Использовать консоль запросов :)

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

Есть еще "Оборачиваемость товара", вроде.

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

а вообще +1 должен типовой быть

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

э, написал тут вроде, но есть проблема:    ТоварыНаСкладахОстаткиИОбороты.Номенклатура,    ТоварыНаСкладахОстаткиИОбороты.КоличествоКонечныйОстаток Показывает товары, по которым не было продаж в начале списка (собственно неликвиды), но не могу сделать чтобы те товары, по которым БЫЛИ продажи - не показывались.

не правильно. где то тут была тема.

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

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

вот еще тема

У делал так: Получем все данные. Остатки, продажи за период, количество дней когда товар был в продаже (на остатках) - чтобы отсеить от неликвидного новый товар или который за указанный период мог прийти поздно. Согласно этих данных считаем ликвидность (срок акутальности текущих остатков согласно статистике продаж). Получаем порог ликвидности. В разработке также выводится детальная инфа по товару. Вот собственно и все. практически 99 процентов - верная информация.

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

я использовал не один регистр а соединение практически всех товарных регистров.

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

неправильно.

ну мало чо устраивает программиста. вопрос правильно это или нет. условие - есть остаток на начало и на конец - неправильно. На конец правильно, а на начало неправильно.

бах товар пришел на следующий день!!!

лана придумывай велосипед раз ничо не нужно)) это любимое занятие программистов.

ну и что, что он пришел на следующий день ? Неликвид - товар, который лежит на прилавке и не продается в течение определенного периода времени. Если я рассматриваю период 1 месяц и беру с 01.04.2010 по 30.04.2010, а товар пришел 02.04.2010, то в рамках теории такой товар неликвидом являться не может в этом периоде, потому как на прилавке на начало периода его не было.

неликвид это не тот товаркоторые не продается. Неликвид этот тот товар которого с любыми продажами больше чем нужно на определенный период времени! причем он может продаваться!

ачто если товара купили на неделю? а он пришел на след день второго числа и гад уже три недели валяется. и его ликвидность показывает что еще полгода будет лежать.

да причем тут это вообще, все зависит от того, какую парадигму ты используешь на разных фирмах неликвидом считают разные товары и это абсолютно нормально я описал, что я хочу получить в первом посте

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

а ну если чисто так "Неликвиды - это товары, которые не продаются в течение определенного срока." то тут да. Запрос по регу остатков с регом продаж. и условие по объединенному запросу по суловию продажи = 0

эти темы можно исследовать и регулировать разными инструментами, например: 2. рентабельность 3. коэффициент возврата инвестиций но сегодня я хочу увидеть товар, который не продавался за определенный период

но я бы подумал и переспросил. начнут за три месяца крутить уже данные будут другими.

или за полгода. начнет фигню выводить.

Отчет "Анализ оборачиваемости товаров" не предлагали??

предлагали, но он кривоват для моих целей

ну тебе ответили. по остаткам выбираешь остаток, по продажам - продажи. объединением. и ставишь условие. остаток больше нуля и продажи равно нулю. всё

и работать это будет нормально только если как ты описал - период месяц. если начнется больше то можешь выкинуть данную логику.

чем кривоват, если не секрет?

я не догоняю где нужно прописать продажи равно нулю

чем кривоват я в 7-ом посте написал

расход за период?

ладно короче не знаешь запросы.

я писать точно запросы для тебя не буду.

угу, грешен :)

конечно, ты лучше мне впаришь вашу монструозную разработку :) правда в итоге окажется, что для того чтобы мы могли ее использовать ее нужно так перетачивать напильником, что проще новую написать просто интересно такие разработки, как "Мания1С: Рабочее место менеджера по закупкам" вообще кто-то покупает, кроме одного единственного первого заказчика для которого все это и писалось ? :)

у это разработки 18 клиентов.

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

ABC XYZ предлагали? или я глубоко?

она полностью ложится в идеале на типовые программы. этой мой бизнес кстати. официальный.

ты логи обновлений и отзывы почитай)

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

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

т.е. если я это решение покупаю, то я могу сам его дорабатывать?

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

да. код открыт, доработка тоже. демо выслать?

ок, от чего бы и не поглядеть ip-alekseev(гав)yandex.ru с типовой-то один фиг работать невозможно

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

выслал весь комлект демок:)

спасибо, посмотрю в ближайшее время

По твоему вопросу, как иы задумал. Делаешь запрос по двум регистрам. Объединением. в запросе это два запроса по двум регистрам с конструкцией ОБЪЕДИНИТЬ ВСЁ получаешь склеенную выборку. По сути все. потом отборы и получаешь что есть на остатках и не продавалось. Опять повторюсь - на малых периодах будет нормально.

кому что, а кому-то лишь бы попиариться )

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

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

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

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

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

все нормально, пиар по адресу, я как раз директор магаза и типовая уже давно сидит у меня в печенках :)

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

но с текущими остатками и состоянием.

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

поставь условие: документ-регистратор не равняется перемещение со склада и фсе

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

а как это сделать? ты скажи мил человек

еще по ордерной схеме убрать регистраторы (могут быть). и еще не забыть что могут быть остатки оптовые, розничные, НТТ.

магазы обычно торгуют, а не ПО выпускают

вы торгуете, мы выпускаем, так сказать инвестиции :)

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

вроде работает: ВЫБРАТЬ    ТоварыНаСкладахОстаткиИОбороты.Номенклатура,    ТоварыНаСкладахОстаткиИОбороты.КоличествоКонечныйОстаток ГДЕ    Продажи.Период МЕЖДУ &ДатаНач И &ДатаКон    И Продажи.Номенклатура В ИЕРАРХИИ(&Номенклатура)    И Продажи.Количество = 0

не так

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

ВЫБРАТЬ ИЗ (ВЫБРАТЬ    ТоварыНаСкладахОстаткиИОбороты.Номенклатура,    ТоварыНаСкладахОстаткиИОбороты.КоличествоНачальныйОстаток,    Продажи.Номенклатура,    0,    0,    Продажи.Количество ИЗ

спасибо, да у меня действительно неправильно было вот мне тут еще товарищ написал такой вариант:    ТоварыНаСкладахОстаткиИОбороты.Номенклатура КАК Номенклатура,    ТоварыНаСкладахОстаткиИОбороты.КоличествоНачальныйОстаток, ПОМЕСТИТЬ ТоварыКоторыеБылиНаОстаткеНаНачалоИКонецПериода    ПродажиОбороты.КоличествоОборот ИЗ    ТоварыКоторыеБылиНаОстаткеНаНачалоИКонецПериода КАК ТоварыКоторыеБылиНаОстаткеНаНачалоИКонецПериода        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Продажи.Обороты(                &НачПериода,                &КонПериода,                ,                    ИЗ ГДЕ    ПродажиОбороты.КоличествоОборот ЕСТЬ NULL УПОРЯДОЧИТЬ ПО    Номенклатура АВТОУПОРЯДОЧИВАНИЕ

Ну тогда - успехов!

Вообще-то в теме вагон тонкостей. Фактически - это элемент анализа и планирования закупок. Все сводится к вопросам, что в каком объеме закупить и кого выпороть за закупку явного неликвида. Для полноценного определения неликвидов (точнее говоря - товаров, которыми склад перегружен) и планирования новых закупок выполнения  условий, перечисленных в данной ветке в общем случае мало: 1) так как для полноценной статистической оценки нужна репрезентативная выборка, то период должен быть заметно выше цикла оборачиваемости запаса 2) поэтому считать надо остатки "по дням". В дни, когда не было товара он продаться не мог, а остатков могло не быть в середине периода в течении целого дня 3) для продавцов, использующих резервирование - считать надо не по фактическому остатку, а по свободному: зарезервированный товар продать не могли 4) если товар продается обычно не по 1 шт., то надо фильтровать не "0" остатки, а меньше "минимального количества покупки" 5) если товар заканчивался в какой-то день периода  (или приходил при "0" остатке), но в этот день продажи были - надо анализировать отклонение продаж от средней цифры, когда товара было достаточно и при падении ниже установленного порога достоверности - не учитывать этот день при расчете "среднедневной" продажи 6) многим еще надо учитывать коэффициенты "празднично-выходных-тематических" дней 7) для продавцов, которые продают и филзицам, и юрлицам, в т.ч. под заказ - может потребоваться фильтрация "случайных крупных" продаж (типа позвонил представитель объединения всех совхозов региона и заказал лопаты в объеме, который год в обычном режиме продаваться будут) - настройка порогов достоверности продажи 8) если речь идет о планировании закупок - то еще может требоваться динамическая корректировка порога достоверности и минимального складского запаса от маржинального дохода (товар с маржой 500% можно и подержать на складе, а лишний товар с маржой 5% нафиг там не нужен) 9) и еще некоторое количество факторов, влияющие на планирование запасов (сроки годности, отсрочка платежа, доля допрасходов на приобретение, минимальная транспортная партия, право возврата...) :) p.s. Видел ли кто-нибудь решение, учитывающее все вышеперечисленное? :)

мое учитывает 80 процентов заявленных пунктов.

1) - есть, причем период произвольный. При этом данные остатков текущие 2) - есть. 3) - есть. текущее состояние оценивается по свободным остаткам (минус - не участвует в расчете по дням когда товар был на остатках - можно предположить что под "ноль" было исключительно мало товаров) 4) - нет. товар может быть штучным. тут наверно специфика. 5) кажется это было по пункту 2. ксли товар в один день приходил и уходил - транзитные накладные. этот товар учитывать не стоит. опираемся только на остаток 6) есть. работает полностью по производственному календарю - соединением. 7) вот этого нет. как голову не ломали но вычислить данное крайне тежело. Поэтому в разработке есть еще два доп окна анализа. диаграмма скачков и числовые показатели. практически помогает в одной разработке получить развернутую картину. 8) есть работа по точкам заказа. определение оптимального складского запаса. Отборы помогают отобрать все что требуется - товары, группы и т.п. тем более в типовой есть сного всякой аналитики - ценовые группы и т.п. все это может учавствовать в отборах. 9) пока такого нет. но нет предела совершенству. 10) зато вместо 9 есть очень много другого.

в имелось в виду, что товара не было и на начало и на конец дня (практически - весь день), эти однозначно фильтровать; в - если товар, к примеру был на начальном остатке, но закончился или был зарезервирован - то все зависит от того, насколько близки показатели к среднедневному расходу, т.к. если фильтровать и эти дни, то при коротком цикле снабжения и политике минимального складского запаса выборка будет сильно фильтроваться в имелось в виду несколько другое: при планировании закупки цветов 9 марта - оценивать 7е и 8е число равнозначно с предыдущими нельзя; а во многих магазинах объем продаж в выходные дни выше обычных. И т.п. делал много лет назад, указывался порог фильтрации и размер допустимого отклонения. При выходе за него продажа "выпадала" из оценки дневной продажи и ярко-ярко выделялась в отчете. в имелся в виду не отбор, а задание плавающего процента товарного запаса: примерно по схеме: планируем на неделю, определяем для товара с маржой до х1% страховой запас на день, с маржой до х2% на 3 дня, с маржой свыше х2% на 6 дней. >> но нет предела совершенству Вот и я об это же :)

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

Если хочешь сделать все по-настоящему, посмотри где-нибудь методику расчета MAD(средний спрос) для номенклатуры, у разных компаний она разная. Учитывается спрос на каждую номенклатурную единицу, номенклатуру бывшую в наличии при обращении покупателя, номенклатуру, которой не было в наличии, но заказанную покупателем; а также упущенный спрос. Получаешь значение MAD, уже танцуя от него, определяешь группу ликвидности, у меня например абсолютный неликвид - MAD=0 в течение 2 лет(группа ликвидности E).

Точно также как нельзя сделать точный заказ. ВОт конкретный пример. у нас закупкой занимаетя непосредственно генеральный. я ему полтора года назад сделал разработку. Ему нужен был простой алгоритм: тупо продажи за три месяца, делим на три. сравниваем с остатком и типа это месячный запас. он делает заказ. Тоже всякие расчеты. Но тем не менее никто не мешает раз в неделю делать просмотр и например быстро продающийся товар еще дозаказывать. В планировании самое важное еще строгие инструкции и периоды заказов, периоды планирования. а также контрольные проверки выполнения в подпериодах. Чего то меньше закупят не страшно, докупить всегда можно. Ну чуток переберут ничо страшного. Но работать вслепую вообще без инструментов - нереально. Ошибки как раз в этом. А какие алгоритмы не пиши мегасупер, все равно машина не даст. Поэтому я отталкиваюсь от мысли: "Любое планирование это попытка увидеть будущее, и в любом случае только "чутье" может это будущее решить. Но как минимум иметь инструмент автоматизирующий работу нужен всегда. Держать все в голове в этом процессе просто невозможно. "

Опять же смотрим что получается на примере управления закупками на нашей фирме. Внимателно вдумайтесь. Директор выбрал простую стратегию казалось бы с кучей погрешностей. тупо три месяца, тупо делим. получается месячный план продаж. Он планированием получет данные по плану продаж и текущим остаткам. Разница закупкам. Но он не делает заказ раз в месяц. Каждую неделю. Прога делает рассчет в момент получения выборки. Еще раз месячный план и поддержка на уровне месячного запаса. Но получение отчета каждую неделю дает ему регуляцию. Программа по сути по анализу каждой прошедшей недели регулирует месячный запас и не дает заказывать то что в течении недели не оправдало одиданий, зато на быстро оборачиваемый товар который планировался на месяц но может за последнюю неделю расходовался быстрее - дает его пополнять с растущим недельным спросом в реальном времени. В итоге никогда не получается что товара не хватает, врдя ли за неделю исчерпают месячный запас, но при более растущем спросе делает пополнение месячного запаса.

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

Неликвиды. Любой руководитель своего предприятия вам ответит без отчетов что такое не ликвиды. все они прекрасно без отчетов знают что это такое. Это в первую очередь брак, не комплекция, дефекты, просроченный товар и т.д. и т.п. И второе - перезаказ товара на слишком большой срок - тоесть избыточное хранение и занимание площадей (очень ценных для оборачиваемого товара). Второе - это ошибки в первую очередь планирования и закупок которые ведутся вручную. Тоесть перезаказ по ошибке, которые допускают и топы в том числе. Происходит это очень часто когда пытаются использовать недостаточно информативные или содержащие мало объемную информацию отчеты. Да еще когда вручную надо забивать. Так вот чтобы такого не происходило и нужно создавать инструменты работы.

Знает владелец ларька.