Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

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

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

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

Именно такое решение было принято управляющим менеджментом компании «ФинансЗвезда». Причиной для внедрения новой системы послужили несколько функциональных ограничений предыдущего решения, которые не устраивали руководство компании. Необходимость внедрения новой информационной системы, которая позволяет реализовать требуемый функционал, который невозможно реализовать в исходной информационной системе, обосновывает актуальность данной работы. Используемые в организации решения производителя «1С» заменяются ERP-системой «Microsoft Dynamics NAV 2015».

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

1. Описание бизнес-процессов

1.1 Краткое описание деятельности компании «ФинансЗвезда»

Компания «ФинансЗвезда» является международным инвестиционным холдингом со штаб-квартирой в Москве и представительствами в Нью-Йорке и Киеве. В настоящее время компания «ФинансЗвезда» владеет и управляет проектами в различных областях - инвестиционный бизнес, микрофинансирование, торговая недвижимость, парфюмерно-косметическая розница.

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

1.2 Список бизнес-процессов к реализации в системе

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

1.2.1 Выдача/погашение займов

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

1.2.2 Начисление процентов по займам

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

1.2.3 Учет приходных/расходных кассовых ордеров и авансовых отчетов

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

1.2.4 Начисление и выдача заработной платы

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

1.2.5 Консолидация

Механизм консолидации не автоматизирован, поэтому операции по разным компаниям собираются вручную с помощью MS Excel. Консолидация необходима, чтобы получить общие суммы по всей компании.

1.2.6 Внесение и учет банковских выписок

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

1.2.7 Переоценка валютных операций

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

1.2.8 Закрытие месяца/года

Выполняется соответствующим заданием в системе. Необходимо для определения чистой прибыли за прошедший период.

2. Анализ покрытия описанных бизнес-процессов стандартным функционалом системы

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

2.1 Основные сведения о системе

Для того, чтобы получить четкое представление о стандартном функционале «Microsoft Dynamics NAV 2015», необходимо знать некоторые базовые принципы работы.

Рис.1 Основное окно приложения

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

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

· Строка состояния - расположена сразу под строкой заголовка. Содержит путь к странице, на которой находится пользователь и строку поиска.

· Лента - находится под строкой состояния. Содержит несколько вкладок с активными кнопками. Набор вкладок и активных кнопок на ленте меняется в зависимости от страницы, на которой находится пользователь.

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

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

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

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

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

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

На следующем рисунке представлено схематическое изображение структуры журналов:

Рис.2 Структура финансовых журналов

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

Рис.3 Финансовый журнал

Кнопка «Учёт» находится почти в самом начале Ленты в левом верхнем углу страницы.

2.2 Описание реализации бизнес-процессов стандартным функционалом системы

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

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

2.2.1 Выдача/погашение займов

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

2.2.2 Начисление процентов по займам

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

2.2.3 Учет приходных/расходных кассовых ордеров и авансовых отчетов

Учёт кассовых операций производится в журнале регистрации кассовых операций. Пользователь создает там проводку, распечатывает приходный/расходный кассовый ордер и затем учитывает операцию. (см. Приложение В и Приложение Г)

2.2.4 Начисление и выдача заработной платы

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

2.2.5 Консолидация

Для выполнения консолидации пользователь запускает стандартное задание по загрузке операций из определенной организации.

2.2.6 Внесение и учет банковских выписок

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

2.2.7 Переоценка валютных операций

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

2.2.8 Закрытие месяца/года

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

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

бизнес пользователь дизайн

3. Формирование функциональных требований

3.1 Классификация пользователей и требований

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

3.1.1 Казначеи

Заводят новых контрагентов в системе. Вводят в систему данные по банковским выпискам на странице «Финансовый журнал» системы. Затем эти данные редактируют менеджеры МСФО и УУ, назначают аналитики для каждой из проводок и учитывают в системе. Формируют проводки по выдаче и получению займов и начислению процентов по ним. Ежедневно «Казначеи» представляют руководству компании отчет, который основывается не неучтенных проводках в финансовом журнале.

3.1.2 Кассиры

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

3.1.3 Финансовые специалисты МСФО

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

3.1.4 Руководящий менеджмент

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

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

3.2 Общие функциональные требования

Таблица 1 Список общих функциональных требований

