Кейсы

Заказчик: оптовый поставщик товаров для сетевых магазинов («Магнит косметик», «Лента», «Окей» и т.д.). Компания имеет разветвленную торговую сеть, представленную фирменными отделами в крупных торговых центрах и собственным интернет-магазином. Кроме того, продукция компании продается на всех популярных маркетплейсах.

Описание ситуации
Компания-заказчик пользуется доработанной конфигурацией программы 1С:УПП.
Объем базы данных заказчика составляет более 7 ТБ. Единовременно с базой может работать порядка 150 – 200 пользователей. А количество записей в некоторых регистрах сведений может превышать 500 млн. Кроме этого, в работе используется много регистров с количеством записей более 100 млн. В некоторых случаях реструктуризация выполняется посредством SQL сервера, потому что средствами платформы это сделать невозможно.
Поэтому силами заказчика была создана собственная самописная обменная система: 1С Обменная, Управление роботами, которая осуществляет контроль состояния практически всех обменов.
Расчеты потребности в товарных запасах для всей сети магазинов выполняют 10 серверов. За каждым из них закреплены свои задачи. В обменной системе можно видеть график загрузки серверов и логи выполнения каждого обмена. Помимо обменной системы используется шина данных IRIS.
Для расчета потребности в товарах всей сети магазинов используется система управления товарными запасами. Она представляет собой комплексное решение, поддерживающее процесс формирования заказов, пополнения магазинов со складов, распределения излишков между магазинами.

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

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

После проведенной доработки в состав контура вошли:
1. Хранилище УТЗ – БД MMStorage на MSSQL Server;
2. Хранилище цен – БД Prices на MSSQL Server;
3. Куб – OLAP Cube MMStorage на Microsoft Analysis Services;
4. WC – БД Oracle (Кассовое ПО, самописка на базе 1С) WinCash – актуальные остатки магазинов;
5. БД УПП – БД MSSQL УПП;
6. БД УТЗ Дата – история рассчитанных документов УТЗ, в которой хранятся документы 1С, ее размер 4ТБ (не входит в состав УПП).
Когда создается установка цен номенклатуры (УЦН) определенного типа, робот на их основе готовит документ управления акциями с определенным коэффициентом. После окончания маркетинговой акции, робот рассчитывает эффективность акции. Учитываются продажи за указанный период.

Существует робот выхода из акций, который уведомляет менеджера марки товара об окончании маркетинговой акции и автоматически возвращает цены, которые были до акции.
Также имеются возможности:
● совмещения акций;
● установления акций с прерванным периодом;
● установления точечных акций;
● установления акций, имеющих разные приоритеты.
Куб рассчитывает прогноз на каждую позицию по каждому магазину на будущий период, с учетом прошлого периода и очищения влияния сезонности и акций. Распределение товарных запасов осуществляется поэтапно в определенной последовательности.

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

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

Заказчик: компания, занимающаяся розничной торговлей запасными частями для автомобилей (NDA).


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


Решение
В качестве учетной системы была выбрана программа 1С:Управление торговлей, поскольку в ней предусмотрен функционал для автоматизации бизнес-процессов заказчика и интеграции с торговым оборудованием и системой «Честный знак».


В ходе проекта были решены следующие задачи:

• «с нуля» внедрена система «1С:Управление торговлей, ред. 10.3», произведены первоначальные настройки;
• подключено и настроено торговое оборудование;
• все магазины сети подключены к системе «Честный знак»;
• разработан новые отчеты, обработки и печатные формы по запросу заказчика;
• проведено обучение для сотрудников по работе в 1С:УТ.

После завершения внедрения мы перешли к сопровождению системы, которое включало в себя:

• обновление платформы 1С на рабочих местах и серверах;
• поддержку нетиповой (доработанной конфигурации) 1С:УТ в актуальном состоянии.

Результат проделанной работы

1. Торговля ведется в соответствии с законодательством о маркировке, благодаря чему заказчик защищен от штрафов за продажу контрафактной продукции.
2. Автоматизация процессов и использование сканеров позволило сократить время на обработку и учет товаров на 20%.
3. Отчеты, разработанные под нужды заказчика, позволяют руководству оперативно получать данные и принимать управленческие решения.

Заказчик: компания, занимающаяся розничной торговлей запасными частями для автомобилей (NDA).


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


Решение
В качестве учетной системы была выбрана программа 1С:Управление торговлей, поскольку в ней предусмотрен функционал для автоматизации бизнес-процессов заказчика и интеграции с торговым оборудованием и системой «Честный знак».


В ходе проекта были решены следующие задачи:

• «с нуля» внедрена система «1С:Управление торговлей, ред. 10.3», произведены первоначальные настройки;
• подключено и настроено торговое оборудование;
• все магазины сети подключены к системе «Честный знак»;
• разработан новые отчеты, обработки и печатные формы по запросу заказчика;
• проведено обучение для сотрудников по работе в 1С:УТ.

После завершения внедрения мы перешли к сопровождению системы, которое включало в себя:

• обновление платформы 1С на рабочих местах и серверах;
• поддержку нетиповой (доработанной конфигурации) 1С:УТ в актуальном состоянии.

Результат проделанной работы

1. Торговля ведется в соответствии с законодательством о маркировке, благодаря чему заказчик защищен от штрафов за продажу контрафактной продукции.
2. Автоматизация процессов и использование сканеров позволило сократить время на обработку и учет товаров на 20%.
3. Отчеты, разработанные под нужды заказчика, позволяют руководству оперативно получать данные и принимать управленческие решения.

