Информация о заказчике

Теперь по существу вопроса.

Если производство единичное и изделия уникальные, то там и так все прекрасно знают, какой заказ для какого заказчика. И группировки по названию заказа и по названию технологической карты, как показывает опыт, хватает «более чем». Также активно используются для группировки и аналитики новые возможности в режиме График производства для работы с комментариями и подключение пользовательских параметров. Так что дополнительно ещё приделывать и колонку «Заказчик» не видится нужным.

Если говорить о производстве, когда одна и та же продукция делается для разных заказчиков, то тут добавив колонку «Заказчик» в режим Производственные заказы и График производства, вы не столько решите какие-то проблемы, сколько наживёте новые. Ибо:

- продукция из одной и той же партии пойдёт разным заказчикам. Что будем делать? Двух в колонке заказчик писать? Трёх? Пятерых? Или будем вводить потом колонки "Заказчик2" и т.д.?

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

- как следствие предыдущих двух пунктов, тут же начнётся классическая путаница имени «перенос с заказа на заказ». Т.е. когда предварительно поставили заказчика, как бы делали для него, а реально отдали в итоге совсем другому. Да причём не всё, что делали в этом заказе, а только часть. И пошло-поехало… «А как бы сделать так, чтобы вот из этих деталей вот в этом заказе часть ,как-бы, стали не сделаны, а вот в этом – наоборот, как будто они раз, и уже готовы, хотя их по документам пока вообще не делали, а там, где изначально они были, их как-бы, меньше готовых стало, и теперь их надо ещё раз поделать в этом же заказе» и т.д. и т.п.

- как в этих режимах вы будете отслеживать заказ, когда часть заказчику отдаётся со склада (остатки с предыдущих заказов), а доделывается только часть? Тут же вопрос: «а где эта часть которая уже готова? Её где смотреть?»

- и т.д. и т.п.

Дело в том, что в такого рода производстве (не единичной уникальной продукции) надо разделять разные понятия. Есть заказ производственный, где указано сколько надо сделать, чего, по какой технологии. А есть заказ Заказчика, где написано, сколько и чего конкретно этому заказчику надо в итоге отдать. И не надо их смешивать в одну кучу. У них совершенно разные, что называется «жизненные циклы». Режимы Производственные заказы и График производства предназначены для работы с производственными заказами. И добавление туда колонки «Заказчик», ситуацию не улучшит, а скорее, запутает. Для работы с внешними заказами, скорее, нужен отдельный режим, чтобы там показывались заявки (заказы) покупателей, что заказно, сколько, что и сколько по этим заявкам отгружено уже, что есть уже готовое на складе, какие позиции в производстве сейчас. Возможно, здесь как раз и связь с производственными заказами проследить, в рамках которых такая продукция сейчас изготавливается. Вот в таком режиме колонке «Заказчик» будет самое место. И именно в нём.

P.S. А то, что в номенклатуре к производственному заказу можно добавить как связанный объект "Заказчика" - так это не механизм какой-то для работы с заказчиками, а на самом деле, всего лишь такой дополнительный сервис для как раз сугубо единично-позаказного производства. Нужно совсем не для просмотра (т.к. там и так всем всё понятно, что для кого делается), а для того, чтобы потом, когда со склада готовой продукции накладные отгрузочные оформлять, но тупо не надо было выбирать Получателя, а он автоматом подставлялся. И только для этого.

P.P.S. Скажу больше, для чисто позаказного производства есть и ещё один маленький сервис. "Работа с заявками" называется. Можно создать расчётный документ, там как раз указать заказчика, продукцию, и потом по этому списку создать производственный заказ. В этом случае заявка связывается с производственным заказом и указывать дополнительно заказчика, как связанный объект, больше не надо. При оформлении расходной накладной на складе получатель берётся из расчётного документа-заявки. Но это режим крайне узкоприменимый, неуниверсальный, только под достаточно конкретный случай и в связи с этим, с весьма ограниченными возможностями. Поэтому в документации этот режим вообще нигде и не описан.