№	Описание	Тип реализации
GR01	Система должна обеспечивать регулярный и своевременный сбор и мультивалютное накопление учетных данных, формируемых в различных системах группы, в составе, обеспечивающем формирование на основании этих данных форм и раскрытий финансовой отчетности по МСФО, а также управленческой отчетности в согласованном в настоящем документе объеме.	Стандартный функционал
GR02	Система должна обеспечивать автоматическое и ручное обогащение учетных данных дополнительными сквозными аналитическими признаками в разрезах, необходимых для формирования форм и раскрытий отчетности по МСФО и управленческой отчетности в согласованном в настоящем документе объеме.	Стандартный функционал
GR03	Система должна обеспечивать возможность раздельного ведения учета по требованиям МСФО и по требованиям управленческого учета	Стандартный функционал
GR04	Система должна иметь развитую структуру ограничения прав доступа и регистрации всех событий и операций, производимых в системе. Результаты регистрации должны быть доступны для последующей проверки	Стандартный функционал
GR05	Система должна обеспечивать автоматизированную загрузку данных пользователями без участия IT-специалистов	Стандартный функционал
GR06	Система должна предоставлять данные пользователям в виде, удобном для дальнейшей самостоятельной обработки. Основным средством самостоятельной обработки табличных данных является Microsoft Excel	Стандартный функционал
GR07	Система должна также обеспечивать возможность построения сложных отчетов на основании произвольных выборок данных	Стандартный функционал
GR08	Система должна обеспечивать многоязычный многопользовательский (не менее 10 пользователей) интерфейс	Стандартный функционал
GR09	Система должна обеспечивать следующие возможности для работы с данными: просмотр, ручной ввод данных, фильтрацию, сортировку, выгрузку данных отчетов и списков (справочников, регистров, журналов).	Стандартный функционал
GR10	Система должна обеспечивать у любого объекта, загруженного из внешних источников, однозначной ссылки на этот объект-источник.	Стандартный функционал
GR11	Система должна иметь развитую структуру документирования всех операций, произведенных в системе. Для каждой операции, которая привела к изменению данных в системе, необходимо иметь возможность формирования внешнего печатного отчета, сохраняемого вне системы или фильтрацию и экспорт данных о проведенных изменениях (добавленных операциях).	Стандартный функционал
GR12	Система должна обеспечивать возможность проведения ежемесячной консолидации данных и дальнейших типов работ с этими данными, указанными в пункте GR13	Стандартный функционал
GR13	Система должна обеспечивать возможность автоматизированного начисления и учета выданных и полученных, краткосрочных и долгосрочных займов и процентов по ним.	Модификация
GR14	В системе должны быть настроены ролевые центры для разных групп пользователей	Модификация
GR15	Добавить проверку на заполнение поля «Код филиала» на страницах журналов при учете операций	Модификация
GR16	Добавить автоматическое заполнение поля «Общий тип учета» на страницах журналов при создании новой строки	Модификация
GR17	Сделать едиными для всех организаций справочники клиентов, поставщиков, банковских счетов, филиалов, курсов валют, измерений, а также всех настроечных таблиц и отчетов	Модификация

3.3 Групповые функциональные требования

3.3.1 Требования Казначеев

Таблица 2 Список функциональных требований казначеев

№	Описание	Тип реализации
TR01	Добавить поле, показывающее сальдо по журналу и сальдо документу в долларах на странице финансового журнала	Модификация
TR02	Добавить поле, показывающее сальдо по банковскому счету/кассе на списочную форму банковских счетов/касс	Модификация
TR03	Доработать задание по импорту курсов валют. Необходимо импортировать курс рубля по отношению к доллару	Модификация
TR04	Сделать автоматическим заполнение полей Бизнес-группа и НДС-группа в карточке клиента и поставщика при создании нового	Модификация
TR05	Разработать отчет "Отчёт казначея". Форма отчета присутствует	Модификация
TR06	Добавить кнопку задания Импорт курсов валют на страницу просмотра курсов валют	Модификация
TR07	Изменить правило выбора активной строки при открытии страниц курсов валют и финансового журнала. Необходимо, чтобы по умолчанию выбиралась последняя из имеющихся записей.	Модификация
TR08	Разработать консолидированный отчет "Акт сверки". Форма отчета присутствует	Модификация
TR09	Разработать консолидированный отчет "Бюджет". Форма отчета присутствует	Модификация
TR10	Разработать консолидированный отчет "Личные расходы". Форма отчета присутствует	Модификация
TR11	Настроить отчет "Акт сверки" с помощью стандартного конструктора отчетов	Модификация
TR12	Настроить отчет "Бюджет" с помощью стандартного конструктора отчетов	Модификация
TR13	Настроить отчет "Личные расходы" с помощью стандартного конструктора отчетов	Модификация