Заказчик: торговый холдинг, имеющий производство в Китае и розничные торговые сети более чем в 100 городах России.

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

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

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

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


Задачи

1. Доработать и интегрировать программное приложение «Склад 15 с Кировкой» с системой 1С:ERP.
2. Разработать процессы приемки и отгрузки продукции на фабриках в Китае.
3. Настроить проверку кодов маркировки по статусам.

Для решения этих задач были привлечены специалисты NETI, чтобы координировать работы по внедрению нового приложения и готовить технические задания, выступая связующим звеном между разработчиками Клеверенс и программистами 1С:ERP, которые дорабатывали систему.

К новому приложению были предъявлены обязательные требования:
1. приложение должно считывать коды маркировки:

• на только что произведенных товарах, которые фасовщики укладывают в коробки,
• на упаковках-коробах, отгружаемых с производства;

2. при каждом сканировании должна происходить проверка статуса и владельца:

• не был ли код ранее перевезен за границу и введен в оборот,
• принадлежит ли код организации, на которую оформлен документ отгрузки;

3. вся информация должна отражаться в программе 1С:ERP.


Реализация проекта
На начальном этапе специалисты Neti:

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

После согласования технических заданий:

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

Разработка проводилась по двум процессам: приемке и отгрузке продукции на фабриках.
Приемка — это первое сканирование на производстве, когда сошедший с конвейера товар упаковывают в коробку.

Отгрузка — это второе сканирование, когда пришедший с фабрики груз с продукцией одного артикула, разного размера или объема загружают в контейнер для перевозки в Россию.
Также внедрялся контроль статусов при сканировании. Если будет считан код маркировки, который еще не зарегистрирован в Государственной информационной системе мониторинга товаров в России (ГИС МТ) или уже выведен из оборота, то приложение сообщит, что код невалидный. Такую коробку пользователь должен отложить или передать менеджерам, чтобы получить новый код.


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

• Двойные согласования

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

• Переобучение китайских пользователей

Непосредственные пользователи терминалов сбора данных (ТСД): кладовщики и другие сотрудники говорят только на китайском языке. Поэтому сложность состояла в том, чтобы научить фабрики работать с новым приложением. Чтобы минимизировать количество ошибок из-за человеческого фактора, наши специалисты готовили инструкции, а отдел внешней логистики компании-заказчика переводил их на китайский язык и доносил до пользователей. Сотрудники складов с трудом принимали новые условия. Кроме знакомства с новым приложением, им предстояло сканировать товары перед упаковкой в коробки. Это осложняло работу и занимало больше времени.
Учитывая то, что каждая фабрика — отдельный подрядчик заказчика, со всеми нужно было договориться и переобучить пользователей.

• Слабый интернет на фабриках

Большинство китайских производств заказчика находится на фабриках, которые расположены в местах, где интернет или слабый, или совсем отсутствует. Каналов проводной связи с интернетом в помещениях нет, а без интернета работать невозможно. При каждом сканировании приложение обращается к базе 1С:ERP, где хранится информация по кодам маркировки. Сотрудникам приходится с телефона с помощью функции Wi-Fi раздавать интернет, чтобы подключить терминалы сбора данных для работы. Поэтому на некоторых фабриках нет возможности внедрить полноценный контроль кодов маркировки по статусам. Для этого случая был установлен следующий порядок работы. Кладовщики считывают коды маркировки и отправляют их в ERP-систему, не получая ответы от базы. После этого менеджер логистики с помощью внешнего отчета проверяет считанные коды в 1С:ERP и сообщает на фабрику о результатах отгрузки, чтобы можно было отпустить машину для дальнейшей транспортировки продукции.

• Покупка и перепрошивка ТСД

Коронавирусные ограничения также внесли в проект свои коррективы. До закрытия границ заказчик планировал отправить терминалы сбора данных с новым приложением из Москвы в Китай. Когда начался локдаун, стало понятно, что доставка займет больше времени, чем ожидалось. На фабриках работали по 1–2 терминала, но этого было мало. Каждое дополнительное сканирование увеличивало время отгрузки товаров, и без новых ТСД обойтись было нельзя.
В связи с тем, что границы были закрыты, пришлось искать новые терминалы сбора данных на китайском рынке. Когда похожее устройство нашлось, представители заказчика занимались переговорами о покупке новых партий ТСД, а специалисты Neti перепрошивали первые китайские устройства на русский язык и устанавливали программу «Склад 15 с Кировкой».
В связи с тем, что эти процедуры заняли дополнительное время, время реализации проекта увеличилось, а заказчик понес непредвиденные расходы.


Результат проделанной работы

1. Сейчас на фабриках заказчика терминалы сбора данных работают на новом приложении от компании Клеверенс — «Склад 15 с Кировкой». С его помощью происходит проверка кодов маркировки при отгрузке. При этом, количество учетных ошибок значительно снизилось. Раньше из-за допущенных ошибок при маркировке на производстве, поступающая в розничные магазины готовая продукция, могла иметь невалидные коды маркировок. С внедрением нового программного обеспечения появилась возможность исключать появление таких ошибок сразу на фабрике.
2. На некоторых фабриках Китая из-за слабого сигнала интернета отсутствует техническая возможность включать онлайн-проверку кодов по статусам, поэтому был внедрен новый отчет в 1C:ERP Он формируется после того, как сотрудник фабрики отсканировал продукцию и выгрузил данные из ТСД в базу. Затем менеджер логистики проверяет в сформированном отчете коды маркировки (валидные они или нет). Благодаря дополнительному контролю исключаются ошибки и ускоряется дальнейшая логистика товара.
3. Сотрудники нашей компании продолжают вести этот проект: работают с обращениями пользователей, исправляют ошибки, взаимодействуют с разработчиками 1С и компанией Клеверенс.

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

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

