Работа в 1с составление заявок. Документ "заявка на платеж"

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

Создание заявки для возвращения товара

Права покупателей на обмен или возврат товаров регламентировано в двух законах Российской Федерации: статьей №25 «О защите прав потребителей» и статьей №502 в Гражданском кодексе. Но не все понимают, что эти документы нацелены не на возврат, а на обмен не понравившегося товара. Если в момент обращения аналогичного товара, на который покупатель бы согласился обменять купленную вещь, то по договоренности с руководством компанией, он может подождать, пока она не появится.

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

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

В зависимости от назначения можно создать один из представленных документов:

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

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

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

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

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

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

• Текущее состояние, в котором находится возвращаемое изделие;
• Срок выполнения;
• Приоритет;
• Менеджер, ответственный за осуществление возврата.

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

• Клиент;
• Комиссионер;
• Розничный покупатель.

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

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

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

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

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

Подбор настроен по принципам ЛИФО, которые предполагают, что отгруженные товары представлены в последних документах.

Кроме того можно загрузить информацию с помощью команды «Добавить товары из документов продаж». При этом необходимо выбрать один из документов продаж и в нем найти необходимые товары.

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

Последняя вкладка «Дополнительно», в ней заполняются следующие строки:

• Операция – из выпадающего списка выбирается от кого оформляется возврат;
• Сделка;
• Подразделение;
• Менеджер, участвующий в сделке;
• Валюта;
• При работе с НДС, ставится галочка рядом с поем валюта;
• Налогообложение.

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

Оформление возвратной накладной в программе 1С Управление торговлей (УТ 11) 11.2

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

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

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

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

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

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

Кроме того, после всех действий в документе «Возврат товаров» возможно формирование таких отчетов как:

• Задолженность клиентов. После проведения задолженность будет изменена только в том случае, если цены за товары, подлежащие обмену отличались;
• Карточку расчетов с клиентами;
• Карточку расчетов по таре;
• Места использования;
• Связанные документы.

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

Важно! Если программа выдает ошибку и не дает сформировать документ, нужно открыть реализацию и изменить статус с «К предоплате» на «Реализовано». При этом все основные данные будут уже указаны и останется только немного их отредактировать.

Для создания расходной накладной, необходимо пройти в раздел «Продажи» — «Документы продажи». Среди распоряжений на оформление необходимо найти заявку, которая была создана ранее для возврата изделия от клиента. Ее необходимо выделить и сформировать реализацию, основываясь на ней. После этого проверить правильность заполненных данных и провести накладную.

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

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

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

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

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

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

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

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

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

1. Быстрое создание заявки

Создавайте новую заявку с помощью кнопки «Скопировать»: программа автоматически вводит данные предыдущей заявки, а вам останется только поправить пару пунктов.

2. Автоматическая выписка документов

Выписывайте счета, акты, счет-фактуры и доверенности быстро и корректно и отправляйте их заказчику и перевозчику на почту.

3. Готовые шаблоны документов

Будьте быстрее конкурентов: отправляйте заявку заказчику и перевозчику, используя готовый шаблон. В него автоматически загружены печать компании и подпись руководителя, поэтому вы экономите от 15 минут своего времени - за этот срок вы можете оформить несколько заявок.

Как создать заявку

1. Найдите в разделе «Логистика» вкладку «Журнал заявок» - здесь хранятся все ваши заявки.

2. Для создания новой кликните «Создать заявку» или «Скопировать» (тогда в заявку прикрепятся данные последней созданной заявки).

3. Открылась форма заявки. Есть поля, выделенные красным: их нужно обязательно заполнить для проведения заявки.

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

Важные советы

Умная Логистика автоматически записывает вашу первую заявку под номером «00001». Если вы хотите продолжить нумерацию заявок, которую использовали до начала работы с программой, введите нужный порядковый номер, сохранив лидирующие нули. В сумме должно получиться 5 цифр. Например, «00345».

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

