Заказ клиента на автомобиль (не из наличия)

Добрый день!
При создании документа "Заказ клиента на автомобиль" в справочнике "Автомобили" появляется авто, отмеченное красным цветом.
Оформляя "поступление автомобилей", заказ покупателя прикрепляется к поступившему авто, после выбора заказанного автомобиля в табличной части документа.
Далее, в самом документе "Поступление автомобилей" указывается VIN-номер, который автоматически заполняется в карточке автомобиля справочника "Автомобили".

И снова здравствуйте!

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

Например, у нас есть 50 заказов, следовательно в справочнике автомобилей есть 50 элементов вида "Марка Модель" без VIN-кодов. Допустим, пришло 5 автовозов и вместе с ними 15 накладных на бумажных носителях. Далее, кладовщику нужно проверить каждую строчку в пришедших накладных на предмет того, а не был ли такой автомобиль кем-то заказан. Если был, то он выбирает существующий элемент справочника, если не был - то создает новый. Мы правильно понимаем алгоритм работы? Если да, то получается, что кладовщику придется делать много ручной работы, что приведет к большому количеству ошибок.

Кроме того, зачастую бывает так, что за оприходование автомобилей на склад и распределение их между покупателями отвечают разные люди и кладовщик может быть не в курсе того, кому отдать машину, если на нее, например, было 2 заказа. По идее, кладовщику проще всего в этой ситуации завести в справочнике все поступившие автомобили и внести их в приходную накладную, а менеджеру уже потом разнести их по заказам. Но непонятно, как быть менеджеру: оформлять документ "Изменение автомобиля"? Но тогда в справочнике появляются ненужные "пустые" машины, освобождающиеся из первоначальных заказов.

При существующей схеме получается, что единственный путь распределить автомобиль на заказ - сделать это через документ "Поступление автомобилей". Но бывают, например, ситуации, когда автомобиль, заказанный одним человеком, освобождается из другого заказа. Как быть в таком случае? Можно, конечно, опять сделать документ "Изменение автомобиля", но тогда снова справочник будет заполняться несуществующими авто.

Заранее спасибо за ответы.

1. При создании документа о "поступлении автомобиля" нужно выбрать пришедший, ссылаясь на справочник "Автомобили". Для удобства поиска можно воспользоваться фильтрацией по моделям и комплектации. Заказанное авто будет отображено красным цветом.  
При выборе заказанного авто в табличной части "Поступление автомобилей" отобразится номер заказа на авто, по которому можно найти заказчика.
Поскольку цепочка движения заказа обрывается после "заказа клиента на автомобиль", то автоматизировать полностью процесс невозможно, поэтому избежать большой ручной работы не получится.
2. В случае же отмены одного из заказов и наличии другого покупателя необходимо на основании первого "заказа клиента на автомобиль" создать второй.

Добрый день.
Возникает ещё вопрос - клинет заказал марку и модель, создалась карточка автомобиля с пустым VIN, затем клинет отказывается и автомобиль к нам не поступает вовсе, получается карточка автомобиля без VIN так и будет болтаться в базе?

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

А каким образом можно продолжить эту цепочку? Если я правильно понимаю, то нужно после заказа клиента делать заказ поставщику - в принципе, это не проблема, пусть он будет. В этом случае мы сможем в документе "Поступление автомобилей" воспользоваться обработкой "Подбор автомобилей по заказам". Но она также ничего нам не дает.

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

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

И вот здесь возникает глобальная проблема:
Допустим, у нас был заказ клиента на автомобиль (отсутствующий на складе и с неизвестным VIN-кодом) №ЗАК1. При его записи создался элемент справочника "Автомобили" №А1. Затем подходящий по параметрам автомобиль №А2 освободился из другого заказа. На основании заказа №ЗАК1 мы создаем новый заказ №ЗАК2, в котором указываем освободившийся автомобиль №А2. Тогда с автомобиля №А1 заказ снимается, а что дальше с ним делать - непонятно. По факту у нас зависает никому не нужный и ничего не значащий элемент справочника, который мы даже не можем удалить. Как обрабатывать эту ситуацию?

Добрый день.
Созданный автомобиль участвует в документах, начиная с "заказа клиента на автомобиль", а затем в "отмене заказа на автомобиль", что обуславливает его наличие в справочнике "Автомобили".
Удаление карточки возможно только при удалении всей цепочки движения документов с участием этого авто.

