Руководство пользователя |
|
|
|
|
ТОМ 17. РАСЧЕТЫ С КОНТРАГЕНТАМИ |
|
|
|
Аннотация
В данном Томе описываются следующие разделы Торговой системы «Супермаг Плюс»:
Платежи – Бонусы от поставщиков.
Платежи – Акт о начислении бонусов.
Платежи – Финансовые обязательства по поставкам.
Платежи – Финансовые обязательства по отгрузкам.
Платежи – Сверка финансовых обязательств.
Платежи – Реестр платежей.
Платежи – Платежи.
Платежи – Получение платежей.
История изменений
Версия |
Дата |
Описание изменений |
Автор |
1.0 |
01.03.2017 |
Создание документа |
Васильева И.Е. |
2.0 |
11.04.2018 |
Переход к версии 1.036.1 |
Васильева И.Е. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Содержание
1 Введение
1.1 Наименование системы
1.2 Назначение документа
1.3 Сокращения
2 Введение в тему «Управление платежами».
2.1 Понятие «Финансового обязательства».
2.2 В чём заключается управление платежами?
3 Бонусы от поставщиков.
3.1 Общие положения.
3.2 Документ «Бонусы от поставщиков»
3.3 Акт о начислении бонуса
4 Управление платежами.
4.1 Общие положения.
4.2 Как реализовано управления обязательствами
4.3 Финансовые обязательства по поставкам
4.4 Финансовые обязательства по отгрузкам
5 Атрибуты и интерфейс раздела аналогичны разделу Финансовые обязательства по поставкам (см. п. 4.3), но интерпретация некоторых атрибутов иная. В частности, атрибуты отсрочка платежа и штраф, относятся к обязательствам контрагента перед торговой организацией. Контроль исполнения этих обязательств является пассивным. То же касается контроля полноты оплаты поставок товаров контрагентам. Формирование документов для регистрации поступления платежа осуществляется в разделе Получение платежей (см. п. 8 Платежи
5.1 Назначение раздела «Платеж»
5.2 Возможные проблемы синхронизации данных между ТС и бухгалтерской программой
5.3 Атрибуты документа «Платеж»
5.4 Статусы Платежей
5.5
5.1 Факторинг. Подмена контрагента в обязательстве по накладной.
6 Сверка финансовых обязательств
7 Реестр платежей
7.1 Назначение раздела «Реестр платежей».
7.2 Бизнес-процесс составления реестра платежей.
7.3 Создание реестра платежей
7.4 Редактирование суммы платежа
7.5 Работа с реестром нескольких пользователей одновременно
8 Платежи
8.1 Назначение раздела «Платеж»
8.2 Возможные проблемы синхронизации данных между ТС и бухгалтерской программой
8.3 Атрибуты документа «Платеж»
8.4 Статусы документа «Платеж»
8.5 Создание документа «Платеж»
8.6 Оплата документов
8.7 Виды операций
9 Получение платежей
9.1 Назначение раздела «Получение платежей»
9.2 Атрибуты документа «Получение платежей»
9.3 Статусы документа «Получение платежа»
9.4 Учет финансовых атрибутов контрактов
9.5 Создание документа «Получение платежей»
9.6 Регистрация продаж
9.7 Операции
ПРИЛОЖЕНИЕ А. УКАЗАТЕЛЬ РАЗДЕЛОВ СИСТЕМЫ и документов
Полное наименование Системы – Торговая система «Супермаг Плюс».
Сокращенное наименование Системы – «Супермаг».
Настоящий документ предназначен для сотрудников «Сервис Плюс»: аналитиков, инженеров техподдержки. А также для системных администраторов, инженеров и аналитиков клиента.
Аббревиатура |
Расшифровка |
МХ |
Место хранения |
ТС |
Торговая система |
В Торговой системе используется понятие Финансовое обязательство. Под финансовым обязательством понимается обязанность одного контрагента передать другому контрагенту денежные средства (или товары, услуги, работы или иные эквиваленты стоимости обязательства).
Финансовое обязательство возникает в результате передачи от одного контрагента другому товаров, денег или иных ценностей или по иным причинам, обусловленным событиями, оговоренными в договорах между контрагентами. Обратное действие, то есть передача ценностей в целях выполнения обязательства, является погашением обязательства.
В Торговой системе финансовое обязательство – это объект системы, имеющий определенное поведение.
Обязательство возникает при регистрации приходных или расходных накладных с операциями движения товара между внешними контрагентами и торговой организацией (юридическим лицом, индивидуальным предпринимателем). Кроме того, финансовое обязательство возникает при начислении бонуса поставщика (регистрация документов «Акт о начислении бонуса»). Также финансовое обязательство возникает в случае получения контрагентом полной или частичной предоплаты или аванса с счёт будущих поставок.
Для возникновения обязательства одна сторона (организация) должна реально получить (передать) некий актив (товар, работу, услугу, бонус) другой стороне и получить право на возмещение стоимости этого актива другой стороной обязательства.
Документ «Счет» не приводит к возникновению финансового обязательства, а служит основанием для получения платежа. Счет не регистрирует факта получения или передачи актива, поэтому не вызывает появления финансового обязательства.
Бизнес-цель, которую преследует процесс «управление платежами», заключается в том, чтобы обеспечить розничную торговлю товарами для продажи. Для этого платежи за поставленные товары должны вестись так, чтобы не мешать закупкам товаров. С другой стороны, они должны быть максимально рациональными, чтобы использовать денежные средства поставщиков максимально возможное время, предусмотренное договором поставки.
В большой розничной сети ежедневно выполняется сотни и тысячи платежей за один банковский сеанс. Для этого нужно иметь ежедневно актуальное состояние расчётов с поставщиками, своевременно сформировать оптимальный список платежей на банковские день (на сегодня), технически оформит сотни и тысячи платёжных документов и передать их в банк. При этом следует учитывать, что расчёты ведутся в условиях ограниченного бюджета и выполнить их нужно так, чтобы не остановить поставки товара не просрочку или неуплату.
Функционал системы предназначен для решения названных задач.
Учёт расчётов с поставщиками и покупателями торговая система не ведёт в бухгалтерском понимании этой задачи. В Системе учитываются лишь те операции, которые влияют на товарные поставки. Иными словами, в торговой системе содержится лишь фрагмент учётных данных, отвечающих за поставку товаров, но они представлены и используются с максимальной детализацией.
Розничные сети могут получать от поставщиков товаров вознаграждения в форме бонусов за выполнение различных условий, связанных с поставкой товаров и их последующей реализацией.
Такие вознаграждения в реальной жизни называют «бонусами». Так же они называются и в торговой системе.
Для вычисления и регистрации сумм начисленных бонусов в системе создан функционал, состоящий из двух разделов: «Бонусы поставщиков» и «Акт о начислении и бонусов».
Документ «Бонус от поставщика» предназначен для регистрации договоренности между розничным продавцом и оптовым поставщиком о предоставлении розничному продавцу вознаграждения при выполнении заданного условия по продвижению товара поставщика (Рисунок 1):

Рисунок 1 – Раздел «Бонусы от поставщиков»
Данный документ дополняет те договорные условия, которые указаны в документах «Контракт с поставщиком» и «Соглашение о поставке», хотя системной связи с этими документами не имеется. Документ имеет дату начала и дату завершения действия соглашения и период начисления бонуса.
Для создания нового документа «Бонусы от поставщиков» необходимо выполнить следующие действия:
Рисунок 2 – Создание документа «Бонусы от поставщика» (2)

Рисунок 3 – Создание документа «Бонусы от поставщика» (3)

Рисунок 4 – Создание документа «Бонусы от поставщика» (4)

Рисунок 5 – Создание документа «Бонусы от поставщика» (5)

Рисунок 6 – Создание документа «Бонусы от поставщика» (6)
Документ создаётся в статусе Черновик и требует внесения данных (Рисунок 7):

Рисунок 7 – Список документов «Бонусы от поставщика»
В документе указываются места хранения, куда делается поставка, влияющая на начисление бонуса. Место хранения, от имени которого создан документ, принципиального значения не имеет. Обычно указывают системное место хранения – «Центральный офис».
Период начисления бонуса определяется как календарный месяц, квартал, полугодие или год. Под периодом начисления понимается период времени, внутри которого происходит учет сумм, определяющих условие начисления бонуса.
В документе можно указать следующие условия начисления бонуса (Рисунок 8):

Рисунок 8 – Условия начисления бонуса
Дополнительными условиями определения суммы для начисления бонуса может быть ограничение сумм списком артикулов и/или перечнем мест поставки товаров.
Бонус определяется как процент от суммы условия, может быть задан в виде ступенчатой функции с разными процентами начисления при условии достижения заданной суммы условия.
Если соглашение начинает действовать не с первого числа календарного периода, то есть если дата начала действия документа не равна первому дню периода начисления, то первый период начисления считается от даты начала действия документа и до завершения календарного периода.
Если соглашение прекращает действие не в последний день календарного периода, то последний неполный календарный период не считается расчетным периодом, поскольку расчет всегда ведется на последнюю дату календарного периода, а в этом случае соглашение уже не действует.
Если ограничение по списку артикулов устанавливать не требуется, в документе Бонус от поставщика необходимо отметить флаг «все артикулы». В этом случае список артикулов будет очищен, а при расчете будут учтены все артикулы, поступившие от данного поставщика или оплаченные.
Сам по себе документ «Бонус поставщика» к начислению суммы бонуса и возникновению финансового обязательства не ведёт. Он лишь содержит договорные условия. Для начисления суммы требуется актировать факт наступления этих условий. Для этого существует отдельный документ «Акт о начислении бонуса».
Документ «Акт о начислении бонуса» может быть создан только в ходе выполнения автоматического расчета бонуса. Ручное редактирование документа не разрешается. Вручную документ можно только удалить или разослать по почте.
Мастер создания документа позволяет задать год и месяц, на конец которого должны быть рассчитаны бонусы (Рисунок 9):

Рисунок 9 – Гененрация акта о начислении бонусов
В ходе расчета подбираются все действующие на конец месяца расчета документы «Бонус от поставщика» и для каждого такого документа производится расчет, если период начисления бонуса оканчивается тем же месяцем, что и заданный в процедуре расчета.
Ход расчета может быть сохранен в файл трассировки. Для этого необходимо установить флаг Сохранять информацию о процессе генерации в файл и указать имя файла. Опция по умолчанию отключена. Состояние опции не запоминается и при повторном старте процедуры опция принимает значение по умолчанию.
В документ «Акт о начислении бонуса» помещается итоговая сумма бонуса и информация об условиях расчета:
В спецификацию акта помещается документы, суммы которых были учтены при расчете суммы для начисления бонуса. Сумма, учтенная при расчете условия начисления, может отличаться от суммы документа в следующих случаях:
Для предварительного расчета бонуса с целью получения ознакомительных результатов расчетного периода создан отчет «Расчет бонусов от поставщиков».
Чтобы управлять платежами, нужно решить последовательно несколько задач.
Для управления обязательствами в Торговой системе созданы разделы: Финансовые обязательства по поставкам, Финансовые обязательства по отгрузкам и Сверка обязательств. Разделы помещены в группу разделов Платежи (Рисунок 10):

Рисунок 10 – Финансовые обязательства
Разделы Финансовые обязательства по поставкам и Финансовые обязательства по отгрузкам схожи по внешнему виду и структуре, в той же мере как схожи разделы Приходные накладные и Расходные накладные.
Раздел Сверка обязательств предназначен для контроля всей совокупности обязательств, выявления непогашенных обязательств, сличения сумм обязательств прихода и расхода ценностей.
Задолженность по накладным управляется только с помощью обязательств и платежей по ним.
Приходная накладная (см. Том 9) и расходная накладная (см. Том 13) с операциями движения товара между организацией и контрагентом не содержат всех необходимых атрибутов для управления обязательством и для его погашения. Кроме того, часть данных, необходимых для формирования обязательства, определяется после окончательной регистрации накладной, что делает работу с ними в рамках накладной неудобной.
Для решения задач управления обязательствами, которые возникают по факту регистрации движения товара, для документов «Приходная накладная» и для документов «Расходная накладная» были созданы объекты «Финансовое обязательство по поставке» (код «FI») и «Финансовое обязательство по отгрузке» (код «FO»), доступные по кнопке Перейти к обязательству на закладке накладной Справка о финансовом обязательстве, см. Том 9 (Рисунок 11):

Рисунок 11 – Финансовые обязательства в накладной
Объекты имеют следующие атрибуты, дополняющие атрибуты накладных:
Финансовое обязательство по поставкам имеет следующий вид (Рисунок 12):

Рисунок 12 – Финансовое обязательство по поставкам
Финансовое обязательство по отгрузкам имеет следующий вид (Рисунок 13):

Рисунок 13 – Финансовое обязательство по отгрузкам
Собственный контрагент – это контрагент, представляющий сторону обязательства, выступающие со стороны торгующей организации (пользователя). При создании обязательства собственный контрагент обязательства по умолчанию устанавливается равным собственному контрагенту места хранения накладной, если он был заранее задан для места хранения в разделе Контрагенты, закладка Собств. Контрагент (Рисунок 14) (см. Том 4).

Рисунок 14 – Собственный контрагент
Сумма обязательства по умолчанию равна полной сумме накладной в базовой валюте, но при необходимости и при наличии прав может быть скорректирована. Сумма обязательства всегда фиксируется в базовой валюте независимо от флага накладной Валютный документ. Погашение обязательства также происходит только в базовой валюте. В текущей реализации не поддерживается погашение обязательств с использованием валютных счетов.
Дата обязательства – это календарная дата, с которой начинается расчет отсрочки платежа. Дата устанавливается равной дате документа – основания (накладной). Далее дату можно изменить вручную. При проверке корректности обязательства проверяется, что срок погашения обязательства (расчетная дата погашения) больше или равна дате документа-основания. Иными словами, срок оплаты более ранний, чем дата поставки считается некорректным. В таком случае это будет уже не оплата по факту, а предоплата или аванс.
Из накладной в финансовое обязательство также перенесены атрибуты Отсрочка платежа, Тип дней, Процент штрафа и Максимальная сумма штрафа.
Срок погашения – расчетная дата погашения обязательства. Параметр не редактируется и вычисляется от даты обязательства по сроку отсрочки платежа (Рисунок 15):

Рисунок 15 – Отсрочка и срок погашения платежа
Приоритет оплаты при создании обязательства берется из атрибутов контрагента, но может быть изменен вручную. Атрибут Приоритет оплаты – новый атрибут в разделе Контрагенты на закладке Поставщик. По умолчанию приоритет установлен в значение -1, что означает отсутствие приоритета.
Одной из типичных функций финансового контролера является проверка финансового обязательства на предмет его достоверности перед его оплатой. Получение товара или иного актива вовсе не является событием, автоматически приводящим к задолженности перед поставщиком. Принятие товара ещё не значит, что сразу «должны денег» и ту сумму, которая указана в накладной. Бизнес-ситуации бывают такими, что задолженность возникает не сразу, а после тщательной проверки различных условий (состояния товара, сопроводительных документов, налоговых документов, выявление ошибок и фактов мошенничества и пр.). Поэтому в системе факт получения актива и возникновения по нему задолженности разделены. Для появления задолженности нужно от пользователя определённое действие – признание задолженности. В терминологии Системы – это признание обязательства «достоверным».
Для автоматизации бизнес-процесса проверки достоверности в обязательство внесен специальный атрибут признания обязательства достоверным. Флаг Достоверно используется для того, чтобы отделить обязательства, полностью оформленные и проверенные от тех, работа над которыми не завершена. Пока обязательство не признано достоверным, его атрибуты могут редактироваться, после его признания редактирование обязательства не разрешено.
Только после признания обязательства «достоверным» оно станет значимым для управления платежами. Система начнёт отслеживать его суммы и даты.
Объект «Финансовое обязательство по поставке» не является полностью самостоятельным. Он является продолжением приходной накладной и дополняет ее. Документ «Приходная накладная» и объект «Финансовое обязательство по поставке» существуют неразрывно в отношении «один к одному».
Аналогично, объект «Финансовое обязательство по отгрузке» связан с документом «Расходная накладная».
Далее в тексте оба объекта обязательств будут именоваться «Финансовое обязательство накладной».
Ручное создание объектов «Финансовое обязательство накладной» не допускается. Финансовое обязательство для накладной создается автоматически в момент перевода статуса приходной или расходной накладной в Принят полностью (Отпущен полностью). Обязательства создаются только для накладных с такой операцией, которая описывает движение товара между организацией пользователя и внешним контрагентом. Операции, которые не подразумевают переход собственности от одного контрагента другому, например, «списание брака», к появлению обязательства не приводят. Для одной накладной создается одно обязательство.
Финансовое обязательство по поставке создается для следующих системных операций (и пользовательских операций, созданных на базе системных) в «Приходной накладной»: «Приход», »Приход инвентаря», «Возврат от покупателя».
«Финансовое обязательство по отгрузке» создается для следующих системных операций (и пользовательских операций, созданных на базе системных) в «Расходной накладной»: «Продажа», «Возврат поставщику».
Функционал финансовых обязательств появился в версии 1.029. При обновлении версии Торговой Системы с более ранних версий в базе данных для каждой подходящей накладной будет создано финансовое обязательство. Процесс создания обязательств может занять значительное время, которое зависит от количества документов в базе данных. Примерная оценка – 30 минут для одного миллиона документов. Истинное время обновления зависит от производительности сервера и эффективности экземпляра базы данных.
Удаления обязательства, как и понижение статуса накладной, является действием не регулярным, а исключительным. На его применении не могут базироваться повседневные бизнес-процессы организации.
Условия удаления обязательства, признанного достоверным, существенно отличаются от условий удаления обязательств, которые еще не признаны достоверными. Для признания обязательства достоверным необходимо выбрать пункт меню кнопки Обработать → Признать обязательства достоверными.
«Достоверные» обязательства защищены системной проверкой и удалить их возможно только вместе с накладной, либо признать их недостоверными (Обработать → Признать обязательства недостоверными).
Причина сохранения «достоверных» обязательств при понижении статуса накладной в следующем. «Достоверные» обязательства могут содержать данные, отличные от данных, которые в них помещаются по умолчанию при создании обязательства. Также они могут быть уже полностью или частично оплаченными, иметь связи с платежными документами или встречными обязательствами.
Удаление обязательства при понижении статуса накладной, особенно в тех случаях, когда требуется незначительная правка накладной, не влияющая на ее финансовые атрибуты, может привести к дополнительным трудозатратам и ошибкам.
Понижение статуса накладной, в результате которого обязательство не удаляется, приводит к тому, что обязательство становится несоответствующим накладной. Такая техническая возможность системой предусмотрена. Эти расхождения должны контролироваться административно.
При последующем повышении статуса, если содержание накладной не вошло в противоречие с содержанием обязательства, обязательство признается соответствующим накладной.
При удалении накладной, если обязательство ранее не было удалено при понижении статуса, обязательство удаляется.
Объект «Финансовое обязательство накладной», как объект Торговой Системы, создан только для приходных и расходных накладных, тогда как бизнес-понятие «обязательство» относится к платежу, получению платежа и к акту о начислении бонуса. Платежные документы и акт о начислении бонусов содержат все необходимые атрибуты обязательства и используются в этом качестве при учете обязательств контрагентов. В Торговой Системе это отразилось в том, что в интерфейсе все перечисленные типы документов считаются обязательствами, могут отражаться совместно, и могут использоваться для погашения обязательств.
Связь может быть установлена только между обязательствами: между финансовыми обязательствами накладных, платежными документами и актами о начислении бонуса. Связь обязательств допускается только между теми обязательствами, которые могут быть взаимно погашены. Связь обязательств описывает сумму связи в базовой валюте и два взаимосвязанных обязательства.
Связь позволяет адресно гасить одно обязательство другим: конкретный приход – конкретным возвратом, конкретный аванс – конкретной поставкой, конкретный приход –конкретным платежом. Например, связь позволяет адресно оплачивать конкретным платежным поручением конкретную приходную накладную в размере определенной суммы. Если бы связи не было и встречные обязательства существовали бы отдельно друг от друга, то невозможно было бы знать, какое конкретно обязательство сейчас погашено, а какое – нет. Можно было бы пользоваться лишь грубым сальдовым методом, при котором невозможно оперировать понятиями срок погашения и просрочка.
Установлена определенная логика гашения обязательств, которая ниже описана на конкретном примере.
Выбираются два обязательства, которые могут быть взаимно погашены. Например, обязательство по поставке и платеж (платеж поставщику). В зависимости от сути бизнес-процесса используется функционал, устанавливающий между ними связь на сумму связи.
Финансовое обязательство по поставке существует на сумму 3068 рублей и признано достоверным (Рисунок 16):

Рисунок 16 – Достоверное финансовое обязательство
Некий бухгалтер создает документ «Платеж» в статусе Черновик (Рисунок 17). В документе «Платеж» указывает связанную приходную накладную и сумму связи. В данном случае это сумма 100800.

Рисунок 17 – Платеж
Как только документ «Платеж» с установленной связью сохранятся в любом статусе Черновик или Проплачен, связь незамедлительно начинает влиять на задолженность (Рисунок 18):

Рисунок 18 – Обязательство по поставке в процессе погашения
Платеж в статусе Черновик или Проплачен в реальной жизни означает намерение (запланированное действие) заплатить сумму. Но этого намерения достаточно, чтобы исключить в дальнейшем из рассмотрения оплачиваемое обязательство. Задолженность по этому обязательству должна быть снижена сразу после того, как это намерение появилось (платеж сохранен в состоянии черновика). В этом случае обязательство не будет повторно ошибочно запланировано к оплате.
Поэтому, как только установлена связь между обязательствами, это влияет на задолженность.
Но при этом, намерение – не свершенный факт. Фактически платежа еще не было. Для публикации такого промежуточного состояния используется сигнал «В процессе гашения». Он публикуется в списковом представлении обязательств в соответствующем поле.
Далее платеж поступает в банк, денежные средства списываются с расчетного счета. После списания денег с расчетного счета документ «Платеж» устанавливается в статус Исполнен.
Сигнал об этом отображается пользователю, работающему с обязательствами, в поле исполнения финансовой связи «Исполнен». Таким образом, финансовая связь может иметь два состояния. 1.Установлена и не исполнена 2. Исполнена (Рисунок 19):

Рисунок 19 – Задолженность
Если финансовая связь исполнена, то процесс погашения по этой связи состоялся и завершен. Сигнал о незавершенности процесса погашения будет выставлен, если у обязательства существует хотя бы одна неисполненная установленная связь. Т.е. начали готовить оплату, но не закончили.
Связь не является частью объектов документов или финансовых обязательств накладных. Но и не является самостоятельным почтовым объектом. Связь обязательств является полузависимым объектом, который перемещается только вместе с любым из объектов, связь между которыми она описывает.
Для установления связи не предъявляется строгих требований к статусу документа или финансового обязательства накладной.
Введено понятие состояния связи (см. подробное описание ниже). У связи обязательств имеется характеристика – состояние связи. Состояние связи зависит от статуса взаимно связанных обязательств. Если связь установлена между достоверными обязательствами и / или документами в наивысшем статусе, то такая связь считается исполненной (флаг Исполнено).
Связь обязательств может создаваться, меняться и удаляться без предъявления обязательных требований к статусу обязательств / документов, между которыми устанавливается связь. Как следствие, допускается существование связи в базе данных без наличия в ней одного из обязательств. Эта возможность используется для передачи информации о погашении обязательства из одной базы данных в другую, без обязательной передачи полного комплекта документов. Тем не менее, при обычной работе с обязательствами в базе данных удаление обязательства приводит к обязательному удалению его связей. Строго не допускается наличие связей, для которых в базе отсутствуют оба обязательства.
Для документа «Счет» связь с документом «Получение платежа» реализована аналогично связям между обязательствами. Связи счета с получением платежа вынесены в отдельный объект (таблицу) для того, чтобы отделить суммы погашения обязательств (ранее именовалось «акцептированием») от сумм, полученных на основании выставленного счета. Управление выставленными счетами осуществляется так же, как управление обязательствами.
При обновлении версии базы данных информация из таблицы финансовых оснований переносится в таблицу финансовых связей.
При рассылке накладной отсылается ее обязательство и связи этого обязательства. При рассылке платежного документа, акта о начислении бонуса или счета, если документы имеют связи с другими обязательствами, эти связи также будут отосланы. Финансовое обязательство накладной может быть отослано самостоятельно, в этом случае связи обязательства также будут отосланы.
Объекты принимаются в базу данных с соблюдением следующих условий:
Разрешен прием в базу данных финансовых обязательств / документов с финансовыми связями без обязательного наличия в принимающей базе объектов, на которые ссылаются связи. Это позволяет пересылать информацию о погашении обязательства без пересылки полного комплекта документов, связанных с его погашением. При нарушениях в документообороте и при неверной рассылке объектов могут возникать ситуации, когда сумма связей может превысить сумму обязательства. Приведение суммы связей в соответствие сумме обязательства проводится в разделе Сверка финансовых обязательств.
Раздел Финансовые обязательства по поставкам служит для работы с финансовыми обязательствами, возникшими перед поставщиками за поставленный товар, услуги.
Окно отобранных обязательств разделено на две зоны – таблицу (список) отобранных обязательств и зону детального содержания выбранного обязательства (Рисунок 20).
Зона детальной публикации обязательства также служит для редактирования атрибутов обязательства и для показа списка связей обязательства с погашающими обязательствами.
Атрибуты финансового обязательства по поставкам были описаны выше.

Рисунок 20 – Финансовые обязательства по поставкам
Интерфейс позволяет указать условие сортировки обязательств по необходимому признаку, например, приоритету платежей или сроку просрочки платежа.
Под термином В процессе погашения понимается то, что связь установлена между обязательствами, по крайней мере, одно из которых еще не выполнено (запланировано или находится в процессе исполнения).
Содержание колонки В процессе погашения соответствует по смыслу опции фильтра отбора обязательств В процессе погашения и колонке В процессе погашения списка отобранных обязательств.
В таблицу со списком обязательств добавлены следующие колонки:
В детальное описание текущего обязательства добавлены следующие поля:
Раздел содержит фильтр для задания условия отбора обязательств, и окно отобранных обязательств.

Рисунок 21 – Фильтр для задания отбора обязательств
Интерфейс фильтра позволяет задать условия отбора обязательств по атрибутам обязательств, например, отбирать обязательства по контрагентам, срокам платежа, операциям накладных и т.д., и по состоянию обязательств (см. ниже).
Для обязательства существенную роль играют важные для бизнеса сигналы. Эти сигналы подаются после определенных бизнес-событий. Наблюдение сигналов пользователем важно для принятия управленческих решений. Пользователь сначала реагирует на сигналы, а потом уже в деталях рассматривает суммы, даты, номера документов и прочие параметры списка обязательств.
Гашение обязательства в системе происходит установление финансовой связи обязательства с другим обязательством (платежом, встречным обязательством) на определенную сумму.
Для отражения текущего состояния процесса гашения обязательства предусмотрено четыре фиксированных значения сигнала. Обязательство может быть не погашено, погашено частично, погашено или погашено избыточно.
В таблице отобранных обязательств строки обязательств выделяются цветами в зависимости от состояния погашения.

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

Рисунок 23 – Параметры раздела
Другим критическим показателем является просрочка оплаты. Для оценки этого показателя используется два фиксированных значения сигнала. Обязательство может быть просрочено или не просрочено. Состояние «просроченности» определяется только для достоверных обязательств. Не признанные достоверными обязательства не считаются просроченными, даже если срок погашения обязательства меньше текущей даты.
Если после истечения календарной даты, являющейся «сроком погашения», не вся сумма обязательства погашена, то обязательство будет просроченным.
Суммы и даты погашения обязательства определяются по соответствующим атрибутам связей обязательства. Но только по таким связям, которые имеют статус Исполнено. Это означает, например, что если обязательство по поставке имеет связь с платежным документом в полной сумме обязательства, но платеж еще не получил статус Исполнен (например, по причине того, что банк не прислал подтверждение о прохождении платежа), то эта связь не будет учтена, как состоявшееся погашение. Обязательство, в этом случае, может быть обозначено как просроченное, несмотря на наличие своевременного распоряжения об его оплате.
Если в поставке имелись товары с отсрочкой платежа (см. раздел Контрагенты, закладка Заказ, поле Отсрочка платежа Том 4) меньшей, чем отсрочка платежа обязательства, то состояние «просрочки» определяется по своевременности и полноте погашения каждой части суммы обязательства со своим сроком погашения. Детализацию сроков погашения обязательства отражается в поле Срок погашения (Рисунок 24):

Рисунок 24 – Срок погашения платежа
Обязательство может быть в процессе погашения или нет. Это зависит от статуса финансовой связи. Если хотя бы для одной связи обязательства не установлен флаг Исполнено, то считается, что обязательство находится в процессе погашения. Например, если приходная накладная связана с платежом и платеж еще не исполнен, то обязательство приходной накладной находится в процессе погашения.
Обязательство может соответствовать накладной или не соответствовать. Зависит от статуса накладной, операции накладной, соотношения даты и суммы накладной и даты и суммы обязательства, контрагента накладной и обязательства. Обязательство может не соответствовать накладной, если после создания и признания обязательства, накладная была изменена без предварительного удаления обязательства, и после повторного оприходования накладной, ее атрибуты вошли в противоречие с атрибутами обязательства.
Функции обработки обязательств доступны при вызове меню кнопки Обработать (Рисунок 25):

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

Рисунок 26 – Генерация платежных документов (1)

Рисунок 27 – Генерация платежных документов (2)
Атрибут От имени места хранения по умолчанию устанавливается в значение «Место хранения по умолчанию».
Функция позволяет указать максимальную сумму оплаты, если текущие средства не позволяют оплатить обязательства полностью, а также указать режим формирования документов «Платеж» по одному платежу на каждое обязательство. В противном случае будет формироваться один платежный документ на группу обязательств с одинаковой парой контрагентов.
Сгенерировать платежный документ на сумму большую, чем требуется для погашения обязательств нельзя, даже если указать сумму к оплате большую, чем указано в интерфейсе запуска функции.
Если сумма к оплате будет меньше суммы обязательств, погашение обязательств будет происходить в порядке приоритета, а при равном приоритете обязательств - в порядке возрастания дат погашения обязательств.
При формировании платежных документов суммы по ставкам НДС рассчитываются по значениям сумм НДС спецификации накладной финансового обязательства. Если сумма оплаты меньше суммы обязательства, суммы по ставкам НДС рассчитываются пропорционально доли оплаты. При автоматическом расчете сумм НДС по ставкам НДС не учитывается возможное расхождение между суммой накладной и суммой обязательства. Если по какой-либо причине, например, по договоренности с контрагентом сумма обязательства была изменена без изменения суммы накладной, суммы по ставкам НДС в платежном документе необходимо будет скорректировать вручную.
При генерации платежных документов автоматически происходит установление связи между обязательством накладной и новым платежным документом на сумму погашения. Если необходимо изменить результаты привязки обязательств к платежам, необходимо удалить платежные документы и заново выполнить функцию генерации платежных документов, либо вручную отредактировать связи в платежном документе. Перейти к платежному документу можно двойным кликом мыши на номере платежного документа в таблице связей.

Рисунок 28 – Распределение задолженности
Нельзя погасить задолженность суммой больше, чем задолженность, также нельзя превысить сумму аванса.
Если возникнет необходимость изменить распределение сумм погашения по авансовым платежам, то необходимо перейти в соответствующий платежный документ и в нем удалить необходимые связи. Редактирование связей в платежном документе разрешено без изменения статуса платежного документа. См. Раздел «Платежи» и «Получение платежей».

Рисунок 29 – Погашение расходом
В диалоге функции показываются все подходящие обязательства по отгрузкам, с которыми может быть связано обязательство по поставке. Если среди списка обязательств по отгрузке имеется обязательство, накладная которой имеет в общем основании ссылку на накладную прихода текущего обязательства, или наоборот, то такое обязательство по отгрузке выделяется шрифтом как наиболее подходящее для погашения.
Функция позволяет автоматически распределить сумму обязательства по погашающим обязательствам (кнопка Распределить задолженность).
Функция может использоваться для погашения обязательства в нестандартных случаях, в том числе при взаимозачете обязательств. В диалоге функции показывается список всех платежных документов и обязательств по отгрузкам, которые могут быть использованы для погашения текущего обязательства (Рисунок 30):

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

Рисунок 31 – Фильтр
Обязательства, для которых есть авансовые платежи со свободной суммой –
опция фильтра отбирает только такие обязательства, которые требуют погашения, могут быть погашены авансовыми платежами, и для которых такие авансовые платежи со свободной суммой имеются.
Раздел Финансовые обязательства по отгрузкам (Рисунок 32) предназначен для работы с информацией о расходе товара, то есть с данными расходных накладных, как с информацией о финансовых обязательствах.
Раздел предназначен для решения следующих задач:

Рисунок 32 – Раздел Финансовые обязательства по отгрузкам»
Документ «Платёж» предназначен для регистрации платежей контрагентам и для установления соответствия между фактами платежей и фактами движения товаров по накладным.
В зависимости от основания платежа и вида контрагента, платежи могут иметь следующие операции: для контрагентов поставщиков: «авансовый платеж» и «платеж»; для контрагентов клиентов: «возврат аванса», «возврат полученных денег».
Операции «авансовый платеж» и «возврат аванса» могут не иметь основания платежа в спецификации документа. Операции «платеж» и «возврат полученных денег» обязаны иметь основание платежа в спецификации документа. Допустимый тип и операции документов основания платежа зависят от операции документа Платежи.
Данный программный модуль предоставляет возможность отражать состояние взаиморасчётов с поставщиками, а также формирует документы, по которым может осуществляться оплата полученного товара.
В ТС возможно отразить либо перечисление определенной суммы поставщику, либо возврат поставщику ранее полученного от него платежа без привязки к товаросопроводительному документу (например, при предоплате по контракту), либо отразить в БД платежи в оплату одной или нескольких приходных накладных данного поставщика. В последнем случае ТС ведётся реестр оплаченных товаросопроводительных документов и, в целом, учёт состояния взаиморасчётов с поставщиком по оплаченным и ещё неоплаченным его накладным.
Как и информация по платежам полученным, данные по взаиморасчётам с поставщиками служат исходной информацией для принятия управленческих решений персоналом предприятия.
Вместе с тем, следует учесть, что действия по получению и отправке платежей, учёт денежных средств и их потоков производится бухгалтерией организации. При этом ни автоматический экспорт, ни прямой импорт данных финансовых потоков между бухгалтерской программой и ТС «Супермаг Плюс» в штатной поставке софта не предусмотрен.
Синхронизация (выверка) содержания баз данных (ТС и бухгалтерской) может поддерживаться только организационными мерами (например, ежедневной передачей менеджерам листинга бухгалтерии с расшифровкой финансовых потоков: как в оплату поступившего товара, так и получением платежей за отгруженный/приготовленный к отгрузке товар; за возврат товара и т.п.) и, в свою очередь, активным использованием работниками финансового дивизиона компании отчетов ТС, например «Графика расчёта с поставщиками», составляемого при бюджетировании бизнес-процесса.
Разработка мер по синхронизации баз данных (бухгалтерской и ТС) в части учёта финансовых потоков остаётся за пользователем.
Возможные причины рассогласования данных:
Одной из проблем является синхронизация реквизитов расчётно-платежных документов и сумм реально произведённых платежей в двух БД. Пусть в ТС для идентификации очередного платежа Поставщику А система сгенерировала номер платежного поручения 105. При экспорте данных этого платежа в бухгалтерскую программу последняя автоматически сгенерировала № 223, который не мог быть исправлен оператором вручную, так как в бухгалтерской БД уже был зарезервирован номер 105 для учёта иной хозяйственной ситуации, по которой уже составлен отчёт. Кроме того, выполнение обязательств по оплате товара (по факту) может разойтись как по дате, так и по сумме платежа с бюджетным планом организации-плательщика, которая к тому же может и дробить свои платежи (несколько платежных поручений в оплату одного счёта). Таким образом, сверка платежей с Поставщиком А (взаиморасчёты) только на основании данных ТС становится проблематичной.
Некоторые поставщики ведут взаиморасчёты в условных единицах, за которую принимают, к примеру, доллар США с пересчётом в рубли РФ по курсу ЦБ РФ (т.е. четыре знака после запятой) и плюс 1,5% по курсу USD на день оплаты. В БД справочник курсов валют может вестись с точностью до 2-х знаков, с автоматическим пересчётом стоимости товара в рубли РФ по курсу на дату его прихода – первая причина рассогласования данных учёта.
Вторая причина – если экспорт данных товарного прихода из БД «Супермаг Плюс» в бухгалтерскую программу производить в национальной валюте (например, в рублях РФ), то в бухгалтерии будет накапливаться систематическая ошибка по сумме задолженности: так как в БД не предусмотрен механизм расчета курсовых разниц, то в момент оплаты товара (к примеру, по поставкам с отсроченным платежом) сумма накладной в рублях РФ, учтённая в ТС, вследствие изменения курса USD никогда не будет равняться сумме реального платежа, разочтённого бухгалтерией в оплату товара по этой накладной резиденту РФ, если такой платёж необходимо произвести на основании первичного документа с отражением цен в нём, выраженных в у.е. и на условиях, оговоренных выше.
Информация о кредитных учреждениях регулярно обновляется ЦБ РФ и доводится до сведения коммерческих банков. Вслед за этим кредитные учреждения, как правило, автоматической рассылкой замещает соответствующие справочники у своих клиентов, поставляемые в составе систем «Банк-клиент». В ТС «Супермаг Плюс» осуществлена возможность ведения справочника «Банки» (см. Том 1), однако автоматизация импорта новых версий справочника банковских реквизитов в ТС не предусмотрена.
|
Напрямую из ТС выгрузить платежное поручение (как полностью оформленный документ) также нельзя. Можно его выгрузить только через какую-то промежуточную стадию с преобразованием экспортируемого файла в тип файла программы «Банк-Клиент». |
В зависимости от указанного типа расчёта документ «Платежи» эквивалентен либо расходному кассовому ордеру (для наличной оплаты), либо банковскому платежному поручению (для безналичной оплаты).
Документ «Платеж» имеет следующий вид (Рисунок 51):

Рисунок 51 – Платеж
Атрибуты:
В связи с изменением законодательства в части определения очередности списания денежных средств и количества категорий очередности, в платежных документах разрешается определять очередность от 1 до 5. По умолчанию предлагается очередность 5.
При открытии документов прежних версий с очередностью 6, в интерфейсе в окне очередности данные показываться не будут, но в содержании документа и при печати величина «6» будет сохранена и будет печататься. При редактировании значения очередности старого документа будут предложены значения от 1 до 5.
Документ «Платеж» имеет следующие статусы:
Для создания документа «Платеж» необходимо выполнить следующие действия:

Рисунок 52 – Создание платежа (1)

Рисунок 53 – Создание платежа (2)

Рисунок 54 – Создание платежа (3)

Рисунок 55 – Создание платежа (4)

Рисунок 56 – Создание платежа (5)

Рисунок 57 – Создание платежа (6)
6. В последнем окне диалога проверить введённую ранее информацию, установить отметку в пункте Перейти к редактированию созданного документа,если она не была там установлена (Рисунок 58):

Рисунок 58 – Создание платежа (7)
7. В заголовке сформированного документа (режим Редактировать) указать сумму платежа, сумму НДС, очередность платежа и его назначение (Рисунок 59):

Рисунок 59 – Создание платежа (8)
С помощью введенного документа-платежа можно отразить в БД оплату произвольного списка документов (номер каждого документа пользователь указывает отдельно), либо отобрать неоплаченные номенклатурные документы из списка.
Выбрать тип оплачиваемого документа (приходная накладная) и отобрать из всплывающего перечня документов требуемый номер товаросопроводительного документа (Рисунок 60):

Рисунок 60 – Оплата документа
Результат отбора документов-оснований представлен на рисунке (Рисунок 61):

Рисунок 61 – Отобранные документа
Если необходимо оплатить иной документ, то после окончания ввода оплачиваемых документов, в том числе и сумм платежей в них, документ-платеж переводится в статус Проплачен, для этого необходимо нажать либо на кнопку Проплатить, либо пользуясь кнопкой Обработать выбором опции Смена статуса. Далее, после ввода отметок документа ( и по факту реального платежа) необходимо перевести его в статус Исполнен, для чего необходимо нажать на кнопку Принять.
Для того чтобы флаг Оплата по документу Платеж в документе устанавливался автоматически необходимо установить его для места хранения. Данный флаг фактически включает или исключает накладные из учета взаиморасчетов. То есть, в случае если флаг Оплата по документу Платеж в накладной не установлен, то поле Задолженность накладной редактируется вручную без участия платежных документов и содержит окончательный результат оплаты. Такие накладные отражаются в отчетах о платежах не в виде движения стоимостей, а в виде результата (сальдо) движения по отношению к данному документу. При установлении связи с приходными накладными платежный документ вносит изменение в поле Задолженность заголовка накладной, не меняя её статус.
По кнопке Печать производится печать проектов платежных поручений. Документы можно также экспортировать с помощью кнопки Обработать, преобразовав их в любой иной документ ТС из предложенного списка.
Возможен из документа «Платеж», формирование аналогично действиям по операции платеж. Включение накладной в спецификацию платежного документа в этом случае происходит автоматически, без понижения статуса платежа. Свободная сумма авансового платежа уменьшается на сумму оплаты по накладной.
Производится также из документа «Платеж».
Производится также из документа Платеж и автоматически из меню раздела Расходных накладных Функции → Генерация платежей (см. Том 13).
Получение платежей) по мере получения информации из банка о поступлении денежных средств. В этом же разделе в процессе формирования документа «Получение платежа» устанавливается его связь с обязательством расходной накладной.
Аналогичен и набор функций обработки обязательств:
В случае обязательства по отгрузкам погашение авансом подразумевает погашение документами «Получение платежа» с операцией Получение аванса.
Погашение приходом – погашение обязательств по отгрузкам с операцией Продажа обязательствами по поставкам с операцией Возврат от покупателя и обязательств по отгрузкам с операцией Возврат поставщику обязательствами по поставкам с операцией Приход (Рисунок 33):