Описание ситуации
К нам обратилась компания. Ее основное направление деятельности – торговля строительной техникой и промышленным оборудованием через B2B-маркетплейс. Однако на их сайт приходят и простые покупатели, то есть не юридические лица. Таким покупателям проще оплатить покупку не через расчетный счет, а сразу с карты. Именно для этой группы покупателей наш заказчик настроил платежи через ЮKаssа.

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

На момент обращения у компании-заказчика типовые конфигурации интегрировались с сервисом ЮKassa через сервис 1С (pay.1c.ru/yookassa). При заказе товара физическим лицом через маркетплейс сначала формировался запрос в 1С, а процесс оформления заказа происходил следующим образом:

1. клиент оформлял заказ на маркетплейсе;
2. менеджер по продажам, получив данный заказ, направлял его через сервис 1С в платежную систему ЮKassa;
3. после этого наступала очередь оплаты заказа.
4. В связи с тем, что работа менеджера по продажам в компании ограничена его рабочим временем, а оформление заказа на сайте маркетплейса происходит круглосуточно, то процедура подготовки документа на оплату зависела от сроков его формирования менеджером в сервисе 1С, что существенно замедляло процесс оплаты заказа.

Задача
Максимально ускорить процедуру оплаты заказа на маркетплейсе для покупателей физических лиц и оптимизировать процесс получения данных компанией-заказчиком о совершенной покупке (чеке) с помощью платежной системы ЮKassа.


Реализация проекта

1. Сначала был создан регистр сведений для хранения идентификаторов платежей в «Ю Kassa» по заказам клиента, статусу выполнения и типу операции (платеж от клиента или возврат клиенту).
2. Затем, для выполнения задания по расписанию, была создана внешняя обработка.

Внешняя обработка по заранее заданному расписанию получает данные по необработанным платежам из нового регистра сведений и через API проверяет статус платежа в сервисе. Если платеж выполнен, то создается типовой документ «Операция по ЮKassa», загружаются данные чека. Для настроек создания документа «Операция по ЮKassa» использовался типовой справочник «Настройки ЮKassa».

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


Результат проделанной работы
В итоге заказчик получил:

• оптимизированную процедуру учета оплаты заказов и получения данных о совершенных покупках (чеках) по покупателям-физическим лицам на площадке маркетплейса напрямую от платежной системы ЮKassa;
• исключено влияние человеческого фактора в процедуре оплаты заказа на маркетплейсе (документ на оплату заказа формируется автоматически, без участия менеджера по продажам);
• финансовую выгоду, связанную с отключением лишнего сервиса 1С, требующего подписки.

Заказчик: B2B маркетплейс (производство оснастки, продажа и аренда оборудования)

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

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


Задача

1. Оперативная помощь в устранении ошибок в работе системы.
2. Анализ и удаление дублей.
3. Настройка платежного календаря.
4. Помощь при выполнении регламентных операций закрытия месяца, квартала, года.

Реализация проекта

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

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

Обработка позволила привести в соответствие более 50 % проблемных данных. Для тех ситуаций, когда механизм «принудительного перехода» по результатам обработки данных не выполнился в нужном объеме, мы дополнительно разработали функционал сверки и выравнивания остатков на основании ранее сформированных в системе актов сверок.
*Для справки: Оффлайн-режим взаиморасчетов подразумевает, что картину расчетов можно увидеть после выполнения фонового задания по расписанию, т.е. отложенный расчет. Онлайн-режим позволяет видеть актуальные расчеты сразу же после проведения любого документа.

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

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

• Вариант 1. На одного и того же клиента заводилось по несколько карточек. В этих карточках взаиморасчеты могли дублироваться, а могли и полностью различаться.
• Вариант 2. Выявлялись карточки с одинаковыми данными, а при проверке выяснялось, что это совершенно разные люди или компании.
• Вариант 3. Различные вариации первого и второго вариантов.

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

Обработка поиска дублей позволила:

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

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

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

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

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

4. Закрытие месяца
После некорректного обновления заказчик долгое время пытался выровнять взаиморасчеты своими силами, перепроводя документы закрытых периодов вплоть до 2015 года. Как результат: процедуры закрытия месяца и расчет себестоимости перестали быть актуальными.
При выполнении регламентных операций закрытия месяца наша команда выявила большое количество ошибок.
Например:

• Некорректные остатки по финансовым регистрам взаиморасчетов.
• Отрицательные остатки товаров.
• Нераспределенные на себестоимость остатки расходов по компании.
• Отрицательные остатки партий в регистре себестоимости по компании.
• Ненулевые остатки по суммам при нулевом остатке по количеству в регистре себестоимости.
• Разные знаки у остатков по суммам и остатка по количеству в регистре себестоимости.

Что мы сделали, чтобы исправить данную проблему:

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

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