3.3.2 Требования Кассиров

Таблица 3 Список функциональных требования кассиров

№	Описание	Тип реализации
CR01	Добавить поле Код филиала в карточку авансового отчета. Обеспечить корректный учет нового поля	Модификация
CR02	Добавить поле Код филиала на страницу Журнала регистрации кассовых документов. Обеспечить корректный учет нового поля	Модификация
CR03	Изменить валюту в печатной форме кредит-ноты на USD	Модификация
CR04	Добавить поле Код филиала в карточку кредит-ноты. Обеспечить корректный учет нового поля	Модификация
CR05	Добавить страницу Книгу платежных документов на главную страницу ролевого центра всех пользователей	Модификация
CR06	Добавить поле Код филиала на страницу Книга платежных документов. Обеспечить корректное заполнение нового поля	Модификация
CR07	Разрешить изменение поля Учетная группа на странице Журнал регистрации кассовых документов	Модификация
CR08	Добавить автоматическое заполнение поля "Тип платежа" значением "Компьютерный" при создании новой строки на странице Журнал регистрации кассовых документов	Модификация
CR09	Переименовать поле "Прямая себестоимость" в карточке авансового отчета на "Сумма USD"	Модификация
CR10	Загрузить шаблоны стандартных отчетов в настроечную таблицу Настройка ГК	Модификация
CR11	Разработать отчет "Отчёт кассира ежедневный". Форма отчета присутствует.	Модификация
CR12	Разработать отчет "Отчёт кассира ежемесячный". Форма отчета присутствует	Модификация
CR13	Изменить валюту, длину полей и правила округления в печатной форме авансового отчета	Модификация

3.3.3 Требования финансовых специалистов МСФО

Таблица 4 Список функциональных требований финансовых специалистов МСФО

№	Описание	Тип реализации
FR01	Создать кнопку "Изменить операцию" на странице "Операции Главной книги" по нажатию которой, выбранная операция помещается в определенный раздел журнала. В журнале заполняются четыре строки: первая - дебет сторнирующей операции, вторая - кредит сторнирующей операции, третья - дебет исходной операции, четвертая - кредит исходной операции. Таким образом, при учете этих четырех проводок должна учесться операция, сторнирующая исходную, и операция, аналогичная исходной.	Модификация
FR02	Добавить настройку для выбора журнала, в котором будет производиться изменение проводок, перемещенных с помощью задания "Изменить операцию", на страницу "Настройка ГК"	Модификация
FR03	Добавить автоматическое открытие журнала, указываемого в настроечной таблице "Настройка ГК", после переноса операций для изменения Главной книги	Модификация
FR04	Добавить поле с датой последней операции по кредитному договору на списочную форму договоров клиента и поставщика	Модификация
FR05	Изменить правила отображения сторнированных проводок с различными значениями аналитики ADJUSTMENTS	Модификация
FR06	Изменить правила формирования стандартного отчета Акт сверки. Не выводить контрагентов с нулевым оборотом.	Модификация
FR08	Добавить настройку шаблона загрузки для строк финансового журнала	Модификация
FR09	Добавить фильтр по полю Код филиала на странице План счетов	Модификация
FR10	Добавить поля Сальдо и Сальдо USD на страницу План счетов	Модификация
FR11	Доработать задание, осуществляющее консолидацию. Добавить фильтр по разделу финансового журнала и полю Код филиала	Модификация
FR12	Добавить возможность переоценки по филиалу	Модификация
FR13	Скрывать операции закрытия периода с нулевой суммой на странице "Операции Главной книги"	Модификация
FR14	Добавить поле сумма(USD) на страницу "Операции Главной книги"	Модификация
FR15	Доработать задание, осуществляющее консолидацию. Консолидировать все суммы в долларах	Модификация
FR16	Изменить правила агрегирования сумм на странице Оборотная ведомость. Необходимо все суммы отображать в долларах	Модификация
FR17	Система должна обеспечивать учет операции уступки договоров займов между всеми типами контрагентов	Модификация

