1С 8-ка: Работа под заказ с предварительным запросом клиента

Обсуждение вопросов по использованию Excel, Access и других программ оптимизирующих работу закупщика
Аватар пользователя
Olgas

1С 8-ка: Работа под заказ с предварительным запросом клиента

Сообщение Olgas » 01 окт 2008 11:17

Доброго времени суток!

Возник следующий вопрос: каким образом лучше настроить в программе (1С 8-ка) работу по запросам клиентов?

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

Но, как я понимаю, это не совсем корректно, т.к. в 1С главным документов является заказ, который прописывается по всех реестрах.

Посоветуйте, каким образом лучше настроить работу?

Реклама
Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 01 окт 2008 11:30

Запрос у вас в системе отображается или идет по почте\телефону\по понятиям?

Аватар пользователя
Olgas

Сообщение Olgas » 01 окт 2008 11:35

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

Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 01 окт 2008 12:20

Olgas писал(а):Да, запросы фиксируются, в том-то и дело. И это очень важный документ. На основании запроса вводится документ "коммерческое предложение поставщика", затем туда проставляются цены и сроки, продажные коэффициенты.
Если появляется заказ, то цены поставщика берутся из коммерческого предложения.

А проблема то в чем?

Аватар пользователя
Olgas

Сообщение Olgas » 01 окт 2008 12:28

Проблема в существенной доработке конфигурации программы. Может быть, кто-то приудмал что-то интереснее?

Аватар пользователя
u-shak-off

Сообщение u-shak-off » 01 окт 2008 12:34

Olgas писал(а):Проблема в существенной доработке конфигурации программы. Может быть, кто-то приудмал что-то интереснее?


мы вообще очень много чего доработали в 8.1. но я если честно не понял вопрос, что надо доработать то?

Аватар пользователя
Olgas

Сообщение Olgas » 01 окт 2008 12:52

Да, мы тоже дорабатывали. Сейчас как раз думаем, как лучше построить работу со счетами/запросами.
Из запроса клиента нужно иметь возможность зарезервировать товар, подобрать аналоги. В программе же основным документом является заказ.
Если у кого-то есть похожая система работы по запросам, и в соответствии с этим доработана конфигурация, просьба поделиться знаниями. Что на основании чего вводится, что откуда тянется, и т.п.

Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 01 окт 2008 12:57

Olgas писал(а):Да, мы тоже дорабатывали. Сейчас как раз думаем, как лучше построить работу со счетами/запросами.
Из запроса клиента нужно иметь возможность зарезервировать товар, подобрать аналоги. В программе же основным документом является заказ.
Если у кого-то есть похожая система работы по запросам, и в соответствии с этим доработана конфигурация, просьба поделиться знаниями. Что на основании чего вводится, что откуда тянется, и т.п.


Ольга, определитесь с задачей.
Если необходимо, что бы запрос при проведении выставлял резервы - то это не проблема. Это скорее вопрос к программистам, чем к закупщикам.
И что значит "основным докумнетом является заказ"? Основным для чего? Для кого?
Программисты вам доказываеют, что кроме как от заказа они ни от чего оттолкнуться не могут? Это не так. Не стоит ли проконсультироваться у сторонней фирмы? По 1 С, слава богу специалистов сейчас даже больше, чем требуется  :D

Аватар пользователя
Роман Бодряков
Авторитет
Авторитет
Сообщений: 5253
Зарегистрирован: 19 апр 2004 03:00
Имя: Роман
Фамилия: Бодряков
Должность: Ген.Директор в кубе - наноолигарх
Откуда: Россия

Сообщение Роман Бодряков » 01 окт 2008 15:22

Я, в свое время, решил задачу так:
Непроводной документ - заявка клиента (на базе счета)
Он имеет статусы принят, передан, подтвержден
Последний статус значит, что закупка на основании него сформировала два документа. Непроводной документ - Заказ поставшику и проводной - Резерв под заказ (счет).
Есть такие решения, после принятия которых тараканы в голове аплодируют стоя! И просят повторить "НА БИС!!!"
Образование круче не у того, кто больше Знает, а у того, кто хоть что-то умеет.

Аватар пользователя
Olgas

Сообщение Olgas » 01 окт 2008 16:13

Да, программисты сейчас предлагают работать через заказы, делать к ним корректировки при необходимости. Мне такая идея не очень нравится.

Аватар пользователя
stanley

Сообщение stanley » 01 окт 2008 16:15

я вообще запутался - что есть запрос и чем он отличается от заказа

Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 02 окт 2008 07:54

stanley писал(а):я вообще запутался - что есть запрос и чем он отличается от заказа

Цикл заказа заказной позиции
1. Запрос цены с сроков поставки.
2. Ответ от поставщика.
3. Заказ от клиента (если его все устраивает)
4. Заказ поставщику.
5. Подтверждение от поставщика.
6. Приход товара.
7. Оприходование.
8. Списание товара клиенту.

