Оформление Заказов поставщикам автоматически в 1С:Управление торговлей 8 ред.11.2

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

Рис.1

РЕГИСТРАЦИЯ ПОТРЕБНОСТЕЙ
Потребности в товарах можно разделить на группы: (Рис.2).

Рис.2

ПОТРЕБНОСТИ ПО ЗАЯВКАМ - это потребности по заказам на отгрузку, заказам на перемещение и т.п. Такие потребности возникают автоматически при проведении Заказа в статусе К обеспечению.

НЕСНИЖАЕМЫЙ ОСТАТОК - это необходимость поддержания на складе остатка товаров для бесперебойной работы предприятия. Необходимо задавать параметры минимального, максимального и страхового запаса. Параметры можем задавать вручную, а можем рассчитывать учитывая среднедневное потребление и сроки поставки.

ПЛАНИРУЕМЫЙ ОБЪЕМ ЗАКУПОК - необходимо создавать в базе документ План закупок (например, на основании данных о продажах в предыдущих периодах).

В журнале Заказов поставщикам встроены две обработки для оформления заказов:

Формирование заказов по потребностям - используем для оформления заказов по заявкам и по неснижаемому остатку;

Формирование заказов по плану - для формирования заказов по долгосрочному планированию закупок. Для включения возможности ведения планов закупок и создания заказов по планам, необходимо установить флажок НСИ и администрирование → Планирование → Планы закупок . (Рис.3).

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

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

Поддержание запаса (min - max ) - когда остатки товаров на складе снижаются до минимального запаса, программа предлагает заказать товар до максимального запаса.

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

Поддержание запасов (расчет по норме) - Среднедневное потребление задается вручную и умножается на количество дней до следующей поставки или на обеспечиваемый период.

Способы обеспечения потребностей - это источник их обеспечения. Также в способе определяются параметры (срок заказа и срок исполнения).
Способы обеспечения потребностей можно зарегистрировать в справочнике, который находится в разделе Склад и доставка Настройки и справочники.
Новые способы можно создавать в момент определения параметров обеспечения для склада или номенклатуры.
В способе обеспечения определяем стратегию, ее выбор зависит от условий поставки. В программе реализованы два варианта стратегии : (Рис.4).

Рис.4

Рассмотрим пример обеспечения товарами розничного магазина при ежедневных поставках

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

Выполняем следующие действия:

1. Определяем список товаров
Для того чтобы вводить и выводить номенклатурные позиции в ассортимент, контролировать продажи и закупки в рознице включаем функциональную опцию в разделе НСИ и администрирование → CRM и маркетинг → Маркетинг → Управление ассортиментом .
Создаем документ Изменение ассортимента (CRM и маркетинг - Ассортимент ). Этап - ввод в ассортимент. Создаем Формат нашего магазина. Заполняем ассортимент, указывая его роль и вид цены. (Рис.5).

Рис.5

2. Настраиваем параметры обеспечения

В карточке Магазина настраиваем ассортимент нашего магазина. (Рис.6).

Рис.6

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


Рис.7

Переходим к параметрам обеспечения и устанавливаем отбор товаров с учетом нашего ассортимента. (Рис.8).

Рис.8

Выделяем все позиции (Ctrl+A), далее Заполнить Метод обеспечения . Нам необходимо обеспечить фиксированные запас товаров, поэтому мы используем метод Поддержание запаса (min - max), указываем необходимое количество минимального и максимального запаса. (Рис.9).

Рис.9

Рис.10

3. Рассчитываем потребность

После определения всех параметров переходим к расчету необходимого количества, используя обработку Формирование заказов по потребностям . Для доступа к обработке заходим в Заказы на перемещение и создаем новый по потребностям. На Шаге 1 устанавливаем отборы и переходим далее. (Рис.11).

Рис.11

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

4. Формируем Заказ
Заказ на перемещение сформируется автоматически при переходе на следующий этап. Статус в Заказе будет К обеспечению. (Рис.13).

Рис.13

1. Введение

Планирование денежных средств - одна из главных задач управленческого учета в отличии от учета бухгалтерского.

Конечно, между УУ и БУ есть и другие существенные различие (разные требования к аналитике, к оценке и переоценке активов/обязательств, необходимость создания резервов и т.д.), но необходимость решать задачи планирования – это самая сложная из них.
Сложность планирования заключается не только в подготовке плана (его расчету, формированию по разным сценариям), но необходимо еще:

