Заказ поставщику, заказ клиента

Итак, мы остановились на том, что мы сформировали заказ поставщику, мы видим, что система ожидает согласования данного заказа, потому что у нас есть система статусов и если бы мы настроили процедуру согласования, то мы бы могли провести ее по всем согласующим звеньям. Соответственно, на выходе получить сформированный заказ, и дальше можно было бы его оплачивать, скажем, так формировать поступление и так далее и так далее. Система заказов у нас работает. Заказы поставщикам – это хорошо, но нас больше интересуют заказы клиентов, заказы, которые делают нам. Вот тут мы сейчас попробуем поработать теперь уже с ними. Первое: я уже систему работы с заказами клиентов включил. Я напомню, что включается она в меню Продажи и у меня есть возможность работать с заказами клиентов. Теперь еще один такой маленький момент: дело в том, что пользователи, которые работали раньше с системой на базе 1С, версия 7 или 1С версия 8, но не торговой конфигурации, не совсем адекватно воспринимают термин «Заказ». Вы привыкли оперировать терминами – «Счет». Так вот, с точки зрения самого документа системы, заказ и есть ничто иное, как аналог счета. Но у заказа есть ряд преимуществ, который в принципе, когда пользователи с ними знакомятся – они почему-то со счетами начинают меньше работать и больше работать все-таки с заказами. Если мы имеем в виду под счетом саму печатную форму, которую выдают нам или которую выдаем мы, то в принципе, заказ эту задачу решает.

Попробуем сейчас посмотреть на примере заказа поставщика.

Я сформировал заказ, я его, допустим, в статусе «согласован» - проведу, я хочу его распечатать.

Заказ поставщику – это по сути, мой внутренний документ или то, что я отправлю поставщику, поэтому он на сам счет не похож, а вот с заказом клиента, который мы выставляем клиенту – там уже форма будет похожа на сам счет.

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

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

Итак, первое – систему мы подготовили, заказы клиентов у нас могут формироваться и здесь тоже есть одно очень интересное новшество системы, построено оно следующим образом. Как обычно сейчас работают все системы торговые, то есть: клиент обращается к вам либо по телефону, либо приходит в офис, либо пишет электронное письмо, то есть, каким-то образом говорит о своем интересе к конкретной вашей продукции, либо к конкретным вашим товарам. И уже менеджеры по продажам, которые занимаются продажами – формируют эти документы – заказы. В системе управления торговлей, версия 3.0, разработчики пошли немного дальше. Они предлагают механизм, который позволит пускать внешних пользователей в нашу систему. То, что я сейчас сказал – очень многих может шокировать на предмет того: а как это так, неизвестно кто, неизвестно что будет делать в моей системе, мы потом ничего не соберем, не разберем и так далее. Но я хочу сразу успокоить: разработчики об этом позаботились, позаботились каким образом: у пользователя внешнего, который пришел к вам, будет доступ только к заказу и только к заказам своим. То есть, если вы подобным образом реализовали систему и разрешили потенциальным клиентам вашим формировать заказы, то вы сможете для каждого из них завести свою учетную запись. И каждый из этих пользователей будет заказывать вам товары, формируя документ заказ – непосредственно сам, опять же, немного позже я этот механизм покажу, мы можем использовать процедуру согласования, и сам клиент будет отслеживать. То есть, он сам сделал заказ, через день он зашел и увидел, что его заказ согласовали, либо сказали: вот этого нет, либо оно будет не в том количестве, либо не в том цвете и так далее и так далее – уже идет какая-то процедура согласования. Клиент с этим согласиться, либо не согласиться, то есть, уже можно говорить о полноценной процедуре согласования. И опять же– потом аргументировать ее клиенту, на предмет того, что вы изначально заявили одно, в результате согласования заказ изменился, вы остановились на окончательном варианте, а требуете от нас немножко не того, о чем, собственно, мы договорились. Итак, в начале мы разберем процедуру формирования заказа, как обычно, традиционным способом, когда это делают наши сотрудники. Чуть попозже мы посмотрим процедуру формирования заказа именно внешнего, когда сам клиент потенциальный у нас формирует заказ. Тем самым, мы можем уменьшить штат своего стола заказов, который принимает у нас эти заказы и получить что-то на примере интернет магазина, когда пользователь, найдя определенный товар на каком-то сайте, сам формирует заказ, выбирает, что он хочет купить, в каком количестве он хочет купить, на каких условиях, он хочет купить и так далее и так далее, а мы уже потом, его просто обрабатываем. Какое-то подобие личного кабинета, который есть уже в самой системе. И неоспоримый плюс этого в том, что нам не нужно, если бы мы это реализовали бы на своем интернет сайте, нам не пришлось бы передавать данные между сайтом и системой Управление торговлей. Поскольку все это у нас работает, непосредственно, в самой Управление торговлей, а сама Управление торговлей может работать через тонкий клиент в браузере – я позже тоже покажу саму эту процедуру. То вы увидите, насколько это просто, насколько это удобно и так далее. Система все-таки развивается в плане удобства довольно-таки активно. Итак, мы попытаемся сформировать новый заказ клиента.

