Бизнес-процесс "Казначейство и бюджетирование"

Краткое описание процесса

Казначейство

• • Сбор документов по всем закупкам и продажам, включая акты выполненных работ, передача в 1С
  • Ведение по каждой заявке необходимой аналитики (юрлица, статьи бюджета и ЦФО в которых произошли расходы);
  • Автоматизированное формирование заявок на оплату на основе первичных документов
  • Автоматическое формирование заявок по установленному перечню расходов с возможностью корректировок установленному инициатору;
  • Ручное формирование заявок.
  • Сбор документов по всем покупкам за наличный расчёт (с точек, с офиса, подотчётные лица)
  • Согласование заявки на оплату установленным сотрудникам (соблюдение пути и последовательности/параллельности согласования).
  • Ввод, согласование оплат с учётом аналитики по статьям, ЦФО и др.
  • Контроль сумм оплат по статьям/договорам.
  • Формирование платежного календаря по заявкам на оплату.
  • Формирование реестра платежей и выгрузка его в систему оплат.
  • Автоматическая загрузку банковских выписок и закрытие соответствующих заявок.
  • Автоматическое получение факта ДДС
  • БДДС, планирование

Бюджетирование

• • Формирование Руководителем ЦФО плана БДР на год.
  • Автоматизированное формирование сводного плана БДР на год (с возможностью группировки по ЦФО, юрлицам и в целом по компании).
  • Автоматическое формирование факта БДР через аналитики казначейства по каждому ЦФО и в целом
  • Автоматическое формирование сводных отчетов по БДР по выбранным вариантам свода.
  • Взаиморасчеты с контрагентами
  • Взаиморасчёты с поставщиками, контроль дебиторской и кредиторской задолженности с контрагентами.
  • Консолидация БДР
  • Взаиморасчёты с подотчётными лицами
  • Контроль расчетов с персоналом
  • Отчёт план-факт

 

Подпроцессы

1. Бюджет доходов и расходов (БДР)
   1. Формирование БДР
   2. Работа с БДР
   3. Контролируемые и неконтролируемые статьи бюджета
2. Бюджет движения денежных средств (БДДС)
   1. Формирование БДДС
   2. Работа с БДДС
      1. Балансировка платежного календаря
3. Закупка
   1. Ведение договоров на покупку
      1. Дополнительные соглашения
      2. Ведение заявок на покупку
         1. Бюджетный контроль (БДР)
      3. Поступления
      4. Кредиторская задолженность
      5. Ведение заявок на оплату
         1. Бюджетный контроль (БДДС)
         2. Утверждение реестра платежей
         3. Исполнение платежей
         4. Разнесение банковской выписки
   2. Авансовые отчёты

      1. Основные направления покупок через авансовые отчёты

      2. Реализация в программе

      3. Способы выдачи под отчёт

      4. Особенности оформления в различных ситуациях

4. Продажа сторонним контрагентам
   
   1. Ведение договоров на продажу
      1. Дополнительные соглашения
      2. Заказы покупателей
      3. Счета
      4. Отгрузки
      5. Поступления оплаты
      6. Дебиторская задолженность 
5. Розничная торговля
   1. Розничные продажи
   2. Кассовые операции. 
      1. Оприходование выручки
         1. Наличные
         2. Кредитные карты
         3. Агрегаторы
      2. Инкассация
6. Интернет-магазин (сайт, приложения)
7. Амортизация ОС
8. Учёт РБП
9. Учет спецодежды и МБП
10. Учёт топлива
11. Учёт запчастей и прочих материалов
12. Учёт приобретаемых услуг
13. Учёт предоставляемых услуг
14. Обжарка кофе
15. Зарплата

Операции и соответствующие им типы документов в ИС

• Закупка
  • Договор на закупку ("Договор на закупку")
    • Дополнительное соглашение ("Дополнительное соглашение к договору на закупку") 
    • Заявка на покупку ("Заказ поставщику")
      • Поступление ТМЦ, услуги, коммуналка, аренда.. ("Приход от поставщика")
        • Возврат поставщику ("Возврат поставщику")
        • Оплата поставщику ("Расход денег")
        • Авансовый отчёт ("Авансовый отчёт")
• Продажа сторонним контрагентам
  • Договор на поставку ("Договор на поставку")
    • Дополнительное соглашение ("Дополнительное соглашение к договору на поставку")
    • Счёт на оплату ("Счёт")
      • Продажа по накладной ("Продажа по накладной")
        • Получение оплаты на р/с ("Приход денег")