Заказчик: компания ComPortal — крупнейший поставщик на рынке ИТ в Казахстане. Организация продает компьютерное оборудование и программное обеспечение. Клиенты компании — оптовые и розничные покупатели.


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

Раньше менеджеры отгружали коды активации в ручном режиме. Клиент просил ключи, менеджеры заводили документы в 1С, находили в Excel подходящие коды, формировали закрывающие документы и передавали весь пакет клиенту.


Задачи

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

Реализация проекта
Погрузившись в задачу, проектная команда обсуждала и уточняла требования ТЗ и дорабатывала 1С. Во время онлайн-встреч проговаривали, как должны работать учетные процессы вплоть до деталей.
Параллельно отдел Битрикс-разработки ComPortal дополнял техзадание, чтобы интегрировать новый функционал с интернет-магазином.

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

Несколько подзадач, которые решались в ходе проекта:

• Автоматизация множественной загрузки и учета ключей в 1С из почтовых писем.
• Автоматическое создание документов реализации в 1С и отправка печатных форм заказчику вместе с лицензионными ключами при продаже.
• Разработка программного интерфейса на веб-сервисах 1С.
• Разработка почтовых уведомлений для клиентов о заказах.
• Разработка новых менеджерских отчетов по продажам.

Общие трудозатраты по проекту составили 843 часа.


Результат проделанной работы

1. Розничные клиенты ComPortal больше не звонят менеджерам для покупки ключей к ПО. Вместо это они покупают ключи в пару кликов в интернет-магазине, не тратя лишнее время.
2. Оптовые клиенты интегрировали свои учетные программы с 1С ComPortal и теперь отправляют запросы на покупку ПО прямо из своих систем. Они могут печатать коды активации на кассовом чеке и отдавать их покупателям при покупке, не придумывая дополнительные способы передачи ключей.
3. За менеджерами осталась только функция наполнения системы ключами. Им нужно просто выбрать письма, из которых взять данные. Ключи загружаются в систему автоматически.
4. Пакет документов, печатные формы и лицензионные данные формируются и отправляются покупателям автоматически. Для этого менеджеры делают несколько кликов.
5. Менеджерам стало проще формировать наклейки для физической продажи ПО. Ключи с описанием теперь есть в системе в виде таблицы.

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

«Разработка целой подсистемы — редкая, но творческая задача, требующая серьезного погружения и уровня ответственности. Приятно работать в гибкой и отзывчивой команде, когда люди готовы слышать доводы и менять принятые решения, если какие-то вещи нужно делать не так, как задумывалось,» — Мавлюд, руководитель проекта в ComPortal

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


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

В процессе формирования задач было выявлено следующее:

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

Задачи

1. Автоматизировать процесс создания электронных документов при записи объектов учета.
2. Автоматизировать процесс подписания созданных электронных документов.
3. Разработать инструмент для управления настройками функциональности.
4. Разработать список для просмотра состояния создания и подписания электронных документов.
5. Автоматизировать обработку ошибок при создании и подписании документов и отобразить состояние проверки в списке.
6. При разработке предусмотреть возможность добавления других объектов учета в будущем.

Реализация проекта
Для работы с электронным документооборотом заказчик использует «1С ЭДО» внутри конфигурации «1С:Управление торговлей».

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

По итогам анализа определено:

• создание и подписание документов возможно на сервере, для этого можно использовать интерфейс библиотек БСП и БЭД;
• для использования серверной подписи, необходимо установить пароль контейнера в программе крипто провайдера.

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

Для удобства просмотра очереди пользователями мы добавили цветовую индикацию записей, при двойном клике на ошибку в отдельном окне открывается её описание (рис. 1 «Очередь администратора»).

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

Таким образом, каждый пользователь, работающий с учетными документами, может из одного окна исправить ошибки и вернуть документ к обработке, без вмешательства администратора.
Для того, чтобы узнать какой именно сертификат подписи использовать при подписании того или иного объекта учета, мы создали регистр с настройками, в котором по организации, подразделению и типу объекта учета определен необходимый сертификат (рис. 3 «Настройки учетных записей»).

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

Для удобства управления функциональностью создана форма, в которой можно указать общие настройки обработки документов, дополнительный отбор объектов учета или отключить функциональность полностью. Кроме того, в этой форме можно просмотреть список очереди и настройки выбора сертификатов (рис. 5 «Управление подписанием ЭДО»).

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


Результат проделанной работы

1. Создана функциональность, позволяющая при записи определенных документов в базе, автоматически создавать на их основании электронные документы и сразу же подписывать автоматически выбранным сертификатом нужной подписи.
2. Созданы инструменты для просмотра состояния создания и подписания электронных документов, а также для управления различными настройками функциональности.
3. Модули и программный интерфейс функциональности разработаны таким образом, чтобы можно было легко добавить новый объект учета к обработке.
4. Для хранения сертификатов подписей, выбора типов электронных документов и их дальнейшей отправки использовались уже имеющиеся в конфигурации объекты и библиотеки.
5. Была автоматизирована работа сразу нескольких сотрудников, что избавило их от выполнения монотонной и рутинной работы, занимавшей длительное время.

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

Заказчик: логистическая компания, которая оказывает, в том числе, предоставляет автомобили в лизинг.


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

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


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


Реализация проекта
Заказчик работает на доработанной 1С:Бухгалтерия КОРП 3.0. Компания заранее перешла на управляемые формы и обновила версию БСП, где есть типовой справочник, нужные сертификаты и компонента для шифрования XML.

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