3.3.4 Требования руководящего менеджмента

Таблица 5 Список функциональных требований руководящего менеджмента

№	Описание	Тип реализации
TMR01	Исключить задваивание оборотов из-за измененных проводок в суммах аналитических отчетов	Модификация
TMR02	Настроить раскладку столбцов по месяцам для финансового отчета	Модификация
TMR03	Добавить фильтр по полю Код филиала в финансовых и аналитических отчетах.	Модификация
TMR04	Добавить поле для описания измерений на английском	Модификация
TMR05	Добавить код филиала в печатную форму акта сверки	Модификация
TMR06	Обновлять аналитические отчеты после проведения консолидации	Модификация

3.4 Требования к разрабатываемым отчетам

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

3.4.1 Отчёт кассира ежедневный

Этот отчет ежедневно предоставляется кассирами руководству компании.

Рис.4 Печатная форма ежедневного отчета кассира

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

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

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

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

1) № п/п - номер операциив таблице отчета по порядку

2) Валюта долл./евро/руб = Приход - сумма по приходному кассовому ордеру в зависимости от валюты операции

3) Валюта долл./евро/руб = Расход - сумма по расходному кассовому ордеру в зависимости от валюты операции

4) Бизнес - полное наименование значения измерения «OFFICETYPE», назначенного на проводке

5) Проект - полное наименование значения измерения «PROJECT», назначенного на проводке

6) Статья - код значения измерения «INC_EXP», назначенного на проводке

7) Подотчетник - полное наименования клиента/поставщика, участвующего в приходной/расходной операции

8) Комментарий - значение поля «Комментарий» на проводке

9) В строку «Итого за день» записываются суммы по соответствующим. Остальные поля не заполняются.

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

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

В полях «Кассир» и «Бухгалтер» записывается имя выбранных пользователем кассира и бухгалтера при запуске отчета в формате «И.О. Фамилия».

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

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

1) № п/п - номер операции в таблице отчета по порядку

2) Дата выдачи - значение поля «Дата учёта» расходного кассового ордера по выбранной кассе

3) Предполагаемая дата отчета - значение поля «Предполагаемая дата отчёта» расходного кассового ордера по выбранной кассе

4) Остаток суммы аванса - значение поля «Сумма остатка» из таблицы «Книга операций клиентов» по соответствующему расходному ордеру

5) Валюта - значение поля «Код валюты»

6) Подотчетник - полное наименование подотчетника из его карточки

7) Статус - заполняется значением «Срочно», если отчетная дата превышаем предполагаемую дата отчета более, чем на две недели. Иначе, заполняется значением «Не срочно».

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

3.4.2 Отчёт кассира ежемесячный

Этот отчет ежемесячно предоставляется кассирами руководству компании.

Рис.5 Печатная форма ежемесячного отчета кассира

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

В поле «Месяц» записывается выбранный пользователем отчетный период в формате «ДД.ММ.ГГ..ДД.ММ.ГГ»

Отчет состоит из одной таблицы в которую попадают все операции по выбранным кассам за отчетный период

1) № п/п - номер операции в таблице отчета по порядку

2) Дата - значение поля «Дата учёта»

3) Валюта долл./евро/руб = Приход - сумма по приходному кассовому ордеру в зависимости от валюты операции

4) Валюта долл./евро/руб = Расход - сумма по расходному кассовому ордеру в зависимости от валюты операции

5) Бизнес - полное наименование значения измерения «OFFICETYPE», назначенного на проводке

6) Проект - полное наименование значения измерения «PROJECT», назначенного на проводке

7) Статья - код значения измерения «INC_EXP», назначенного на проводке

8) Подотчетник - полное наименования клиента/поставщика, участвующего в приходной/расходной операции. Если проводка учтена на финансовый счёт из плана счетов прямым учетом, то поле остается незаполненным

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

10) Дата авансового отчета - значение поля «Дата учета» в авансовом отчете с номером из предыдущего поля.

11) Комментарий - значение поля «Комментарий» на проводке

12) Обменный курс долл/евро/руб - рассчитываемая величина на дату операции. Заполняется в зависимости от кода валюты операции.