Olgas писал(а):Да, программисты сейчас предлагают работать через заказы, делать к ним корректировки при необходимости. Мне такая идея не очень нравится.

Ну на Вас не угодишь  :D

Аватар пользователя
stanley

Сообщение stanley » 03 окт 2008 10:12

Дядя_Ежик писал(а):
stanley писал(а):я вообще запутался - что есть запрос и чем он отличается от заказа

Цикл заказа заказной позиции
1. Запрос цены с сроков поставки.
2. Ответ от поставщика.
3. Заказ от клиента (если его все устраивает)
4. Заказ поставщику.
5. Подтверждение от поставщика.
6. Приход товара.
7. Оприходование.
8. Списание товара клиенту.

Olgas писал(а):Да, программисты сейчас предлагают работать через заказы, делать к ним корректировки при необходимости. Мне такая идея не очень нравится.

Ну на Вас не угодишь  :D


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

Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 03 окт 2008 10:46

stanley писал(а):[ вплоть до пункта 6 это с точки зрения ИС один и тот же документ.

Нет.
Запрос цены - это скорее переписка, сохранять которую я бы очень рекомендавал. Если это можно сделать в ИС - просто чудесно.

Заказ клиента в итоге совсем не обязательно будет совпадать с заказом поставщику. Тут и округление до коробки/машины и объеденение нескольких клиентских заказов в один и еще много чего...

Аватар пользователя
stanley

Сообщение stanley » 03 окт 2008 13:04

Дядя_Ежик писал(а):
stanley писал(а):[ вплоть до пункта 6 это с точки зрения ИС один и тот же документ.

Нет.
Запрос цены - это скорее переписка, сохранять которую я бы очень рекомендавал. Если это можно сделать в ИС - просто чудесно.

Заказ клиента в итоге совсем не обязательно будет совпадать с заказом поставщику. Тут и округление до коробки/машины и объеденение нескольких клиентских заказов в один и еще много чего...


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

Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 03 окт 2008 13:31

Первый документ - эапрос.
Заказ клиента - второй документ.
Заказ поставщику - третий.

Ты какой из них имеешь ввиду?

dimitrius
Пользователь
Пользователь
Сообщений: 100
Зарегистрирован: 20 июл 2007 03:00

Сообщение dimitrius » 03 окт 2008 14:03

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

Аватар пользователя
Olgas

Сообщение Olgas » 03 окт 2008 15:06

Спасибо всем за обсуждение ))

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

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

Отсюда и вопрос - каким образом лучше все это реализовать в программе? Может кто уже с этим сталкивался.

Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 03 окт 2008 15:13

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

Аватар пользователя
stanley

Сообщение stanley » 03 окт 2008 16:17

Дядя_Ежик писал(а):Первый документ - эапрос.
Заказ клиента - второй документ.
Заказ поставщику - третий.

Ты какой из них имеешь ввиду?


вот по сути 1 и 2 надо поменять местами, как мне кажется

Аватар пользователя
stanley

Сообщение stanley » 03 окт 2008 16:23

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


еще раз повторяю, табличная часть документа в процессе его жизни может меняться. да и будет, куда уж денешься.

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

Аватар пользователя
stanley

Сообщение stanley » 03 окт 2008 16:32

Olgas писал(а):Спасибо всем за обсуждение ))

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

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

Отсюда и вопрос - каким образом лучше все это реализовать в программе? Может кто уже с этим сталкивался.


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

Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 06 окт 2008 10:08

stanley писал(а):
Olgas писал(а):Спасибо всем за обсуждение ))

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

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

Отсюда и вопрос - каким образом лучше все это реализовать в программе? Может кто уже с этим сталкивался.


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


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

Аватар пользователя
stanley

Сообщение stanley » 08 окт 2008 10:07

Дядя_Ежик писал(а):
stanley писал(а):
Olgas писал(а):Спасибо всем за обсуждение ))

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

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

Отсюда и вопрос - каким образом лучше все это реализовать в программе? Может кто уже с этим сталкивался.


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


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


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

если я в результате обсуждения все понимаю правильно, процесс выглядит так:

1. на входе - заказ клиента
2. режем по ассортименту, выделяем заказную часть.
3. проверяем по справочнику актуальность информации об условиях поставки.
4. если актуальность ПО КАКИМ-ТО позициям недостаточна, вырезаем только их и формируем запрос. без клиента и возможно количеств.
5. вот здесь неоднозначный момент. как таковой этот запрос нами использоваться не будет, поэтому его вполне можно распечатать, отправить и не хранить в ИС. но если в реальности необходимо проконтролировать своевременность ответа поставщика, имеет смысл хранить и протоколировать жизнь такого документа. соответственно появляются и нужные атрибуты.
6. получили ответ, внесли информацию в справочник поставщиков, уведомили владельцев заинтересованных заказов.