Рисунок 33 – Погашение приходом
Обязательство гасится любым подходящим обязательством. Генерация платежных документов – позволяет создать для отобранных обязательств документы «Получение платежа» с операцией «Получение платежа».
Если в расчётах между ретейлером и поставщиком участвует третье лицо (финансовый агент), то для создания платёжных документов и построения взаиморасчётов в таких случаях используется функционал, названный «Факторинг».
В разделе Контрагенты закладка Счета и факторинг (Рисунок 34) содержат элементы «Финансовый агент» и «Договор цессии».

Рисунок 34 – Закладка «Счета и факторинг»
Финансовый агент – это контрагент, который принимает на себя финансовые обязательства текущего контрагента по договору цессии, номер которого указывается в поле Договор цессии. Название договора цессии в дальнейшем будет вставляться в платёжный документ при его формировании (Рисунок 35). Для контрагента может быть указан только один финансовый агент.

Рисунок 35 – Финансовый агент
Финансовый агент, если он назначен контрагенту, проставляется в финансовые обязательства, создаваемые на основании приходных и расходных накладных, и показывается в заголовке обязательства. Если финансовое обязательство уже создано, назначение или смена финансового агента для контрагента на это обязательство не влияет.
Финансовый агент показывается также в интерфейсе накладных на закладке Справка о финансовом обязательстве (Рисунок 36):

