Ранее я описал проблему (ч.1), поставил задачу (ч.2), спроектировал решение (ч.3), познакомил вас с платформой разработки (ч.4), начал разработку заказа покупателя (ч.5), Разработал Техкарту (ч.6), Закодировал на языке C#\.Net логику заказа (ч.7), Разработал заказ поставщику (ч.8).
В предыдущих сериях я реализовал информационные потоки планового выбытия материалов и планового поступления материалов (МТР). Сегодня доработаю фактическое поступление материалов и фактическое выбытие.
Заказ поставщика станет источником данных о факте поступления МТР, если расширить его данными о фактическом поступлении МТР. Добавляю поля "Дата поступления(факт)" и статус "План-факт".
Также требуется минимальная доработка схемы операций, чтобы отражать в учете не только план, но и факт.
Готово. Теперь при получении МТР на склад удаляем плановые проводки в Заказе поставщику, устанавливаем переключатель "План-факт" в факт, указываем фактическую дату поставки и заново делаем проводки. Если перечень МТР, количество или цена изменились, - перед проведением эти изменения также следует внести в заказ. Таким образом, плановые проводки в системе заменились на фактические.
В Заказе покупателя также дорабатываю этапы фактического взятия заказа в работу и фактической отгрузки готовой продукции покупателю. Для этого в заказ добавляю соответствующие поля статусов и дат:
Для отражения в учете фактического взятия заказа в производство, по аналогии с Заказом поставщику, дорабатываю схему проведения "Списание в производство" (к плану добавляю факт). Далее создаю две новые схемы для проведения в учете статусов "выпуск готовой продукции на склад" и "отгрузка готовой продукции заказчику": называю операции "ГП на склад" и "Отгрузка ГП".
Готово. Проверяем: Удаляем проводки документа в статусе "Заказ принят", меняем статус на "Взят в производство", проводим документ. Меняем статус на "ГП поступила на склад", проводим документ (при этом в поле схема автоматически меняется схема на "ГП на склад" - мелочь, но без нее неудобно. Для этого я добавил соответствующее событие по сохранению документа в настройках документа). Меняем статус на "Заказ отгружен", проводим документ.
Для просмотра проводок нажимаем на "галку" над документом:
Теперь, если мы будем отражать в учете все статусы заказов, то сможем в отчете видеть либо только фактическое состояние складов (фильтр "план-факт"= факт), либо прогноз на будущие даты с учетом плановых выбытий и поступлений (фильтр "план-факт" не используется).
Подвожу итог: Я разработал, наверное, самую минималистичную систему планирования материалов для производства. И это не абстрактное упражнение, а реальная полезная система, если сосредоточиться на планировании материалов по количеству. Время, которое я затратил на разработку оказалось сопоставимо с временем, которое я затратил на это описание. При этом мне понадобилось написать всего одну страницу программного кода (вот он - настоящий Low-Code!).
Вы можете найти очевидные недоработки в части стоимостного учета:
Фактическое поступление материалов учитывается по реальной стоимости закупки, тогда как списание в производство производится по нормативной стоимости, без учета реальной закупочной стоимости. Первое, что бы следовало доработать, - это списание по средней цене или по фактической стоимости партий, например FIFO.
Следует понимать, что при дальнейшем развитии система (как и любая реально полезная) будет усложняться. Потребуется больше прибегать к программированию. Скорость внесения изменений замедлится. Но это будут ваши - полезные именно вашему бизнесу функции (вариант их реализации). Во многих случаях я бы порекомендовал начать с такой "голой" системы. Альтернатива - связать себя с готовой "развитой системой" и получить соответствующий риск ограничений и затрат при осуществлении поддержки и развития "большой" системы с учетом "груза наследия".
Приглашаю всех заинтересованных лиц бесплатно использовать в своей деятельности мою систему планирования производства.