Реализация возвратных отходов собственного производства

Бесплатный курс по 1С: Бухгалтерии

Научитесь работать в программе с нуля, получите сертификат о прохождении и бонус от Scloud!

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

В актуальных версиях 1С Бухгалтерия 8.3 документ существенно модернизировали и дали ему новое название . Причиной таких обновлений стало введение ФСБУ 5/2019 «Запасы».

Из статьи вы узнаете:

Что такое BRD для маркетплейса

Маркетплейс – это коммерческая электронная площадка, которая предоставляет товары и услуги от поставщиков. (Business Requirement Document) для маркетплейса детально описывает структуру проекта, отображает все этапы разработки: от резюме до ожидаемой прибыли.

Что включает документ бизнес требований:

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

Для начала отметьте в настройках 1С 8.3 Бухгалтерия, по какому способу списываются материалы: ФИФО или средней стоимости. Для этого перейдите Главное – Учетная политика. С помощью этой настройки программа определяет необходимость ведения учета в разрезе партий согласно учетной политике, а также выбирает, с помощью какого алгоритма выполнять списание материалов в производство.

Документ применяют при передаче запасов в:

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

Передача в производство

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

Документформируется на основании документа Поступление (акт, накладная, УПД) или через раздел Склад – Расход материалов (Требования – накладные). Нажмите , а затем укажите:

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

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

Нажмите на кнопку , включите переключатель в позицию .

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

Нажмите Перенести в документ.

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

Использование материалов заказчика

При использовании материалов третьего лица (заказчика) в документе заполняется вкладка . Такие материалы поступают на учет с оформлением документа Поступление (акты, накладные, УПД) с видом Материалы в переработку.

Шапка документа заполняется аналогично как при передаче материалов в производство. Далее перейдите на вкладку .

Укажите заказчика в поле .

Заполните табличную часть, используя или , как описано выше.

Передача материалов сотруднику

При создании документа выберите — Передача сотруднику.

В поле выберите работника из справочника Физические лица. Заполните поля.

Учитывать по сотруднику — переключатель в положение:

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

Документ с видом операции позволяет выполнять передачу спецодежды, спецоснастки, инвентаря и хозпринадлежностей (Расход и остаток), но нужно учитывать, что при проведении документ не отличает спецодежду от инвентаря и относит все на МЦ.04, что не совсем корректно, так как для спецодежды на забалансовых счетах есть счет МЦ.02.

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

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

При списании материалов в затраты для оформления заполните внизу формы состав комиссии по одноименной ссылке.

Передача тары в эксплуатацию

Вид операции Передача тары в эксплуатацию доступен, если в разделе Функциональность — Запасы установлен флажок .

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

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

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

Подробнее про Учет возвратной тары у продавца в 1С.

Мы рассмотрели, где в 1С найти требование-накладную и как его оформить с помощью документа в зависимости от поставленной задачи.

https://youtube.com/watch?v=KWvIvvoZR1c%3Ffeature%3Doembed%26wmode%3Dopaque

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 8 дней
бесплатно

Первый случай

Конфигурация Бухгалтерия предприятия, редакция 3.0. При попытке провести документ «требование-накладная» возникает ошибка:

Для целей учета НДС не списано 1,000 товара Мобильный кондиционер Ballu, счет учета: 10.09, склад: Основной склад, партия: Поступление (акт, накладная, УПД) БП-002346 от 18.09.2019 23:59:59

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

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

Посмотрим движения по регистру «Раздельный учет НДС»:

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

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

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

Пробуем провести документ. Ошибки нет.

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

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

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

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

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

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

Как сформировать документ бизнес-требований

Рассмотрим порядок действий при составлении BRD. Итак, с чего начать работу над документом бизнес-требований?

Один из важнейших разделов BRD – подробное описание объема предстоящих работ, для маркетплейса это особенно важно.

Типы BRD

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

Цели, которые основаны на времени – долгосрочные и краткосрочные.

Цели, которые основаны на производительности. Это краткосрочные цели для оценки производительности. Например, повысить производительность труда сотрудников отдела продаж на 25 % до конца первого квартала; менеджерам онлайн-магазина увеличить процент привлечения новых вендоров на 15 % в течение полугода и тому подобное.

Количественные и качественные цели.

Цели, которые ориентированы на результат и на процесс.

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

Учет малоценных объектов по ФСБУ 6/2020 в 1С