Рисунок 36 – Справка о финансовом обязательстве
Значения полей на закладке Справка о финансовом обязательстве заполняются системой автоматически после создания документа «Финансовое обязательство» при повышения статуса товародвиженческого документа до статуса Принят полностью или Отпущен полностью.
При генерации платежей на основании финансовых обязательств, в которых определен финансовый агент, в платежные документы в качестве внешнего контрагента будет проставляться не внешний контрагент финансового обязательства, а его финансовый агент. В поле Назначение платежа документа «Платеж», в этом случае, дополнительно заносится информация из поля Договор цессии внешнего контрагента финансового обязательства: Сгенерирован автоматически. Договор цессии <номер договора цессии>.
В отчете «Расчеты с контрагентами» вместо внешнего контрагента финансового обязательства используется финансовый агент, если он указан в финансовом обязательстве.
Раздел предназначен для отображения и сверки всех видов обязательств, включая акты о начислении бонусов. В первую очередь раздел выполняет информационную роль. Путем целевой настройки фильтра можно получить произвольное представление взаиморасчетов собственных контрагентов с внешними. Кроме того, присутствует возможность в этом же разделе гасить обязательства и устанавливать финансовые связи. Раздел позволяет контролировать корректность погашения обязательств, погашать обязательства и корректировать связи обязательства.
В таблице отобранных обязательств отдельно показываются суммы обязательств прихода ценностей и суммы расхода ценностей, и подводится итог по отобранным обязательствам. При отборе всех обязательств пары собственного и внешнего контрагента и в заданном диапазоне времени, раздел позволяет осуществлять сверку обязательств собственного и внешнего контрагентов (Рисунок 37):

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