1. научить 1С получать XML и разбирать его на значения;
2. отправлять свой XML с правильными тегами и значениями.

Мы ориентировались на инструкцию СЭП и примеры файлов XSD и XML, которые дал заказчик. Опираясь на них, собирали проверочные XML и настраивали обмены.

• Ошибки СЭП

В ходе проекта возникали технические трудности. Например, в СЭП отправляется большой запрос на 50 тегов, а в ответ возвращается ошибка о неверном формате параметра. Система не дает комментариев: какой параметр, какой тег, какая ошибка — вместо этого выводится сообщение без подробностей (рис. 1 «Ошибки СЭП»).

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

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

• Прием транспорта в собственность

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

Как было раньше: пользователь заходил на портал СЭП в личный кабинет. Искал заявление, по которому пришло письмо, открывал форму подтверждения и вводил код. После этого транспорт переходил в собственность компании.
Как стало: мы добавили в 1С парсер писем СЭП. Если в письме есть номер заявления, часть номера ПТС, VIN транспортного средства и код подтверждения, все это сохраняется в регистрах (рис. 2).

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

• Передача транспорта в лизинг

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

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

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

• Получение выписки из ЭПТС

Еще одна частая операция — получение PDF-выписки из базы данных СЭП.

Как было раньше: сотрудники заходили на портал, авторизовывались и запрашивали сведения об автомобиле. Из-за медленной скорости сайта поиск и загрузка одной выписки занимали около 10 минут.
Как стало: сотрудникам больше не нужно заходить на портал и делать поиск по базе. Теперь они отправляют запрос из 1С и всего через минуту получают PDF-выписку (рис. 4).

Выписки из ЭПТС хранятся в 1С в виде PDF-файлов.
Одна минута — минимально возможное время этой операции. Когда 1С отправляет запрос, СЭП в ответ дает номер очереди. Через минуту 1С спрашивает, готов ли результат, и СЭП его отправляет. Если посылать запросы чаще, чем раз в минуту, система их блокирует.
Таким образом, время получения выписок сократилось с 10 до 2–3 минут.

• Прекращение лизинга

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

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

• Персональные уведомления сотрудникам

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

Как было раньше: письмо СЭП приходило на общую почту, зарегистрированную в личном кабинете портала. Ответственные сотрудники проверяли один электронный ящик и искали заявления на подопечные автомобили. После этого они шли на сайт СЭП и проводили соответствующие операции.
Как стало: мы настроили персональные уведомления для ответственных сотрудников. В письмах СЭП указываются данные паспортов автомобилей. Когда 1С парсит эти данные, она находит по ним ответственного и отправляет ему письмо. Благодаря этому сотрудник узнает, что его транспортное средство поменяло статус, например, ушло в лизинг или передано в собственность. После этого он подтверждает полученные заявления в 1С. Информация сразу отправляется в базу данных, и пользователю больше не нужно заходить в личный кабинет СЭП (рис. 5).

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


Результат проделанной работы
Сотрудники заказчика стали тратить меньше времени на работу с системой электронных ПТС. Если раньше на создание заявления через портал уходило около 10 минут, сейчас тот же результат можно получить за 2–3 минуты.

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

Заказчик: международная логистическая компания.


Описание ситуации
К нам обратилась международная логистическая компания, один из лидеров российского логистического рынка. Она предоставляет полный комплекс услуг по управлению цепочкой поставок, таких как: складирование, перевозки всеми видами транспорта, упаковка и расфасовка, таможенное оформление. Штат сотрудников насчитывает порядка 5000 человек.
Компания-заказчик является юридическим лицом. В соответствии с новыми изменениями законодательства у нее возникла необходимость, начиная с января 2023 года, сдавать новый регламентированный отчет «Уведомление об исчисленных суммах налогов, авансовых платежей по налогам, сборов, страховых взносов».

Заказчик использует конфигурацию 1С:Зарплата и управление персоналом КОРП, для которой фирма 1С разработала решение по сдаче нового регламентированного отчета, но посредством синхронизации с 1С:Бухгалтерией, и сдачей отчета из бухгалтерской программы.


Задачи

1. Реализовать в конфигурации 1С:ЗУП алгоритм формирования уведомления об исчисленных суммах налогов, авансовых платежей по налогам, сборов, страховых взносов в электронной форме.
2. Предусмотреть возможность ручной проверки и корректировки полученного результата.
3. Осуществить возможность последующей выгрузки xml-файла уведомления в Контур.

Реализация проекта
На начальном этапе были проанализированы рекомендации 1С и Федеральной налоговой службы по заполнению нового регламентированного отчета. Был произведен поиск возможного готового решения под текущий запрос. Итоговым решением стала доработка конфигурации 1С:ЗУП.

Для составления технического задания была использована информация из приказа ФНС России от 02.11.2022 № ЕД-7-8/1047@ «Об утверждении формы, порядка заполнения и формата представления уведомления об исчисленных суммах налогов, авансовых платежей по налогам, сборов, страховым взносам в электронной форме» (Зарегистрировано в Минюсте России 06.12.2022 N 71387).
В приказе описаны конкретные требования к файлу для электронной сдачи отчета, по которым также реализована загрузка отчета в Контур.
Диаграмма структуры файла обмена из приказа показана на рис. 1.