Всем добрый день.

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

Из обсуждения функции обработки следующие:
1. Ручное сопоставление свободных автомобилей на складе (поступивших) и автомобилей из не закрытых заказов покупателей;
2. Заполнение автомобиля в заказе покупателя тем поступившем автомобилем, который был выбран пользователем (сопоставлен) в обработке;
3. Пометка на удаление "освободившихся" карточек автомобилей, чтобы они не засоряли справочник.

Последовательность действий следующая:
1. Кладовщик/диспонент/логист проводит поступления автомобилей в соответствии с бумажными приходными документами - с VIN-номерами и всеми остальными полями, полные карточки;
2. Менеджер узнает (как? варианты - напоминание или событие от кладовщика) о поступлении автомобилей;
3. Менеджер запускает обработку сопоставления;
4. Менеджер в обработке сопоставления вручную сопоставляет поступившие автомобили.
5. Менеджер нажимает кнопку "Выполнить";
6. Обработка подменяет карточки автомобилей в заказах покупателей на авто и помечает на удаление "лишние" карточки.

Вопросы:
1. Можно ли сопоставлять "чужие" заказы? Например, один менеджер указывает заказы другого менеджера?
2. Как обрабатывать конфликты сопоставления? Например, два или более менеджеров параллельно выполняют сопоставление. Результаты этих сопоставлений не стыкуются. Кто прав? Как определить приоритет или заблокировать "чужие" сопоставления?
3. Возможны ли повторные сопоставления уже распределенных автомобилей? Или работаем только со свободными автомобилями?

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


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

Здравствуйте, Роман.

В целом, мы с коллегой также пришли к выводу, что нужна такая обработка, какую вы описали. Однако, так и не поняли, для чего была сделана обязательная ссылка на конкретный автомобиль в документе "Заказ на автомобиль" (в 4-ке ее нет). Какая цель преследовалась? =) Но это, в общем-то, второстепенный вопрос...

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

Не так принципиально - у менеджера от этого зарплата зависит, он узнает =) В крайнем случае кладовщик может его физически проинформировать (по телефону).

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

Вопросы 2 и 3, думаю, можно объединить. Смысл в следующем: можно оставить возможность распределить на заказ только свободный автомобиль (освобождаться при необходимости а/м будут документом отмены заказа). И это будет даже правильнее с учетом того, что менеджеры будут иметь доступ к чужим заказам - так они не смогут "снять" авто с заказа другого менеджера. А конфликты, как следствие, будут разрешаться методом "кто первый встал, того и тапки". Но, повторюсь еще раз, в нашем частном случае это не принципиально.

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

Карточки автомобилей с пустыми VIN не указанные ни в одном документе. Скорее так.

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

Алексей, особенности реализации функционала. Не ясно, с пользовательской точки зрения, чем это полезно/вредит/не заметно.

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

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

Коллеги, спасибо за информацию и ответы.
Подумаем над задачей, обсудим внутри.

Может кому будет интересно.
У нас по другому решена проблема пустых Vin. Мы с пользователями исходили из положения, что заказ на автомобиль всегда сопровождается заключением договора -все ранние договоренности - в раб. листах отражаются. Поэтому сделали процедуру проверки при записи заказа на автомобиль на наличие пустого Vin, после создания карточки авто. Если Vin пустой , в него добавляется номер договора (отформатированный) +текущее время для уникальности. Ну конечно после прихода авто все равно приходится ручками информацию разносить, но по крайней мере нет пустых Vin и менеджер сразу может по номерам договоров проставить Vin в нужные карточки. Но проблему автоматического распределения прихода по заказам покупателей -это никак не решает. Вот если бы была возможность создания документа (назовем его "Ожидаемый приход"), который  либо в ручную заполнялся, либо автоматически с портала загружался . Эта информации заранее известна -и тогда старший менеджер заполняет его-в нем делает распределение заказов по ожидаемому приходу -кладовщику останется только ввести на основании ожидаемого прихода накладную на приход и провести его.
Еще пару замечаний:
почему нельзя сделать Заказ поставщику  многострочным? Оформлять на каждый автомобиль отдельный заказ -дико не удобно, у меня пользователи просто отказываются им пользоваться. Если бы можно было указать несколько автомобилей в заказе поставщику - это был по сути описанный мною выше "Ожидаемый приход" -можно наверно и существующий документ доработать-вставить в него новую хоз. операцию со своими движениями .
И еще вопрос к разработчикам:
сейчас у каждого производителя есть свои интернет порталы, куда они ОБЯЗЫВАЮТ все дилерские центры заносить ту или иную информацию. И на практике получается , что у менеджеров, мастеров по гарантии и т.д. происходит двойная работа (очень часто) -им нужно занести данные в 1с Рарус -для оперативной работы и тут же отразить  эту же информацию на портале производителя. Так как производителей автомобилей у нас ограниченное количество (а некоторые объединены в общие структуры -концерны , например Sollers, Джип-крайслер-фиат), почему бы не запросить у производителей форматы, интерфейсы обмена данными с порталами и не включить их в стандартную конфигурацию АльфаАвто? Меняются они редко и их не так много. Хотя бы по основным крупным брендам. Этот механизм снял бы большой  объем двойного забивания одной и той же информации в разные структуры данных, и как следствие увеличил бы КПД работы пользователей