Согласно ПБУ 6/01 малоценными объектами признавались объекты, стоимостью ниже 40 тысяч рублей, а по ФСБУ 6/2020 определять малоценные объекты сможет организация исходя их принципа существенности. То есть определенного стоимостного порога нет, ее определяет каждый экономический субъект конкретно для себя.

Согласно ФСБУ 5/2019 «Запасы», которое будет обязательным для применения с отчетности за 2021 год, организации могут относить стоимость затрат на несущественные запасы и основные средства (в том числе спецодежду и спецоснастку) в затраты сразу же, в момент приобретения/создания.

Таким образом, немного конкретизируем разбивку материальных объектов по уровню существенности:

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

Запасы – существенные материалы, учитываемые на 10 счете со сроком использования менее 12 месяцев. Включаются в расходы при передаче в производство.

Основные средства – существенные МПЗ, поступающие на 08 или 07 счет, срок службы более 12 месяцев. Начисляется амортизация после ввода в эксплуатацию.

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

Для учета малоценных объектов предусмотрен отдельный счет 10.21 «Малоценные объекты».

На счете 10.21.1 будет отражаться информация по поступлению малоценных объектов

Счет 10.21.2 используется для отражения расходов на малоценные объекты (по аналогии с 02 счетом)

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

Для малоценных объектов возможно перемещение между складами, выдача сотруднику, то есть работать с ними в программе можно как и с любыми другими материалами. Главное – верно указать счет учета: 10.21.1.
Отслеживать и контролировать движение малоценных объектов можно из ОСВ по счету 10.21 в разрезе субсчетов, а также по забалансовому счету МЦ.04 и увидеть малоценные объекты, переданные сотрудникам.
Отразить передачу сотруднику можно документом Передача материалов в эксплуатацию (Склад – Передача материалов в эксплуатацию)

Или документом «Расход материалов (требование-накладная)» (Склад — Расход материалов (требование-накладная)). При выбранном в документе виде операции «Использование материалов» это обычное требование-накладная, а если выбрать видом операции «передача сотруднику», то можно выбрать в шапке сотрудника для передачи и каким способом учитывать данный малоценный объект по сотруднику – только в расход или с остатками. Счет затрат может быть указан в целом для всего документе, если определяется в шапке, а также отдельно для каждой номенклатуры, если выбрать отображение «в списке».

При выборе учета по сотруднику «Расход», будет сформирована проводка по Дт и Кт забалансового счета МЦ.04

И проводка только по Дт МЦ.04 при выборе учета «Расход и остатки»:

Для списания малоценных объектов используйте документ Списание материалов (Склад – Списание товаров, материалов) с видом операции Списание с сотрудника. В шапке укажите дату списания и сотрудника.

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

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

После проведения документа Списание товаров, материалов
получаем следующие проводки:

Материалы по теме

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

Обычно клиенты мало знакомы со всеми нюансами разработки проекта, поэтому могут упустить какие-то моменты. Назовем самые распространенные ошибки:

Выбрана неподходящая платформа. Например, бизнес планирует работать по модели маркетплейса (Multi-Vendor), а заказчик покупает лицензию для интернет-магазина с одним пользователем (CS-Cart). А это разные функционал и возможности. Поэтому покупку лицензии нужно осуществлять только, когда определитесь с бизнес-процессами.

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

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

Что дает правильно оформленный BRD

Задача исполнителя – помочь заказчику составить четкий документ бизнес-требований и структурировать всю имеющуюся информацию по будущему проекту.

Что дает правильно оформленный документ BRD:

Правильно оформленный документ бизнес-требований минимизирует ошибки в процессе реализации проекта.

Зачем заказчику документ бизнес-требований

BRD документ дает подробную структурированную информацию о будущем проекте. С помощью документа бизнес-требований заказчик решает множество проблем и страхует себя от возможных рисков при реализации проекта. По данным PMI, команды, которые начинают новые проекты без предварительного планирования, в два раза чаще терпят фиаско. Наличие развитого проектного управления помогает достичь 77 % поставленных целей, для сравнения – проекты с неразвитой системой управления достигают 56 % целей.

Что дает заказчику наличие документа с бизнес-требованиями:

План (структура) BRD для маркетплейса

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

Рассмотрим более подробно, что должен включать BRD документ для маркетплейса:

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

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

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

Как помочь заказчику в составлении документа бизнес-требований

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

Список вопросов может быть шире, мы привели лишь некоторые.