• Продажа через кассу ("Продажа через кассу")
  • Приход денег в кассу ("Приход денег")
  • Инкассация ("Перемещение денег"
  • Выручка по кредитным картам ("Приход денег")

 

Специальные интерфейсы казначейства

• • БДР
  • БДДС (Платёжный календарь)
  • Реестр платежей
  • Финансовые операции

Требования к процессу

Общие требования

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

 

Общие требования к составлению бюджетов БДР и БДДС

Формирование бюджета	Права на создание/корректировку БДР	Да	Да
Формирование бюджета	Периоды планирования: месяц, год. Учесть необходимость детализации годовых бюджетов по месяцам. Бюджет должен рассчитывать итоги за год.	Да	Да
Формирование бюджета	Обеспечить иерархическую структуру статей бюджета. Возможность планирования в разрезе статей бюджета от нижнего к верхнему уровню.	Да	Да
Формирование бюджета	Обеспечить  возможность планирования в разрезе иерархической Структуры предприятия.	Да	Да
Формирование бюджета	В системе должна быть реализована возможность ввода плановых данных для бюджетов следующими способами: • ручным вводом; • расчетным путем • загрузкой из Excel	частично	Да

 

Договора

Условия оплат

Реализация функционала условий оплат

Да

Да

 

Управленческий учёт

Аналитические разрезы	Необходима возможность ведения следующих аналитических разрезов управленческого учета: Контрагент Договор ЦФО (Торговая точка, объект) Статья БДР Статья БДДС Период ТМЦ (номенклатурная позиция СИМ, ОС и проч) РБП Сотрудник	Да	Да
Формирование отчетности	В системе должны присутствовать отчеты: - план-факт исполнения бюджета - отчет о движении денежных средств БДДС;	Да	Да

 

Основные средства

Расчет амортизации ВНА

Система должна обеспечивать учёт амортизации основных средств и нематериальных активов.

Нет

Да

 

Заявки на покупку

Бюджетный контроль заявок на оплату	Сверка заявок с бюджетом, лимитом. Проверка на не превышение лимитов сумм. Запрет на проведение заявок при превышении лимитов.	Да	Да
Настройка процесса согласования и доступа	Реализовать механизм настройки маршрутов согласования в соответствии с ролями и полномочиями присвоенными пользователям для заявок на оплату, заявок на покупку, договор, реестра платежей.	Да	Да
Бюджетный контроль заявок на оплату	Реализовать настраиваемый механизм проверки лимита по статье расходования	Да	Да
Бюджетный контроль	При корректировке бюджетов необходимо предусмотреть возможность переноса лимитов между статьями, периодами, ЦФО.	Да	Да
Бюджетный контроль	В системе необходимо предусмотреть установку контролируемых/ неконтролируемых статей для контроля лимитов по Бюджетам.	Да	Да

 

Платёжный календарь

Платежный календарь

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

Да

Да

Заявки на оплату

Создание Заявок на оплату на основании	Предусмотреть возможность создания Заявок на оплату на основании условий платежа, указанных в договоре и в Заявке на покупку.	Да	Да
Формирование платежных поручений	Возможность автоматического и/или ручного формирования платежных поручений на основании согласованных реестров платежей.	Да	Да
Группировка платежей	Реализовать возможность объединения нескольких заявок в один платеж или разделение одной заявки на несколько платежей (частичная оплата)	Да	Да

 

Реестры платежей

 

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

 

Оплаты

Загрузка данных из клиент-банка

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

Да

Да

Основное назначение Казначейства

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

Бюджет доходов и расходов (БДР)

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

Статьи бюджета

Дерево статей

Основой БДР является иерархический список статей бюджета, разделённый на два больших раздела - ДОХОДЫ и РАСХОДЫ.

Параметры статьи

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

• • Финансовый смысл статьи
    • Выручка
    • Себестоимость проданного
    • Списание
    • Инвентаризация
    • Расходы на капитализацию
  • Признак "Контролируемые / Неконтролируемые" затраты
  • Признак "Постоянные / Переменные" затраты.

По статьям бюджета рассчитываются расчётные показатели для отображения в БДР

 

С БДР можно работать в следующих режимах:

1. Во выбранным торговым ЦФО за один месяц - позволяет вводить план по каждому ЦФО на этот месяц
2. По одному ЦФО за год в разбивке по месяцам - тоже позволяет вводить план по ЦФО за каждый месяц
3. По выбранным (или всем) ЦФО за год в разбивке по месяцам - отображает и план и факт. Если вводить план на месяц в этом режиме, его нужно будет потом разделить по ЦФО в режиме №1.

Таким образом, БДР в основном планируется по ЦФО помесячно с агрегацией до года и группы точек.

 

Работа БДР с модулем ЗП.

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

Формирование БДР

Фактический БДР формируется программой автоматически по следующим документам:

• • Все приходные и расходные товарные документы - поступления, продажи, списания, инвентаризация и проч.
  • Ведомости начисления зарплаты
  • Бюджетные операции - финансовые операции:
    • типа "Доходы"
    • типа "Расходы" (налоги, комиссии и прочие расходы без товарной части)

 

Консолидированный бюджет

При формировании консолидированного бюджета должны быть исключены:

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

 

Связь статей бюджета с документами

У каждого документа в системе есть тип ("Приход от поставщика", "Продажа через кассу") и подтип - например "Приход СИМ", "Оприходование услуг", "Продажа через агрегаторов". Подтипы позволяют гибко разделить типовые операции на части. Чтобы документы данного подтипа отразились в БДР по нужной статье, эта статья прописывается в подтип документа:

В подтипах реализации можно указать до 3 статей БДР, поскольку по таким документам нужно учесть сразу три показателя - фактическую сумму, размер скидок и себестоимость:

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

Параметры подтипа документа:

• • Название подтипа
  • Префикс для нумерации документов
  • Статья БДР
  • Бухгалтерский счёт для ТМЦ
  • Параметры создаваемой фин.операции (для оплаты)
    • Тип фин.операции
    • Бюджет (плановый/фактический)
    • Место хранения денег
    • Какую сумму использовать
    • Статья ДДС

 

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

Если нужно, чтобы приход учитывался в БДР (например, принятие услуг), то в подтипе таких документов нужно проставить статью бюджета.

Расширенная привязка статей бюджета

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

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

В одном документе могут быть строки, которые нужно отнести к разным статьям бюджета.

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

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

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

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

Параметры строки настройки:

• • Строка настройки для Товарных документов
    • Тип товарного документа 
    • Статья БДР
    • Тип суммы для БДР
      • Фактическая
      • Розничная
      • Сумма скидки
      • Себестоимость
    • Группы контрагентов
    • Группы номенклатуры

 

• • Строка настройки для Ведомостей начислений зарплаты
    • Статья БДР
    • Тип суммы
      • Начислено
      • Штрафы
      • Поощрения
      • Инвентаризация
      • Накопления
    • Группы сотрудников

Для Финансовых операций типа "Доходы" и "Расходы"

статья БДР указывается в самой фин.операции, куда попадает:

• • Из договора
  • Из заявки на покупку
  • Из подтипа документа
  • Указывается вручную

Работа с БДР

 

Помимо вводимых статей, в БДР отображаются и расчётные показатели:

 

Работа с БДР состоит из следующих шагов:

1. Планирование
   • Выполнятся в интерфейсе БДР путём внесения плановых значений по статьям бюджета для каждого ЦФО на месяц.
2. Сбор фактов
   • Происходит автоматически, по мере появления с системе соответствующих документов.
3. Бюджетный контроль
   
   • Осуществляется на этапе утверждения Казначеем заявок на покупку.
4. Анализ исполнения бюджета
   • В БДР можно отобразить колонки План, Факт, Процент выполнения, Процент от выручки.

 

Планирование БДР

Планирование осуществляется путём заполнения колонки "План" по точке, статье и месяцу.

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

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

Алгоритмы расчёта плановых показателей БДР на следующий месяц

• • Как среднее за последние N месяцев - задаётся в настройках статьи бюджета
  • От предыдущего года с коэфф по пред.месяцу - задаётся в настройках статьи бюджета
  • По договорам - создаются документы на год вперёд для отражения в БДР 

Контролируемые и неконтролируемые статьи бюджета

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

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

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

Например:

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

Распределение статей между этими категориями определяется политикой организации.

Печать БДР

Можно сохранить БДР в виде сводной таблицы Excel для последующего анализа - за выбранный год по выбранным ЦФО

Бюджет движения денежных средств (БДДС)

Бюджет движения денежных средств (БДДС) — финансовый документ, содержащий план всех поступлений и платежей.

Задачи, решаемые с помощью БДДС:

• • Прогноз наличия денежных средств в нужном объёме на нужную дату
  • Недопущение кассовых разрывов через планирование и распределение сумм и сроков оплат
  • Понимание объёма свободных денег в компании

Планирование БДР

Планирование осуществляется путём заполнения колонки "План" по месту хранения денег и месяцу.

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

Алгоритмы расчёта плановых показателей БДДС на следующий месяц

• • Как среднее за последние N месяцев - задаётся в настройках статьи бюджета
  • От предыдущего года с коэфф по пред.месяцу - задаётся в настройках статьи бюджета
  • По договорам - создаются документы на год вперёд для отражения в БДР 

 

Статьи БДДС

Для БДДС ведётся своё дерево статей, отличное от статей БДР, а статьи имеют иные параметры.

• • Бухгалтерский Счёт.Субсчёт - используется для обмена операциями с 1С
  • Раздел ДДС
    • Операционная деятельность
    • Инвестиционная деятельность
    • Финансовая деятельность
  • Не отображать в кассовом отчёте за день, Наименование в кассовом отчёте за день - система ЮПИТЕР позволяет торговым точкам отражать в программе определённые финансовые операции (оплаты, выдачу з/п, экстренные закупки и проч.). Эти операции делаются по определённым шаблонам и отражаются в итоговом отчёте по точке.
  • Вид оплаты для кассового отчёта за день - можно указать, если расход по этой статье связан с конкретным видом денег - наличными, кредитными картами и проч.
  • Ограничение на право доступа к этой статье - есть такие статьи, которые всем видеть не надо.
  • Учитывать в зарплате - такой расход денег будут учтён в зарплатной ведомости как сумма выданная сотруднику в счёт зарплаты.
  • Шаблон для печати - можно задать шаблон печатной формы, которая будет печататься по таким операциям (ПКО, РКО и т.д.)

Формирование БДДС

Факт БДДС формируется программой автоматически по следующим документам:

• • "Приход денег"
  • "Расход денег"

Нужная статья ДДС указывается в этих документах.

Работа с БДДС

В программе БДДС объединён с календарным планом. Работа с БДДС ведётся по выбранному месту хранения денег за один месяц. Отображается входящий остаток, приход/расход по статьям ДДС и исходящий остаток на месяц и на каждый день.

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

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

Печать БДДС

Можно сохранить БДДС за произвольный период по выбранным ЦФО в виде сводной таблицы Excel для последующего анализа:

Для формирования БДДС выбираем торговые точки

Балансировка платежного календаря

В БДДС попадают все финансовые операции по выбранному месту хранения, связанные с движением денег. Это "Приход денег", "Расход денег", "Перемещение денег" (расход/приход). Эти операции в свою очередь могут относиться к плановому или фактическому бюджетам. 

• • Операции, относящиеся к плановому бюджету, считаются плановыми, не утверждёнными.
  • Относящиеся к фактическому - считаются утверждёнными. Если они ещё и проведены - то выполненными.

В ячейке статья-день отображается общая сумма операций по этой статье в этот день.

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

• • Тип операции
  • Статьи БДР и ДДС
  • Контрагент
  • Сумма
  • Бюджет (план/факт)
  • Проведена ли
  • Все статусы

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

Закупка

Некоторые закупки делаются строго по договору. Некоторые - без договора. Некоторые - даже без заявки на покупку.

Ниже мы рассмотрим все варианты.

 

Ведение договоров на покупку

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

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

 

Фиксированный договор

• • Определяет жёсткие условия - что и когда мы должны получить и сколько и когда мы должны заплатить. 
  • Периодичность: Разовый, Месяц, Год.
  • Расписание приходов - отражает что и когда мы должны получать по этому договору.
  • Расписание платежей - отражает сколько и когда мы должны оплачивать по этому договору

Расписание приходов

• • Это строковая часть, в которой как правило только одна строка (потому что как правило, мы приходуем что-то одно один раз за период). Например, аренда. Но можно завести и несколько строк. Поля строки:
    • Ссылка на документ-шаблон прихода.
      • Это документы типа "Шаблон прихода от поставщика" или "Шаблон расхода", которые полностью наследуются соответственно от "Прихода от поставщика" и документа "Расходы".
      • На основании документа-шаблона будут создаваться приходные документы.
    • Указание дат создания прихода:
      • Либо явно указанный перечень дат
      • Либо алгоритм, например "ежемесячно - 5 числа", "ежемесячно - последний день месяца" и т.п.

Расписание платежей

• • Это строковая часть, в которой как правило только одна строка (потому что как правило, мы оплачиваем один раз за период). Поля строки:
  • Ссылка на документ-шаблон оплаты.
    • Это документы типа "Шаблон расхода денег", который полностью наследуется от документа типа "Расход денег".
    • На основании документа-шаблона будут создаваться заявки на оплату.
    • В поле "комментарий" прописываются условия, которые должны быть выполнены для оплаты и другие примечания для того, кто будет платить.
  • Указание дат создания заявок на оплату:
    • Либо явно указанный перечень дат
    • Либо алгоритм, например "ежемесячно - 5 числа", "ежемесячно - последний день месяца" и т.п.

Схема работы по фиксированному договору:

1. При утверждении фиксированного договора создаются (автоматически, до конца года):
   1. На основании шаблона прихода - документы "Приход от поставщика" или "Расходы"
      1. Создаются датой из расписания прихода
      2. Создаются сразу проведёнными ("Расходы" сразу отображаются в БДР в соответствующем периоде)
      3. Признак "Принят" = "Нет", т.е. мы видим, что товар/услуга пока не приняты.
      4. Признак "Документы в порядке"="Нет" - т.е. бухгалтерия будет должна подтвердить, что первичные документы получены и оформлены правильно.
   2. На основании шаблона оплаты создаются Заявки на оплату (проведённый "Расход денег" по плановому бюджету)
      1. В них будут текстом указаны условия оплаты
      2. В заявки на оплату наследуются признаки "Принят" и "Документы в порядке" из приходного документа. Т.е. пока бухгалтерия не подтвердит правильность оформления первички по приходу (накладные, акты и проч), - казначей будет видеть, что оплачивать ещё рано. Если, конечно, это не предоплата.
2. Чтобы создать документы по фиксированным договорам на следующий год, нужно запустить процедуру "Создать документы по фиксированным договорам".

Рамочный договор (покупка сырья и материалов и т.п)

• • Рамочный договор означает наличие отношений с поставщиком. В зависимости от типа отношений, существуют следующие типы рамочных договоров:
    • Договора поставки сырья и материалов
      • Прайс-лист обязательно есть.
      • По такому договору поставщик поставляет сырьё и материалы. Работа по таким договорам происходит по алгоритму "Заказы поставщикам" (см. документ "Бизнес-процесс "Заказы поставщикам""). В БДР такие закупки как правило не попадают, т.к. себестоимость СИМ учитывается при списании, а не при приходе. 
    • Договор с товарной частью
      • Прайс-листа может не быть.
      • По такому договору можно закупить что-то, не обязательно указанное в прайс-листе поставщика. Прайс-листа может не быть вовсе. Например, закупка в ЛеруаМерлен. Но это что-то мы будем приходовать как ТМЦ или как услуги. Как правило, такие приходы тоже не попадают в БДР, поскольку мы не понести расхода. Расход будет когда мы спишем то, что купили.
      • Если статья БДР в договоре имеет признак "Контролируемый расход", то приход возможен только по заявке на покупку. Иначе можно заводить приход от поставщика по этому договору без всякой заявки. Например, если нам разрешено покупать канцтовары в пределах лимита.
    • Договор без товарной части
      • Прайс-листа нет.
      • Используется тогда, когда нам не нужно приходовать то, что мы купили, а нужно сразу отразить расход. Например, мы покупаем канцтовары в рамках ежемесячного лимита. Нет смысла их покупать, приходовать, потом списывать. Вместо этого мы сразу создаём по этому договору документ типа "Расходы", с нужной статьёй БДР и комментарием.
      • Если статья БДР в договоре имеет признак "Контролируемый расход", то создание документа "Расходы" возможно только по заявке на покупку. Иначе можно заводить "Расходы" по этому договору без всякой заявки. 

 

Закупки без договора

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

В системе должна быть возможность установить ограничение, что без договора по каждому поставщику может быть заявок не более чем на определённую сумму в месяц за весь период работы с этим поставщиком. Лимит задаётся в статье БДР.

Схема закупки без договора:

1. Заказ поставщику делается минуя программу.
2. По итогам приёмки товаров/услуг в ручную создаётся "Приход от поставщика" с признаком "Документы не в порядке" - бухгалтерия должна будет проверить документы и этот признак снять.
3. При проведении такого документа программа предложит указать ожидаемую дату оплаты и автоматически создаст заявку на оплату (проведённый документ типа "Расход денег" по плановому бюджету). Признак "Документы в порядке" в нём наследуется от приходной накладной - т.о. в реестре платежей будет видно, можно ли оплачивать этот приход.

 

Реквизиты договора на покупку

• Тип договора
  • Фиксированный договор
  • Рамочный договор на поставку сырья и материалов
  • Рамочный договор с товарной частью
  • Рамочный договор без товарной части
• Основные параметры
  • Контрагент
  • Номер договора
  • Предмет договора (суть) договора (краткий текст)
  • Лимит по договору (сумма всех закупок/платежей по договору не может превышать этот лимит)
  • Даты
    • Дата заключения договора;
    • Дата начала действия договора;
    • Дата окончания действия договора;
• Бюджетные параметры
  • Статья БДР
  • Статья ДДС
• Сканы документов (прикрепляем pdf, картинки) - это делает инициатор
• Параметры Фиксированного договора
  • Сумма договора
  • Периодичность
  • Условие выполнения платежей
  • Расписание приходов
  • Расписание платежей
• Параметры рамочного договора
  • Отсрочка платежа (дней)

 

Реквизиты прайс-листа поставщика

• • Поставщик
  • Ссылка на договор
  • Дата начала действия
  • Товарная часть
    • ТМЦ
    • Цена
    • Упаковка для заказа

 

Дополнительные соглашения

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

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

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

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

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

Родительский договор заканчивается, когда заканчивается последнее доп. соглашение (либо сам договор).

 

Жизненный цикл и статусы договора:

1. Создание договора
   1. "Создан" - создан Инициатором.
   2. "Подтверждён" - руководителем профильного отдела, либо ЦФО.
2. Проверка
   1. "Финконтроль" - Утверждён финансовым контролером (целесообразность, рыночной конъюнктуры).
   2. "Бухгалтерия" - Утверждён бухгалтером (правильность оформления документов).
3. Подписание
   1. "Юрист" - Утверждён юристом (минимизация рисков для компании)..
   2. "СЕО" - Согласован с CEO.
   3. "Подписан" - Подписан гендиректором.
4. Завершение договора.
   1. Договор автоматически прекращается по окончании срока его действия.

 

Для смены статуса нужно встать на договор, и нажать слева кнопку "Статус".

Откроется окошко, где можно будет выбрать статус.

Статусы, которые пользователь может выставлять задаются в статье БДР, где для каждого статуса должно быть указано, какой конкретно сотрудник может для этой статьи этот статус выставлять. Эти параметры наследуются по дереву статей. Если для какого-то статуса сотрудник не указан, то берётся сотрудник из родительской статьи. 

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

Ведение заявок на покупку

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

Для фиксированных договоров заявки на покупку не ведутся, т.к. для таких договоров всё уже согласовано самим договором.

 

Заявка на покупку обладает следующими свойствами:

• • Смысл документа "Заявка на закупку" - прохождение цепочки согласований и получение разрешения осуществить закупку .

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

• • Если заявка по договору с товарной частью
    • То у неё обязательно должна быть Товарная часть, в которой перечислено, что именно мы приобретаем - какой товар, какую услугу.
    • Товарная часть в идеале должна выбираться из текущего прайс-листа по договору. Но может вводиться вручную.
    • Цена закупки может меняться вручную.
  • Если заявка по договору без товарной части
    • То у заявки тоже нет товарной части. Описание того, что приобретаем берём из текстового поля "Предмет покупки".
  • Финансовая часть - как и когда мы это хотим оплатить в заявке отсутствует:
    • Период отсрочки берётся из договора.
    • Если заявка без договора, то желаемая дата оплаты указывается в самой заявке. Если по заявке  без договора предполагается несколько оплат, то создаются несколько заявок на оплату не нужные даты.

 

Параметры документа "Заявка на покупку"

• Ссылка на договор
  • Если ссылка на договор не заполнена, то предполагается разовая закупка без договора
  • Тип договора
    • Заполняется автоматически из типа договора, менять нельзя
• Предмет покупки
  • это текст
  • заполняется из поля “Предмет договора”
  • если нет договора, то заполняется вручную
  • при необходимости может корректироваться 
• Даты
  • Дата создания заявки (заполняется автоматически)
  • Планируемая дата поступления (оприходования)
  • Желаемая дата оплаты (Когда Инициатору нужно, чтобы было оплачено, если указан договор, то подставляется из договора по отсрочке, может меняться)
  • На какую дату запланировано к оплате (информационное поле - проставляется при изменении даты заявки на оплату, вручную не меняется)
  • Когда оплачено (проставляется автоматически, вручную не меняется)
• Сканы документов
  • Прикрепляются сканы первичных документов по этой заявке
• Сумма закупки
  • Это жёстко сумма товарной части (если она есть), если нет, то вводится вручную
  • Нужна проверка, что эта сумма не приводит к превышению лимита договора (с учётом доп. соглашений). Проверка работает, только если в договоре явно указан лимит (даже если 0). 
  • Суммы НДС (в разбивке по ставкам НДС)
• История смены статусов с комментариями
• Реквизиты
  • ЮЛ - заявитель
  • ЦФО (торговая точка)
  • Инициатор
  • Контрагент (поставщик)
• Казначейство
  • Статья БДР (берётся из договора, если нет, то проставляется вручную)
  • Статья ДДС (берётся из договора, если нет, то проставляется вручную)
  • Признак “Платёж сверх бюджета” 
    • Автоматически проставляется при создании заявки, если она приводит к превышению бюджета месяца. Признак может быть снят казначеем, если он решит учесть эти траты в бюджете следующих периодов.

 

Статусы заявки на покупку

1. 1. Создана (создана Инициатором или программой, если по договору)
      • • При создании заявки Инициатор должен её провести. При этом происходит следующее:
          • Статус заявки - "Создана"
          • По заявке сразу создаётся проведённый приходный документ, с признаками "Не принят", "Документы не в порядке" - чтобы было видно, что мы ждём этого прихода и чтобы приход отобразился в БДР.  Сразу отображаем как факт БДР - до окончательных согласований (проверяем, что попадаем в бюджет БДР).
          • Сразу создаём заявку на оплату и отображаем в платежном календаре - до окончательных согласований (при этом в календаре видно, попадаем ли мы в план ДДС)
   2. Утверждена руководителем профильного отдела.
   3. Проверка первичных документов - акты, счета.. (бухгалтерия).
   4. Операционный директор.
   5. Казначей (бюджетный контроль - БДР и БДДС)

   6. Оплачена частично

   7. Оплачена

 

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

Бюджетный контроль (БДР)

• • По закупкам, требующим согласования:
    • Бюджетный контроль осуществляет Казначей, который утверждает каждую такую заявку.
    • При этом Казначей может утвердить заявку, превышающую план, если он это согласовал с руководством, или если эта заявка относится не к одному периоду, а к нескольким.
  • По закупкам, не требующим согласования:
    • Бюджетный контроль осуществляет программа, запрещая проведение документов, которые приводят к превышению факта над планом БДР по данной статье. При этом программа выдаёт соотвествующее сообщение.
    • Решить вопрос можно тремя путями:
      • Отложить закупку на следующий месяц
      • Увеличить план по этой статье бюджета (особые права)
      • Преодолеть ограничение и превысить лимит (особые права)

 

Поступления

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

Если надо что-то приходовать - то "Приход от поставщика".

Если это чистый расход (услуга, канцтовары и проч.), то документом типа "Расходы". 

Оба этих документа имеют свойства:

• • Статус "Принят" - признак ставит ответственный за приёмку
  • Статус "Документы в порядке" - признак ставит бухгалтер
  • Сумма
  • Сумма НДС (по ставкам)
  • Предполагаемая дата оплаты
  • Статья БДР
  • Статья ДДС

Кредиторская задолженность

По документам поступления программа ведёт задолженность. Которая гасится при проведении оплаты.

Ведение заявок на оплату

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

• Это финансовая операция типа “Расход денег”, но по плановому бюджету
• Финансовая операция типа “Расход денег”, создаётся сразу же при создании заявки на покупку (создаётся по плановому бюджету) и сразу отображается в календарном плане желаемой датой оплаты.
• При необходимости, эта операция может быть путём копирования разделена на две или более частей и разнесена по нужным датам.
• Оплаты могут передвигаться и ставиться на конкретную, которую определяет казначей.
• Оплаты согласовываются через утверждение "Реестра платежей".
• После утверждения заявки считаются проведёнными и выгружаются для оплаты в клиент-банк.
• При загрузке выписки проверяем, что все оплаты прошли.

Жизненный цикл заявки на оплату:

• • Создание (автоматически или вручную)
    • После создания заявка на оплату стазу отражается в БДДС и платёжном календаре - как план.
  • Возможное разделение заявки на оплату на несколько частей
  • Подтверждение (при утверждении реестра платежей)
  • Оплата (передача на оплату в клиент-банк или в 1С - превращается в "Расход денег" по фактическому бюджету)
  • Подтверждение оплаты (приходит из клиент-банка, или из 1С)

 

Признаки заявки на оплату:

• • "Принят" - наследуется от приходного документа, отражает приняты ли товары/услуги или ещё нет.
  • "Документы в порядке" - наследуется от приходного документа, отражает в порядке ли все документы.
  • "Оплатить" - проставляется при утверждении Реестра платежей.
  • "Оплачено" - проставляется при обработке банковской выписки

 

Бюджетный контроль (БДДС)

БДДС на месяц совмещён с календарным планом на месяц и отображает как итоги за месяц, так и данные по дням.

Плановые цифры по статьям ДДС указываются на месяц. Рядом показываются фактические значения - в т.ч. с учётом ещё не выполненных заявок на оплату.

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

Бюджетный контроль состоит в следующем:

• • Контроль за соблюдением плана расхода по статьям БДДС за месяц.
  • Контроль за отсутствием кассовых разрывов.

 

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

Руководитель утверждает "Реестр платежей":

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

Исполнение платежей

Заявки в статусе "Оплатить" выгружаются в 1С или в клиент-банк, где оплачиваются.

Разнесение банковской выписки

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

 

Авансовые отчёты

Основные направления покупок через авансовые отчёты:

• • Командировочные расходы
  • Офисные расходы
    • Административные расходы
    • Почтовые расходы - их много
    • Канцтовары
    • Хозяйственные
  • Операционные (экстренные)
  • Сырьё

 

Реализация в программе:

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

•  

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

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

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

Логика работы программы такова, что если после проведения авансового отчёта остаток на сотруднике отрицательный (т.е. имел место перерасход), то программа автоматически создаёт заявку на закрытие этого минуса, запрашивая только дату и источник денег.

При этом создаётся заявка на оплату (точнее, заявка на перемещение) - документ "Перемещение денег" по плановому бюджету. Такая заявка будет отображена в БДДС и в календарном плане выплат. Эти заявки  утверждаются так же, через реестр платежей и исполняются через 1С.

Способы выдачи под отчёт:

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

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

Покупки по авансовым отчётам за наличный расчёт и по вариантам 2 и 3 оформляются единообразно.

 

Статьи БДР и ДДС для создаваемых по авансовым отчётам документам берутся стандартно:

• • Если закупка была по заявке - то из заявки.
  • Если без заявки - то из документа покупки ("Приход от поставщика" или "Расходы").

 

Особенности оформления в различных ситуациях:

• • Командировочные расходы
    • Это расходы, понесённые по факту, без заявок на покупку.
    • Расходы оформляются документами типа "Расходы", в котором и указываются статьи БДР и ДДС .
    • Авансовые отчёты делаются на командированного.
    • Заявка на выдачу под отчёт формируется либо вручную (до командировки), либо автоматом при закрытии авансового отчёта.
  • Офисные расходы
    • Это, как правило, закупки по неконтролируемым статьям в рамках выделенного месячного лимита - без заявок на покупку.
    • Статьи БДР и ДДС указываются в создаваемых документах ("Приход от поставщика", "Расходы")

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

      • Авансовые отчёты делаются по тому сотруднику, на чьё имя выдана корпоративная карта.
      • Выдача денег под отчёт не оформляется, т.к. карта привязана к р/с.

• • Покупка сырья (через авансовый отчёт - всегда через заявку на покупку)
    
    • Оплата с корпоративной карты закупщика
      • Момент выдачи под отчёт - это момент списания денег с карты.
      • Авансовые отчёты делаются по этой карте (по сотруднику, кому она выдана).
      • Выдача денег под отчёт не оформляется, т.к. карта привязана к р/с.
    • Оплата с личной карты территориального управляющего.
      • Деньги на личную карту переводятся под конкретную утверждённую заявку на закупку (в этом случае это и есть заявка на оплату - перевести деньги). Этот перевод и есть выдача денег под отчёт.
      • Заявка на выдачу под отчёт формируется либо вручную (авансом), либо автоматом при закрытии авансового отчёта.
  • Операционные (экстренные расходы)
    • Всегда выполняются через заявку на покупку, которая утверждается операционным директором.
    • В остальном механизм такой же, как описан выше для закупки сырья.

 

Продажа сторонним контрагентам

Ведение договоров на продажу

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

• • Указываются приходные статьи БДР и ДДС
  • Вместо прайс-листа поставщика с договором связан прайс-лист для покупателя.
  • Формируемые документы - это "Продажа по накладной" (если есть товарная часть) или "Доходы" (если нет товарной части)
  • Движение денег оформляется документами "Приход денег". 
  • Вместо заявок на покупку используются заказы покупателей.

Дополнительные соглашения

К договорам продажи могут быть доп. соглашения - в полной аналогии с договорами на покупку.

Заказы покупателей

Вместо заявок на покупку используются заказы покупателей.

Заказом покупателя является неакцептованная расходная накладная. В её строках есть поля "Заказанное количество" (заполняется при создании заявки) и "Отгруженное количество".

Работа с заказами покупателей описана в документе: Бизнес-процесс "Работа по заказам сторонних покупателей (юр.лиц)".

Счета

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

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

В счёте также указывается подтип документа, который определяет статьи БДР и ДДС.

 

• Счёт с товарной частью
  • При нажатии кнопки "Отгрузить" по такому счёту создаётся документ типа "Продажа по накладной", в которую автоматически попадают ещё не отгруженные количества. По одному счёту может быть несколько отгрузок, пока всё не будет отгружено.
  • Задолженность по оплате возникает по счёту, оплата принимается тоже по счёту и закрывает эту задолженность. По одному счёту может быть несколько оплат - пока счёт не будет оплачен полностью.
  • Есть две сверки - "счета - оплаты" и "отгрузки - оплаты". Отгрузки с оплатами жёстко не связаны, сравнивается общая сумма отгрузок и оплат.
• Счёт без товарной части
  • Варианты
    • Разовый счёт за услуги - услуги указываются текстом в назначении платежа.
      • Назначение платежа копируется в документ "Приход денег".
      • При нажатии кнопки "Отгрузить" по такому счёту создаётся документа типа "Доходы", который и попадает в БДР.
    • Счёт, выставляемый постфактум за одну или несколько отгрузок (общей суммой)
  • Задолженность по оплате возникает по счёту, оплата принимается тоже по счёту и закрывает эту задолженность. По одному счёту может быть несколько оплат - пока счёт не будет оплачен полностью.
  • Используется сверка - "счета - оплаты".

 

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

Отгрузки

Отгрузки - это документы типа "Продажа по накладной". Могут формироваться на основании счёта или самостоятельно.

Подтип документа определяет статьи БДР и ДДС, а также будет ли отгрузка оплачиваться напрямую, или через выставление счёта.

Поступление оплаты

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

Дебиторская задолженность 

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

Есть две сверки - "счета - оплаты" и "отгрузки - оплаты". 

Также есть обычная сверка по контрагенту, которая показывает состояние взаиморасчётов с этим контрагентом.

И оборотка по контрагентам, которая показывает общее состояние взаиморасчётов по всем контрагентам.

 

Розничная торговля

Розничные продажи

Кассовые чеки в программе объединяются в документы типа "Рабочий день". Для корректного отнесения выручки после полуночи на нужную дату.

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

На основании продаж программа ежедневно формирует следующие документы:

• • "Продажа через кассу". При этом программа автоматически формирует несколько таких документов с разными подтипами, согласно подтипам, указанным в видах оплат. И по разным складам, если списания каких-то подгрупп следует сделать с других складов.
  • "Списание" - формируется несколько документов списания, согласно причинам списания, указанным кассиром.
  • "Приход денег" - формируется по одному такому документу за день по каждому виду оплат. Документы формируются сразу проведёнными, по фактическому бюджету и отражаются в БДДС как свершившийся факт. Деньги поступают в кассу торговой точки.

 

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

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

​Кассовые операции

Кассы точек

На каждой точке есть своя офисная касса, куда кассиры ежедневно сдают деньги по Z-отчёту.

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

Наличные

Инкассация​​​​​

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

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

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

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

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

Если из кассы точки запрещены все траты, то сумма сдаваемых денег будет равна сумме наличных согласно Z-отчёта. В таком случае при создании документа "Перемещение денег" программа должна запросить фото Z-отчёта и приложить его к создаваемому документу.

В завершении программа должна печатать формы (КО-4 и КО-5).

​

Кредитные карты

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

При этом создаётся документ типа "Приход денег" с параметрами, заданными в виде оплаты. 

Как правило, приход осуществляется сразу на р/с, минуя 57 счёт, т.к. проблем с зачислением нет. При загрузке банковской выписки программа в любом случае выполнит проверку и сообщит, если что-то не поступило. Считаем, что это крайний случай.

При необходимости, можно настроить работу и через 57 счёт.

Агрегаторы

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

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

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

 

Как должно быть реализовано в программе:

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

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

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

Если такой чек возвращается в работу, эта скидка автоматически удаляется и сумма чека восстанавливается как была до комиссии.

Оприходование выручки:

При закрытии рабочего дня для каждого агрегатора создаётся "Приход денег" по месту хранения этого агрегатора, указанном в настройке вида оплат. Это место хранения - аналог 57 счёта - "деньги в пути". Остаток денег на этом счёте - сколько нам должен агрегатор.

При загрузке выписки банка, по приходу денег от агрегатора создаётся не приход денег, а документ перемещения со счёта "деньги в пути" этого агрегатора на р/с организации. 

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

 

НДС при розничных продажах

Продаваемые товары могут иметь разные ставки НДС. Ставки и суммы НДС должны отражаться в кассовых чеках.

При работе по УСН это не нужно.

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

 

Интернет-магазин (сайт, приложения)

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

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

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

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

 

ОС и амортизация

• Приход ОС - оформляется в Юпитере документом "Приход поставщика" с ТМЦ типа "Основное средство", передаётся в 1С.
• Ввод ОС в эксплуатацию - выполняется только в 1С, в Юпитер не передаётся.
• Амортизация ОС - рассчитывается в 1С, в Юпитер передаются новые цены ОС.
• Перемещение ОС между подразделениями в Юпитере и 1С синхронизируется вручную. Поскольку может быть неудобно оформлять в 1С физическое перемещение ОС между складами и между юрлицами. 

 

Амортизация

ОС приходуются как обычно, можно в составе смешанной накладной.

Списываются и перемещаются ОС тоже как обычно, вообще всё товародвижение ничем не отличается от обычных товаров. Используются те же документы и отчёты.

Для этого:

• • Создаётся новый тип расходного документа "Амортизация расход". Указывается подразделение и дата. Содержимое не заполняется.
    • При акцепте документа
      • Удаляются все строки, если они есть, удаляется связанный документ, если есть
      • В строки документа загружаются все партии ОС, числящиеся на этом подразделении в количестве, равном остатку на дату документа. Эти партии при акцепте списываются в указанном количестве, т.е. в ноль.
      • Для каждой строки рассчитывается новая закупочная и учётная цена (от текущей цены отнимается доля, равная 1/<кол-во месяцев использования>), рассчитанные цены прописываются в строку и отображаются потом в списке строк.
      • Автоматически создаётся приходный документ "Амортизация приход"
        • Каждая строка расходного документа копируется в приходный, в качестве цены прихода берётся новая цена, количество берётся из исходной строки.
          • При акцепте строки создаётся новая партия ОС, в которую в комментарий  к партии прописывается та партия, на замену которой она создана.
        • У приходного документа нет сумм.
    • В сумму закупочную и учётную документа записывается разница между старой и новой ценой.

Таким образом, этот документ списывает все ОС по старой цене и приходует уже по новой.

При деакцепте этого документа:

• • Связанный приходный документ удаляется
  • Строки документа удаляются

 

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

• • Создаётся новый расходный документ "Амортизация расход". Подразделение и дата берутся из файла выгрузки.
  • Содержимое документа заполняется на основании файла из 1С - с новыми ценами.
  • При акцепте документа
    • Все существующие партии перечисленных ОС списываются по старой цене.
    • Автоматически создаётся приходный документ "Амортизация приход"
      • Каждая строка расходного документа копируется в приходный, в качестве цены прихода берётся новая цена, количество берётся из исходной строки.
        • При акцепте строки создаётся новая партия ОС, в которую в комментарий  к партии прописывается та партия, на замену которой она создана.
        • У приходного документа нет сумм.
    • В сумму закупочную и учётную документа записывается разница между старой и новой ценой.

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

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

 

Учёт РБП

Описанный выше механизм равномерного помесячного списания стоимости может быть применён не только к ОС, но и к РБП.

Если же учёт РБП ведётся в 1С, то при получении из 1С документа о списании РБП, мы создаём документ типа "Расходы" с соответствующим текстом и статьёй бюджета. И этот документ попадает в БДР.

Учет спецодежды и МБП

Необходимые операции:

1. Оприходование
2. Выдача в использование
3. Списание

Реализация:

МБП отражаются в программе через ТМЦ типа "материал".

Приход оформляется обычным образом, через "Приход от поставщика" на специальный "Склад МБП".

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

Списание МБП производится документом "Списание" с указанием нужной причины.

Учёт топлива

Схема работы:

• • Заключаем рамочный договор с топливной компанией (ТК)
  • На счёт ТК вносится аванс
  • У каждого водителя есть карта, привязанная к этому лицевому счёта.
  • Когда водитель расплачивается на АЗС этой картой, ТК фиксирует, по какой карте какое топливо было куплено.
  • В конце месяца от ТК приходит одна приходная накладная (содержит все виды топлива).
  • Расход топлива - делается путём вычислений на основании паспортного расхода топлива а/м и пробега за отчётный период (месяц). Путевые листы оформляются в последний день месяца На каждую а/м делается отдельная накладная на списание.
  • В 1С передаём документом списания без указания а/м

 

Учёт топлива

• • Если ТК предоставляет данные в разрезе а/м (или топливных карт), то номенклатура заводится следующим образом: "Бензин 95 <госномер а/м> <номер топливной карты> ". Таким образом можно отслеживать остатки топлива по каждой а/м отдельно. Тип ТМЦ - "Материал".
  • Если ТК предоставляет данные только в разрезе видов топлива, то номенклатура заводится как "Бензин 95" и ведётся скопом для всех а/м его использующих.
  • Оприходование - осуществляется стандартно, документом "Приход от поставщика" на основании накладных и с/ф, выставляемых транспортной компанией (обычно одна накладная за месяц).
  • Расход топлива оформляется документом на списание с подтипом "Нормативный расход топлива". На каждый а/м оформяется отдельный документ. В комментарии к документу указывается:
    • номер карты
    • марка а/м
    • пробег на начало месяца
    • пробег на конец месяца
    • пробег за месяц
    • нормативный расход топлива л/100 км на основании распоряжения "N АМ-23-р от 14 марта 2008 г."
    • расчётный расход топлива

В строках документа указывается одна строка, содержащая:

• • • • Вид топлива (если есть данные по а/м - то выбирается номенклатура для этой а/м)
      • Расчётный расход топлива
  • Для простоты заполнения можно скопировать предыдущий документ и внести нужные корректировки.
  • В случае, если остаток вида топлива на конец месяца превышает возможный остаток топлива в баках всех а/м его использующих, производится сверхнормативное списание, которое оформляется аналогично, документом списания, но по отдельному подтипу "Сверхнормативное списание топлива".
  • Списание топлива производится методом FIFO.
  • Документы прихода и списания топлива передаются в 1С..

 

Учёт топливных карт

Сами по себе топливные карты (пластик) тоже подлежат учёту, т.к. заказываются у ТК, обладают стоимостью и нам нужно знать, у кого какая карта. Учёт топливных карт осуществляется по схеме "Учет спецодежды и МБП".
Название номенклатуры топливной карты выглядит так: "ТК №... а/м №... выдана Иванову И.И." - чтобы было проще с ними работать. Тип ТМЦ - "Материал".

Учёт запчастей и прочих материалов

Запчасти и материалы могут находиться в организации в двух состояниях - на складе и использованы. В момент начала использования они списываются. Поэтому:

• • Приход - оформляется документом "Приход от поставщика"
  • Списание - оформляется документом "Списание" 

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

Учёт приобретаемых услуг

Приобретаемые услуги могут отражаться:

• • Документом "Приход от поставщика" - в этом случае в документе создаётся строка с ТМЦ типа "Услуга".
  • Документом "Расходы" - описание приобретаемой услуги отражается в комментарии к документом.

В обоих случаях должно быть настроено, чтобы полученные услуги в момент получения сразу отражались в БДР как понесённый расход,
В БДДС они отразятся при создании связанной финансовой операции типа "Расход денег".

Учёт предоставляемых услуг

Предоставляемые услуги могут отражаться:

• • Документом "Продажа по накладной" - в этом случае в документе создаётся строка с ТМЦ типа "Услуга".
  • Документом "Доходы" - описание предоставленной услуги отражается в комментарии к документом.

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

В БДДС они отразятся при создании связанной финансовой операции типа "Приход денег".

Обжарка кофе

Схема работы:

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

 

По БДР себестоимость сырья учитывается в момент его списания.

Так и с кофе - его полная себестоимость будет отражена в БДР при продаже. Ни суммы закупки, ни стоимости обжарки в БДР не будет.

То, что мы это кофе так сложно обжариваем (а не покупаем сразу обжаренным) - это просто особенности технологического процесса.

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

 

Отражение в программе:

• • Приход - обычным документом "Приход от поставщика", как все остальные ингредиенты приходуем "Кофе не обжаренный".
  • Передача на обжарку - документом "Продажа по накладной" с подтипом "Кофе на обжарку" передаём "Кофе не обжаренный".
    • Отпускная цена - 0.
    • Себестоимость считается по FIFO.
    • При этом остаток "Кофе не обжаренный" на складе становится 0 (если весь передали).
  • Приём с обжарки - документом "Приход от поставщика" с подтипом "Кофе с обжарки" приходуем "Кофе обжаренный"
    • Сумма прихода - сумма себестоимости из документа продажи складывается со стоимостью обжарки.
    • В итоге имеем на остатке "Кофе обжаренный" по полной себестоимости.

 

При загрузке в 1С на основании переданных подтипов создаются нужные бухгалтерские документы.

Зарплата

Обстоятельства:

• • Зарплата в целом ведётся в 1С ЗУП.
  • Зарплата состоит из оклада и премиальной части.
  • Премиальную часть нужно рассчитывать исходя из коммерческих показателей, про которые ЗУП ничего не знает. Сейчас премия рассчитывается в Excel и руками переносится в ЗУП.
  • Начисленную з/п нужно отражать по БДР, выданную - по БДДС.
  • В БДР з/п нужно делить по категориям сотрудников (АУП, линейный персонал, ... )
  • Нужно корректно рассчитывать з/п для сотрудников, которые числятся на одной точке, а какое-то время работают на другой.
  • Выдача з/п делается безналичным образом на карты сотрудников - в один день по одному юр.лицу. Нужно иметь это в плане, чтобы не забыть заплатить и расставлять платежи, чтобы критичные были проведены гарантированно.

Реализация

• • Сотрудники ведутся и в Юпитере, и в ЗУП. Синхронизация по ИНН.
  • В Юпитере ведётся:
    • учёт рабочего времени
    • расчёт % с продаж
    • штрафы и поощрения
    • распределение итогов инвентаризации
  • В итоге, в Юпитере формируется ведомость начислений, где для каждого сотрудника рассчитана сумма премии. Эта ведомость пока не попадает в БДР в Юпитере.
  • Эта ведомость передаётся в 1С ЗУП, где загружается как премиальная часть з/п.
  • Когда в ЗУП рассчитана з/п за месяц, ЗУП передаёт данные в 1С бухгалтерию о начисленной з/п - отдельно аванс и зарплата.
  • 1С бухгалтерия передаёт данные о начисленной з/п (отдельно аванс и зарплата) в Юпитер с указанием к какому месяцу относится з/п и планируемые даты выдачи аванса и з/п.
    • Юпитер создаёт документы типа "Расходы" на начисленную з/п (последним числом месяца)
    • Юпитер создаёт заявки на оплату на выдачу аванса и з/п датами, полученными из 1С.
      • При этом все иные заявки на выдачу з/п по этому месту хранения за этот месяц автоматически удаляются, как более не актуальные.
    • В Юпитере заявки на оплату ставятся в календарный план и после подтверждения Казначеем уходят в 1С, где совершают выплату по соответствующим платёжным ведомостям.