| Цитата |
|---|
Дмитрий Ворожейкин пишет:
Вот если бы была возможность создания документа (назовем его "Ожидаемый приход"), который либо в ручную заполнялся, либо автоматически с портала загружался . Эта информации заранее известна -и тогда старший менеджер заполняет его-в нем делает распределение заказов по ожидаемому приходу -кладовщику останется только ввести на основании ожидаемого прихода накладную на приход и провести его. |
Тоже приходила в голову похожая мысль. Т. е. предварительно имея в базе некий набор данных о поступивших (но еще не оприходованных) автомобилях, можно было бы предварительно подправлять нужные элементы справочника "Автомобили". Но отказались, поскольку, во-первых, появляется лишнее действие - цепочка "Приход - Распределение" превращается в "Предварительный приход - Распределение - Приход" (здесь, как вы правильно подметили, сильно помогла бы интеграция с БД поставщика), а, во-вторых, все же хочется иметь возможность вообще исключить из работы кладовщика какое-либо упоминание заказов.
| Цитата |
|---|
Роман Агальцев пишет:
Алексей, особенности реализации функционала. Не ясно, с пользовательской точки зрения, чем это полезно/вредит/не заметно. |
Полезно это может быть при составлении разнообразных отчетов - когда в регистре заказов есть ссылка на конкретный элемент справочника, то не надо дополнительно описывать алгоритм поиска этого элемента по параметрам. Вредит это, как уже отмечалось, тем, что при текущей структуре неизбежно ведет к появлению "мусорных" элементов справочника. Ну, и с третьей точки зрения, можно на них просто плюнуть и не обращать внимания, но как-то это "не по фэн-шую" =)
Вообще, я считаю, что заказ на автомобиль должен быть представлен в двух вариантах (либо это отдельные документы, либо хоз. операция, сложно сказать).
Первый вариант - это когда мы как бы говорим программе "Вот этот вот конкретный элемент справочника можно продавать только Иванову и никому больше". В этом случае соответствующая запись регистра действительно должна содержать конкретную ссылку (либо значение некоего уникального реквизита - например, VIN, как в четверке). Этот вариант носит как бы ограничительный характер, он служит для того, чтобы определить дальнейшую возможность использования элемента.
Второй же вариант - когда мы говорим, что "Иванову нужен
любой элемент справочника, удовлетворяющий набору условий". Он служит исключительно для того, чтобы сохранить необходимую информацию для поиска подходящего элемента. И на основании результатов этого поиска уже принимается дальнейшее решение. Например (очень образно), сформировали отчет, увидели что в остатках на складе есть 2 машины нужной человеку модели, позвонили, выяснили какой цвет ему больше нравится, и уже по первому варианту зафиксировали за ним нужную. Вот в этом случае ссылка на конкретный объект имеет весьма туманное назначение.
Возможно, с учетом того, что второй вариант заказа может иметь разный набор критериев от случая к случаю (кому-то нужна определенная модель, а кому-то - та же модель, но только черного цвета), технически проще было сделать так, как сейчас. Но лично мое мнение таково, что любую систему можно спроектировать так, чтобы избежать ситуаций, в которых накапливается бессмысленная информация (в нашем случае - автомобили без VIN).
| Цитата |
|---|
Роман Агальцев пишет:
На мой взгляд, менеджеру полезно знать не только о факте поступления автомобилей, но и о составе поступления. Т.е. хорошо бы избавить менеджера от необходимости искать - а что же пришло. Узнали о факте, увидели наполнение. |
Согласен, что система информирования была бы не лишней, но встает еще один вопрос - к чему ее привязать. Если кладовщик будет вручную создавать событие, то это примерно то же самое, что он наберет номер на телефоне. Если же некое сообщение будет создаваться автоматически по факту проведения приходной накладной, то здесь есть нюансы - зачастую отдельные накладные приходят чуть ли не на каждый автомобиль и менеджер просто утонет в напоминалках =) Я бы лично (опять же, в своей конкретной ситуации), ограничился фильтром по дате поступления.