Тоже приходила в голову похожая мысль. Т. е. предварительно имея в базе некий набор данных о поступивших (но еще не оприходованных) автомобилях, можно было бы предварительно подправлять нужные элементы справочника "Автомобили". Но отказались, поскольку, во-первых, появляется лишнее действие - цепочка "Приход - Распределение" превращается в "Предварительный приход - Распределение - Приход" (здесь, как вы правильно подметили, сильно помогла бы интеграция с БД поставщика), а, во-вторых, все же хочется иметь возможность вообще исключить из работы кладовщика какое-либо упоминание заказов.

Полезно это может быть при составлении разнообразных отчетов - когда в регистре заказов есть ссылка на конкретный элемент справочника, то не надо дополнительно описывать алгоритм поиска этого элемента по параметрам. Вредит это, как уже отмечалось, тем, что при текущей структуре неизбежно ведет к появлению "мусорных" элементов справочника. Ну, и с третьей точки зрения, можно на них просто плюнуть и не обращать внимания, но как-то это "не по фэн-шую" =)

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

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

Второй же вариант - когда мы говорим, что "Иванову нужен любой элемент справочника, удовлетворяющий набору условий". Он служит исключительно для того, чтобы сохранить необходимую информацию для поиска подходящего элемента. И на основании результатов этого поиска уже принимается дальнейшее решение. Например (очень образно), сформировали отчет, увидели что в остатках на складе есть 2 машины нужной человеку модели, позвонили, выяснили какой цвет ему больше нравится, и уже по первому варианту зафиксировали за ним нужную. Вот в этом случае ссылка на конкретный объект имеет весьма туманное назначение.

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

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

Ну идея у меня была несколько иная. Я исхожу из того что, до момента фактического прихода на портале дилера уже присутствует информация о отгруженных автомобилях. Поэтому  старший менеджер может заранее (за день, за час - не важно ) подготовить документ "Ожидаемый приход" с уже  встроенным распределением автомобилей по заказам -зачем 2 операции плодить? А кладовщик будет просто фиксировать факт прихода авто - если на основании делать документ -заказы покупателей  будут оттуда браться автоматом, если заказа нет -это свободный автомобиль.

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

Просто в данном случае документ заказа поставщику отражал бы не факт того, что мы заказали некоторый автомобиль, а появление информации об отгрузке в БД поставщика. Кстати, в версии 8.04 есть обработка пакетного заказа, возможно она поможет облегчить вашу задачу.

Надо будет попробовать пакетный заказ, никак до обновления базы не доходят руки

Здравствуйте!

Искренне прошу прощения за ап старой темы, но уж очень интересно узнать, как обстоят дела с
Дело в том, что переход с 4-ки на 5-ку уже отчетливо виднеется на горизонте и хотелось бы понять, стоит ли ждать от Деда Мороза подарок под новогодней елкой или пора все-таки самим взяться за напильник? =)

И еще хотелось бы знать, если есть такая информация, с какой вероятностью до Нового Года появятся новые релизы или хотфиксы?

Алексей, добрый день.
На тему этой ветки подарков ждать не стоит.
В планах до конца года выпустить релиз 5.0.09.