Заказ звонка

Закрыть

*
*
*

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

Страницы: 1
RSS
Информация о заказчике
Информация о заказчике в номенклатуре (категория производственные заказы) ведется через связанные объекты, как эту информацию (в гриде) выводить в режимах «производственные заказы» или «график производства» и есть ли какой универсальный механизм по выводу в одном гриде не только параметров, но другой информации по связанным объектам, коллекциям компонентов и т.д.
Цитата
juri пишет:
есть ли какой универсальный механизм по выводу в одном гриде не только параметров, но другой информации по связанным объектам, коллекциям компонентов и т.д

Такой механизм называется "Сохранённые запросы". Вот здесь пример приводится. Зависимых объектов может быть открыто не один, а несколько. В зависимости от того, что нужно отобразить.
Как составлять запросы по номенклатуре понятно, вопрос звучал как добавить заказчика в режимах «производственные заказы» или «график производства», чтоб в последствии группировать по заказчику, выдавать задания и т.д., а там нет возможности формировать запрос, если есть объясните как это сделать.
В производственных заказах добавлять колонку Заказчик не нужно, т.к. он на то и производственный, что может вообще не относится к какому-либо конкретному заказчику или в рамках одного производственного заказа может изготавливаться продукция не для одного заказчика.

А если у вас единичное производство и каждый заказ в производство строго под конкрнетного заказчика, то проще всего для начала в наименование производственного заказа впишите, например, эту информацию.
Народ привык отождествлять производственный заказ с конкретным заказчиком, поскольку данная информация требуется, зачастую, для решений вопросов с заказчиком, заносить информацию в наименование не выход, во первых более трудоемко, во вторых вероятность ошибки снижает эффективность от механизма группировки.
А хотите я вас лично познакомлю с человеком с производства, который ежедневно общается со своими заказчиками и при этом на самом деле в режиме реального времени берёт нужную для этого общения информацию непосредственно из VOGBIT?
Теперь по существу вопроса.

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

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

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

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

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

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

- и т.д. и т.п.

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

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

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