От Vic :

Добрый день. Это не история внедрения, а история поиска варианта для внедрения. Пока она только начинается.
У нас небольшая организация по производству электроники. Назрела необходимость иметь инструмент для двух больших задач.

Первая задача — необходимоть менеджерам и директору вести совместный учет заказов. Под этими словами понимается следующее. Есть заказы от клиентов. Каждый заказ проходит определенный цикл.

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

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

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

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

Сейчас учет ход работ над заказами ведется в Excel, документация по изделиям хранится на выделенном сервере. Планирование сроков — очень приблизительное и на короткий отрезок времени.

Я делаю web-base систему, которая на текущий момент имеет следующий функционал: ввод заказов (со списками изделий в них), назначение менеджера заказа, ввод этапов производства со сроками и вожможными зависимостями этапов друг от друга, отвестственных за эти этапы, установки дат прохождения этапов. Соотвественно видны просроченные заказы, можно фильтровать по менеджерам, изделиям, заказчикам. И даже работает шустро, так как система заточена под наши требования.

Но есть загвоздка — нужно еще и вести склад по комплектации и изделиям. Есть мысль, что писать склад — сложно, и лучше взять готовый продукт. Но, если брать готовый продукт, то почему бы не взять и готовый продукт по превой задаче — по ведению заказов. Я наткулся на этот продукт и теперь хочу понять, подойдет ли он нам.

От Vic :

На всякий случай опишу здесь вторую задачу — склад.

Итак, клиенты делают заказ на производство изделий. Некоторые клиенты для этих изделий передают нам свою комплектацию, некоторые просят нас, чтобы мы сами закупили комплектацию. Поэтому на складе может находится как наша комплектация, так и комплектация заказчиков. Уже тут нам нужно знать, что из того, что лежит на складе — наше, а что — какого заказчика.

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

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

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

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

Прошу подсказать, насколько сложно то, что описано выше делается в эOpenERP или какой-то функционал уже есть из коробки.