Рисунок 38 – Раздел «Реестр платежей»
В разделе поддержан бизнес-процесс планирования и подготовки безналичных платежей на указанную дату. В разделе можно реализовать путем настроек функционально-ролевую модель взаимодействия менеджера по закупкам, финансового менеджера и коммерческого руководителя (начальника) менеджеров по закупкам.
Ритм запуска и время жизни процесса определяется его бизнес-смыслом. Зависит это от правил бюджетирования и порядка проведения безналичных платежей в банках. За банковский день проводится один или несколько сеансов перечисления денег. При этом банк оперирует суммой, находящейся на расчетном счете плательщика.
Процесс «Реестр платежей» рекомендуется использовать следующим образом.
Утром из выписки банка финансовый менеджер узнает доступную сумму и планирует свои денежные потоки. Часть денежных средств идет на оплату поставок товаров. Эту сумму далее будем называть лимитом. Лимит определяет финансовый менеджер.
Сведения о выделенном лимите финансовый менеджер сообщает начальнику менеджеров по закупкам (далее, Начальник). Менеджеры по закупкам могут работать каждый со своим пулом поставщиков.
Начальник запускает формирование реестра платежей и вносит сумму лимита. Далее менеджеры по закупкам планируют платежи вручную по тем обязательствам, где требуется наибольшая срочность, важность. Например, поставщик приостанавливает поставки. При этом каждый менеджер может работать со своим пулом поставщиков.
Далее реестр поступает начальнику. Он вносит коррективы вручную в планы менеджеров.
Если после ручного планирования осталась еще нераспределенная сумма лимита, то ее начальник может распределить автоматически. При этом система учтет срочность и приоритетность обязательств.
После автоматического распределения начальник снова может вручную вмешаться и скорректировать предложения системы.
Когда реестр платежей создан, начальник запускает генерацию платежных документов. После этого реестр становится ненужным и интересен только как история действий пользователей.
На рисунке схематично показан описанный выше процесс (Рисунок 39):