Процедура та же самая, то есть, я формирую новый заказ, администратор, допустим, ил давайте все-таки менеджер, потому что я администратор – буду его согласовывать. Итак, мы вернемся – менеджер по продажам, формирует заказ клиента. Кстати, обратите внимание, у нас появились, до этого они были скрыты, не видно было их, а сейчас, появился, допустим, мой контрагент ООО Вымпел, которого я раньше указал и появился розничный покупатель. Розничный покупатель у нас доступен, когда идет массовая продажа, она обычно связана с розницей, мы завтра планируем к этому прийти, то есть, посмотреть, как реализованы розничные продажи. Либо розничному покупателю мы можем продавать и без использования механизма розницы, ну, по примеру, допустим, интернет сайта, они могут нас не идентифицировать, мы для них для всех можем быть розничными покупателями. Мы поступим проще – у нас есть Вымпел, есть его соглашение, опять же – сама номенклатура, то есть, к нам обратился клиент и говорит: я хочу купить то-то, сейчас начинаем пользоваться механизмом подбора. Допустим, хочет купить штук чипсов, цена не указана, поэтому мы фиксируем их произвольно, допустим, по 5 гривен, хочет он это купить, допустим, 28 числа. Так, и хочет купить мороженое: 50 штук по 12 гривен, хочет купить 30 числа. Переносим документ, вот у нас наш заказ сформировался. Мы видим даты отгрузки, мы видим сумму цен. Поскольку, цены не установлены, они у нас произвольные, и мы говорим: заказ не согласован. Человек, который принимает заказ, его принимает – она пока не обязателен к исполнению, он дальше пойдет по процедуре согласования. Опять же программа напоминает, что нужно согласовать графики оплаты, мы их согласовали, и сразу обращаю внимание - фиксируется, кто сформировал данный заказ.

Вот наш менеджер по продажам принял наш заказ, и мы можем начинать с ним работать.

Следующее: как идет процедура согласования.

Тот же самый механизм: я принял заказ, и я запускаю процедуру согласования. Я прошу срок до 26 числа – согласовать. У меня не указаны согласующие 4 других условия, давайте их все-таки настроим.

Итак, возвращаемся, пытаемся стартовать процедуру согласования и что у нас произошло: у нас настроен процесс согласования, в результате которого все 4 этапа согласования у нас выполняет пользователь администратор.

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

Я открываю и вижу заказ, я с ним согласен и говорю: заказ согласован.

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

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

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

Единственная проблема, которая может возникнуть – это с процедурой идентификации заказов, потому что если все-таки регулярные наши партнеры, то они идентифицированы, видно, от кого приходит платеж. А если все-таки это розничный покупатель, то тут ситуация сложнее: у нас в системе это один контрагент и каждый раз от этого одного контрагента средства приходят с разных счетов, поэтому, в данном случае, если мы такой механизм захотим внедрять, то он скорее всего, в качестве идентифицирующего будет все-таки, наверное, заказ. Итак, берем денежки, оплата поступила, вот, мы тут же видим, что по нашему заказу есть 100% оплаты. Теперь наш долг составляет 100%, потому что клиент нам оплатил, но мы товар ему еще не отгрузили.

  • Экспертное сопровождение бухгалтеров