4. Не пишите название компаний полностью: используйте все возможности программы. Начните вводить в строке название компании и выберите нужное из открывшегося списка или воспользуйтесь справочником, кликнув <...>.

Не нашли необходимого заказчика или перевозчика? Не нужно вспоминать, в каком разделе создается новый контрагент: добавьте его во время составления заявки. Нажмите <...> и на открывшейся странице выберите «Создать заказчика/перевозчика».

5. Пропускаем поле «Маршрут»: оно заполнится автоматически, когда вы введете всю информацию о перевозке.

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

7. Заполните поля в разделе «Оплата». Если в карточке контрагента внесены все данные, поля «Форма» и «Условие» заполнятся автоматически.

8. Перейдем к данным о погрузке и разгрузке. Создавая адрес погрузки, не забудьте указать наименование грузоотправителя - тогда будет автоматически формироваться журнал потенциальных заказчиков. Вы найдете его, передвигаясь по пути: «Продажи» → «Журналы» → «Потенциальные заказчики».

9. Кликните «Добавить» → «Разгрузка», чтобы внести данные о разгрузке. Далее повторяем рекомендации из предыдущего пункта, только для разгрузки.

10. Теперь посмотрите направо - вы найдете поле «Дополнительно». Не пренебрегайте им - оставьте здесь дополнительную информацию о перевозке, чтобы не забыть. Например, запишите точное описание места погрузки и разгрузки.

Важная заметка

При перевозке со сборным грузом поставьте галочку над маршрутом в поле «Сборный груз» - так вы отметите, что заявка состоит в сборке. Выберите из списка наименование сборки или создайте новую: назовите ее так, чтобы в отчете по сборным грузам вы легко могли найти нужную. Вы найдете этот отчет, пройдя путь «Логистика» → «Отчеты» → .

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

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

12. Хотите контролировать перевозки на всех этапах? Мы сняли вашу головную боль, добавив поля «Статус перевозки» и «Статус ТТН». Вы найдете выбор статусов в конце страницы.

13. Все нужные поля заполнены? Кликните иконку дискетки, чтобы сохранить заявку. Теперь ее можно распечатать - выберите «Печать». Умная Логистика позволяет распечатать заявку с заказчиком и перевозчиком из одной формы. Но не беспокойтесь! Ваш клиент и перевозчик «не встретятся» друг с другом в одной печатной форме.

Вы создали заявку.

Оформление Заказов поставщикам автоматически в 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С 8.3 и 8.2:

1С ERP управление предприятием 2.0.

1С Управление производственным предприятием.

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

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

Рассмотрим на примере работу с платежным календарем в программе 1С Управление торговлей 11. Для начала нужно произвести некоторые настройки. Переходим на вкладку «Администрирование» раздел «Организации и денежные средства». В других версиях программы этот пункт находится в разделе «Казначейство»:

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

Также здесь можно установить параметры контроля лимитов всей организации или непосредственно по каждому подразделению. После произведенных настроек в разделе «Финансы» появится пункт «Планирование денежных средств». (Другие версии программ - раздел «Казначейство»):

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

В документе «Заявка на расходование ДС» важным поле является «Операция». Указанный вид операции определяет статью ДДС.

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

Для увеличения лимита нужно сформировать документ «Лимиты расхода ДС».

Каждая заявка определяется статусом:

Согласована.

Не согласована.

К оплате.

Отклонена.

Заявки, которые не согласованы, отражаются в журнале «Заявки на расходование ДС к согласованию».

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

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

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

Кроме вышеуказанных документов возможно создание платежных документов. Для этого выбирается нужная заявка или документ поступления денежных средств. Через клавишу «Настройки» имеется возможность редактирования дополнительных параметров отчета, которые каждый пользователь может настроить по своему усмотрению. Например, расширенный режим позволяет установить отображение статей ДДС в виде иерархии, что дает возможность вывода итогов не только индивидуально по каждой статье, но и по группам.