Рисунок 39 – Формирование реестра платежей
Описанный выше бизнес-процесс в системе реализуется ниже описанными действиями. Создание нового реестра осуществляется при нажатии кнопки Новый реестр (Рисунок 40):

Рисунок 40 – Создение реестра платежей
Система дает возможность выбрать дату реестра. При регулярной работе должна ставиться текущая дата.
При создании реестра платежей необходимо указать собственного контрагента. Это позволяет сформировать реестр от лица выбранной организации, независимо от места хранения, куда поступал товар.
Вносится сумма лимита.
Сумма лимита может быть изменена в ходе работы с реестром при наличии у сотрудника функционального права «Реестр платежей: редактирование суммы лимита».
После заполнения полей для формирования реестра необходимо нажать кнопку Готово.
Интерфейс реестра платежей содержит информацию для принятия решения о проведении платежа (Рисунок 41):

Рисунок 41 – Информация о платежах
Поскольку интерфейс весьма информативный, то рекомендуется организация рабочего места для работы с реестром с использованием широкоэкранного монитора.
В интерфейсе реестра платежей выводятся финансовые обязательства по поставке, сгруппированные по поставщикам. Интерфейс содержит две табличные части.
В таблице поставщиков выводится список поставщиков с итоговыми данными по задолженности. Данные по выбранному в этой таблице поставщику показываются в таблице ниже.
Обе таблицы содержат одинаковые по смыслу столбцы:
Финансовое обязательство по отгрузке (колонка Обязательство) попадает в просмотр, если:
В данном случае рассматривается задолженность, которая не погашена не только фактически платежом или встречным обязательством, но даже не запланирована к погашению. То есть, если документ «Платеж» в статусе Черновик связан с финансовым обязательством на определенную сумму запланированного платежа, то эта еще не погашенная фактически задолженность в реестр платежей не попадет. Считается, что намерение оплатить эту сумму уже зарегистрировано в Системе черновиком платежа и повторно планировать эту оплату нельзя.
Кнопка Группы товаров предназначена для установки фильтра на обязательства. При установке фильтра в отбор попадают только обязательства, основаниями которых являются накладные, в спецификацию которых входит хотя бы один товар из выбранной группы (Рисунок 42):

