[УТ10] SubSys: Помощник закупок (анализ продаж, анализ склада, анализ поставщиков и цен) Планирование закупок и формирование заказов 1С УТ 10-11, КА, УПП, 1СРозница
![[УТ10] SubSys: Помощник закупок (анализ продаж, анализ склада, анализ поставщиков и цен) Планирование закупок и формирование заказов 1С УТ 10-11, КА, УПП, 1СРозница](/upload/iblock/082/pie-chart.png)
Обработка формирования потребностей в товарах на основе интерактивных полных товарных данных, формирование заказов поставщикам по потребностям по анализу и подбору поставщиков. Большое количество функция для работы снабженцев.
03.09.2009 14:29 [16.05.2012 14:05] 32 [+] [−] Перейти к публикации
(2) формирование внутреннего заказа. У нас розница делает заказ с оптовых складов.
В этом режиме необходимо делать отбор по подразделениям розницы (для фильтрации продаж и остатков). Для этого в настройке достаточно поставить курсор на нужное подразделение (или два раза щелкнуть, тогда отчет выкрутится автоматически).
В этом режиме анализируется подразделение. При нажатии кнопки авторасчет программа проанализирует остатки на оптовых складах и в колонку заказать поставит то что есть на остатке согластно тому что требуется.
Ответили: (6)
(4) это связано с (5). у нас розница делает в автоматическом режиме заявки на склад. Сеть магазинов в каждом несколько тысяч номенклатуры.
Заказывать со склада все вручную просто нереальный ужос. Поэтому была доработана функция автоопределения остатка и склада (в моей базе также еще была реализована приоритетность).
И потом программа автоматом на каждый склад формирует заявки одной кнопкой.
На самом деле там еще есть возможность и по характетистикам. У нас стройматериалы. На оптовых складах товар в фасовке (упаковках). В рознице может быть поштучно, и учет по характеристикам не ведется.
Так вот. Когда по магазинам происходит планирование, программа расчитывает что нужно заказать. По кнопке авторасчет программа не только еще определяет остаток и склад, но еще и ищет нужную фасовку под нужное количество.
Ответили: (9)
(3) рекомендуется заказать это то что программа расчитала. В колонку заказать можно вбить/изменить вручную. Разбито на две колонки чтобы визуально видеть отличия ручного ввода. Для автоматического заполнения колонки Заказать используется кнопка "Авторасчет". она также округляет.
Также у нас еще есть свое округление. Опять же товар фасованный. Но программа рекомендует точное количество по формуле. А заказываем мы кратно упаковкам (минимальной упаковке). Поэтому авторасчет также считает и это. А две колокни - чтобы различать отличия.
Ответили: (9)
В нашей конторе неоднократно предпринимались попытки адаптировать учетную информационну ситсему для нужд планирования продаж и закупок. Скажу сразу, используется НЕ 1С.
В итоге пошли другим путем. Все функции планирования вывели ЗА пределы учтеной ИС.
При этом поставленная задача была предельно проста: уйти от использования Excel, с его бесконечными ВПР-ами. Руководству надоело отбирать персонал по критерию "умеете ли Вы вэпээрить?".
Решение оказалось настолько удачным, что при переходе на 1С решили его переработать и использовать совместно с новой ИС. В общих чертах это связка MS Access + (некий) SQL Server. На стороне последнего выполняются все ресурсоемкие вычисления. А они действительно требовательны к ресурсам (тысячи наименований, понедельно, подраздения, производство, составы изделий). Там же реализовано хранилище данных для традиционного OLAP-анализа.
Хотя бы по причине требовательности к ресурсам лично у меня изначально возникают сомнения в обоснованности попыток решать задачи сугубо вычислительного характера средствами какой-либо учетной системы.
Все же 1C мало приспособлена для задач планирования, если речь не идет об элементарном пополнении склада по точке заказа, отчетах, графиках. Любой шаг в сторону - это новая обработка или отчет. Косвенным подтверждением служит создание 1С-никами подобного рода обработок и отчетов. Да, они в какой-то мере справляются с поставленными задачами. Но, увы, наследуют целый букет особенностей 1С, которая изначально предназначена НЕ для планирования продаж/закупок хотя бы на пол-года вперед. Да и, в любом случае, это отчеты. ИМХО. А где Вы будете просто хранить информацию о заключенных контрактах (обязательствах), запланированных акциях, намеченном обновлении ассортимента. Кто должен корректировать планы на основе статистики, наличия товара в продаже (дефицита), да еще в случае, если сезонность ярко выражена? Как выделять новинки, определять избыточное количество товара, который еще только в пути или не собран из комплектующих, которые еще в пути?
Ни чего не имею против самой 1С. Скорее всего переходить будетм именно на нее. Но не в части планирования.
В качестве краткой иллюстрации могу предложить простую картинку.
Кому тема близка, тот поймет 
(15) я последние леть пять занимался планированием на двух фирмах. Основные проблемы это квалификация закупщиков и умение сформулировать четкие критерии. Если есть данные и есть нормальное ТЗ то в 1С 8.1 можно сделать все что угодно, и по максимум автоматизировать работу.
То что в 1С нет нормального планирования, так а что вы хотите от типовых решений. Нормальные решения рождаются в процессе работы конкретных предприятий.
"Если есть данные и есть нормальное ТЗ то в 1С 8.1 можно сделать все что угодно, и по максимум автоматизировать работу."
А надо? Именно в 1С. Да, в нашей конторе уже нет квалифицированных закупщиков, во множественном числе. Они просто стали не нужны. А было человек пять.
Да, для закупщиков это плохо. А для бизнеса?
В ассортименте несколько товарных групп. Заказ по каждой готовится раз в месяц. Скорость - от 10 сек до 1 мин. на позицию. У местных поставщиков заказ формируется в автоматическом режиме. Зачем штат закупщиков, если на эту работу у одного человека, "набившего руку", уходит несколько часов в неделю?
Причем, если он уволится, с его работой легко справится его непосредственный руководитель или смежник. Все ясно и прозрачно.
1С - это наверно лучшая в нашей стране учетная система. Она надлежащим образом поддерживается, обновляется. Это целая индустрия, много разработок и разработчиков.
Но мы говорим об очень специфичной и крайне ответственной (финансово) области, которая заслуживает специализированного решения. Безусловно, не во всех организациях. Кому-то вполне достаточно пополнения склада по точке заказа. Мы работает с крупнейшими розничными сетями. Каждая ошибка в планировании стоит очень дорого. Цикл поставки - 3-5 мес. Клиент ни каких обязательств/рисков по ассортименту или количествам не несет. Решение в пользу одного клиента чревато полным разрывом с другим. За недопоставку очень серьезный штраф. Прогнозировать продажи новинок очень сложно (предметы интерьера, где важены эстетические предпочтения потребителя). Одно продается, другое нет. Легко оказаться с набитыми складами, без денег и при долгах.
Планирование потребности НАШИХ КЛИЕНТОВ в товаре - это наша компетенция. Мы делаем это лучше, чем они сами или наши конкуренты. Поэтому работают именно с нами.
Мне важно Ваше мнение, как специалиста в 1С. Действительно интересно, как Вы сами очениваете потенциальные возможности 1С в означенной области.
Ответили: (20)
Решение по сабжу автоматизировало работу нескольких конкретных предприятий где все условия просты до удивления. И это правильно.
Другое решение автоматизировало работу другого предприятия которое тоже искало решения долгий период.
Другие решения решают задачи других предприятий. И без разницы 1С или не 1С.
Каждый вправе выбирать сам то, что ему подходит.
Ну, к примеру, возможно ли в 1С вот это?
Имеется в виду величина складского запаса на перспективу несколько месяцев (серая кривая), рассчитанная на основе:
- текущих запасов;
- планов отгрузки, заданных помесячно, в разрезе по клиентским группам;
- размещенных заказов поставщикам (синие столбцы);
- чистой потребности в товаре (исходя из условия условия расхода складского запаса только во время наличия товара на складе).
Фактически, речь о простейшем моделировании запасов и потребности в очередном пополнении склада путем элементарной реализации алогоритма MRP.
При этом на основе чистой потребности в товаре происходит рассчет потребности в новых поставках готовых изделий. Так формируется рекомендуемый заказ, с учетом длительности и периодичности поставки, минимального заказа, страхового запаса, кратности упаковки и проч.
А поскольку мы еще имеем дело и с полноценным производством, на следующем этапе, аналогичным образом моделируется расход и требуемое пополнение склада комплектующих.
Система упрощенная, всего двухуровневая (в общем случае MRP предусматривает в изделиях промежуточные узлы неограниченной вложенности). Но нам достаточно дух уровней (изделия, комплектующие нижнего уровня).
Когда Вы готовите заказ на закупку, помимо рассчитанного системой рекомендуемого значения, просто смотрите на приведенный график и уже экспертно оцениваете потребность в товаре. Тут же в форме можете посмотреть, кто когда и сколько продавал и планирует продавать каждый товар. Так Вы более точно оцениваете риски.
По опыту столкнулся с тем, что многие коммерсанты, предприниматели (не путать с закупщиками), не доверяют разным там скрытым в системе формулам. Они хотят иметь возможность воочию, визуально оценить ситуацию и принять решение, основанное на собственном понимании ситуации.
Вот об этом и речь...
А эта разработка расчитана на те фирмы где сроки процессирования товара очень небольшие. Тоесть товар 2-3 дня с момента заказа.
Обычно такие фирмы делают план на ровно на месяц в начале каждого месяца. Очень многие оперируют продажами за последние три месяца, получают план продаж на месяц и это заказывают.
Разработка "Планирование закупок v.2 для УТ/УПП" расчитаная как раз для таких компаний где все просто. Нужно получить все данные и сделать заказ.
У нас например 18000 номенклатуры. каждый месяц колбасить это нереально.
А разработка позволяет автоматом всё сделать. И потом если нужно корректировать.
Мне кажется, в подобного рода решениях должна быть некая общая идеология, платформонезависимая. Более того, она не нова и давно релизована в западных системах. Есть же разные MRP-MRPII решения. 1С себя позиционирует сразу на уровне ERP. Но последнее, без полноценной реализации MRP - скорее нонсенс.
А тот же SAP не доступен тем, кто ориентирован на 1С. А 1С изначально не нацелен на решение задач планирования. Вот народ и "вэпээрит" в экселе. А более продвинутые заказывают обработки.
Лично я оцениваю ситуацию именно так. Будь оно иначе, 1С давно сами предложили бы готовое решение.
"почитал. Посмотрите .
Эта разработка делает то, о чем вы говорите."
Заинтересовала предложенная Вами "таблица состояний". А можно ее отобразить в виде графика?
У нас в таблице, где выполняется основной рассчет, порядка 300 тыс. строк.
Как Вы оцениваете время обработки такого количества средствами 1С? Думаю, алогоритм близок к тому, который используете Вы. Только реализуется в таблицах SQL-Server.
Специфики как таковой я как раз не вижу, если не считать таковой наши повышенные требования к собственно планированию.
Вы, наверно, действительно правы в том, что Ваше решение отлично подходит для торговых организаций с коротким циклом поставки. Меня лишь удивляет, что 1С не предложили готового. У них же как-то реализовано по точке заказа. Чем не устраивает?
(30) запросто можно. Если в 1С есть какая то таблица то её можно в любую диаграмму сделать. Это обычная примитивная возможность в 1С. кокнертно в этой разработки я диаграмму не делал, но сделать проще простого.
В той компании где применяется это планирование расчет по 80000 номенклатуры выполняется несколько секунд.
(30) у них есть готовое. Причем в УТ даже два различных варианта.
Один на основе расчета от планов продаж, второй от точек заказа и установленных минимальных количеств (тоесть если конкретно описана шахматка склада). Оба решения работают. НО!! самое главное что я там не нашел там нету визуального отображения. Тоесть она все делает, но визуально эжто вообще не видно. И второй огромный минус, там надо кучу ручных действий выполнять. Даже в тех же планах номенклатуру надо руками вбивать которую хотим заказывать. А нафиг оно такое кому надо.
Людям нужно чтобы все была автоматизировано, наглядно и правильно.
"База для планирования отдельная. В неё выгружаются нужные данные из семерки. Соответственно база содержит только нужные данные. Высокая скорость была достигнута как раз этим способом."
Опять же SQL-Server или Access? Я правильно понял, что из 1С Вам нужной производитеельности вычислений вытянуть не удалось?
Тем более, что структура исходных таблиц там не располагает к сотрудничеству
Сама семерка на скл сервере. база порядка 12 гигабайт.
Программа на восьмерке в файловом варианте отрабатывает 80000 номенклатуры по данным за несколько лет (хотя они берут год).
В клиент-серверный вариант потребности не возникло.
Не стоит забывать что главное для чего нужны мощные ресурсы в 1С это не чтение в большинстве случаев запись документов, которые используют расчеты и транзакции.
(39) занимается работой в экселе. Из за недостатка инструментов в системе, начинают придумывать другие способы. Выкручивать десять отчетов в 1С, сохранять в экселе, потом объединять отчеты, писать формулы, чтобы сделать заказы. и все это ВРУЧНУЮ.
скорость обработки таким методом желает лучше, а точность вообще под большим вопросом. где то ошибется - крантык.. Такие результаты не проверить да и достоверность желает лучшего.
Ответили: (41)
Новость. В ближайшее время планируется сделать значительную доработку отчета под типовую схему по Установке точки заказа.
С помощью обработки можно будет автоматически устанавливать точки заказа, видеть оптимальные запасы.
Доработка возникла в связи с проблемой типовой. В документе Установка точки заказа нет способов заполнения номенклатуры (все делается полностью вручную). Обработка поможет автоматизировать этот процесс.
Ответили: (46)
Вполне возможно будет сделан функционал и под типовую схему планирования. Тоесть обработка будет позволять автоматически вводить документы планов продаж для фиксации показателей и в дальнейшем план-фактному анализу.
Все перечисленные обновления увеличат стоимость разработки как я уже сообщил в (43) пункте.
А как Вы намерены на основе плана продаж формировать заказ на закупку по точке заказа? Она ведь на то и точка заказа, что учитывает только наличие товара на складе и в пути.
Либо планы будут лишь для статистики и мотивации персонала? Тогда не факт, что за ними будут хоть как-то следить. Ведь они формируются по каждой позиции ассортимента.
В нашей организиции товар закупается на основании планов. Но и то полагаться на 100% на планы, предоставленные отделом продаж, нельзя. Если бы не автоматизированная корректировка планов самой системой, достоверность их была не высока...
Ну а ради мотивации персонала формировать планы ПОПОЗИЦИОННО, да еще в разрезе по подразделениями - вообще перебор. Для этой задачи достаточно планов, заданных по товарным группам и в деньгах, а не штуках.
Первое, с чем столкнется плановик - это двукратно завышенные "сэйлзами" количества. Вы сами наверняка не раз замечали, что любой сейлз-менеджер готов биться до последнего, чтобы убедить, что может продать в два раза больше, не будь дефицита по (обычно по нескольким позициям). И когда ему дают поставить план по каждой позиции - он просто удваивает количество по каждой. Когда это умножаешь на цену - становишься горд за будущее бизнеса, равно как и за тех, в чьи руки его доверили
Мы прошли через это. В результате планы на 80% формирует программа, по статистике. Остальные 20% - это новинки, акции и прочи ситуации, когда (пока) статистика не работает.
Так что подумайте хорошо, прежде чем предлагать своим клиентам столь изощренный метод. Это добрый мой Вам совет
(47) вообще план продаж обработкой сам генерируется. как раз то что вы сказали "В результате планы на 80% формирует программа, по статистике."
В демо есть колонка План продаж который сам автоматически по позиционно расчитывается по анализу прошлых подпериодов.
Сейчас я просто добавлю кнопку которая будет из обработки создавать документ план продаж. Никаких расчетов вручную никто не ставит.
Точка заказа сейчас добавлена для информации.
Так как в типовой в документ Точки заказов надо каждую позицию вбивать вручную (плюс заполнение каждой строчки) в моей обработке орна реализована колонкой. Пользователю достаточно внести данные по строкам наждать одну кнопку и программа откроет заполненный документ Точки заказа. который можно провести. дальше эти значения выпадут в обработку. Их можно менять и т.д. видя статистику и данные. (вполне мвозможно будет добавлен автоматический расчет и динамика изменения точки заказа).
По поподу планов продаж, в обработке колонка План продаж, расчитывается автоматически по статистке. То что я описал по планам, это просто запись этих данных в базу.
(47) тут просто фишка в том что в типовой для получения данных по статистике нужно:
1) запускать помощник планирования, выбирать там всякую чепушню типа сценариев, настроек и прочего (пусть даже если настроенную).
И там нет возможности подбора номенклатуры, вот поэтому вы и пользуетесь номенлатурными группами (а для такого учета еще нужно и номенлатуру правильно держать по группам и вес вхождения вбивать). Короче типовой планирование настолько замудрено и запутано. Неправильно указали что то все пипец.
2) согласно настройкам выбрать группы (или руками набить номенклатуру). Нажать формирование. После чего программа без всякого вывода на экран расчетов (по кторым считает) создаст документы Планы продаж.
3) Дальше вам на основе этих планов продаж надо сделать планы закупок.
4) На основе планов закупок сделать заказы поставщикам.
Короче говоря надо столько всего сделать, и на каждом этапе есть свои ограничения, да и не показыыает она то что считает (а вдруг надо что то скоректировать по статистике).
Короче говоря такой геммор....
Что делаем обработка у меня:
Ставите обор, указываете период, количество периодов заказа. Всё!.
Результат: вывод интерактивно статистики (пономенклатурно), динамики, расчет плана продаж, ликвидность, расчет заказа. Возможность корректировки.
А дальше одной кнопкой делаете нужный документ из списка.
Опять же типовой механизм интерактивно ничего не выводит. На выходе он показывает голый план продаж, и черт его знает что он туда насчитал.
Пользователи что? должны сидеть отчеты крутить чтобы быть уверенными что такой документ стоит не глядя проводить.
Или потом отчеты крутить пять штук чтобы понять что план нормальный.
У меня главная задача была - минимум действий, максимум функций, максимум всех необходимых данных в одной форме.
Все же я так и не понял, для чего Вы формируете и как используете попозиционные планы продаж. Я все о том, что с моделью по точке заказа планы, заданные по периодам (на несколько моесяцев вперед) не дружат.
Или речь не о плане, как конкретной потребности для каждого из предстоящих плановых периодов, а о некой нормативной потребности, среднестатистическом спросе, величина которого используется для коррекции точки заказа?
Ответили: (53)
(52) план продаж в обработке расчитывается по статистике. это автоматическая величина. Она не берется из базы и не вводится вручную.
Расчет плана продаж, это среднестатические продажи за прошлывй период (умноженные на количество периодов заказа).
На основае этой колонки расчитывается закупка: план продаж - (остатки+сущ. заказы - резервы) . Выводистя колонка заказать.
Вот для этого и формирую. чтобы сделать закупку.
"Расчет плана продаж, это среднестатические продажи за прошлывй период".
Не совсем корретно называть эту величину планом продаж. Это нормативная потребность, среднее значение для периода, выбранного в качестве базы для усреднения (месяц?). Так можно запутать людей.
С некоторой натяжкой можно назвать это плановой потребностью, но не планом прдаж, т.к. любой план хоть какое-то хронологическое измерение, а не просто количественную оценку.
Точка заказа конкретно понадобилась, для реализации установки требуемого постоянного количества по конретным складам.
Сейчас она пока несет информативную функцию о том сколько этого товара должно быть и сколько есть на данный момент (по колонке остаток).
Каждый может придумать сам как это использовать.
У моего заказчика сейчас задача пополнять склад постоянно по точке заказа с других складов (тоесть без заказа поставщику).
Есть очень большой склад и несколько мелких на которых постоянно должен быть определенный товар в заданном количестве.
Вот я сида и решил приделать типовой механизм точек заказа.
(55) вы вообще демо смотрели? может быть тогда сразу бы снялось половина ваших вопросов. Выкрутите у себя, посмотрите расчеты колонок, периодичности. Тогда будем говорить что верно а что нет.
По мне так типовой механизм планирования продаж и закупок очень далек от реальности. аргументы я привел.
С Ваших слов я понял, что рассчитывает именно норматив (среденстатистическую потребность), а не план продаж (индивидуально заданные для каждого планового периода количества, которые можно изменять)
К стати, как будет отличаться у Вас план на Октябрь от ноябрьского или декабрьского, количественно, разумеется?
Ответили: (63)
(62) в обработке нету функционала сезонности. Эта задача не стояла.
Тут уже было сказано что обработка в основном расчитана на предприятия с маленьким сроком процессирования товара. Тоесть неделя-две максимум.
Доработку под сезонность могу сделать если будут заказы. пока таковых заказов не было.
Обновление 21-09-09: Добавлена опция "Расчитывать точку заказа от объема продаж". Позволяет расчитывать точку заказа на основании объема продаж за указанный период по выбранному подраздению. Если опция не стоит в отчет выходится хранящееся значение. Например, можно на выбранное подразделение автоматически расчитать точку заказа исходя из объема продаж за 10 дней.
Добавьте пожалуйста аналитику по оборочаемости товаром по отгрузке и по оплате. Очень нужно.
Не совсем понятно что такое скорость продажи
Интересные Вы вещи делаете! Одну из Ваших работ уже заказал. Скажите, Вы писали, что занимаетесь с розничной сетью стройматериалов. А вот обои в ассортименте есть? Есть ли какие-нибудь наработки по учету такого товара? Мне важно знать реализуется ли у вас учет по партиям (колористикам) в цепочке "заказ-хранение-реализация"?
Ответили: (71)
(69) это очень и очень странно. даже невероятно) что у вас за программа?))
(70) у нас партионный учет в полно красе по характеристикам.
""заказ-хранение-реализация" - имеется ввиду разница между выписокй заказа и отгрузкой (количество дней нахождения резерва). Вы имеете ввиду учет продаж не по отгрузке, а когда был выписан заказ (реальная продажа) ? Так? В мебели такой учет вел (товар мог месяц лежать на складе, продажа считалась не в момент отгрузки а в момент заказа с оплатой).
На сегодняшний момент мы ведем учет по-артикульно без характеристик. Однако, товар (обои) каждый раз приходит разных колористик (партий). Это такая производственная особенность. И производитель маркирует это цветовое расхождение своим индивидуальным кодом. У каждой фабрики свой индивидуальным номеров, свой формат, буквы, цифры.... У нас Розница, штрих-кодирование по артикулам. И когда на складе одного артикула несколько колористик продажа может не состоятся - разнотонка, хотя один артикул. Из-за этого много сложностей: по остаткам товара достаточно, но разнотонка большая и продажи срываются, дозаказ поставщику приводит к увеличению разнотонки по каждому артикулу, сложность учета разнотонки - он без штрихкода. Нужна Ваша консультация по возможному учету разнотонки и системы планирования запасов и анализа торговли в данных условиях. Мой е-майл: yarilchenko@mail.ru
Ответили: (73)
Ну, на сколько я понимаю характеристики можно использовать, если есть параметры постоянные (размер, цвет и т.д.). А разнотонка - это как серийные номера у сотовых телефонов они всегда разные у каждой новой партии. Этот параметр не указывают в накладных от поставщика, этот параметр у каждой фабрики свой ("34758-5678", "АНК-56-40", "парт.2"....). Не заводить же каждый приход как позиция с новой характеристикой. Дальше партию продали и все, больше такой не будет. Это реально реализовать с помощью характеристик?
Ответили: (75)
Обновление 27-11-09: Точки заказа.
Реализована работа с точками заказа (минимальный складской остаток). В форме есть колонка "Значение точки заказа" (можно использовать под минимальный остаток). На начальном этапе для выборочных позиций можно указать какое количество товара должно быть на остатке.
В меню есть команда Создать документ Установка точки заказа. При нажатии вводится документ с установленными точками по указанной номенклатуре. После проведения, данные сохраняются в базе.
В дальнейшем в отчет выводятся точки заказа по установленным позициям.
Изменения в расчете: по позициям которые опираются от точки заказа расчет "рекомендуется заказать" происходит не от продаж, а от сравнения точки заказа с существующим остатком.
Изменения в интерфейсе: позиции, которые были расчитаны от точки выделяются одним цветом, которые от продаж - другим цветом.
В общую форму добавлена закладка с журналом документов "Установки точек заказа".
Обновление 16-12-09:
- Добавлены расшифровки. В панель команд добавлено подменю "Отчеты". Пока 4 отчета: продажи, ведомость по остаткам, анализ доступности товаров на складах, ведомость по заказам поставщикам.
При нажатии любого отчета выкручивается соответствующий отчет по текущей номенклатуре.
- Добавлен новый реквизит "Поставщик". Служит для анализа номенклатуры и формированию заказа по конкретному поставщику. Номенклатура отбирается по условию: программа выводит всю номенклатуру которая когда либо приходила от указанного контрагента по приходным накладным.
Ответили: (87)
Обновление 12-01-10:
- НОВОЕ: два режима автоматического расчета рекомендуемого заказа: 1) от среднестатических продаж периодов, 2) от средних продаж за дни, когда товар был на остатке.
Изменения в интерфейсе. для управления видом расчета добавлены два флажка переключения.
Для второго режима добавлено диалоговое окно ввода количества дней для заказа.
Внимание! оба режима влияют на расчет колонки План продаж (средние продажи умноженное на количество периодов или дней заказа). И уже после расчета плана продаж вычисляется объем закупки, исходя из того какое количество товара есть на остатках.
Обновление 12-01-10:
-НОВОЕ: добавлено поле "Дата остатков", период переименован в "Период продаж". Внимание. Теперь отчет может работать по разным данным. Например: период анализа продаж можно выбирать произвольный (например первый квартал прошлого года), а остатки (с помощью даты остатков) текущие. Таким образом мы получаем анализ продаж за прошлый период, а всё текущее состояние (остатков, резервов, существующих заказов) на текущую дату.
Раньше в отчете был только выбор периода и текущие остатки выводились на дату конца указанного периода.
Обновление 19-01-10:
Установка точек заказа. переделана опция "Устанавливать точку заказа от объема продаж" на "Установка точки заказа от плана продаж".
Разница заключается в том что ранее точка заказа устанавливалась от всего количества продаж, полученного в результате формирования отчета.
Сейчас устанавливается от плана продаж.
Разница заключается в том, что во втором варианте план продаж является анализируемым показателем в результате большого периода выкрутитки отчета, в отличие от первого варианта, который просто устанавливал все продажи как точку заказа.
Разработана спецверсия для конфигурации 1С Розница.
Упрощенная версия специализированная для розницы.
- Содержит весь основной функционал (анализ продаж, остатков, ликвидности, среднестатических продаж, количество дней когда товар был на остатках, авторасчет заказа).
- Создание внутренних заказов.
Обновление 26-01-10:
Новая опция "Порог нормальной ликвидности" и новая колонка "Возврат".
Порог нормальной ликвидности - показатель, при котором товар считается в большом излишке. При получении отчета и установке порога, в колонку "Возврат" помещается количество неликвидного товара (порог ликвидности меньше данных ликвидности отчета по каждому товару) из расчета остатков за минусом нормы плана продаж.
Таким образом в отчете интерактивно очень хорошо видно эти позиции.
Новый вид операции: Возврат поставщику. Согласно данным таблицы по колонке "Возврат" создается документ Возврат поставщику с заполненной номенклатурой и количеством.
Колонка "Возврат" редактируемая. Оператор может с помощью обработки делать анализ для возврата любых позиций поставщику.
Обновление 26-01-10:
Опция "Пересчитыват в единицы отчетов", опция полностью пересчитывает все данные в таблице согластно единицам и коэффициентам единиц отчетов карточек товаров.
Например: в единицах отчетов иногда фиксируются единицы и коэффициенты по которым делается заказ поставщику.
Основной учет компании ведется в единицах хранения остатков, но может быть ситуация когда в единицы отчетов заводят единицы под которыми делается заказ (например упаковки).
(96) как показывает практика, а конкретно те заказчики которые приобрели программу и те кто потенциально хочет приобрести нуждаются во всех функциях и даже больше. Практически большинство обновлений связано с заказами на доработку. И все просят и просят больше. А те кто получил обновления которые были сделаны другим - еще больше довольны.
===
По схеме заказов поставщикам от заказов покупателей - зачем искать? в типовой как раз этот процесс прекрасно реализован. ...Кстати. надо будет включить свободные заказы и в эту разработку.
Обновление 09-02-10:
Усовершенствован расчет дней продажи товара (когда товар был на остатках).
Механизм полностью переделан и теперь соответствует регламентному календарю. В расчет не берется выходные и праздничные дни. Календарь настраивается в программе (Сервис - Настройки учета - Регламентный производственный календарь)
Обновление 28-01-10:
Добавление. В случае если ликвидность = 0 (тоесть не было вообще продаж) опция порог ликвидности не помещает на возврат товар который есть на остатке и не было вообще продаж. Установлено условие по которому данный товар также попадает в колонку возврат.
32 [+] [−] Перейти к публикации
Маленькое замечание: при отборе Объект анализа лучше заменить на Номенклатура