Основой для написания технического требования послужил раздел II «Описание файла обмена» Приказа ФНС. Также потребовалось внести корректировки для адаптации информации под конфигурацию 1С:ЗУП, а именно: указать конкретные места хранения нужных данных.
Основная задача заключалась в создании конечного документа-уведомления, который будет заполняться автоматически путем получения и сбора необходимых данных для формирования xml-файла. Для этого пользователь должен выбрать отчетный месяц, организацию и нажать на кнопку «Заполнить». После этого заполняются данные шапки и табличной части, как показано на рис. 2.

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

Табличная часть заполняется данными из документов «Отражение удержанного НДФЛ в бухучете» и «Отражение зарплаты в бухучете» (поля: Сумма налога, КПП, ОКТМО и КБК).
В случае, если в документе нет этих данных (например, КПП, ОКТМО и КБК не указываются явно в документе «Отражение зарплаты в бухучете»), то используются данные из ИФНС головной организации (РС История регистраций в налоговом органе).

А для хранения значений КБК был реализован отдельный вспомогательный регистр сведений.
Поля «Период налога», «Номер месяца» и «Отчетный год» заполняются по правилам из приказа ФНС исходя из выбранного отчетного месяца.
После автоматического заполнения документа пользователи, при необходимости, имеют возможность внести правки в любое из полей документа.
После сохранения документа нажатием кнопки «Сохранить файл» выбирается каталог для сохранения на компьютер пользователя xml-файла заданной структуры.

Итоговый файл имеет стандартную структуру и подходит для загрузки в различные сервисы ЭДО с контролирующими органами, а в текущем случае – в Контур.


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

Реализованный механизм позволил:

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

Заказчик
Международная логистическая компания, один из лидеров российского логистического рынка. Компания предоставляет полный комплекс услуг по управлению цепочкой поставок, таких как складирование, перевозки всеми видами транспорта, упаковка и расфасовка, таможенное оформление. Штат сотрудников 5000 человек.


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

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

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


Задачи

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

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

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

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

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

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

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

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

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

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

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

Заказчик
Логистическая компания


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

Заказчик работает в конфигурации «1С:Документооборот КОРП 2.1», для управленческого учета использует SAP. Точкой создания контрагентов является «1С:Документооборот», где они проверяются службой безопасности. После проверки службой безопасности подписанные договорные документы с контрагентами выгружаются в SAP.

В рамках работы с контрагентами заказчик столкнулся со следующими трудностями:

• при регистрации контрагентов в программе случались ошибки, связанные с человеческим фактором. А именно: пользователи могли некорректно завести данные контрагента. Указывали неправильные реквизиты или не всегда заполняли обязательные реквизиты для выгрузки в SAP. Случалось, что создавали дубли контрагентов.
• создание контрагентов было возможно двумя способами: через стандартный механизм «1С:Документооборот» или через обработку для отправки контрагента на проверку. При этом, в обоих случаях оставалась возможность создавать документы с контрагентами, не одобренными службой безопасности. Поэтому существовал риск заключения договора с неблагонадежным клиентом.
• при загрузке данных по договорным документам с контрагентами в системе SAP существует обязательный для заполнения перечень реквизитов. Из-за некорректного или неполного заполнения реквизитов контрагента загрузка договорных документов с контрагентами очень часто происходила с ошибками.
• для выгрузки договорного документа с контрагентом в SAP требуется ручная проверка наличия его скан-копии (даже если этот документ был подписан электронно, а в карточке есть вложенный файл, подписанный через ЭДО). Эта проверка значительно замедляет процесс отправки в SAP.

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


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


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

• Устранение ошибок при регистрации контрагентов в системе «1С:Документооборот»

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

Дополнительно для всех пользователей введен запрет на создание контрагентов не через сервис «1С:Контрагент» по юрлицам и ИП. Исключение сделано для пользователей, имеющих специальные полномочия. Поэтому у большинства пользователей активна только кнопка «Заполнить по ИНН» и ряд реквизитов, которые требуется заполнить вручную.
Реквизиты, которые заполняются через сервис «1С:Контрагент» (ИНН, КПП, ОГРН(ИП), Наименование, Полное наименование, Юридический адрес) недоступны для редактирования рядовым пользователям.
Изменение этих реквизитов возможно только пользователем, имеющим дополнительно определенные полномочия, или через специально созданный вид документа «Изменение контрагента», в котором можно изменить юридический адрес, наименование, полное наименование и КПП.
При регистрации этого вида документа, изменения транслируются в карточку контрагента в «1С:Документооборот» и выгружаются в SAP.

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

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

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

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

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

Реализована проверка на повторное рассмотрение службой безопасности контрагентов. Отправка возможна только по другому виду взаимоотношений организации и контрагента (например: был клиентом, стал поставщиком).

• Проведены работы для корректной выгрузки договорного документа и контрагента в SAP

1. Доработан функционал проверки обязательных для заполнения реквизитов, настроен мэппинг.
2. Разработан функционал автоматической выгрузки договорного документа и контрагента в SAP после завершения процесса обработки документа (завершения последней задачи на юридический отдел по проверке скан-копии документа). При этом, если договорный документ был подписан через ЭДО, тогда задача на юридический отдел по проверке наличия скан-копии подписанного документа автоматически закрывается по правилам эскалации, когда в «1С:Документооборот» будет загружен файл, подписанный через ЭДО обеими сторонами договорного документа.

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

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

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