Рисунок 42 – Выбор группы товаров
Содержание фильтра запоминается и восстанавливается при следующем открытии реестра платежей.
Установка фильтра не отменяет того правила, что совместная работа над реестром возможна только среди пользователей, которым назначены права работы с разными контрагентами. Если пользователь, имеющий право работы с конкретным контрагентом открыл реестр для редактирования, другой пользователь имеющий право работы с тем же контрагентом не сможет редактировать реестр, даже если он собирается обрабатывать другую группу обязательств, связанных с иной группой товаров (см. п. 7.5 «Работа с реестром нескольких пользователей одновременно«).
Редактирование суммы платежа может осуществляться по каждому поставщику вручную или с помощью функции Распределение суммы лимита (Рисунок 43, Рисунок 44):

Рисунок 43 – Распределение суммы лимита (1)

Рисунок 44 – Распределение суммы лимита (2)
При ручном назначении сумм платежа пользователь может превысить сумму лимита. В этом случае Сумма к оплате будет отображаться красным цветом (Рисунок 45):

Рисунок 45 – Сумма к оплате
Это индикация превышения лимита. Система не разрешит создать платежные документы, если лимит превышен. Поэтому пользователь должен следить за цветом текста и не превышать суммы лимита.
Автоматическое распределение суммы не затрагивает ранее установленные вручную суммы платежей. Сумму для распределения пользователь устанавливает сам. Автоматическое распределение сумм позволяет обрабатывать сразу несколько поставщиков (или всех). Есть возможность работать с поставщиками индивидуально в разрезе обязательств. Больше, чем положено по сроку, система автоматически к оплате не назначит. Излишки распределяемой суммы будут относиться к нераспределенному лимиту.
Если сумма лимита недостаточна для погашения всей задолженности, то функция в первую очередь погашает обязательства с наивысшим приоритетом оплаты. Среди обязательств с одинаковым приоритетом в первую очередь погашаются обязательства с наименьшим сроком погашения. Среди обязательств с одинаковым сроком погашения в первую очередь будут погашаться обязательства с наименьшим номером основания.
В больших организациях с поставками и закупками работают несколько менеджеров (Рисунок 46). Нагрузка между ними распределяется по выбранному правилу. Реестр платежей позволяет поддержать работу нескольких менеджеров одновременно, если между ними будут распределены поставщики.