• Выполнять перепланирование;
• Актуализировать планы, переносить корректировки на следующие периоды;
• Проводить план - фактный анализ.

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

Учет нужно наладить, да, но не в ущерб планированию.
Конечно же, планированием все равно занимаются (но не в «1С», а XLS). И самую первую, основную задачу (которую и стараются решить) – это планирование денежных средств.

• (1) Стратегическое (бюджетирование);
• (2) Оперативное.

И если бюджетирование (конечно, при подходе к планированию «сверху-вниз»), можно осуществлять с помощью XLS, то выполнять оперативное планирование – нельзя.
Суть в том, что с таблицами бюджетов чаще всего работают минимум пользователей (1-2 человека). Для большинства предприятий количество статей бюджетирования и пр. аналитик – их не так много. Т.е все можно обработать «ручками» в XLS.

А вот что касается оперативного планирования д/c, то здесь ситуация иная. Т.е часто бывает большое количество счетов на оплату, много регулярных платежей, ожидаемых оплат по заказам клиентов и т.д.

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

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

И эти заявки, соответственно, нужно вовремя обрабатывать, принимать / отклонять, «ставить в план» и оплачивать.

Итого: оперативное планирование д/с - это самая первая из задач планирования , которая должна быть автоматизирована в «1С» у любого предприятия.

И в результате планирования, финансовый департамент / казначейство должны «видеть» в системе:

• Когда, кому, c какого расчетного счета/кассы, на какую сумму нужно оплатить;
• Какой остаток д/c будет на «такую-то» дату c учетом текущих остатков, запланированных расходов и поступлений д/c. Нужно избегать т.н. «кассовых разрывов».

  Т.е возникает необходимость работать с платежным календарем.

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

  Т.е возникает необходимость работать с календарем расчетов.

Цель данной статьи – рассказать о возможностях автоматизации оперативного планирования д/c. При этом, будет проведен сравнительный анализ 3-х разных тиражных конфигураций (две – типовые от «1С», одна - специализированная от компании wiseadvice ).

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

2. Возможности УПП 1.3

На данный момент фирма «1С» еще не выпустила долгожданную, новую редакцию УПП (ред 2). И по этому, будем ориентироваться на то, что доступно - соответствующие подсистемы УПП 1.3:

Нужно отменить, что подсистема «ЗаявкиНаРасходДенежныхСредств» обновлялась в конфигурации относительно не давно (2011 г). И как следствие, в режиме управляемого интерфейса, в панели разделов появился пункт «Заявки на расходование д/с/».

Если попробовать в типовой конфигурации, в файловом режиме, открыть форму документа «Заявка на расход д/с» (она же, ЗРДС), то сразу возникает ошибка по переменной «глОбщиеЗначения» из общего модуля «РаботаСОбщимиПеременными».

Такого рода ошибки можно будет исправить, однако, как говорится: «осадочек остался». Т.е «шероховатостей» в подсистеме ЗРДС УПП – хватает.
Возможность через WEB-браузер оформить документ ЗРДС является полезной, но при этом на практике придется хорошенько задуматься над упрощением и эргономикой типовой формы документа. Особенно это будет важно для мобильных устройств.

А вот что касается платежного календаря, то в режиме тонкого клиента, удаленно через WEB-браузер и т.д. воспользоваться им не получится. Причина в том, что подсистема «Управление денежными средствами» давно не обновлялась и, в частности, отчет «Платежный календарь» построен не на системе компоновки данных. А следовательно, у этого отчета нет возможности использования в тонких клиентах, нет возможности создавать для него произвольные настройки.

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

В УПП, подсистема согласования и утверждения реализована. В ней предусмотрены достаточно гибкие настройки.

• Согласование – это подтверждение необходимости оплатить заявку. Обычно, согласование должно проходить через начальников подразделений, руководителей и других ответственных лиц компании.
• Утверждение – это завершающее подтверждение (со стороны казначея) того, что заявка будет оплачена. При этом обязательно должна быть определена дата платежа, расчетный счет/касса с которой будет осуществлена оплата. Таким образом, платеж попадает в оперативный план (платежный календарь).

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

1. Включить использование механизма согласования заявок можно отдельно, по каждой организации.

• Предусмотрена настройка последовательности прохождения заявки по маршрутам, иерархия маршрутов.

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

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