где не так?

Аватар пользователя
Olgas

Сообщение Olgas » 08 окт 2008 10:17

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

если я в результате обсуждения все понимаю правильно, процесс выглядит так:

1. на входе - заказ клиента
2. режем по ассортименту, выделяем заказную часть.
3. проверяем по справочнику актуальность информации об условиях поставки.
4. если актуальность ПО КАКИМ-ТО позициям недостаточна, вырезаем только их и формируем запрос. без клиента и возможно количеств.
5. вот здесь неоднозначный момент. как таковой этот запрос нами использоваться не будет, поэтому его вполне можно распечатать, отправить и не хранить в ИС. но если в реальности необходимо проконтролировать своевременность ответа поставщика, имеет смысл хранить и протоколировать жизнь такого документа. соответственно появляются и нужные атрибуты.
6. получили ответ, внесли информацию в справочник поставщиков, уведомили владельцев заинтересованных заказов.

где не так?



Процесс следующий:

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

2. Запрос отсылается нескольким поставщикам, от них получаем цены, выбираем самые лучшие. Проставляем в счет менеджера по продажам.

3. Мен. по продажам отправляет счет клиенту. Далее см. пункт первый.

4. Если все ок, то клиент присылает нам заказ.

5. На основании счета формируется заказ в программе. Кол-ва и ассортимент может отличаться (в большую или меньшую сторону).

6. Проверяем наличие на складе, на отсутствующие позиции размещаем заказ поставщику.

7. Получаем товар, отгружаем клиенту.

Такие вот дела :)

Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 08 окт 2008 10:23

stanley писал(а):2. режем по ассортименту, выделяем заказную часть.

Ничего не режем.
У нас на входе запрос на заказной товар.
stanley писал(а):проверяем по справочнику актуальность информации об условиях поставки.

Ничего не проверяем. Проверять надо было до того, как запрос сформирован. Продажнику надо было проверить. Если проверил - в базе есть - запрос на сроки и цену не нужен. Нужен заказ. Если база не ответила - нужен запрос.
stanley писал(а):4. если актуальность ПО КАКИМ-ТО позициям недостаточна, вырезаем только их и формируем запрос. без клиента и возможно количеств.

Вообще не понял о чем ты... Клиента не устроила цена и срок поставки?
Тогда продажник не включает эту позицию в заказ.

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

stanley писал(а):получили ответ, внесли информацию в справочник поставщиков,

Угу, внесли, если она там нужна... Только кто внес? Продажник? В справочник поставщиков? Нииизя. Ее туда внесет закупщик, если она там нужна, если она постоянна, если он не хочет постоянно отвечать на вопрос о сроках и цене поставки.

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

Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 08 окт 2008 10:28

Olgas писал(а):
Процесс следующий:

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

2. Запрос отсылается нескольким поставщикам, от них получаем цены, выбираем самые лучшие. Проставляем в счет менеджера по продажам.

3. Мен. по продажам отправляет счет клиенту. Далее см. пункт первый.

4. Если все ок, то клиент присылает нам заказ.

5. На основании счета формируется заказ в программе. Кол-ва и ассортимент может отличаться (в большую или меньшую сторону).

6. Проверяем наличие на складе, на отсутствующие позиции размещаем заказ поставщику.

7. Получаем товар, отгружаем клиенту.

Такие вот дела :)


Ольга, супер  :D
И еще один пункт
8, Через месяц проверяем - если товар на складе и покупателю не отгружен - выдаем его продажнику в качестве з/п.

Аватар пользователя
Olgas

Сообщение Olgas » 08 окт 2008 10:37

Дядя_Ежик писал(а):
Ольга, супер  :D
И еще один пункт
8, Через месяц проверяем - если товар на складе и покупателю не отгружен - выдаем его продажнику в качестве з/п.


Это точно! Надо бы как раз этим и озаботиться. На складе уже кой-чего лежит :lol:

Аватар пользователя
stanley

Сообщение stanley » 08 окт 2008 10:53

Дядя_Ежик писал(а):
stanley писал(а):2. режем по ассортименту, выделяем заказную часть.

Ничего не режем.
У нас на входе запрос на заказной товар.


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

Аватар пользователя
Дядя_Ежик

Сообщение Дядя_Ежик » 08 окт 2008 11:02

stanley писал(а):
Дядя_Ежик писал(а):
stanley писал(а):2. режем по ассортименту, выделяем заказную часть.

Ничего не режем.
У нас на входе запрос на заказной товар.


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


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


Вернуться в «Программы для закупщиков»

Кто сейчас на форуме

Количество пользователей, которые сейчас просматривают этот форум: CommonCrawl [Bot] и 0 гостей