Рисунок 46 – Работа с реестром нескольких пользователей одновременно
Реестр платежей предназначен для групповой работы сотрудников с одним реестром. Когда реестр создан, с ним одновременно может работать несколько сотрудников, если для них введены ограничения на работу со списком поставщиков. В этом случае каждый сотрудник работает только с обязательствами своих поставщиков и не может повлиять на обработку обязательств поставщиков, назначенных другим сотрудникам. Завершать работу с реестром в этом случае должен сотрудник, наделенный правами работы со всеми поставщиками и правом на выполнение функции «Реестр платежей: Генерация платежных документов».
В связи с возможностью одновременной работы с реестром нескольких сотрудников необходимо административно следить за тем, чтобы сотрудники не работали с одинаковым или пересекающимся перечнем поставщиков. Блокировка редактирования обязательств поставщика не позволяет одновременно редактировать его обязательства, но не защищает от того, что ранее отредактированные обязательства не будут изменены другим сотрудником.
Для организации работы нескольких менеджеров требуется в административном модуле назначить каждому из них список доступных ему поставщиков (Рисунок 47 – Рисунок 49):

Рисунок 47 – Назначение списков поставщиков менеджеру (1)
Для этого заранее создаются списки поставщиков.

Рисунок 48 – Назначение списков поставщиков менеджеру (2)

Рисунок 49 – Назначение списков поставщиков менеджеру (3)
Данная настройка является общесистемной и влияет не только на работу с реестром, но и на доступ пользователя иным разделам Системы.
Пользователь с ограниченным доступом к работе с контрагентами сможет видеть и редактировать только данные по тем поставщикам, что ему доступны. В примере на рисунке (см. Рисунок 49) пользователю доступен только один поставщик. При этом лимит и нераспределенная сумма лимита, что наблюдает пользователь, едины для всех сотрудников.
Как и при единоличном использовании реестра, работает функция распределения суммы. Сумма лимита, заданная в заголовке процесса, относится ко всем обязательствам собственного контрагента, а не к обязательствам только тех поставщиков, которые относятся к ведению сотрудника, работающего с реестром. Если сумма лимита распределена между несколькими сотрудниками, то в диалоге функции необходимо задавать сумму лимита, назначенную текущему сотруднику. Превышение лимита всеми пользователями приводит к отображению суммы платежа красным цветом.
При ручном редактировании сумм оплаты обязательств поставщика, нажатие кнопки Редактировать блокирует поставщика от возможного редактирования сумм оплаты другим сотрудником.
После того как сумма лимита распределена и формирование реестра окончено, пользователь, руководящий всем процессом, нажимает кнопку Создать платежные документы и закрыть реестр.
Для одной организации (собственного контрагента) для одного дня можно создать только один реестр платежей. Созданный и незавершенный экземпляр процесса имеет признак Активный. Процесс завершается генерацией документов «Платеж» с суммами к оплате из реестра платежей. Завершенный процесс не может быть изменен. Список экземпляров процесса можно увидеть в интерфейсе раздела Реестр платежей, а также в разделе Реестр процессов в группе данных Платежи (см. Том 18). В интерфейсе раздела Реестр платежей по умолчанию установлен фильтр отбора только активных реестров (Рисунок 50):