• Для каждого подразделения можно назначить соответствующую точку маршрута согласования. Суть в этом такая: при оформлении заявки (ЗРДС) обязательно должно быть указано ЦФО (подразделение). И в зависимости от указанного подразделения, УПП «находит» соответствующую ему точку согласования и «отправляет» заявку на согласование в эту точку.

Так же в настройке маршрута согласования допустимо не указать подразделение. В этом случает, такая точка согласования будет «применятся» для всех ЦФО, для которых конкретно не указана соответствующая точка маршрута.

1. Само согласование выполняется с помощью специальной обработки «Согласование заявок»

1. Анализ запланированного наличия денежных средств, графика платежей и отслеживания кассовых разрывов выполняется в отчете «Платежный календарь».

Помимо планируемого расхода д/c (ЗРДС) можно учитывать и планируемое поступление д/c. Для этих целей предусмотрено оформление специального документа «Планируемое поступление д/c».

Нужно отметь, что документе «Планируемое поступление д/c» хотя и есть состояния (подготовлен, согласован и т.д), но возможность согласовать этот документ (так же как ЗРДС) отсутствует. Т.е изменение статусов документа возможно только в режиме «ручного управления».

И еще в УПП есть возможность учитывать планируемое поступление д/с от покупателей без оформления документов «Планируемое поступление д/с».

Т.е если для покупателя оформляются «Заказы клиентов», то в отдельном отчете «Платежный календарь с учетом заказов» это запланированное поступление д/c можно будет увидеть.

1. Помимо отчета «Платежный календарь» предусмотрен отчет «Анализ доступности денежных средств».

При этом предусмотрена возможность резервировать д/c (по заявкам на расход) или размещать заявки в счет запланированных поступлений.

Так же есть функционал закрытия ЗРДС и планируемых поступления д/c. Для этих целей, в режиме «обычного клиента» предусмотрены документы «Закрытие заявок на расходование/поступление д/c».

Однако, данная функциональность так же не поддерживается в режиме тонкого/web-клиента.
Здесь нужно понимать, что методика «жесткого резервирования» сильно завязана на хронологию ввода документов, и это затрудняет корректировки и перепланирование.

По этому, функциональность оставлена в УПП скорее как «наследие прошлого», а для анализа доступности д/c следует применять платежный календарь.

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

1. По документу «Заявка на расходование д/c»:
   1. В документе можно указать «Подразделение» (кстати, в конфигурации оно обозначено как ЦФО – центр финансовой ответственности). Но вполне возможна ситуация, когда заявка оформляется от одного подразделения (ЦФО), и при этом затраты нужно будет далее отнести/распределить на другое/другие подразделения (ЦФУ – центры финансового управления).

      Возможность указывать ЦФУ и т.д. – отсутствует.

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

1. Отсутствует возможность запланировать перемещение д/c между расчетными счетами, cо счета в кассу и прочее.
1. Процесс согласования:
   1. Существует возможность согласовывать ЗРДС, но отсутствует возможность согласовывать планируемое поступление д/с.
   2. На практике возникает необходимость выполнять согласование за других сотрудников. При этом, в системе нужно фиксировать еще и информацию о том «кто и за кого выполнил согласование».

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

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

   3. В процессе согласования заявок, когда заявка переходит на согласование следующему по маршруту, востребована функциональность автоматического информирования (по e-mail) следующего исполнителя, а так же автора заявки.
   4. Если автор заявки уже является ответственным за согласование/утверждение (на любом из этапом маршрута!), то вполне логично что бы программа автоматически «сокращала» маршрут, переадресую заявку на наиболее высокий, доступный уровень. Однако, в УПП это не предусмотрено.
   • Все перечисленные требования, хотя и отсутствуют в типовой конфигурации, тем не менее .

1. Отчеты, права доступа.
   1. Востребована возможность ограничения доступа к заявкам только по доступным авторам / исполнителям (согласователям); по доступным пользователю подразделениям.
   2. Отсутствует отчетность по контролю (по дням и интервалам) фактической и запланированной задолженности. Это актуально и для покупателей и для поставщиков.
   3. Отчетность и часть функционала не пригодны для работы в режиме тонкого/web-клиента.
2. Учет по регулярным соглашениям, договорам.
   1. Часто встречаются ситуации, когда необходимо регулярно осуществлять оплату поставщикам. Например, арендные платежи и т.д.

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

   2. В договорах с покупателями, c поставщиками могут быть прописаны условия по проценту предоплаты, по срокам оплаты и т.д.

      В УПП не автоматизирован учет всей этой информации и (как следствие) автоматическое отражение ее в платежном календаре.

