Оцениваем затраты на переход между платформами 1С

25/01/2016

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

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

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

ОБЩИЙ АЛГОРИТМ ПЕРЕЕЗДА

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

1. Доработка новой программы.

2. Подготовка средств переноса или конвертации данных из старой системы.

3. Подготовка данных для переноса.

4. Перенос данных с помощью средств переноса.

5. Выверка перенесенных данных.

    Разберем этапы более подробно.

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

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

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

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

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

ЧТО ГОВОРЯТ ПРОГРАММИСТЫ ОБ ЭТОМ АЛГОРИТМЕ

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

    На практике так работать нереально, лучше разбить переход на несколько участков и на каждом участке реализовать процесс перехода отдельно. В этом случае работы может оказаться намного меньше, а проект станет более управляемым. Тогда главной проблемой становиться задача, как разбить переход на несколько независимых участков, которые можно переносить независимо друг от друга. Этой проблеме посвящен раздел КАК СОСТАВИТЬ ПЛАН ПЕРЕЕЗДА

Рисунок 1. После каждого этапа возможен возврат на предыдущий этап или этапы.

О ТРУДНОСТЯХ ПЕРЕХОДА

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

    Первая группа проблем возникает по причине разных Моделей данных используемых в ПО. Например, некоторые хозяйственные операции отражаются в 1С:Предприятие 7.7 несколькими видами документов, а в 1С:Предприятие 8 - одним (поступление материалов и товаров отражается в новой программе одним документом, а в старой – двумя). Поэтому при попытке переноса документов «Поступление материалов №22» и «Поступление товаров №22» возникает ошибка контроля уникальности. Поскольку запись двух документов с одним номером в заданном периоде невозможна, необходимо искусственно вносить в них отличия и система внесения этих отличий оговаривается заранее. Часто, данная проблема решается прибавлением дополнительного префикса к номеру загружаемого документа. Для каждой особенности документа этот префикс выделяется отдельно. Это может быть характеристика базы, из которой загружаются документы или вид документа, из которого произведена загрузка. Приведем пример формирования такого префикса. База филиала в Красноярске дает префикс «КР». Вид документа «Поступление материалов», из которого производится загрузка, дает префикс «М». Так, если номер документа в семерке был 00000031, то восьмерочный номер будет следующим:

    «КР» + «М» + «00000031» = «КРМ00000031»

    Вторая группа проблем возникает из-за отсутствия некоторого специфического функционала в новой программе, который был доработан в старой. Это необязательно внутренняя разработка заказчика, а официально купленный пакет программ. Например, до переезда у вас было 1С 8.2 Комплексная автоматизация + Бит Финанс, а после переезда 1С 8.3 ERP. В обоих случаях решается задача бюджетирования, но настолько по-разному, что готового механизма конвертации практически нет.

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

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

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

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

    Все перечисленные трудности являются универсальными для всех переездов, не только 1С. Где-то может быть больше или меньше технических проблем, но не надейтесь, что не придется скрупулезно продумывать перенос каждого справочника, документа или отчета. Даже если 95% сделает стандартный инструмент переноса, остальные 5% могут вылиться в серьезный проект.

КАК СОСТАВИТЬ ПЛАН ПЕРЕХОДА

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

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

Рисунок 2. Разбиваем весь учет на несколько крупных участков, которые не зависимы друг от друга.

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

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

- учет безналичных денежных средств;

- учет наличных денежных средств;

- учет расчетов с дебиторами-кредиторами;

- расчет заработной платы;

- учет готовой продукции;

- учет производства;

- налоговый учет;

- учет прочих услуг, по приносящей доход деятельности;

- учет основных средств и нематериальных активов.

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

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

