Это создаст новую страницу заказов верхнего уровня.
Целью страницы заказов является:
Мы заказываем запчасти по трем причинам:
Чтобы создавать заказы, пользователь начинает с постановки в очередь деталей, которые необходимо приобрести, в списке покупок. Список покупок является промежуточной областью и не зависит от дистрибьютора (ов), который будет поставлять детали. Кто-то еще запросил функцию «список желаний», чтобы отслеживать детали, которые вы, возможно, захотите приобрести в будущем. Список покупок - это, по сути, та же идея. Он будет постоянным, чтобы вы могли добавлять или удалять элементы в любое время.
Детали помещаются в очередь (добавляются в список покупок) при любой комбинации следующих действий:
Эти три шага можно повторять в любой комбинации и столько раз, сколько необходимо, потенциально выстраивая в очередь большой список покупок, чтобы собрать множество досок, уложиться в запасы и приобрести другие лишние предметы.
После того, как список покупок будет завершен, пора решить, у какого дистрибьютора (-ов) заказать товары. В этом процессе товары перемещаются из списка покупок в заказы, по одному заказу на дистрибьютора.
Есть две альтернативные стратегии для заказа:
Пользователь может вручную создавать Заказы и перемещать отдельные части между Списком покупок и Заказом или перемещать их из одного Заказа в другой.
Но лучший подход - нажать кнопку, в результате чего PartKeepr рассчитает две альтернативные стратегии заказа и представит альтернативы и их предполагаемую общую стоимость. Пользователь выберет одну из альтернатив, и PartKeepr автоматически создаст заказы и переместит товары из списка покупок в заказы.
Как объяснялось выше, пользователь может вручную перемещать детали между заказами, помещать их обратно в список покупок, добавлять или удалять детали, изменять количество и т. Д., Так что это дает возможность точно настроить заказы.
Когда пользователь доволен Заказом, Заказ экспортируется в виде электронной таблицы CSV. Некоторые дистрибьюторы позволяют загружать CSV BOM для создания корзины покупок.
После того, как пользователь разместит заказ у дистрибьютора, пользователь может изменить его статус с «Ожидающий» на «Заказанный».
В любой момент пользователь может установить дополнительные данные о заказе, такие как:
Когда посылка получена, пользователь может просмотреть список частей в Заказе и зарегистрировать их. При регистрации элемента откроется диалоговое окно со следующими полями: Полученное количество, Цена за элемент. Они будут предварительно заполнены информацией из Заказа. При необходимости пользователь может внести изменения. Например, возможно, товары были отозваны, и дистрибьютор отправил меньше деталей, чем заказано, или, возможно, фактическая стоимость детали отличается от стоимости в базе данных PartKeepr. Нажатие OK в этом диалоговом окне обновит историю запасов и уровень запасов для этой детали. Он также обновит позицию в заказе, записав фактическую цену, указанную в счете, и полученное количество. Если было получено полное количество, некоторые визуальные подсказки укажут, что деталь полностью выверена. После проверки всех поступивших предметов пользователь сможет сразу увидеть, выполнен ли заказ или отсутствуют детали.
Выполняя этот процесс, усилия по обновлению уровней запасов сводятся к минимуму, и мы получаем дополнительное преимущество в виде согласования заказов и отслеживания дефицита в случае, если дистрибьютору необходимо отправить дополнительные пакеты или ошибку дистрибьютора.
После того, как все элементы в заказе будут отмечены как доставленные в хорошем состоянии, PartKeepr отметит весь заказ как завершенный.
У меня тоже есть эта просьба. В настоящее время я работаю над добавлением таблицы «Заказы» в базу данных sql для собственного использования и пытаюсь добавить свои заказы через внешний инструмент sql (очень сильно). Я хотел бы интегрировать управление заказами в рабочий процесс Kicad to Partkeepr, для расчета не только моих текущих запасов, но и будущих уровней запасов, включая расчет времени выполнения заказа.
Включение функции «Заказы» верхнего уровня с описанной функциональностью добавило бы в PartKeepr базовую функциональность SCM, что было бы очень полезно. Даже более простые функции простого отслеживания текущих заказов с указанием дат доставки были бы очень полезны.
Согласовано. В настоящее время мы тратим чрезмерное количество времени на обновление уровней запасов, что требует от нас иметь под рукой документы по заказу, а также второе окно браузера, открытое на веб-сайте дистрибьютора, и согласовывать каждую позицию вручную. Основная мотивация функциональности заказов, описанная в исходном посте, - автоматизировать этот утомительный процесс.
Самый полезный комментарий
У меня тоже есть эта просьба. В настоящее время я работаю над добавлением таблицы «Заказы» в базу данных sql для собственного использования и пытаюсь добавить свои заказы через внешний инструмент sql (очень сильно). Я хотел бы интегрировать управление заказами в рабочий процесс Kicad to Partkeepr, для расчета не только моих текущих запасов, но и будущих уровней запасов, включая расчет времени выполнения заказа.
Включение функции «Заказы» верхнего уровня с описанной функциональностью добавило бы в PartKeepr базовую функциональность SCM, что было бы очень полезно. Даже более простые функции простого отслеживания текущих заказов с указанием дат доставки были бы очень полезны.