Рисунок 50 – Активные реестры платежей
Завершенные реестры могут удаляться автоматически. Для этого необходимо в административном модуле в разделе Базы данных на закладке Конфигурация в группе данных Журналы настроить опцию Автоудаление процессов «Реестр платежей» старше (дн. Удаление старых реестров осуществляется заданием «Сбор 'мусора'».
Документ «Платёж» предназначен для регистрации платежей контрагентам и для установления соответствия между фактами платежей и фактами движения товаров по накладным.
В зависимости от основания платежа и вида контрагента, платежи могут иметь следующие операции: для контрагентов поставщиков: «авансовый платеж» и «платеж»; для контрагентов клиентов: «возврат аванса», «возврат полученных денег».
Операции «авансовый платеж» и «возврат аванса» могут не иметь основания платежа в спецификации документа. Операции «платеж» и «возврат полученных денег» обязаны иметь основание платежа в спецификации документа. Допустимый тип и операции документов основания платежа зависят от операции документа Платежи.
Данный программный модуль предоставляет возможность отражать состояние взаиморасчётов с поставщиками, а также формирует документы, по которым может осуществляться оплата полученного товара.
В ТС возможно отразить либо перечисление определенной суммы поставщику, либо возврат поставщику ранее полученного от него платежа без привязки к товаросопроводительному документу (например, при предоплате по контракту), либо отразить в БД платежи в оплату одной или нескольких приходных накладных данного поставщика. В последнем случае ТС ведётся реестр оплаченных товаросопроводительных документов и, в целом, учёт состояния взаиморасчётов с поставщиком по оплаченным и ещё неоплаченным его накладным.
Как и информация по платежам полученным, данные по взаиморасчётам с поставщиками служат исходной информацией для принятия управленческих решений персоналом предприятия.
Вместе с тем, следует учесть, что действия по получению и отправке платежей, учёт денежных средств и их потоков производится бухгалтерией организации. При этом ни автоматический экспорт, ни прямой импорт данных финансовых потоков между бухгалтерской программой и ТС «Супермаг Плюс» в штатной поставке софта не предусмотрен.
Синхронизация (выверка) содержания баз данных (ТС и бухгалтерской) может поддерживаться только организационными мерами (например, ежедневной передачей менеджерам листинга бухгалтерии с расшифровкой финансовых потоков: как в оплату поступившего товара, так и получением платежей за отгруженный/приготовленный к отгрузке товар; за возврат товара и т.п.) и, в свою очередь, активным использованием работниками финансового дивизиона компании отчетов ТС, например «Графика расчёта с поставщиками», составляемого при бюджетировании бизнес-процесса.
Разработка мер по синхронизации баз данных (бухгалтерской и ТС) в части учёта финансовых потоков остаётся за пользователем.
Возможные причины рассогласования данных:
Одной из проблем является синхронизация реквизитов расчётно-платежных документов и сумм реально произведённых платежей в двух БД. Пусть в ТС для идентификации очередного платежа Поставщику А система сгенерировала номер платежного поручения 105. При экспорте данных этого платежа в бухгалтерскую программу последняя автоматически сгенерировала № 223, который не мог быть исправлен оператором вручную, так как в бухгалтерской БД уже был зарезервирован номер 105 для учёта иной хозяйственной ситуации, по которой уже составлен отчёт. Кроме того, выполнение обязательств по оплате товара (по факту) может разойтись как по дате, так и по сумме платежа с бюджетным планом организации-плательщика, которая к тому же может и дробить свои платежи (несколько платежных поручений в оплату одного счёта). Таким образом, сверка платежей с Поставщиком А (взаиморасчёты) только на основании данных ТС становится проблематичной.
Некоторые поставщики ведут взаиморасчёты в условных единицах, за которую принимают, к примеру, доллар США с пересчётом в рубли РФ по курсу ЦБ РФ (т.е. четыре знака после запятой) и плюс 1,5% по курсу USD на день оплаты. В БД справочник курсов валют может вестись с точностью до 2-х знаков, с автоматическим пересчётом стоимости товара в рубли РФ по курсу на дату его прихода – первая причина рассогласования данных учёта.
Вторая причина – если экспорт данных товарного прихода из БД «Супермаг Плюс» в бухгалтерскую программу производить в национальной валюте (например, в рублях РФ), то в бухгалтерии будет накапливаться систематическая ошибка по сумме задолженности: так как в БД не предусмотрен механизм расчета курсовых разниц, то в момент оплаты товара (к примеру, по поставкам с отсроченным платежом) сумма накладной в рублях РФ, учтённая в ТС, вследствие изменения курса USD никогда не будет равняться сумме реального платежа, разочтённого бухгалтерией в оплату товара по этой накладной резиденту РФ, если такой платёж необходимо произвести на основании первичного документа с отражением цен в нём, выраженных в у.е. и на условиях, оговоренных выше.
Информация о кредитных учреждениях регулярно обновляется ЦБ РФ и доводится до сведения коммерческих банков. Вслед за этим кредитные учреждения, как правило, автоматической рассылкой замещает соответствующие справочники у своих клиентов, поставляемые в составе систем «Банк-клиент». В ТС «Супермаг Плюс» осуществлена возможность ведения справочника «Банки» (см. Том 1), однако автоматизация импорта новых версий справочника банковских реквизитов в ТС не предусмотрена.
|
Напрямую из ТС выгрузить платежное поручение (как полностью оформленный документ) также нельзя. Можно его выгрузить только через какую-то промежуточную стадию с преобразованием экспортируемого файла в тип файла программы «Банк-Клиент». |
В зависимости от указанного типа расчёта документ «Платежи» эквивалентен либо расходному кассовому ордеру (для наличной оплаты), либо банковскому платежному поручению (для безналичной оплаты).
Документ «Платеж» имеет следующий вид (Рисунок 51):

Рисунок 51 – Платеж
Атрибуты:
В связи с изменением законодательства в части определения очередности списания денежных средств и количества категорий очередности, в платежных документах разрешается определять очередность от 1 до 5. По умолчанию предлагается очередность 5.
При открытии документов прежних версий с очередностью 6, в интерфейсе в окне очередности данные показываться не будут, но в содержании документа и при печати величина «6» будет сохранена и будет печататься. При редактировании значения очередности старого документа будут предложены значения от 1 до 5.
Документ «Платеж» имеет следующие статусы:
Для создания документа «Платеж» необходимо выполнить следующие действия:

Рисунок 52 – Создание платежа (1)

Рисунок 53 – Создание платежа (2)

Рисунок 54 – Создание платежа (3)

Рисунок 55 – Создание платежа (4)

Рисунок 56 – Создание платежа (5)

Рисунок 57 – Создание платежа (6)
6. В последнем окне диалога проверить введённую ранее информацию, установить отметку в пункте Перейти к редактированию созданного документа,если она не была там установлена (Рисунок 58):

Рисунок 58 – Создание платежа (7)
7. В заголовке сформированного документа (режим Редактировать) указать сумму платежа, сумму НДС, очередность платежа и его назначение (Рисунок 59):

Рисунок 59 – Создание платежа (8)
С помощью введенного документа-платежа можно отразить в БД оплату произвольного списка документов (номер каждого документа пользователь указывает отдельно), либо отобрать неоплаченные номенклатурные документы из списка.
Выбрать тип оплачиваемого документа (приходная накладная) и отобрать из всплывающего перечня документов требуемый номер товаросопроводительного документа (Рисунок 60):

Рисунок 60 – Оплата документа
Результат отбора документов-оснований представлен на рисунке (Рисунок 61):

Рисунок 61 – Отобранные документа
Если необходимо оплатить иной документ, то после окончания ввода оплачиваемых документов, в том числе и сумм платежей в них, документ-платеж переводится в статус Проплачен, для этого необходимо нажать либо на кнопку Проплатить, либо пользуясь кнопкой Обработать выбором опции Смена статуса. Далее, после ввода отметок документа ( и по факту реального платежа) необходимо перевести его в статус Исполнен, для чего необходимо нажать на кнопку Принять.
Для того чтобы флаг Оплата по документу Платеж в документе устанавливался автоматически необходимо установить его для места хранения. Данный флаг фактически включает или исключает накладные из учета взаиморасчетов. То есть, в случае если флаг Оплата по документу Платеж в накладной не установлен, то поле Задолженность накладной редактируется вручную без участия платежных документов и содержит окончательный результат оплаты. Такие накладные отражаются в отчетах о платежах не в виде движения стоимостей, а в виде результата (сальдо) движения по отношению к данному документу. При установлении связи с приходными накладными платежный документ вносит изменение в поле Задолженность заголовка накладной, не меняя её статус.
По кнопке Печать производится печать проектов платежных поручений. Документы можно также экспортировать с помощью кнопки Обработать, преобразовав их в любой иной документ ТС из предложенного списка.
Возможен из документа «Платеж», формирование аналогично действиям по операции платеж. Включение накладной в спецификацию платежного документа в этом случае происходит автоматически, без понижения статуса платежа. Свободная сумма авансового платежа уменьшается на сумму оплаты по накладной.
Производится также из документа «Платеж».
Производится также из документа Платеж и автоматически из меню раздела Расходных накладных Функции → Генерация платежей (см. Том 13).
Документ «Получение платежа» предназначен для регистрации факта получения платежей от контрагентов и для установления соответствия между фактами платежей и фактами движения товаров по накладным.
В зависимости от основания платежа и вида контрагента, документ может иметь следующие операции: для контрагентов-клиентов: Получение аванса и Получение платежа; для контрагентов-поставщиков – Возврат авансового платежа и Возврат платежа.
Операции Получение аванса и Возврат авансового платежа могут не иметь основания платежа в спецификации документа. Операции Получение платежа и Возврат платежа обязаны иметь основание платежа в спецификации документа. Допустимый тип и операции документов основания платежа зависят от операции документа «Получение платежей».
Раздел ТС Получение платежей предназначен для учёта входящих финансовых потоков, оплат за отгруженный оптовым и мелкооптовым покупателям товар.
В зависимости от указанного типа взаиморасчётов документ эквивалентен либо приходному кассовому ордеру (для наличной оплаты), либо банковскому платежному поручению (для безналичной оплаты).
Атрибуты документа – Рисунок 62.

Рисунок 62 – Документ «Получение платежа»
Документ имеет 4 статуса: «подготовлен», «черновик», «проплачен» и «исполнен»:
Финансовые атрибуты документа «Получение платежа» ищутся по следующему алгоритму:
Если в основании накладной имеются заказы в статусах Размещен или Закрыт, и в основании этих заказов имеются контракты с клиентами в статусе Принят или контракты с поставщиками в статусе Принят полностью, и если найден только один такой контракт, то указанные финансовые атрибуты берутся из контракта. Если таких контрактов найдено несколько или не найдено вообще, то, по-прежнему, финансовые атрибуты берутся из свойств внешнего контрагента накладной.
В диалоге редактирования штрафных санкций/отсрочки платежа по кнопке Обработать → Установить штрафные санкции содержится опция Установить штрафные санкции из контракта (Рисунок 63), в диалоге Обработать → Установить штрафные санкции, Установить отсрочку платежа содержится опция Установить отсрочку платежа из контракта (Рисунок 64). При выборе данных опций контракт ищется по описанным выше правилам.

Рисунок 63 – Установка штрафных санкций

Рисунок 64 – Установка отсрочки платежа
Для создания документа «Получение платежей» необходимо выполнить следующие действия:

Рисунок 65 – Создание документа «Получение платежей» (1)

Рисунок 66 – Создание документа «Получение платежей» (2)

Рисунок 67 – Создание документа «Получение платежей» (3)

Рисунок 68 – Создание документа «Получение платежей» (4)

Рисунок 69 – Создание документа «Получение платежей» (5)

Рисунок 70 – Создание документа «Получение платежей» (6)
Результат действий по вводу заголовка спецификации представлен на рисунке (Рисунок 71):

Рисунок 71 – Заголовок спецификации документа «Получение платежей»
С помощью введённого документа получения платежа можно зарегистрировать получение оплат произвольного списка расходных накладных. Номер каждого документа указывается отдельно, либо путём выбора неоплаченных документов из списка.
Отбор неоплаченных документов может быть произведен из списка, который выводится по кнопке в поле Номер документа в левой нижней части экрана.
Для добавления документов можно так же воспользоваться полями в нижней части экрана: непосредственно указать тип, номер и сумму документа, в результате чего оплачиваемый документ будет добавлен в список.
После нажатия кнопки Редактировать и выбора типа документа (например, расходная накладная) в правом нижнем углу экрана пользователь, установив фильтр на закладке Выбор документа отмечает накладные, по которым произведена оплата.
После окончания ввода документ переводится в статус Проплачен. Для этого необходимо нажать на кнопку Проплатить. После ввода отметок документа необходимо перевести его в статус Принят, для чего нажать на кнопку Принять.
В ТС авансовые поступления и платежи отдельно не учитываются. Получение аванса выбирается из документа Получение платежа.
Из расходной накладной на возврат товара поставщику можно уменьшить сумму задолженности по приходу по кнопке Оплата прихода. Никаких документов при этом не создается.
Если возврат необходимо оформить в виде получения платежа, то сделать это можно как из документа Получение платежа, так и автоматически из меню Генерация платежных документов.
Возврат авансового платежа рассматривается ТС как возврат платежа.
Раздел ТС |
Описание в документации |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Т |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Том 18 «Процессы и потоки работ» |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Не содержит описания разделов. Содержит описание алгоритмов и методик.
|
|
|
||
|
|
|
|
||
|
||
Том 26. |
||
|
|
|