3. Возможности УТ 11.1

C выходом новой конфигурации «Управление торговлей ред.11» появилось много новых, полезных возможностей по задачам оперативного планирования и контроля финансов.
Пожалуй, наиболее существенно в этой части в УТ11 (по сравнению с УПП 1.3) – это механизм учета графика платежей. Этот механизм как раз «закрывает» то, чего сильно не хватало – автоматизация планирования/учета по регулярным соглашениям, договорам.

Таким образом, в УТ11 можно вообще не оформлять (если нет необходимости, конечно) документы планирования расхода и поступления д/c, и при этом, платежный календарь будет нормально формироваться.

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

Функциональность отчета сильно расширилась (по сравнению с УПП 1.3) за счет использования системы компоновки данных. Теперь, отчет можно формировать в тонком/web-клиенте, сохранять в базе и назначать разным пользователям нужные им настройки.

Кроме планирования расхода и поступления д/с в УТ11 появилась функциональность планирования перемещения д/c. Для этих целей можно оформлять документы «Распоряжение на перемещение д/c».

По сравнению с УПП 1.3 для документа «Заявка на расходование д/c» увеличилось количество учитываемых видов хозяйственных операций:

Появилась возможность утверждать как документы «Заявка на расходование д/c», так и другие распоряжения:

Для анализа задолженности по интервалам/срокам предусмотрен отчет «Дебиторская задолженность». При необходимости, можно сформировать и календарь задолженности. Для этого в пользовательском режиме следует добавить группировку по датам оплаты.

К сожалению, в УТ11 (как и ранее) не предусмотрена возможность анализа календаря задолженности по поставщикам. Однако, доработать УТ11 по данной задаче .

Резюмируя: новые методологические решения «1С» вместе с возможностями платформы 8.2 предоставляют хорошую базу для автоматизации задач оперативного планирования и контроля д/c.

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

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

4. Возможности WA: Финансист

Исторически конфигурация «WA:Финансист» была разработана на базе продукта «Управление казначейством».

И при этом, в новое решение «Финансист» от компании WiseAdvice входят еще:

• Подсистема бюджетного планирования;
• Подсистема управления договорами;
• Подсистема формирования и учета фактических платежей;
• Гибкий, настраиваемый механизм формирования/заполнения документов на основе шаблонов;
• Гибкая, настраиваемая подсистема интеграции с клиент-банком.

Рассмотрим основные функциональные возможности «WA:Финансист» в части казначейства - от учета условий по договорам до формирования платежного календаря.

1. В процессе утверждения заявки можно не только согласовать/отклонить документ (как это сделано в УПП), но доступны и другие функции: например, отправить документ на доработку, либо запросить доп. информацию.

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

5. Итоги

Выводы:

1. Для автоматизации работы финансовых департаментов, казначейств, организаций со сложной орг. структурой наиболее подходящим решением является «WA:Финансист » .

   Данное решение развивалось и эволюционировало длительное время, соответственно аккумулировало специфику и требования разных фин. департаментов и казначейств. Общие трудозатраты на разработку решения составили более 5000 чел/часов.

   Преимуществом решения «WA:Финансист» является развитая функциональность и большое количество механизмов настроек программы. Таким образом, внедрение этого решения возможно в короткие сроки (т.н. «коробочное внедрение»), без доп. разработок, программирования и т.д.

   Так как в решении заложены механизмы двухстороннего обмена со всеми основными типовыми конфигурациями, то интеграция в имеющуюся структуру (обмен данными с базами УТ, УПП, Комплексная, Бух) будет не сложной.

2. Для автоматизации фин.департамента / казначейства в рамках проекта комплексной автоматизации лучше всего подойдем решение на базе УПП .

   При этом нужно понимать, функциональность УПП потребует доработок.

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

   Таким образом, внедрение УПП по этим задачам следует выполнять только в рамках проекта автоматизации.

3. Для крупных организаций, для автоматизации департамента казначейства УТ11 не подходит.

   В данном решении, во-первых, отсутствуют механизмы согласования/утверждения документов планирования.

   Во-вторых, отсутствует подсистема бюджетирования и контроль выполнения бюджетов при оперативном планировании.

   Однако, УТ11 отлично подойдет для автоматизации (в т.ч. оперативного планирования д/c) небольших фин. отделов компаний .