Дальше мы можем перевести его в статус обеспечения и, соответственно, служба обеспечения может его уже приступать к отбору. Мы можем заказ начинать собирать, готовить его к отгрузке. И последнее, когда мы заказ формируем к отгрузке, на основании уже можно формировать документ реализации.

То есть, вот мы, сформировали 20 штук – первое, потому что по этим позициям у нас идет первая отгрузка.

Заполнить подразделение, какое у нас есть – отдел продаж и теперь, если мы вернемся в журнал заказа, мы увидим, что у нас есть предоплата в 100%, есть такая-то часть отгружена, есть такая-то часть не отгружена.

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

Заказ выполнен – можно его уже считать закрытым. Вся процедура у нас прошла. То есть, что мы с вами попытались продемонстрировать: мы приняли заказ от клиента, мы провели его через процедуру согласования – то есть, несколько заинтересованных лиц согласились с тем, что мы на таких условиях такое количество с такого склада можем обеспечить, можем продать. После этого клиент увидел, что его заказ согласован, он его может подтвердить дополнительно, то есть, он согласен, ничего не поменялось.

После этого, мы приступаем к работе с данным заказом. Система может у нас отработать следующим образом: если условно разделить работу с заказом на 2 стороны, то есть наша сторона – наши менеджеры по продажам и есть сторона, с которой выступает сам заказчик, клиент. Клиент формирует заказ в стадии не согласован, мы подтверждаем, что заказ мы можем обеспечить, провели у себя процедуру согласования всех заинтересованных сторон и говорим: да, мы можем его обеспечить. Клиент его подтверждает, и после этого мы приступаем к его обеспечению. Можно говорить о том, что на этих этапах согласования установить, так называемые точки не возврата, когда невозможно отменить заказ. Представим себе ситуацию, что для того, чтобы выполнить этот заказ, мы должны со своей стороны сделать заказ поставщику на поставку каких-то комплектующих. Они могут быть особо дорогие, особо ценные, у них может быть довольно большой срок доставки и так далее, и вот до определенной стадии, клиент может отказаться. Клиент сделал заказ, мы его согласовали, мы говорим: да, мы можем, но пока он не пойдет в производство, в работу, пока клиент его не подтвердит. Мало того, можно сделать даже систему, что он не пойдет в производство, пока клиент не внесет свою часть предоплаты. Потому что может получиться такая ситуация, что клиент говорит: хорошо, я подтверждаю – мы уже запускаем свои механизмы, наша служба снабжения заработала, уже что-то там едет, плывет, пилиться. А клиент говорит: извините, я не буду брать – и денег нет, и материал испорчен и так далее. Поэтому здесь уже нужно выстраивать свои процессы таким образом, чтобы мы даже при ситуациях, когда клиенты отказываются от заказов, чтобы мы все-таки эти ситуации сводить к минимуму. Вот так работает стол заказов, когда заказы принимают непосредственно наши сотрудники. Теперь то, что появилось в Управлении торговлей – версия 3.0: появилась довольно интересная особенность – это возможность работать с заказами внешним пользователям, так называемым, внешним клиентом. Первое, что нам необходимо сделать - мы должны донастроить систему: опять же я постоянно говорю, что система может это делать, но ее нужно донастроить. Идем в наш раздел Администрирования, раздел Продажи – итак, первое, что мы должны, это разрешить удаленный доступ своим партнерам, первый параметр – предоставить удаленный доступ партнерам. Второй момент – мы должны определить перечень этих внешних партнеров. В данном случае, я определил одного партнера, который может формировать заказы, таким образом, это – ООО Вымпел.

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

То есть, мы говорим, что он внешний пользователь и определенный функционал у него есть.

Теперь следующий момент: мы настраиваем, что именно данный пользователь может видеть.