13) Транзакция долл - значение поля заполняется долларовым эквивалентом суммы, если операция проведена в рублях или евро. Рассчитывается по формуле [«Приход/Расход» *умножить* «Обменный курс»]

14) Строка ИТОГО - суммирует значения в соответствующих столбцах

3.4.3 Отчёт казначея

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

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



Рис.6 Печатная форма отчета казначея

Поля «CB RF RUR» и «CB RF EUR» заполняется на основании курсов валют на отчетную дату.

В отчете существует несколько типов строк, которые имеют различные правила заполнения:

1) Строка компании - заполняется значение поля [1] полным наименованием компании из карточки клиента/поставщика. Остальные поля не заполняются

2) Строка банковского счета - у каждой из компаний существует несколько банковских счетов разных валют. В отчет попадают те банковские счета, которые используются в выбираемом пользователем разделе финансового журнала. Такие строки выделяются оранжевым цветом и жирным шрифтом. В поле [1] записывается код валюты банковского счета компании, а в поле [2] сальдо на отчетную дату по учтенным операциям в системе плюс операции по данному банковскому счету, занесенные в финансовый журнал. Остальные поля остаются незаполненными

3) Строка операции - является частичной копией операции, внесенной в финансовом журнале. Такие строки располагаются в соответствии с банковским счетом компании. Поле [1] заполняется значением поля «Код валюты» и должно соответствовать коду валюты банковского счета. Поле [2] остается незаполненным. Поля [3] и [4] заполняются из значения поля «Сумма» с учетом того, что суммы в отчете расположены по правилам банковской выписки. Поле [5] заполняется полным наименованием контрагента, участвующего в операции. Поле [6] заполняется полным наименование значения измерения «PROJECT». Поле [7] заполняется значением поля «Комментарий».

4) Строки «Итого RUR/USD/EUR» - являются суммирующими строками. Агрегируют суммы по всем банковским счетам, использованным в отчете, в соответствии с кодом валюты.

5) Строка «Всего USD» - показывает долларовый эквивалент сумм в разных валютах по всем банковским счетам присутствующим в отчете.

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

3.4.4 Акт сверки

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

Рис.7 Печатная форма акта сверки по проекту

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

1) Дата - заполняется значением поля «Дата учёта» операции

2) Комментарий - заполняется значением поля «Комментарий» операции

3) Тип операции - если одним из контрагентов является банковский счет, заполняется значением «безнал», если касса - «нал», иное - «зачет»

4) Контрагент - поля заполняются полным наименование контрагентов, участвующих в операции

5) Код валюты - значение поля «Код валюты» операции

6) Курс - заполняется если «Код валюты» не пустое значение. Рассчитывает по формуле [«Сумма» *делить* «Сумма (USD)»] если «Код валюты» = EUR, [«Сумма (USD)» *делить* «Сумма»] если «Код валюты» = RUR

7) Сумма - значение поля «Сумма» операции

8) Сумма (USD) - значение поля Сумма (USD) операции

9) Сумма над полем Сумма (USD) - сальдо на начало отчетного периода

10) Строка «Итого за период» - суммирует значения по столбцам

11) Сумма под строкой «Итого за период» - сальдо на конец отчетного периода

3.4.5 Бюджет

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



Рис.8 Печатная форма отчета «Бюджет»

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

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

3.4.6 Личные расходы

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

Рис.9 Печатная форма отчета «Личные расходы»

4. Описание реализации требуемых модификаций

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

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

4.1.1 GR13

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

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

4.1.1.1 Учет кредитов и займов в разрезе договоров

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

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

4.1.1.2 Карточки договоров

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

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

· Вкладка «Общее»:

Добавлены поля для создания копии договора сразу после его создания

Рис.10 Поля для копии договора

1) Есть копия - поле-маркер, показывающее существует ли копия просматриваемого договора в параллельном справочнике договоров Клиентов/Поставщиков

2) Создать копию договора - если это поле активно, то, при создании договора, будет создана копия договора в параллельном справочнике договоров

3) Тип контрагента копии - поле доступно для редактирования только когда активно поле «Создать копию договора». В зависимости от типа создаваемого договора (Клиент или Поставщик) выбирается тип контрагента (Поставщик или Клиент, соответственно), в справочнике которого будет создана копия редактируемого договора