Для более точного формулирования бизнес-требований используйте уточняющие вопросы.

Кто занимается сбором первичных бизнес-требований

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

Алгоритм сбора бизнес-требований

Сбор бизнес-требований можно проводить через опросы, интервью, или в специальных сервисах, таких как Trello или Notion.

Аналитика на госпроектах – это не страшно

Время на прочтение

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

Сегодня я хотел бы поделиться с вами нашим опытом, подчеркнув, что работа аналитиком на государственных проектах не так страшна, как может показаться. Меня зовут Георгий Доделия, и я руковожу международными ИТ-проектами в компании АО «ГНИВЦ», работаю в отрасли ИТ уже более 12 лет. Начинал как бизнес-аналитик, потом проникся системным анализом, а уже после ушел в проектный менеджмент.

Небольшая справка о компании АО «ГНИВЦ»: существуем на рынке более 46 лет, штат сотрудников превышает 1700 человек, мы представлены в 8 городах Российской Федерации. Наши продукты вам хорошо известны: это и мобильные приложения для разных типов налогоплательщиков (например, личный кабинет индивидуальных предпринимателей, физических лиц, самозанятых), платформа для проверки чеков, проект реестра ЗАГС и т.п. Также в нашем ведении набор систем для внутренних нужд Федеральной налоговой службы России.

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

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

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

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

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

Пятое – достаточно устаревшие ИТ-процессы у заказчика. Например, отсутствуют роли: аналитик, тестировщик, руководители проектов. Я уж не говорю про DevOps. Разработчик поднимается «наверх» к своему руководителю (представитель «бизнеса»), получает от него задачу и идет ее реализовывать. Через неделю у него уже новая задача и так далее. Добавим, что присутствует только dev-стенд и промышленный. А разрабатывают коллеги только OLTP-системы. В рамках своего же проекта мы столкнулись с проблемой, что аналитическую систему по обнаружению нарушителей налоговой дисциплины сложно построить по одной простой причине – достаточно низкое качество данных (из-за плохой проработки бизнес-требований к системе, коллеги постоянно ее дорабатывают и генерят уйму «костылей»).

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

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

По окончании серии встреч мы сформировали требования к команде аналитики. Делимся.

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

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

Следующие договоренности лидов были в отношении рабочих объектов. Мы их назвали «рабочие элементы Jira». Всю разработку разбили по бизнес-смыслу на эпики, которые декомпозировали на «стори». А для четкого понимания прогресса по реализации той или иной «стори» приняли решение заводить sub-task для каждой из ролей. Во время работ могут появляться задачи, которые напрямую с бизнес-фичей не связаны, под них следует заводить просто task. Например, подготовка к презентации, написание ПМИ, работа с новой библиотекой. Также у команды тестирования готовятся тест-кейсы и тест-планы. Дополнительно мы заводим дефекты.

После всего этого у нас выстроился следующий производственный процесс.

Но сначала про состав ролей продуктовой команды:

· группа методологии, это бывшие сотрудники Центрального аппарата Федеральной налоговой службы России, которые перешли в АО «ГНИВЦ» и обучались на курсах продуктологов;

· аналитики: как бизнес-ориентированные, так и системно-ориентированные.

· группа разработки, состоящая из frontend, сервисного слоя и уровня данных (в своей работе мы используем подход с «озером данных»);

· команды тестировщиков (мануальных, автоматизаторов и нагрузчиков).

За базу в процессе взяты Kanban-принципы, визуализация осуществляется через Kanban-доску.

Шаг 2 – планирование задач. «Сторе» присваивается тот или иной приоритет, и она попадает в колонку «Запланировано».

Шаг 3. Из колонки запланированных задачи берутся в работу аналитиками. Аналитик начинает сбор требований, проектирование. После полной готовности сбора и проектирования, он передает свою постановку на внутреннее ревью команде аналитиков и команде методологии. Так мы поддерживаем принцип V&V — Validation and Verification.

Шаг 4. Если задача прошла ревью, она уходит в колонку «Анализ готово». При этом она должна удовлетворять требованиям Definition of Ready. Это набор критериев, которым должна удовлетворять любая постановка, чтобы считаться готовой. Например, среди постановок должен быть сценарий демонстрации, а также скорректированный с учетом работы аналитика набор критериев приемки.

