С «сортами» - не знаю…
В современной версии можно сделать штатными средствами вот такую конструкцию:
После сдачи из производства продукция попадает не сразу на склад, а не контроль (технически – отдельный «склад» в программе). Проводится «контроль». При этом можно зафиксировать параметры какие-либо, признаки, фото приложить, появляется некий номер «документа», дата (когда «контроль» этот случился) и автор (кто провел это в программе).
В результате либо соответствующая продукция признаётся годной – тогда она с соответствующими пометками попадает на основной склад, либо не годной – тогда с соответствующими пометками попадает на склад брака.
Можно настроить, где учитывать продукцию при расчёте «обеспеченности» заявок. Например, на основном складе и на складе ОТК – считать, на складе брака – не считать.
Так можно. Соответствующие функции и экранные формы есть в VOGBIT (версия 21.2).
А вот чтобы делить одни и те же «изделия» на разные «сорта» - такого нет. И не предполагалось пока чего-то подобного.
Поскольку наши клиенты, в основном, работают с «железом», а там обычно детали не делятся на «1 сорт», «2 сорт» и т.п. Есть чертёж, есть деталь. Она или годная, или не годная. Не годную можно или выкинуть, или доработать, чтобы стала годной, или сделать из нее что-нибудь другое. А чтобы какие-нибудь «муфты», «крышки», «приборы» делились на «1 сорт», «2 сорт» и т.п. – такого нет обычно среди подавляющего большинства нашей клиентуры. Пока, по крайней мере, не наблюдается.
Потому на сегодня резюме: суть вопроса в целом понятна, решения готового нет.
P.S.
Если рассуждать теоретически:
Если потребителю (будь то, клиент, или собственное подразделение) принципиально важно какого именно «сорта» изделия ему нужны, то тогда, по логике всего остального VOGBIT – это, наверное, должна быть разная номенклатура. «Изделие А, сорт 1», «Изделие А, сорт 2», «Изделие А, сорт 3». Ну пока мне так кажется….
Превращение некоего «Изделия А вообще» в «Изделие А сорт Х» - технически на уровне платформы, в той части, которая относится к складскому учёту, такая операция предусмотрена. То есть действие, превращающее одну, числящуюся «на складе», номенклатуру в несколько других, числящихся «на складе», номенклатур с другим количеством технически возможно. Вручную на уровне базовых объектов системы (учётных документов и карточек) можно сгородить такое. Что приведёт к соответствующему результату («просто Изделия А» на складе исчезнут, а вместо них появятся «Изделия А, сорт 1», «Изделия А, сорт 2» и т.д.). Но пользовательский интерфейс, положа руку на сердце, в текущем варианте там годится разве что, чтобы администратор мог руками, изредка, разово что-то подобное сделать. Но никак не для того, чтобы дать это «контролёру» (простому, неподготовленному пользователю), и он ежедневно этим занимался.
(во-первых – много действий, окон и кнопок с непонятными для «контролера» названиями, во-вторых, как и везде на уровне «платформы», там нет никакой «защиты от дурака» или «вшитой логики»: что во что можно или нельзя «превращать», должно или не должно совпадать, например, «количество» и т.п.)
Можно ли продумать некую предопределенную логику и написать более дружелюбный интерфейс для выполнения такого рода операции?
Можно.
Вопрос только в том, что, как я писал выше, на сейчас среди основной массы наших текущих клиентов ничего похожего нет, и им не нужно. Если будет понятно, что есть реальный спрос на движение какое-то в этом направлении (много клиентов, кому что-то похожее реально сейчас нужно) – можно двигаться в этом направлении.
И ещё, конечно, вопрос с «обеспеченностью». Сейчас там всё рассчитано на то, что «запрос» на получение со склада содержит ту же номенклатуру, какую и нужно выдавать. Есть под это дело существующий механизм под названием «Замены». Но он в некоторых случаях хорош, а для других случаев сложноват. Есть (в планах на будущее) мысли ещё подорабатывать «Замены» (сделать ещё один вариант – попроще). Хватит ли этого в контексте всего, что связано с «сортами» (заявки покупателей, планирование, производство, отгрузка) – не знаю. Может, да, а может, и нет. Глубоко пока не пытались даже продумывать в таком контексте по причинам, указанным выше.