Заказчик
Производственная компания


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

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

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


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

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

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

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


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

Существует четыре варианта контроля оплаты:

1. оплата до обеспечения в заказе, которая не позволяет проставить сроки к обеспечению и резервированию без наличия в заказе соответствующего процента оплаты;
2. оплата до отгрузки, не позволяющая проставить сроки товаров к отгрузке без соответствующего процента оплаты в заказе;
3. оплата после отгрузки;
4. оплата независимо от отгрузки, которая не контролируется.

Правила оплаты отражаются в регистре накопления плановой оплаты клиентов в конфигураторе, который называется «Расчеты с клиентами. План оплат» (рис. 1).


Механизм резервирования товара и запись в регистр сведений 1С ЕРП
Варианты обеспечения указываются на вкладке «Товары» в колонке «Действия» (рис. 2).

Предусмотрено 5 вариантов обеспечения:

1. «Не обеспечивать» — данное действие используется, если нет необходимости фиксировать потребности и предварительно резервировать товар на складе до его отгрузки.
2. «К обеспечению» — позволяет зафиксировать потребность в товаре на складе отправителя на указанную дату начала отгрузки.
3. «Резервировать по мере поступления» — позволяет зарезервировать товар на складе отправителя после его появления на остатках.
4. «Резервировать на складе» — позволяет зарезервировать товар на складе отправителя для последующего перемещения по заказу.
5. «Отгрузить» — является распоряжением к началу оформления складских документов или оказанию услуг.

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


Реализация проекта

• Этап сбора данных

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

Для получения данных была добавлена кнопка (рис. 3).
Рассмотрим ее код. Он в основном состоит из запроса, который собирает данные при помощи пяти временных таблиц.

1. В первой временной таблице получаем данные заказов клиентов: к обеспечению ресурса, к обеспечению без резерва и к резерву по мере поступления ресурса. Ресурс резервируется по мере поступления при помощи регистра накопления «Распределение запасов». Чтобы выбрать только заказы клиентов, устанавливаем отбор на тип измерения «Заказ на отгрузку», равный типу «Заказ клиента».
2. Во второй временной таблице создаем группы по заказам клиентов для удобства работы с ними в дальнейшем.
3. В третьей временной таблице выбираем все планы оплат из регистра «Расчет с клиентами. План оплат».
4. В четвертой временной таблице получаем только первые оплаты с контролем «Оплата до обеспечения». В конфигурации наименований данный контроль интерпретируется как «Аванс до обеспечения».
5. Пятая временная таблица состоит из объединения. В первой части выбираем только оплаченные приходы, равные расходам заказов клиентов с контролем «Оплата до обеспечения». Во второй части отбираем все прочие заказы клиентов.
6. Шестая часть запроса является итоговой и получает конечные данные для вывода в таблице на форме.

Затем загружаем полученные данные.

• Программирование создания заказа на производство в 1С:ERP

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

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

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

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

Результатом работы этой функции является структура, включающая в себя:

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

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

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

• Тестирование работы системы

Проверим работу обработки в режиме предприятия.
Для этого откроем нашу обработку. На форму добавлена кнопка «Получить данные» для удобства анализа. Также мы вывели на форму колонку «График оплаты». Как мы видим, предоплата у нас всего лишь по одному заказу (рис. 4).

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

А теперь рассмотрим несколько других заказов клиентов на предмет оплаты и вариантов обеспечения.
Например, у VIP-клиентов есть: оплата до отгрузки, оплаты независимо от отгрузки и действия: «Резервировать на складе», «Резервировать по мере поступления». Нас интересует только «Резервировать по мере поступления». Рассмотрим еще один заказ клиента, например, кредит.
Здесь оплата независимо от отгрузки, и товары стоят с отметкой «Резервировать по мере поступления», что верно.

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

• Ручная проверка обработки по созданию заказов на производство в 1С

Создадим заказ на производство с помощью кнопки «Создать заказ на производство», выберем подразделение, например, «Производство мебели» — «Основное производство». Заказ на производство дивана создался (рис. 6).

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

Подробное видео «Создание обработки по получению потребности производства заказов клиентов Механизм создания заказов»


Результат проделанной работы
На примере реализации данного кейса мы подробно разобрали как создать обработку, собирающую заказы клиентов, которые еще не запущены в производство. Кроме этого рассмотрели механизм сбора и создания заказов клиентов на производство и определили, что представляют собой правила оплаты и варианты обеспечения. А также показали как можно заполнить спецификацию типовыми методами.
Если у вас возникли вопросы по данной теме или любой другой при работе в системе 1С:ERP Управление предприятием, то наши специалисты Neti всегда готовы провести профессиональную консультацию и оказать помощь в решении актуальных вопросов.

Заказчик
Группа производственных компаний (производство сельскохозяйственной техники).


Описание ситуации
Система заказчика имела следующие особенности:

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

В связи с этим заказчик постоянно сталкивался проблемами.
1. Отсутствие информации:

• о необходимости производства той или иной продукции;
• о соответствии сроков производства срокам отгрузки;
• о проценте готовности продукции по заказу;
• о дефиците закупок;
• об остатках материалов и полуфабрикатов под конкретную готовую продукцию.