4) Номер контрагента копии - в поле выбирается код контрагента-участника договора займа. В зависимости от значения в поле «Тип контрагента копии» открывается справочник Клиентов или Поставщиков.

· Вкладка «Кредиты и займы»

Добавлены поля для автоматизации работы модуля по учету кредитов/займов и начисления процентов по ним



Рис.11 Вкладка Кредиты и займы в карточке договора

1) Тип договора - выбирается значение «Кредиты и Займы», если создается договор займа.

2) Займодавец - поле доступно для редактирования, если создается договор Клиента. В поле необходимо выбрать Поставщика, который предоставляет займ по создаваемому договору займа. Поле автоматически заполняется тем же значением, если пользователь заполняет поле «Номер контрагента копии». Примечание: если пользователь создает договор Поставщика, то поле Займодавец автоматически заполняется кодом этого поставщика и выглядит как поле Заёмщик на скриншоте.

3) Заёмщик - поле доступно для редактирования, если создается договор Поставщика. В поле необходимо выбрать Клиента, который получает займ по создаваемому договору займа. Поле автоматически заполняется тем же значением, если пользователь заполняет поле «Номер контрагента копии».

4) Учетная группа процентов - в поле выбирается учетная группа, из настроек которой, автоматически выбираются финансовый счета для начисления процентов по займу.

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

6) Сумма кредитного договора - заполняется пользователем и содержит справочную информацию по договору займа.

4.1.1.3 Условия договоров

Функционал по учету договоров займов и процентов по ним включает в себя новую созданную таблицу «Кредитные условия договоров». Для того, чтобы создать условие договора, в карточке договора на Ленте выбирается «Кредитные условия»:

Рис.12 Кнопка «Кредитные условия»

После этого открывается новая страница кредитных условий текущего договора. Чтобы создать новое условие, на Ленте выбирается «Создать кредитное условие»:

Рис.13 Кнопка «Создать кредитное условие»

После этого открывается окно с параметрами для создания нового кредитного условия:

1) Дата начала - поле заполняется значением «Дата начала» из карточки договора

2) Дата окончания - поле заполняется значением «Дата начала» из карточки договора

3) Периодичность - периодичность начисления процентов по договору. Возможные значения: «День», «Месяц», «Квартал», «Год»

4) Количество дней в году - количество дней, зафиксированное в условиях заключенного договора. Влияет на расчет начисления процентов. Возможные значения: «360», «365», «Фактичекое»

Рис.14 Задание по созданию кредитного условия договора

5) Тип процентной ставки - тип начисления процентов. Возможные значения: «Простой», «Сложный»

6) Процентная ставка - величина процентной ставки

7) Пересчет неучтенных процентов - признак позволения перерасчета графика начисления процентов

8) Код валюты - заполняется значением «Код валюты» из карточки договора

9) Код филиала - заполняется значением кода контрагента по текущему договору

10) Код филиала копии - заполняется значением «Код контрагента копии» из карточки договора

11) Сумма - заполняется значением «Сумма кредитного договора» из карточки договора

12) ICO код - выбирается пользователем значение измерения ICO

13) PROJECT код - пользователем выбирается значение измерения PROJECT

4.1.1.4 Изменение условий договора

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

Для того чтобы изменить/добавить новые условия договора кредита и займа, необходимо на странице «Список кредитных условий договора» выбрать «Изменить кредитное условие», задать необходимые изменения и выбрать ОК.

4.1.1.5 Начисление процентов

Для начисления процентов по выбранному кредитному условию необходимо на странице «Список кредитных условий договора» выбрать «Начисление процентов». Необходимо наличие выданного/полученного займа, чтобы запустить задание по начислению процентов. Откроется следующее окно, в котором вводятся параметры начисления.

1) Периодичность начисления - автоматически заполняется на основе кредитного условия

2) Дата начала - задается пользователем. Указывается начальная дата для периода, за который будет проведено начисление.

3) Дата окончания - задается пользователем. Указывается конечная дата для периода, за который будет проведено начисление.

4) Пересчет - признак перерасчета начисленных процентов в связи с изменением кредитного условия или изменения суммы займа

5) Создать Фин. Журнал Строки - признак создания строк начисления в финансовом журнале для последующего учета

6) Детали в Excel - признак выгрузки в Excel проведенных расчетов по начислению процентов.



Рис.15 Задание по начисление процентов