КАК СЧИТАЕМ ЗАТРАТЫ

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

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

    Задача связанные с подготовкой и выверкой данных (3 и 5 пункты алгоритма) включают участие сотрудников заказчика. Здесь нужно четко определиться, какую часть работы берет на себя заказчик и что делает подрядчик. Подрядчик в любом случае проводит консультирование, как готовить, как проверять, отвечает на вопросы и контролирует итоговые показатели. Трудозатраты здесь оценить сложно, можно примерно сказать сколько нужно времени на консультации, но лучше использовать почасовую схему оплаты.

    На Рисунке 3 показана модель стоимости проекта перехода. Кроме сказанного выше сюда добавлено обучение сотрудников, которое относится к категории определяемых затрат и затраты на поддержку после перехода на новую программу. В среднем по проектам на так называемую «переменную» составляющую, которую сложно посчитать в начале проекта уходит до 70% трудозатрат.

Рисунок 3. Проект перехода состоит из 4-х блоков трудозатрат.

    Что еще важного подсказывает Рисунок 3. Если подрядчик оговаривает сразу всю стоимость перехода, то он где-то лукавит. Либо он не включил все работы в оценку проекта, либо переменную часть он взял с запасом (более 50%). Заказчику выгодно перенести переменную часть в почасовую форму оплаты, так делают многие программисты 1С. Но здесь нужно внимательно следить, чтобы вся доработка новой программы не перекачивалась в этап технической поддержки, поскольку это не выгодно заказчику.

МОЖНО ПРИСТУПАТЬ К РЕАЛИЗАЦИИ

    План сделали, затраты посчитали. Приступаем к реализации сразу всех 5-ти пунктов. Звучит противоречиво, но суть в том, что когда мы выполняем 1 пункт, нужно проверить результат, а чтобы проверить результат нужно перенести данные и выполнить пункт 2. Чтоб перенести данные, нужно их подготовить, и так далее... Не получится выполнять этапы последовательно, придется разрабатывать программное обеспечение и одновременно его тестировать.

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

    Главное! Постоянно тестируйте новую программу, делайте пробные конвертации и обучайте сотрудников.

А ЧТО ПОТОМ?

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

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

ВРЕМЯ ПЕРЕХОДА

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

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

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

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

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

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

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

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

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

    3. Переход осуществляется с середины года

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

- начать работу если не с начала года, то хотя бы с начала квартал;

- перенести остатки на начало года;

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

    4. Переход с дополнительным переносом документов прошлого периода

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

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

КРУПНЫЙ ПЕРЕЕЗД

    Автору статьи удалось поучаствовать в крупном проекте слияния нескольких юридических лиц, повлекших за собой слияние информационных систем. Конечной системой была выбрана платформа 1С. Размер справочников контрагентов, сотрудников, основных средств достигал сотни тысяч наименований. Не все исходные системы были на платформе 1С, присутствовало много «самописных» систем с неопределенным сроком эксплуатации (например, написанные под DOS).

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

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

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

3. Обучение провели заранее, централизовано с приглашением профессиональных преподавателей.

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

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

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

О ПОЛЕЗНОСТИ ОБРЕЗАНИЯ ДАННЫХ

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

- лишние пробелы;

- ООО, ИП, ЗАО, которые могут быть, а могут и не быть;

- поменянные местами слова;

- Одинаковый ввод двух наименований (дубли).

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

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

    В момент перехода нужно принять ряд важных решений.

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

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

- Что еще можно, нужно стереть, упростить, пока есть удачная возможность.

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

    Во-первых, можно не отключать старую базу и разрешить ею пользоваться в режиме чтения еще несколько лет. Если кому-то надо, то он берет с нее цифры и в Excel делает отчет. Во-вторых, можно воспользоваться концепцией информационного хранилища. Суть этой концепции в построении отдельной базы, в которой хранятся данные, специально подготовленные для построения нужных отчетов. Это может быть 1С платформа или другое решение. Например, можно закидывать в отдельную базу все документы не проводя их. Второе решение более правильное с технической точки зрения. Но сложно предугадать какие данные потребуются через 5 - 10 лет, поэтому технология хранилищ данные встречаются только в крупных компаниях.

ключевые слова: интеграция, конвертация, переход между платформами, 1С Предприятие Владивосток