2. Формирование всех подчиненных заказов на производство и этапов необходимо было производить вручную (т.к. структура заказа формирует связанные между собой этапы).
Эти проблемы приводили к срыву сроков производства, что вело к штрафам и потери прибыли. На складе наблюдался не только дефицит, но и неконтролируемые излишки.
Дефицит приводил к тому, что приходилось срочно закупать материалы по завышенной цене. А излишки – к нерациональному использованию денежных средств и их «заморозке» на складе.
А это, в любом случае, снижение рентабельности предприятия.

Также для быстрой и эффективной работы производства заказчику был необходим АРМ, отвечающий следующим требованиям:

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

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

Особенности реализации
В связи с обработкой большого объема данных и множественными ограничениями в правах пользователей (RLS) мы столкнулись с проблемой долгого формирования обработки.
Представьте, что вам нужно сформировать обработку. Вы выбираете нужные параметры, запускаете систему... А она в падает в режим «я в домике» на полчаса, на час, а то и больше.
Более того, в это время в системе больше ничего нельзя было делать. Пользователь просто выпадал из рабочего процесса на все это время.
Иногда, чтобы вывести систему из ступора, приходилось полностью ее перезагружать.
Для того, чтобы справиться с данной задачей, нами были оптимизированы и сокращены механизмы обработки.
В результате, чтобы не останавливать работу пользователей, выполнение этой задачи было переведено в фоновый режим. Был установлен привилегированный режим на время получения данных для решения проблемы с RLS.
На практике это выглядело следующим образом: с пользователя снимались все ограничения на время формирования обработки. А именно ограничения и приводили к описанным проблемам. А после завершения обработки – восстанавливались.


Результат проделанной работы
Была реализована обработка, которая обладала следующей функциональностью:

1. На первой странице отображались незакрытые заказы на производство с процентом готовности продукции и суммами, рассчитанными на основании готовности и сумм продукции в заказах клиентов.
2. Была возможность отбора только тех заказов, которые необходимо произвести.
3. Формирование потребности производилось согласно выбранным заказам на производство в виде дерева.
4. Было реализовано 3 варианта формирования (по подразделениям, по покупателям, по заказам на производство).
5. Во всех трех вариантах были такие общие уровни как: подразделение, номенклатура, материал. Для вариантов по покупателям и по заказам на производство сверху добавлялся уровень Покупатель или Заказ на производство с датой отгрузки соответственно.
6. Готовая продукция разворачивалась по ресурсным спецификациям из заказов на производство. Полуфабрикаты разворачивались по основным ресурсным спецификациям.
7. На уровнях номенклатуры и материала выводились следующие данные: обособленные остатки, свободные остатки, остатки в производстве (передел), остатки переработки, остатки аутсорса, остатки аналогов. Отдельно по настройке выводились остатки готовой продукции на определенных складах. Все остатки распределялись по приоритетам готовой продукции.
8. В результате суммирования остатков материалов и полуфабрикатов по правилам, заданным заказчиком, рассчитывалось количество, которое возможно отправить в документы производства.
9. Для удобства восприятия выводимой информации были добавлены следующие инструменты: условное оформление, расшифровки к каждому виду остатков, возможность быстрой свертки и развертки всех уровней дерева, возможность скрытия и показа колонок остатков, переключение режима выводимых колонок (остатки материалов, остатки готовой продукции).
10. По выбранным строкам была возможность сформировать документы производства на указанное количество. Так как была необходимость производства номенклатуры по разным условиям (с назначением и без, с созданием заказа на производство и без) по просьбе заказчика документ, отражающий начало производства, был разделен на два вида. Механизмы формирования отрабатывали согласно данному условию.

В результате время получения и вывода данных сократилось более чем на 60%.
Созданная обработка стала фундаментом всех производственных процессов организации.


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

1. Сокращение незавершенного производства
2. Сокращение цикла производства
3. Сокращение количества просроченных заказов
4. Удобный механизм создания производственных документов
5. Контроль и эффективное управление производственными процессами
6. Получение дефицита закупок
7. Уменьшение трудозатрат рабочих и операторов

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

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

Задача
В соответствии с действующим законодательством у заказчика возникла необходимость перейти на новые стандарты ФСБУ в части порядка учета ОС и Арендованного имущества, при этом специфика действующего учета заказчика усложняла переход на последние версии 1С в редакции 3.0 с поддержкой ФСБУ 6/2020 и 25/2020.


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

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


Результат проделанной работы
Теперь в компании учет ОС и арендованного имущества ведется в соответствии со стандартами ФСБУ.

Заказчик
Производственная компания


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


Реализация проекта
✔ Разработаны различные интерфейсы и АРМ по запросу заказчика.
✔ Разработаны новые документы, отчеты, обработки и печатные формы.
✔ Обновлены типовые и доработанные конфигураций 1С.
✔ Разработана собственная конфигурация по логистике для отдела продаж.
✔ Внедрена собственная подсистема учёта рабочего времени в УПП 1.3.
✔ Настроена интеграция с электронной проходной.
✔ Разработана собственная конфигурация учёта доработок.
✔ Осуществлен переход с 1С:БП 2.0 на 1С:БП 3.0, 1С:УПП 1.3 на 1С:БП 3.0.


Результат проделанной работы

1. Оптимизированы бизнес-процессы компании.
2. Снижены временные затраты сотрудников на выполнение задач благодаря новым интерфейсам и инструментам.
3. Обеспечен четкий контроль рабочего времени благодаря интеграции с электронной проходной.
4. Минимизированы риски при обновлении платформ за счёт плавного перехода и сохранения всех данных.