4.1.1.6 График платежей

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

Рис.16 Страница «График договора»

1) Источник Тип - Поставщик/Клиент

2) Источник Но. - номер Поставщика или Клиента

3) Договор Но. - номер Договора

4) Условие Но. - порядковый номер условия по договору

5) Тип - опция из значений Начисление/Погашение

6) Дата - дата начисления процентов по договору в случае, если установлен Тип=Начисление. Дата погашения задолженности по договору в случае, если установлен Тип=Погашение

7) Сумма - Сумма операции в валюте деталей договора

8) Сумма (USD) - сумма в долларовом эквиваленте

9) Блокировано - признак неиспользования данной строки при обработке данных (формирование проводок по начислению процентов)

10) Обработано - признак, указывающий, что данный параметр был обработан заданием по начислению процентов

11) Учтены - признак, указывающий, что учтены финансовые проводки по начислению/погашению процентов

4.1.1.7 Автоматическое начисление процентов

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

1) Дата начала - задается пользователем. Указывается начальная дата для периода, за который будет проведено начисление.

2) Дата конца - задается пользователем. Указывается конечная дата для периода, за который будет проведено начисление.



Рис.17 Задание по автоматическому начислению процентов по всем активным договорам

3) Тип контрагента - Поставщик/Клиент

4) Код контрагента - код Поставщика/Клиента по которому будет проводиться начисление процентов. Если тип и код контрагента пустые, то начисление проводится по всем контрагентам, существующим в системе.

4.2 Групповые требования

4.2.1 FR01, FR02, FR03

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

4.2.1.1 Перенос проводок в финансовый журнал

В соответствии с требованием, на Ленте страницы «Операции Главной книги» помещается кнопка «Изменение операции».

Рис.18 Кнопка «Изменение операции»

При её нажатии открывается страница преднастроенного раздела финансового журнала. Данная настройка доступна на странице «Настройка ГК» на вкладке «Общее»:

Рис.19 Поля настройка журнала по умолчанию

Для наглядности реализации модификации далее рассматривается пример. В системе учтена проводка, соответствующая выплате клиенту TEST суммы 150000 рублей с банковского счета. Операции в Главной книге, сформировавшиеся после учета, выглядят следующим образом:

Рис.20 Операции Главной книги для переноса

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

Рис.21 Перенесенные операции Главной книги

4.2.1.2 Учёт перенесенной проводки

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

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

4.2.2 FR17

Система должна обеспечивать учет операций переуступки займов между всеми типами контрагентов. Модификация базируется на реализации требования GR13 и не может быть сделана до полной готовности модуля Кредиты и займы. Далее представлен пример проводок переуступки 3000 рублей тела займа и 100 рублей начисленных процентов по нему. Формирующиеся операции по переуступке должны соответствовать следующим строкам:

Таблица 6 Операции переуступки договора займа

Тип операции	Название счёта	Сумма
Счета Цедента
Дт	Дебиторы по прочим операциям	3100
Кт	Краткосрочные/долгосрочные займы предоставленные	-3000
Кт	Проценты по краткосрочным/долгосрочным займам начисленные	-100
Счета Должника
Дт	Краткосрочные/долгосрочные займы полученные	3000
Кт	Краткосрочные/долгосрочные займы полученные	-3000
Дт	Проценты по краткосрочным/долгосрочным займам полученным	100
Кт	Проценты по краткосрочным/долгосрочным займам полученным	-100
Счета Цессионария
Дт	Краткосрочные/долгосрочные займы предоставленные	3000
Дт	Проценты по краткосрочным/долгосрочным займам начисленные	100
Кт	Кредиторская задолженность по прочим операциям	-3100

4.2.2.1 Создание договора уступки

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

4.2.2.2 Создание договора займа

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

4.2.2.3 Формирование операций по переуступке

Создается задание, которое заполняет строки в финансовом журнале, формируя операции по переуступке. Задание вызывается на Ленте страницы списка договоров Клиента/Поставщика или, непосредственно, из карточки договора Клиента/Поставщика.

Рис.22 Кнопка «Уступка»

Для запуска задания заполняются следующие параметры:

1) Тип Цедента - Поставщик по умолчанию

2) Номер Цедента - код Поставщика, предоставляющего займ. Заполняется автоматически на основании поля «Займодавец» в карточке договора