Как правило, здесь все завязано на соглашении. Мы обращаемся к соглашениям, видим соглашения ООО Вымпел и говорим: это соглашение доступно внешним пользователям, то есть, пользователь по этому соглашению может что-либо формировать, здесь же у нас определяется, с какого склада будет идти отгрузка, и по какому типу цен мы планируем в данном случае работать.

Теперь следующий момент: как будет выглядеть идентификация данного пользователя. Мы вернемся в настройки пользователей и посмотрим: у нас есть группа доступа, которая называется – Внешние пользователи.

Мы можем сказать, что у нас есть определенный ряд ограничений по складам и по видам цен. Вот эти ограничения настроены не здесь, а настроены у нас через соглашение.

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

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

Мы так поступим с нашим Вымпелом. Итак, я вручную набираю, система меня пускает и вот, обратите внимание, какой внешний рабочий стол видит у себя наш пользователь Вымпел.

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

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

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

В данном случае, в соглашении у нас указано, что данный пользователь по типу цен – оптовая.

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

Я изменил количество первоначальная закупка для того, чтобы у меня был реальный остаток. Вот наш пользователь формирует заказ, говорит: я хочу N количество этих тостеров, я хочу их 5 штук, перенесли эти данные в корзину, программа говорит, доступен этот товар или недоступен и мы сохраняем наш заказ.

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

Еще раз программа проверяет заказы, еще раз я могу увидеть, заказ оформлен.

Мы идем в раздел Заказы и видим – вот наш заказ, сумма большая, вот мы можем его увидеть – он не согласован, как видим, поменять статус пользователь не может.

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

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

Сейчас попробуем обойтись без нее. Вот, допустим, заказ – согласован, да, будет у нас 1000 штук. Только, допустим, не 1000, а только 20.

Соответственно, суммы будут другие. Мы можем обеспечить только 20. Наш заказчик заходит в следующий раз или через какое-то время, то т же самый Вымпел и смотрит: 3 заказа, он согласован и теперь количество 20 штук, общую сумму я вижу, все я вижу, я могу сразу же распечатать себе этот заказ, и, допустим, пойти его оплачивать.

Если же этот заказ распечатает менеджер по продажам, то здесь уже можно распечатать комплект документов.

Есть. Что видит наш потенциальный заказчик: вот его заказ, вот его состояние выполнения.

То есть, мы заказали, но еще никаких документов по нему не оформлено.

Теперь идем разбирать дальше процедуру.

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

Вот, мы видим, что у нас есть просроченная задача.

Вот, мы его согласовали и теперь мы можем обеспечить поступление денег.

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

Вот, мы формируем.

Итак, мы отгрузили наш заказ, видим, что заказ оформлен, поскольку сборка не требуется, поэтому…

Здесь связанные документы по заказу сформированы, вот мы видим: есть на основании заказ клиента, есть реализация – все тоже самое.

Вот таким вот образом у нас строиться сама система, мы можем пользователю написать сообщение, допустим: получение заказа на складе 12, не можем мы ему написать. Вот таким вот образом, мы проиллюстрировали процедуру, как могут формировать заказ и наши внешние клиенты, те, кто получил доступ к нашей базе. Это могут быть клиенты, естественно, разовым клиентом это можно не обязательно предоставлять этот доступ, а вот клиенты, которые регулярно делают у нас заказы с целью облегчения этой процедуры и с целью уменьшения работы своего персонала – пусть работает другое предприятие, пусть они все эти данные вводят. Мы это все можем организовать, как видим, система уже готова, все эти данные позволяет делать. Теперь давайте немножко посмотрим систему отчетов, которая у нас есть, что мы можем посмотреть. Естественно, мы не моделировали процедуру отмены заказов, то есть, когда у нас заказы есть, потом они по каким-то причинам отменяются. Вот если это есть, соответственно, мы можем похоже анализировать причину, почему они отменяются эти заказы, почему заказы отменяются, чьих конкретно менеджеров заказы отменяются и так далее. Поэтому отчеты по продажам вот эти в данном случае мы сейчас посмотреть не сможем, они пустые – там ничего нет.