1с: Оформляется документ "Заявка покупателя" ("Заявка на поставку"). На следующий день оформляется документ "Поступление ТМЦ (купля-продажа)" ...

Вопрос по 1С Торговля и Склад 7.7:

Оформляется документ "Заявка покупателя" ("Заявка на поставку"). На следующий день оформляется документ "Поступление ТМЦ (купля-продажа)" (без оформления заказа поставщику). Поступивший товар не резервируется под данную заявку. Почему?

Ответ 1с:

Распределение заявок покупателей на поставку и резервирование по ним товаров производится только в том случае, если оформляется "Заказ поставщику" и поступление оформляется на основании заказа. Это позволяет организовывать схемы торговли "по заказам", то есть в этом случае производится анализ предстоящих поставок по уже сделанным заказам поставщикам, исходя из указанной в документе даты предполагаемой отгрузки, чтобы, начиная с этой даты, ТМЦ под эту заявку оказались зарезервированы.
Отдельно оформленный документ "Поступление ТМЦ (купля-продажа)" ничего не резервирует. Однако, если поступление ТМЦ оформлено и не на основании конкретного Заказа поставщику, а просто в рамках одного договора, тогда оно автоматически привязывается к Заказу и на основе этого производится резервирование.
Оформление таких заявок позволяет увеличить размер свободного складского остатка за счет предстоящих поступлений по заказам поставщикам.

Еще вопросы и ответы по 1С Торговля и Склад 7.7:

Комментарии к "Оформляется документ "Заявка покупателя" ("Заявка на поставку"). На следующий день оформляется документ "Поступление ТМЦ (купля-продажа)" ...":

23.08.2017 в 12:58 Андрей написал(а):

1С 7.7 Торговля+склад. Оформляется заказ от покупателя "заявка на поставку" 10 августа. Но покупатель хочет забрать её 22 августа. Как не забыть про эту заявку за эти дни? Заявок очень много. Как сделать напоминание если это возможно

Добавление комментария:

(Продолжение. Начало см. в № 34-44)

Работа с поставщиками

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

Прикладное решение "1С:Управление торговлей 8" ред. 11 предлагает две различные схемы работы с поставщиками при закупке товаров. Одна из них предполагает поставку товаров в случае появления потребности в них по предварительному заказу поставщику. Другая схема не предусматривает оформления соглашения и предварительного заказа поставщику. Поставка по этой схеме выполняется по произвольным ценам.

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

Оформление соглашения с поставщиком

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

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

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

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

Работа с заказами поставщикам

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

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

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

Для заказа поставщику по согласованию с ним можно зарегистрировать несколько этапов оплаты – "Аванс (до подтверждения)", "Предоплата (до поступления)" или "Кредит (после поступления)". Этап "Аванс (до подтверждения)", например, означает, что поставщик подтверждает поставку товара только после получения аванса. Для каждого этапа указываются процент и дата оплаты. Суммы оплаты по каждому этапу при этом будут рассчитаны автоматически.

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

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

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

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

Регистрация поступления товаров

Прикладное решение позволяет оформить поступление товаров как на основании заказа поставщику, так и без заказа. При оформлении поставки импортных товаров можно указать номера ГТД и страну их происхождения.

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

Управление денежными средствами

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

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

Предполагается, что заявки на оплату могут создавать сотрудники любых подразделений предприятия. При оформлении заявки указывается планируемый вид оплаты – наличными денежными средствами, безналичными денежными средствами или платежной картой. В заявке можно обосновать необходимость оплаты, а также прикрепить к ней файлы, которые содержат необходимую информацию – отсканированные счета, таблицы с расчетами и т.д. Созданная заявка имеет статус "Не согласована" и передается на согласование ответственному сотруднику, например финансовому менеджеру или финансовому директору. В процессе дальнейшей работы с заявкой на оплату она может получить статус "Согласована", "Отклонена" или "Утверждена".

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

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

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

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

Многие торговые организации работают «под заказ». Т. е. организация сначала получает несколько заказов от покупателей. Потом находит поставщиков и у них приобретает необходимые товары. Как только товар приходит на склад от поставщика – он сразу отгружается покупателям.

В такой ситуации менеджеры по закупкам должны иметь удобные механизмы для формирования заказов поставщикам и отслеживания сроков поставки.

В программе «1С:Управление торговлей, ред. 10.3» менеджер по закупкам может сделать следующее:

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

Рассмотрим подробнее каждую из этих возможностей.

