Posted: 21 Sep 2005 09:58 Post subject: Вопросы по модулю "Планирование закупок"
Вопросы по модулю "Планирование закупок".
(версия 12.01 без sp)
1. Пункт меню №1 называется "Картотека партнеров", входя в него видим: "Картотека поставщиков". Это нелогично. Названия должны быть одинаковыми.
2. В "Картотеке поставщиков" в режиме ввода товаров поставщика (Alt+t):
2.1. Что означает буква "Н" в конце строки?
2.2. ****
2.3. Поле, в которое записывается ном. номер, называется "Артикул". Умножение сущностей, имхо.
2.4. При вводе новой записи в диалоговом окне отображаются данные текущей записи. Считаю, лучше было бы очищать поля.
2.5. Нет контроля уникальности записей. Запросто можно ввести идентичные записи, либо записи с одинаковыми артикулами (ном.номерами) и разными показателями.
2.6. В диалоге ввода нового товара после выбора товара не подставляется наименование товара в поле "Наименование по каталогу" (только если не очищать его вручную), а было бы удобно.
2.7. В таблице vnd_item.dbf непонятно назначение поля "Name" C10.
2.8. Ввод ном. номера в поле "Артикул" включает в товары поставщика закрытые карточки.
2.9. Тормоза при входе в справочник запасов и при перемещении по нему (в mlabel 14500 строк).
3. Режим "Учет товаров…", номенклатурный справочник, режим "Закупки" (Alt+h):
3.1. В поле "Поставщик" отображается только код партнера из Справочника партнеров, а неплохо было бы видеть краткое наименование (вместе с кодом или вместо него)
4. Формирование отчетов:
4.1. Отчет "Ведомость заявок на товары" формируется некорректно. При выборе сортировки "По кодам поставщика" коды поставщиков указываются верно, наименования – неверно. При выборе сортировки "По наименованию поставщиков" заявки неверно группируются, неверно выводятся наименования и коды поставщиков. Такая ситуация при выводе в ДОС, excel, word.
4.2. Отчет "Ведомость заказов на товары" – та же ситуация.
4.3. Отчет "Ведомость заказов на товары" – складывает количество по сводному заказу с его заказами-этапами.
4.4. В отчет "Ведомость заявок на товары" не попадают заявки и строки из заявок, подтвержденные квотами.
5. Формирование заявки поставщикам.
5.1. Импорт строк из заявок покупателей открывает не только заявки покупателей , но и заказы и закрытые заказы.
5.2. Ситуация: сформирована заявка покупателя на 100 ед. товара, на складе имеется 50 ед. Импорт этой заявки в заявку поставщику дает заявку на все 100 ед. Неплохо бы как-то отслеживать остатки для такой ситуации.
5.3. Неплохо бы различать цветом строки заявки с различным статусом.
5.4. Я не понял, каким образом сводный заказ "выполняет функцию контроля исполнения сделки" (цитата из инструкции_комментарии.chm). Это реализовано?
6. Квоты поставщиков:
6.1. При импорте строк в квоту из заявки поставщику программа не дает возможности корректировать количество.
7. При автоматическом планировании протокол пишется в plan\ message.dbf без очистки – неконтролируемый рост файла.
8. Контроль заказа в Заказах покупки. При привязке более чем одной приходной накладной к одному заказу в окне контроля заказа в поле "в заказе" у всех строк кроме первой стоит нулевое количество, соответственно и отклонения некорректные. Следовало бы считать нарастающим итогом (остатком).
9. Планирование покупок.
9.1. Страховой запас не отражается на результатах планирования. Моделирование спокойно снижает остатки до нуля.
9.2. При некоторых сочетаниях точки запаса, страхового запаса, объема заказа и периода планирования товар не включается в планирование, в протоколе об этом не упоминается. Например, если страховой запас меньше точки заказа или близок к ней. (в демке: кофеварка Unit при точке заказа (остальное – по дефолту) >=117 планирование есть, при <=116 – нет.)
9.3. В алгоритме моделирования есть что-то мне непонятное. В демке для кофеварки Unit ставлю:
9.3.1. Мин. партия = 100
9.3.2. Макс. партия = 9999999
9.3.3. Время доставки = 15
9.3.4. Точка заказа = 501
9.3.5. Объем заказа = 200
9.3.6. Макс. запас = 90000
9.3.7. Страх. запас = 100
9.3.8. Текущий остаток = 601 шт. Остальное по дефолту. Делаю планирование. Моделирование опускает 601 единицу остатка до нуля к первому приходу на 200 шт., а потом тем же темпом снижает уже 200 ед. остатка. Имеем половину времени пустой склад.
Joined: 20 Sep 2002 Posts: 32 Location: Яковлев С.В. Occupation: Компания БЭСТ, Отдел разработки
Posted: 21 Sep 2005 16:08 Post subject:
Добрый день!
Большое спасибо за подробный анализ модуля. Большинство Ваших замечаний принято и будет исправлено в ближайшем SP. В отношении примера планирования по остатку есть нюансы. Скорость продаж в системе определяется делением точки заказа на время доставки. Очень желательно, чтобы точка заказа была кратна времени доставки. Иначе получаются дробные величины, а округлять их до целого иногда можно, а иногда и нельзя (Может быть кно-нибудь предложит решение). Второй нюанс заключается в том, чтобы объем заказа превосходил точку заказа. Если объем меньше, то за время доставки программа "съедает" весь запас. В вашем примере так оно и есть. Точка заказа 501, а объем заказа всего 200.
2. Картотека поставщиков:
2.10. Проблемы с "синхронизацией" каталога товаров поставщика, параметров закупок в номенклатуре и планирования. При удалении товара из каталога поставщика не происходит обновления параметров закупок в номенклатуре, они остаются прежними. Планирование также не замечает отсутствия поставщика по данному товару, планирование выполняется, по спланированному документу формируются заявки (заказы). Предлагаю примерный вариант реакции программы на событие: Предложить пользователю выбрать поставщика (из других поставщиков данного товара или указать нового поставщика, если удаленный поставщик был единственным) и обновить параметры закупок или отложить выбор и тогда пометить в параметрах товар как не имеющий поставщика с обнулением полей, относящихся к условиям поставки, при планировании заказу присваивать статус "нет поставщика", выделять цветом и блокировать формирование заявки (заказа) по спланированному заказу до выбора поставщика (предоставить такую возможность в Планирование/Корректировка).
2.11. Валюта цен в каталоге. Выбранная валюта автоматом подставляется во все товары поставщика (атрибут в каталоге – read only) и в параметры товара. Теряется возможность вести товары у поставщика в разных валютах.
2.12. Вообще, следует разделить параметры товара на зависящие от поставщика: код по каталогу, название по каталогу поставщика, валюта, ед.измерения поставки, цена, мин. и мах. партия, время доставки, и зависящие от покупателя (т.е.,меня):точка заказа, объем заказа, макс. запас, страховой запас. И по этому делению разрешать редактирование первой группы только из каталога поставщика, а второй – только из параметров закупок в номенклатурном справочнике. Сейчас возможно независимое изменение параметров, что приводит к парадоксам.
2.13. В окне "Корректировка" параметров поставщика поле "Статус поставщика" излишнее. Присвоение ему значения false выкидывает поставщика из картотеки, что равнозначно простому удалению. А все, кто картотеке есть, имеют true.
2.14. В параметры товара следует ввести параметры доставки – самовывоз, бесплатная доставка и т.п.
2.15. Одного значения скидки на все товары поставщика явно недостаточно. Нужно предусмотреть принятые в деловой практике виды скидок: по объему поставки, по объему поставки за период. Возможно, следует привязывать скидки не только к поставщику, но и к отдельному товару.
9. Планирование.
9.3. Протокол. Добавить:
9.3.1. Печать
9.3.2. Фильтр
9.3.3. Поиск
9.3.4. Сохранение в файл
9.4. Терминологическое. В модуле фактически используются 4 наименования этапов планирования: заявка, квота, заказ и опять-таки заказ из автоматического планирования, который конвертируется в заказ (заявку). Предлагаю назвать (авто)заказ как-то иначе.
5. Формирование заявки поставщикам.
5.5. Импорт строк из заявок (заказов) покупателей. Механизм оставляет желать. Выводится перечень заявок с наименованиями покупателей и датами. Нельзя увидеть, что в этой заявке, нельзя как-то определить есть ли среди заказанных товаров те, что входят в каталог уже выбранного поставщика. Нет обратной связи. Нельзя отследить судьбу заявки, можно сделать по ней повторный заказ. Возможно, следует для заявки (заказа) покупателя ввести контроль прохождения заказа поставщику в виде статусов для строк документа и док-та в целом: нет заявки, есть заявка, есть квота, есть заказ, есть поступление на склад (это только по планированию закупок), и фактические условия поставки на конкретном этапе.
10. Маркетинг поставщиков (все здесь мое имхо о перспективах программы, реализовать это в sp3 я не прошу, а обсудить было бы интересно)
10.1. Существующая структура модуля позволяет вести маркетинг предложений поставщиков. Однако, для реализации этого необходимы доработки:
10.1.1. Каждая товарная позиция может иметь несколько поставщиков с собственными условиями поставки (цены, скидки, объем партии, время доставки и т.п.). Один из этих поставщиков решением менеджера признается основным. Это реализовано (хотя кое-что нужно бы уточнить)
10.1.2. Предлагаю исходить из разделения функций по логистике закупок. Примем за отдельную функцию маркетинг предложений: изучение рынка, сбор прайс-листов, уточнение условий и включение этих данных в базу данных по предложениям поставщиков. Для этого необходимо:
10.1.2.1. Импорт в товары поставщика из прайс-листов в форматах xls и xml. (При работе с основными крупными поставщиками вполне возможно договориться о форматах и автоматически подтягивать их в базу предложений.)
10.1.2.2. Что-то нужно делать со справочником партнеров. Например, маркетологу по закупкам дать право добавлять туда _потенциальных_ поставщиков, возможно, с соответствующим статусом.
10.1.2.3. Номенклатурный справочник незыблем. Однако, может потребоваться ввод неких новых товаров, товаров с новыми спецификациями. Бизнес-процесс ведь может идти не только от спроса (как привязано все планирование закупок сейчас), но и от предложений поставщиков, которые попадут в фирму через эту функцию. Конечно, ввод _потенциальных_ товаров из Планирования закупок в номенклатурный справочник невозможен. Я вижу лишь один вариант: убрать поля по закупкам из mlabel в отдельную таблицу с созданием связи между ними.
10.1.3. Следующая функция – выбор основного поставщика. Я считаю, принципиально следует признавать поставщика основным не с некого момента ввода параметров закупки и не с момента обновления каталога предложений поставщиков и определения лучшего предложения (это предыдущая функция). Выбор поставщика должен осуществляться в момент формирования заказа по возникшей потребности (автоматического планирования). Конечно, это идеализированный вариант, основные закупки делаются у постоянных поставщиков, а этот вариант подходит только для высококонкурентного рынка и стандартных товаров. Тем не менее, считаю, этот вариант должен в логике программы являться основным, а постоянный - частным случаем. Для реализации этого:
10.1.3.1. Ввести в ном. справочнике параметр закупки для товара - "Выбор поставщика", принимающий значения: "постоянный", "переменный", "не определен".
10.1.3.2. При создании заявки (заказа) вручную предусмотреть выбор поставщиков данного товара с механизмом сравнения их условий поставки.
10.1.3.3. Создать механизм выбора постоянного поставщика – сравнительные отчеты.
10.1.4. Следующая функция – непосредственное формирование заявки. Имхо, главная цель здесь – удовлетворение потребности в товарной позиции. Иначе говоря, впереди стоит товар, а уже за ним – потенциальный его поставщик. Исходя из этой логики, механизм создания заявки (заказа) перевернут. Сначала выбирается поставщик, а уж затем вводятся строки документа, содержащие товары. Я вижу этот механизм несколько иначе:
10.1.4.1. Первым действием при формировании заявки должен быть ввод товаров.
10.1.4.2. Далее программа на основании параметра "Выбор поставщика" по каждой товарной позиции либо сопоставляет товарной позиции конкретного поставщика, либо предлагает пользователю определить поставщика самостоятельно по п. 10.1.3.2
10.1.4.3. Определившись с поставщиками, заявка трансформируется в несколько документов по количеству поставщиков, либо в сводную заявку (кстати, если существует сводный заказ, видимо, следует предусмотреть и сводную заявку?) и в заявки-этапы.
10.1.4.4. С таким механизмом более логично будет действовать механизм импорта строк из заказов покупателей.
10.1.5. Функция – контроль прохождения заказа. В общих чертах это реализовано. Не хватает отчетности. Возможно, следовало бы хотя бы в информационных целях дать возможность привязывать к строкам заказа информацию о поступлении товара на склад. Чтобы закрытие заказа хоть на чем-то было основано. Это могло бы и дать основу для анализа поставщика в плане фактического выполнения условий поставки.
10.1.6. Функция – транспортная задача. К сожалению, в этом я совсем слабо разбираюсь. Предложить пока нечего.
Скорость продаж в системе определяется делением точки заказа на время доставки.
ага, понятно.
точнее так:
скорость продаж = (точка заказа - страховой запас)/ время доставки.
а вот еще вариант:
В демке для кофеварки Unit ставлю:
Мин. партия = 1
Макс. партия = 90000
Время доставки = 20
Точка заказа = 400
Объем заказа = 400 (идеальный вариант, как я понимаю)
Макс. запас = 90000
Страх. запас = 0
Период планир. = 90
Текущий остаток = 420 шт. Остальное по дефолту.
После второго прихода моделирование дает 1 день пустого склада.
Так как страховой запас пока не работает, интересно узнать, как будет реагировать система на снижение запаса ниже страхового.
Имхо, варианты реакции могут быть такими:
1. Сдвинуть срок очередной поставки ближе.
2. Увеличить объем очередной поставки
3. первое + второе в какой-то пропорции
Joined: 20 Sep 2002 Posts: 32 Location: Яковлев С.В. Occupation: Компания БЭСТ, Отдел разработки
Posted: 23 Sep 2005 09:53 Post subject:
Добрый день!
Сейчас в системе принята очень "мягкая" тактика работы с картотекой поставщиков. Использование этих функций не обязательно. Система работает только с номенклатурой, а справочник товаров поставщика позволяет быстро ввести данные от нового поставщика. Если установлен значек "Н", то данные по этому товару переписываются в номенклатуру и этот поставщик для данного товара становится основным. Если это направлени будет интересным, то мы готовы развить его в полной мере.
В отношении страхового запаса. Его единственное предназначение - компенсировать колебания времени доставки или скорости продажи. Если запасов не хватает, то страховой запас будет использован. Если говорить о теории, то это задача оптимизации: что лучше, упустить доход из-за временного отсутсвия товара или нести потери из-за излишних запасов на складе. На практике в рознице зачастую страховой запас раньше назначали в 1/2 точки заказа (даже существовали рекомендации). Современная практика по этому поводу мне не известна
Еще раз благодарим за подробные анализ,
С уважением,
С. Яковлев, ОТдел разрабо
Joined: 06 Sep 2004 Posts: 821 Location: Олег Смирнов Occupation: Раут (поганист-сисадмин) Interests: Новосибирск
Posted: 23 Sep 2005 16:36 Post subject:
grey wrote:
Компания БЭСТ, пригласите LuisFigo на работу, в отдел разработок.
Хы!.. Тогда уж на должность "Постановщик задач"!.. А вообще-то, отдельное спасибо LuisFigo за такую глубину анализа - читаю, и со всем соглашаюсь, а вот самому всё так чётко и подробно описать - слабО... _________________ С уважением, Олег Р. Смирн
Joined: 24 Jul 2002 Posts: 20 Location: БОНДАРЧУК ВАЛЕРИЙ ИВАНОВИЧ
Posted: 25 Sep 2005 06:50 Post subject:
Добрый день всем.
Не нашел отчет в котором можно сравнить цены поставщиков.
6 активных поставщиков супермаркета по 1500 позиций в прайсе у каждого. У кого шоколад Alpenlibe с орехами 100 гр. дешевле?
Скоро закупать товар на Новый год. Какова помощь "Планировщика закупок" в этом деле?
Искренне с Вами, Валери Бондарчук г. Казань
9. Планирование.
9.5. Eastern eggs Прошу на пункт 9.5.1 сделать запрос и задокументировать или совсем убрать от греха. (Остальное относительно безопасно и попадается по всему БЭСТу, но зачем?)
9.5.1. Ctrl+a, Home - удаляет все спланированные заказы.
9.5.2. Alt+] - моделирование
9.5.3. Ctrl+i - протокол
9.5.4. Ctrl+e - up
9.5.5. Ctrl+r - PageUp
9.5.6. Ctrl+w, Ctrl+[ - выход из режима (Esc)
9.5.7. Ctrl+x - down
9.5.8. Ctrl+с - PageDown
9.5.9. Ctrl+m - корректировка
9.6. По поводу ошибки планирования с одним днем пустого склада из предыдущего сообщения. Ошибка у вас, имхо, в том, что в день прихода имеется: нач. остаток = 0, расход = 20, приход = 400, кон. остаток = 380, а заказ моделирование планирует на след. день, хотя точка заказа уже достигнута. Поэтому в последующих циклах выпадает одни день. А вообще, принципиально неверно считать приход осуществленным ранее расхода. Если имеем нач. остаток = 0, то и расхода быть не может, несмотря на запланированный на этот день приход. Приход должен моделироваться на день, когда расходуются последние запасы, чтобы след. день не начинался с нулевого остатка.
11. Итак, основой всего моделирования процесса Закупка-Доставка-Продажа являются два критерия: 1) запас должен постоянно обеспечивать потребность покупателей для поддержания уровня продаж; 2) запас должен быть возможно минимален для предотвращения замораживания оборотных средств в запасах и снижения издержек по хранению. Из первого критерия следует формула: точка заказа = скорость продаж * время доставки (страховой запас для упрощения игнорируем). А второй критерий дает такую формулу: объем заказа --> точка заказа. Итак, здесь время доставки – аргумент, зависящий от поставщика, а он может быть величиной переменной, как я уже писал в п.10.1.3. Скорость продаж – константа на период планирования, определяемая нашей оценкой спроса на данный период. А точка заказа – лишь функция от этих двух величин. Соответственно, смена поставщика (или его времени доставки) ведет к изменению и точки заказа, и объема заказа. Оба этих параметра необходимо вручную вычислить и ввести в параметры закупок. Считаю, намного логичнее было бы:
11.1. ввести в параметры закупок скорость продаж как главный параметр, определяющий потребность. Это даст возможность:
11.1.1. Упростить расчеты.
11.1.2. Сделать процесс планирования более понятным. Т.е., вывести в логике программы главную цель – Продажи из тени вперед, а уровень запасов и их покрытие сделать зависимой от нее функцией, которой они в действительности и являются.
11.1.3. Возможность разделения функций. Выбор поставщика, объемы, сроки закупок – функция маркетинга закупок, а уровень продаж – функция маркетинга продаж. Сейчас в логике программы здесь есть некоторое смешение.
11.1.4. Большую гибкость как следствие предыдущих пунктов.
11.2. задать связь между объемом заказа и точкой заказа. Это:
11.2.1. реализует критерий 2)
11.2.2. автоматизирует назначение одного из параметров.
11.2.3. связь не должна быть жесткой. Объем заказа может увеличиваться по причинам комплектования единиц отправки (контейнеров, вагонов…) и из-за скидок. Т.е., планирование осуществляется с учетом связи, но может корректироваться и/или попадает под ограничения на партии поставщика.
11.3. ввести возможность указывать скорость продаж для разных периодов, например, помесячно. Возможности:
11.3.1. учета сезонных колебаний продаж
11.3.2. создаст основу для развития направления, которое сейчас в Б4 отсутствует, - прогнозирования и планирования сбыта. Как-то:
11.3.2.1. возможность строить прогнозы продаж на основе данных о колебаниях спроса, тренде за прошедшие периоды,
11.3.2.2. планировать продажи,
11.3.2.3. автоматически получать потребные запасы под запланированный уровень через функцию управления закупками,
11.3.2.4. гибко реагировать на колебания спроса,
11.3.2.5. оценивать эффективность ранее принятых решений по планированию продаж.
11.4. построить соответствующие отчеты. Конкретизирую позже, но в первую очередь по уровню продаж с разбивкой по периодам и с учетом наличия обеспечения спроса запасами, в т.ч. и по архивным данным.
12. Рассмотрите возможность введения еще одной системы заказа для автоматического планирования. Назовем ее, к примеру, скользящие закупки. Она является частным случаем заказов по остатку. Поэтому можно не вводить новую систему заказа, а ввести параметр к заказам по остатку. Существующее моделирование предполагает только два варианта доставки. При объеме заказа = точке заказа срок доставки = периоду оборота (объем заказа/скорость продаж) и цикл отправка-время в пути-получение непрерывная линия. При объеме заказа > точки заказа срок доставки < периода оборота, а цикл доставки – пунктир. В обоих случаях отправка осуществляется не ранее получения, следовательно срок доставки не может быть больше периода оборота. Тем не менее, такая ситуация возможна. Например, каждые 5 дней из Гамбурга в Новосибирск выезжает фура с пятидневным ( период оборота) запасом товара. Время в пути (срок доставки) - 10 дней. Сейчас же возможно спланировать только доставку десятидневного запаса, при этом среднетекущие запасы на складе возрастают почти вдвое.
Присоединяюсь к пожеланию ВАЛЕРИ БОНДАРЧУК, я говорил о том же в п.10.1.3.3, и делать это желательно не в будущем, а уже в ближайшем SP.[/b]
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Прошу на пункт 9.5.1 сделать запрос и задокументировать или совсем убрать от греха. (Остальное относительно безопасно и попадается по всему БЭСТу, но зачем?)