Шаг 5 – разработка кода. Когда команда разработки заявляет о свободных ресурсах, назначается «стори-ревью», на котором аналитик защищает свою постановку перед командой разработки и тестирования. Задача уходит в разработку, декомпозируется, и происходит колдовство написания кода. Чтобы перевести задачу из «Разработки» в «Разработка готово», она должна удовлетворять требованиям готовности команды разработки — Definition of Done.

На этапе «Разработка» к работам подключается команда тестирования, которая формирует тестовые данные и тестовый дизайн.

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

Шаг 7. Теперь очередь команды тестирования. Перед тем как приступить к тестированию, аналитиком и продуктологом проводится тест-кейс-ревью. Это ревью тест-кейсов, чтобы понять, все ли вариации покрыты и нет ничего лишнего, чтобы не тратить время впустую. По результатам тестирования задача будет переведена в статус «Тестирование готово» при удовлетворении требованиям test-compelation criteria, так называемым критериям готовности по результатам тестирования. Например, определенное количество дефектов допустимо при некотором уровне их значимости и так далее.

Шаг 8 – подготовка релиза. Как накопилось определенное количество «сторей» в «Тестировании готово», по решению команды происходит их объединение в релиз.

Шаг 9 – релиз устанавливается на промышленный стенд. Как только установка выполнена, задачи переводятся в статус «Deployed».

Какие же артефакты готовят аналитики у нас на проекте?

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

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

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

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

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

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

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

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

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

Теперь хочется кратко рассказать о наших планах.

Во-первых, сейчас есть небольшая проблема с шаблонами документации для системных кейсов. О чем идет речь? Чтобы получить расчет или выборку, зачастую необходимо настроить ETL-процесс. Все это запихнуть в одну пользовательскую историю будет некорректно, она будет и по времени разрабатываться долго, и потянет за собой большое количество накладных расходов (начиная от контроля реализации, заканчивая долгим согласованием с заказчиком). Сейчас это заводится в виде dev-task, что не очень красиво. Мы хотим шаблонизировать артефакты для таких типов задач и по ним работать.

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

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

Второй случай

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

1. Открываем движения документа поступления. Смотрим движения по «Раздельный учет НДС».

2. Копируем название Аналитики учета затрат в буфер обмена.

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

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

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

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

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

Функциональные требования в BRD для маркетплейса и других веб-продуктов можно включить как раздел в документ бизнес-требований или вынести в отдельный документ FRD (Functional Requirements Document).

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

Например, клиент хочет, чтобы посетители магазина могли сразу на площадке рассчитать стоимость доставки в их регион. Разработчик выстраивает следующий алгоритм: система по API (Application Programming Interface, программный интерфейс, позволяющий связывать между собой различные системы) запрашивает информацию у сервиса доставки, который выбрал пользователь, (например, СДЭК или Почта России) и выдает пользователю стоимость доставки. И так по каждой бизнес-опции.

Какие требования необходимо учитывать

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

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

Какие требования защиты необходимы:

Верхнеуровневая интеграция с основными системами:

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

Масштабирование маркетплейса. Для владельца маркетплейса важно на начальном этапе определиться – намерен он в будущем масштабировать маркетплейс или нет. Если намерен, то при разработке необходимо заложить возможности для дальнейшего увеличения онлайн-магазина. Необходимо спрогнозировать какое количество пользователей и товаров будет на входе, через полгода или два года. Об особенностях продвижения маркетплейса читайте в нашем материале.

Юридические ограничения. Цифровая платформа должна отвечать требованиям законодательства и соблюдать все юридические ограничения: 44-ФЗ (Федеральный закон о контрактной системе в сфере госзакупок), налоговый режим, закон об антимонопольном регулировании маркетплейсов и агрегаторов и др. Ранее мы подробно рассказали о требованиях налогового режима для маркетплейса.

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

Вывод

Наличие документа бизнес-требований при разработке нового проекта убережет заказчика от множества проблем. У владельца бизнеса будет четкое понимание, зачем нужен данный проект и какие выгоды он принесет. У стейкхолдеров (заинтересованных лиц) будет полное представление о способах достижения поставленных целей: с указанием алгоритма действий, дедлайнов, условий взаимодействия друг с другом и т.д. Еще один важный момент – благодаря BRD вы сможете точно спланировать бюджет с учетом расходов, инвестиций, доходов.

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

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

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

Digital-агентство «Цифровой элемент» более 10 лет работает на рынке цифровых технологий. Мы выполняем проекты любой сложности и специфики.