Для анализа товаров, которые необходимо закупить для клиентов, можно использовать отчет «Анализ заказов покупателей».

Меню: Отчеты – Продажи – Анализ заказов – Анализ заказов покупателей

Отчет можно сформировать по еще не отгруженным заказам. Для этого установим флаг «Состояние отгрузки по заказу» и отметим значения «Не отгружено» и «Отгружено частично». Таким образом, мы получим отчет по заказам, которые еще не отгружены полностью:

В отчете показываются все неотгруженные заказы. По каждому заказу мы видим необходимые товары, в колонке «Осталось обеспечить» указывается необходимое количество. Если эта колонка не пустая, значит товар отсутствует на складе и не был зарезервирован – его нужно заказать у поставщика.

Создание заказа поставщику

Из отчета «Анализ заказов покупателей» мы выяснили, что для наших клиентов необходимо сделать заказ поставщику. Но нам необязательно запоминать, кому и какого товара не хватает. Прямо из отчета можно сформировать заказ поставщику на все недостающие товары!

Нажмем на кнопку «Заказ поставщику – Сформировать один заказ поставщику»:

Создается новый документ «Заказ поставщику», в который автоматически попали все необходимые для заказа товары:

Для каждого товара в колонке «Заказ» указан заказ покупателя, под который товар заказывается у поставщика. Благодаря этой информации в момент поступления товара на склад он будет зарезервирован для покупателя автоматически.

В заказе нужно выбрать поставщика, договор, заполнить цены покупки. Мы договорились с контрагентом «Мобил» о поставке данного товара 28.12.2011. Укажем предполагаемую дату поступления товара в поле «Поступление»:

По кнопке «ОК» проведем и закроем заказ поставщику.

После оформления заказа поставщику снова сформируем отчет «Анализ заказов покупателей». Теперь колонка «Осталось обеспечить» пуста, т. к. мы заказали все необходимые товары у поставщика. Информация о том, что товар заказан поставщику, отображается в колонке «Размещено в заказах»:

Контроль сроков поставки

Для контроля сроков поставки воспользуемся отчетом «Анализ заказов поставщикам».

Меню: Отчеты – Закупки – Анализ заказов – Анализ заказов поставщикам

Сделаем настройку, чтобы увидеть заказы, по которым нарушен срок поставки. Нажмем кнопку «Настройка».

В открывшейся форме настройки внизу в таблице добавим новый отбор «Заказ.Дата поступления меньше или равна текущей дате». Для этого нажмем кнопку «Добавить», в открывшемся окне выбора поля найдем поле «Заказ», развернем его по плюсу и выберем внутри поле «Дата поступления»:

В основной форме отчета также установим флаг «Состояние поступления» и отметим значения «Не поступило» и «Поступило частично».

Нажмем «Сформировать» и в результате увидим все заказы, которые должны были полностью поступить до текущей даты, но этого не произошло:

В колонке «Осталось закупить» будет указано количество не поступившего вовремя товара.

По результатам анализа менеджер может принять решение аннулировать заказ поставщику. Для этого оформляется документ «Закрытие заказа поставщику». Создать документ можно на основании заказа поставщику или вручную.

Меню: Документы – Закупки – Закрытия заказов поставщикам

Сделаем закрытие заказа на основании. Для этого можно найти нужный заказ поставщику в списке заказов:

Меню: Документы – Закупки – Заказы поставщикам

Или открыть заказ поставщику прямо из отчета.

Чтобы открыть заказ поставщику из отчета, нужно сделать по нему двойной клик мышью и в открывшемся списке действий выбрать пункт «Открыть заказ поставщику»:

В заказе поставщику воспользуемся кнопкой ввода на основании и выберем пункт «Закрытие заказов поставщикам»:

В открывшемся документе «Закрытие заказов поставщикам» уже будет указан закрываемый заказ, контрагент, сумма заказа:

Также можно указать причину закрытия заказа и потом анализировать причины закрытий заказов в отчете:

Меню: Отчеты – Закупки – Анализ заказов – Анализ причин закрытия заказов

По кнопке «ОК» проведем и закроем документ.

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

Кроме того, если еще раз сформировать отчет «Анализ заказов покупателей», мы увидим, что товар снова появился в колонке «Осталось обеспечить»:

Теперь менеджеру по закупкам следует сформировать новый заказ поставщику на недостающие товары и ожидать поставку данного товара в срок.