Cms с интеграцией 1с: Лучшая CMS для интернет-магазина • СофтБиз. 1С для интернет-магазина и торговли

10 вариантов «подружить» сайт с 1С — CMS Magazine

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

Обмен с сайтам по формату CommerceML

В типовых конфигурациях 1С:Предприятие существует 2 типа обмена, основанного на формате CommerceML:

1. Обмен по схеме Поставщик-Покупатель

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

2. Обмен с web-сайтом 1С-Битрикс

   Обмен с web-сайтом 1С-Битрикс после настройки выполняется в автоматическом режиме, но заказы необходимо проводить в 1С вручную. Заказ выгружаемый по такой схеме не контролируется на наличие остатка на складе. И при проведении заказа может оказаться, что заказанный товар уже зарезервирован другим заказом.

Больше не нужно искать и обзванивать каждое диджитал-агентство

Создайте конкурс на workspace.ru – получите предложения от участников CMS Magazine по цене и срокам. Это бесплатно и займет 5 минут. В каталоге 15 617 диджитал-агентств, готовых вам помочь – выберите и сэкономьте до 30%.
Создать конкурс →

web-расширение

В ассортименте программных продуктов 1С есть компонента web-расширение для платформы 1С:Предприятие. Данное решение основано на технологии Web Forms, которая интегрирует веб-форму, элемент управления и источник данных. Для доступа к данным элементы управления используют технологию ADO.NET, а пользовательский интерфейс работает на ASP.NET

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

Использовать подключаемую DLL

Подключаемых dll для обмена на рынке нет, нужно писать самому. Есть только примеры. Для автоматического обмена по протоколу sftp из встроенного языка можно использовать существующие утилиты вроде WinSCP.exe. Однако, более надежно написать для этих целей внешнюю компоненту. Тем более, что есть готовые библиотеки для С++.

Использовать COM интерфейс

Использование COM интерфейса предполагает наличие у сайта com-объекта, к которому можно подключиться

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

Использовать web-сервисы 1С

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

Наиболее удобно для обмена 1С с сайтом использовать встроенную в платформу 1С:Предприятие технологии web-сервисов. Но использование этого решения отталкивает компании из-за необходимости открывать доступ к 1С из Интернет.

Перейти на 1С 8.3 (Возможно)

В версии 8.3 1С:Предприятие реализована поддержка SSL, сертификатов в web-сервисах и объектах встроенного языка использующих FTP и HTTP-соединение. В данном случае в web-сервисах уже обеспечивается необходимый уровень безопасности доступа к данным. Для данной платформы пока еще не реализованы типовые конфигурации, что ограничивает ее распространение.

Универсальный обмен XML

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

Самописный обмен

1С выгружает файлы формата txt, xml или csv, которые передаются на сайт по протоколам http или ftp. Сайт обрабатывает полученные файлы.

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

Веб-сервер на стороне 1С

Встроенная в платформу 1С:Предприятие технология web-сервисов позволяет создать конфигурацию с полноценной CMS-системой генерирующей по запросу html-код. Таким образом кардинально решается вопрос обмена с сайтом, его по сути дела нет, так как сайт работает на базе 1С. Данное решение потенциально обладает низкой производительностью производительностью.

Комбинированный

Каждый из описанных выше вариантов имеет свои преимущества и недостатки. Какой из них выбрать в конечном итоге зависит от множества факторов. И в каждом случае решается индивидуально. По нашему опыту наиболее оптимальным является решение, использующее сразу несколько вариантов обмена для разных ситуаций. По собственному опыту могу сказать, что когда встал выбор какой тип обмена использовать в масштабном проекте по созданию готовой b2b системы с универсальной интеграцией в большинство конфигураций 1С, на основе глубокого анализа нами был выбран формат CommerceML с доработанным функционалом. Именно он сочетает в себе гибкость настройки универсального обмена XML, высокую автоматизацию и повышенную производительность. В итоге в указанной выше системе интернет-дистрибуции мы использовали оптимизированный CommerceML формат для обмена сайта с базами 1С:Предприятие. При этом есть возможность гибкой настройки объектов обмена без программирования, путем добавления объектов в пакет XDTO. Большие объемы данных система передает по протоколу sftp, что заметно повышает отказоустойчивость и гарантирует безопасность.

Таблица сравнения обменов

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

От редакции

Настоящие эксперты в области веб-разработки делают не только красиво, но и функционально. Хотите найти веб-студию, способную обеспечить не только аккуратный, приятный дизайн, но и последующее удобство при использовании интернет-магазина? Тогда обязательно изучите независимый рейтинг разработчиков интернет-магазинов! Он позволяет получить представление сразу о всех лучших веб-студиях, специализирующихся именно на этом типе сайтов, причем сразу по 4 ценовым категориям.

3 способа интеграции 1С и сайта на CMS 1C- Битрикс

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

1. Обмен с помощью модуля обмена 1С-Битрикс (рекомендуемый способ)

Пример отображения модуля 1С-Битрикс

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

Информацию о модуле, как и сам модуль, можно получить на 
официальной странице.

Здесь внимание нужно обратить на то, что модуль может быть установлен на ограниченный ряд конфигураций 1С. Если вашей конфигурации нет в списке по ссылке, то данный способ вам не подходит. Хотя у нас были случаи, когда умелые 1С-специалисты интегрировали и адаптировали этот модуль под нетиповые конфигурации.

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

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

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

2. Обмен с помощью стандартного функционала 1С

Пример отображения в интерфейсе штатного функционала обмена

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

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

Функциональные возможности обмена «из коробки» значительно скромнее специального модуля 1С-Битрикс. В этом случае спасают опытные 1С-специалисты и дорабатывают данный функционал.

3. Обмен с помощью веб-сервисов

Пример веб-сервиса в 1С

Подробнее о том, что такое веб-сервисы, можно прочитать на странице.

Если коротко и просто: сайт отправляет запрос в определенном формате в 1С, 1С отвечает необходимой информацией в заданном формате — режим запрос-ответ (как правило post-запрос и ответ в json или xml).

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

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

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

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

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

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

Содержание

Программное обеспечение

ERP для малого и среднего бизнеса | Система ERP

Имя*

Фамилия*

Должность*
-Выберите свою позициюCEO / Президент / Генеральный директор / OwnerIT — CTO / CIO / IT VP / Dir / ExecIT — Professional / ManagerOperations — COO / VP / Dir / ExecOperations — Professional / ManagerSales — CSO / VP / Dir / ExecSales — Professional / ManagerProduction — Руководитель / Директор по производству — Специалист / Менеджер по проекту — Руководитель по проекту — Специалист / Менеджер по финансам — Финансовый директор / Вице-президент / Директор / Исполнительный директор по финансам — Специалист / Менеджер по закупкам — Руководитель / Директор по закупкам — Специалист / МенеджерРуководитель по разработке продуктов — Руководитель / Директор по развитию — Специалист / Менеджер по развитию — РазработчикДругое

Компания*

Страна*
_Choose your countryAfghanistanAland IslandsAlbaniaAlgeriaAmerican SamoaAndorraAngolaAnguillaAntarcticaAntigua and BarbudaArgentinaArmeniaArubaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBonaire, Sint Eustatius and SabaBosnia and HerzegovinaBotswanaBouvet IslandBrazilBritish Indian Ocean TerritoryBrunei DarussalamBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCabo VerdeCayman IslandsCentral African RepublicChadChileChinaChristmas IslandCocos (Keeling) IslandsColombiaComorosCongoCongo, the democratic republic of theCook IslandsCosta RicaCote d’IvoireCroatiaCubaCuracaoCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFalkland Islands (Malvinas)Faroe IslandsFijiFinlandFranceFrench ГвианаФранцузская ПолинезияФранцузские южные территорииГабонГамбияГрузияГерманияГанаГибралтарГрецияГренландияГренадаГваделупаГуамГватемалаГернсиГвинеяГвинея-бисауГайанаГаитиHeard Is land and Mcdonald IslandsHondurasHong KongHungaryIcelandIndiaIndonesiaIran, Islamic republic ofIraqIrelandIsle of manIsraelItalyJamaicaJapanJerseyJordanKazakhstanKenyaKiribatiKorea, democratic people’s republic ofKorea, republic ofKuwaitKyrgyzstanLao people’s democratic republicLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacaoMacedonia, the former yugoslav republic ofMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMartiniqueMauritaniaMauritiusMayotteMexicoMicronesia, federated states ofMoldova, republic ofMonacoMongoliaMontenegroMontserratMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNetherlands AntillesNew CaledoniaNew ZealandNicaraguaNigerNigeriaNiueNorfolk IslandNorthern Mariana IslandsNorwayOmanPakistanPalauPalestine, State ofPanamaPapua New GuineaParaguayPeruPhilippinesPitcairnPolandPortugalPuerto RicoQatarReunionRomaniaRussian FederationRwandaSaint BarthelemySaint Елена, Вознесение и Тристан-да-КуньяСент-Китс и НевисСент-ЛюсияСент-Мартин Saint Pierre and MiquelonSaint Vincent and the GrenadinesSamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbiaSeychellesSierra LeoneSingaporeSint MaartenSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSouth Georgia and the South Sandwich IslandsSouth SudanSpainSri LankaSudanSurinameSvalbard and Jan MayenSwazilandSwedenSwitzerlandSyrian Arab RepublicTaiwanTajikistanTanzania, United Republic OfThailandTimor-lesteTogoTokelauTongaTrinidad and TobagoTunisiaTurkiyeTurkmenistanTurks and Caicos IslandsTuvaluUgandaUkraineUnited Arab EmiratesUnited KingdomUnited StatesUnited States Minor Outlying IslandsUruguayUzbekistanVanuatuVatican City ГосударствоВенесуэла, Боливарианская РеспубликаВьетнамВиргинские острова, Британские Виргинские острова, СШАУоллис и ФутунаЗападная СахараЙеменЗамбияЗимбабве

Размер компании*
_Выберите размер вашей компании1-1011-5051-100101-10001001+

Количество мест в проекте*

Отрасль компании*
_Выберите отрасль вашей компанииОптовая торговля и дистрибуцияТекстильПроизводствоПромышленное оборудованиеОбслуживаниеТранспортРозничная торговляПроизводство продуктов питанияАвтомобилестроениеМеталлоизделияСельское хозяйствоДерево и мебель

Телефон*

Электронная почта*

Я подтверждаю, что прочитал и понял политику конфиденциальности. *

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

Как мы разрабатываем 1С:ERP и другие программные продукты

В

одной из предыдущих статей

 мы описали процедуру разработки платформы 1С:Предприятие. Сегодня мы хотели бы рассказать о разработке приложения 1С:Предприятие с богатейшим функционалом: 1С:ERP Управление предприятием 2.

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

Смотрим инфографику:

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

На рисунке показаны логотипы некоторых пользователей 1С:ERP:

Что интересно в 1С:ERP, так это то, что мы разрабатываем одно решение (1С:ERP) и автоматически получаем четыре решения на основе исходного кода ERP путем ограничения функционал и переключение функциональных опций:

1. 1С:ERP  высокофункциональное приложение. Он готов к внедрению для средних и крупных предприятий с тысячами пользователей.
   Включает в себя следующие модули:
2. 1С:Комплексная автоматизация — идеальное решение для растущих малых и средних предприятий, процессы управления которыми требуют идеальной координации и согласованных действий нескольких исполнителей.
3. 1С:Управление торговлей позволяет комплексно автоматизировать оперативный и управленческий учет, планирование и анализ продаж. Этот модуль повышает эффективность управления современными торговыми компаниями.
4. 1С:Управление торговлей. Базовая версия — решение для небольших торговых компаний. Он позволяет вести учет одной организации: юридического лица или индивидуального предпринимателя. Решение не поддерживает изменение конфигурации: вы можете использовать и обновлять только стандартную конфигурацию; одновременно с информационной базой может работать только один пользователь; развертывания клиент/сервер также не поддерживаются. Это буквально решение для автоматизации киоска.

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

1С:ERP Разработка

Делаем четыре из одного

У нас только одна ветка разработки (ERP). Построение «легких» приложений с ограниченным функционалом (Complete Automation, или CA, и Trade Management стандартные и базовые версии, или TM и TMB) на базе нашей флагманской ERP-системы автоматизировано.

Все изменения ERP автоматически применяются к «производным» конфигурациям (CA, TM и TMB) с помощью инструмента сравнения и объединения конфигураций. Этот инструмент изначально разрабатывался для автоматизации миграции на новые версии приложений для пользователей, меняющих или расширяющих функционал приложений на своей стороне. Инструмент сравнения и слияния конфигураций выполняет трехстороннее семантическое слияние на основе анализа трех конфигураций:

• Конфигурация старого поставщика
• Новая конфигурация поставщика
• Текущая пользовательская конфигурация (старая конфигурация поставщика плюс изменения, внесенные пользователем)

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

В качестве текущей конфигурации мы рассматриваем CA, TM и TMB; старая и новая версии системы ERP как старая и новая конфигурация поставщика соответственно. Короче говоря, мы рассматриваем функционально ограниченные конфигурации (CA, TM и TMB) как конфигурации ERP, настроенные в основном путем удаления неиспользуемых объектов.

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

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

Согласно международному стандарту ISO 9241-11:

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

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

Особенности разработки

При разработке ERP мы всегда должны помнить, что программируемая нами функциональность может быть включена в одно или несколько производных решений, таких как CA, TM или TMB. Чтобы упростить включение и отключение функций, мы используем функциональные опции, изначально предназначенные для этой цели. Функциональные опции помогают определить функции приложения, которые необходимо включить или отключить при развертывании, не изменяя само приложение. Функциональные опции — это настройки решения (обычно флажки), которые отключают все связанные функции при снятии. Функциональные опции используются в первую очередь для тонкой настройки приложения с учетом параметров конкретного проекта развертывания. Помимо основного назначения, мы также используем этот инструмент для создания производных конфигураций на основе ERP. Например, решение ERP содержит функциональную опцию под названием «Управление предприятием». Связанный с ним функционал отвечает за управление производством, включая календарное планирование и планирование производства, учет затрат, отчетность и многое другое. Эта опция включена только в 1С:ERP и отключена в «производных» (CA, TM и TMB). Общее количество функциональных возможностей 1С:ERP составляет более 600.

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

1. Управление и Полная автоматизация.
2. «Объекты ERP и CA» включены только в конфигурации ERP и Complete Automation.
3. «Объекты ERP» включены только в решение ERP.

Любой прикладной объект ERP должен входить в состав ТОЛЬКО ОДНОЙ из подсистем. Это условие проверяется при статическом анализе кода ERP (см. ниже).

Версии

Версия ERP обозначается четырьмя цифрами, разделенными точками (2.1.3.117).

• Первая цифра (редакция) меняется редко. Нам понадобилось восемь лет, чтобы сменить УЦ 1.х.х.х на УЦ 2.х.х.х.
• Вторая цифра (подревизия) меняется примерно раз в год. Выпуск с новым номером подревизии обычно содержит новые функции.
• Релизы с новой третьей цифрой (версия) содержат расширения существующей функциональности; обычно мы запускаем новые версии каждые 2–3 месяца.
• Релизы с обновленной четвертой цифрой (сборка) содержат только исправления и обновления соответствия законодательству. Мы публикуем новые сборки раз в две недели.

У нас может быть одновременно в разработке до трех версий продукта, например:

1. 2.1.3.X, поддерживаемый выпуск предыдущей подревизии. Запланированные обновления будут доступны до конца 2016 года. Они включают только исправления и обновления для соответствия законодательству.
2. 2.2.1.X, текущий выпуск текущей подревизии. Он содержит новую функциональность подревизий. Запланированные обновления будут доступны до выхода версии 2.2.2.X.
3. 2.2.2.X, функциональное расширение текущей подревизии. Этот релиз находится в активной разработке.

В каждом филиале ERP мы разрабатываем четыре решения (ERP, CA, TM и TMB). Итак, всего у нас есть 12 версий продукта в 12 разных репозиториях.
В процессе разработки у нас есть до четырех горизонтов планирования:

1. 2.1.3 (поддерживается). Мы решаем, какие ошибки исправлять, а какие законодательные проекты реализовывать. Мы применяем только те изменения, которые вступят в силу в 2016 году. Плановый период длится до конца 2016 года.
2. 2.2.1 (поддерживается). Исправляем «внешние» ошибки и добавляем поддержку изменений законодательства, вступающих в силу до выхода релиза 2.2.2. Период планирования длится до выхода версии 2.2.2.
3. 2.2.2 (в активной разработке). Исправляем «внешние» и найденные ошибки, внедряем новые функции. Период планирования длится до выхода версии 2.2.3.
4. 2.2.3 (планируется). Для этой версии часто изначально разрабатываются масштабные проекты. Мы не включаем такие проекты в предыдущую версию. Период планирования длится до выхода версии 2.2.4 или до конца 2017 года.

Использование 1С:Системы проектирования приложений при разработке ERP

Как мы уже упоминали, в 1С мы руководствуемся принципом «Ешь свой собственный тест», используя собственные продукты во внутренних процессах. В том числе мы используем 1С:Систему проектирования приложений (ADS) при разработке ERP. Как видно из названия, ADS помогает проектировать приложения на базе «1С:Предприятия» и поддерживает полный цикл разработки программного обеспечения, включая сбор требований, контроль версий, документирование, отслеживание ошибок и т. д.

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

1. Имеется запрос от клиента или партнера. Мы часто собираем такие запросы во время партнерских семинаров. Мы определяем запросы наивысшего приоритета путем партнерского голосования.
2. В ходе пилотного проекта по развертыванию новой версии возникла заявка, так как у заказчика есть жизненная потребность.
3. Есть запрос от нашей системы технической поддержки (точнее, запрос от партнера или клиента, обработанный техподдержкой), с форума партнеров или нашего менеджера по работе с важным клиентом.
4. Есть запрос от команды разработчиков платформы «1С:Предприятие». Команда платформы просит команду разработчиков ERP или другой стандартной конфигурации использовать новую функцию платформы, такую ​​как интерфейс «Такси», исключение модальных окон, блокировка синхронных вызовов и т. д.
5. Рефакторинг, оптимизация архитектуры, улучшение юзабилити.

Критические изменения архитектуры могут стать поводом для рефакторинга (см. стр. 5). Например, это может быть пересмотр заказов на отгрузку, когда клиенты начинают использовать такие заказы вместо накладных.

ADS входит в состав решения ERP, но его также можно приобрести отдельно. Когда ERP работает в режиме интеграции с ADS, каждая форма содержит кнопку, которая открывает функциональную модель формы (описание функциональности) в ADS.

На следующем рисунке показана модель рабочей станции в нотации IDEF0:

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

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

Процесс разработки ERP: 6 этапов проекта

Итак, мы решили внедрить новое запрошенное изменение функциональности. Мы объединяем похожие требования в проекты. Новый выпуск ERP обычно включает 100–150 проектов, содержащих до нескольких десятков требований. Мы создаем проекты в ADS, и у каждого проекта есть шесть контрольных точек, все они задокументированы в ADS.

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

За управление процессом проекта отвечает тимлид или ведущий разработчик:

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

Веха 1. Запуск проекта

Руководитель группы создает проекты в ADS в виде списка релизов. Цели и требования, которые необходимо реализовать, подробно описаны для каждого проекта. Список необходимо обсудить с ведущим разработчиком до начала работ. У нас нет встреч на старте проекта, поэтому проект отправляется на запуск в ADS.

Команда проекта начинает разработку концепции.

Этап 2. Доработка концепции

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

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

Веха 3. Доработка прототипа

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

Функциональная проектная модель в нотации IDEF0 разрабатывается и хранится в ADS.

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

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

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

И они начинают развиваться!

Этап 4. Завершение разработки решения

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

Если проект публичный (т.е. фигурирует в списке планируемых решений, доступных партнерам на сайте 1С), мы публикуем презентацию в разделе ERP на форуме партнеров 1С, чтобы заинтересованные партнеры могли ознакомиться с ней и дать нам обратная связь.

Веха 5. Тестирование и аудит проекта

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

Программный код подлежит проверке кода. Для проектов ERP проверка кода выполняется членами другой проектной группы. Все разработчики ERP должны по очереди проводить проверку кода. Любые обнаруженные ошибки кода регистрируются в ADS и должны быть исправлены до рубежа 5.

Тестировщики также проверяют процесс обновления на новую версию с предыдущей (последней выпущенной).

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

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

Веха 6. Завершение проекта

Команда закрывает проект в ADS со статусом «Завершено».

Выпуск версии

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

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

Патчи

Мы публикуем патчи к выпущенным версиям каждые две недели. Сегодня 2.1.3.х, а когда выйдет 2.2.1, мы выпустим еще два патча: 2.1.3.х и 2.2.1.х. Нам требуется менее двух недель, чтобы исправить зарегистрированную ошибку и внедрить исправление в патч. Согласно нашей статистике, исправление ошибки ERP, о которой сообщил заказчик, выпускается в составе патча в среднем в течение девяти дней.

Многоотраслевая разработка

При разработке ERP мы обычно используем инструменты, предоставляемые платформой 1С:Предприятие. Конфигурации хранятся в хранилище конфигураций; когда мы регистрируем новый функционал в ветке, мы используем стандартные инструменты доставки и поддержки. Все операции автоматизированы. Если объекты обновлялись только на стороне разработчика, код интегрируется автоматически. Если для объединения исходного кода нам необходимо привлечь разработчика, мы обычно используем встроенные возможности платформы. Также можно вызывать сторонние инструменты сравнения/объединения из набора инструментов платформы, включая KDiff3 или Araxis. Кстати, мы добавили в платформу функцию вызова сторонних инструментов сравнения/объединения по запросу команды разработчиков ERP.

Разное

При разработке нового функционала мы используем версию платформы, которая будет доступна на момент выхода новой версии ERP (сегодня это 8.3.8).

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

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

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

ERP содержит десять библиотек, разработанных другими командами. Члены команды разработчиков ERP не изменяют код библиотеки.

Библиотеки включают:

1. Библиотека подсистем
   Базовый функционал: права доступа, печать, управление электронной почтой и т. д. Входит в состав большинства приложений «1С:Предприятия».
2. Библиотека нормативной отчетности
   Составление отчетов для фискальных органов, сдача электронных отчетов.
3. Библиотека периферийного оборудования
   Драйвера для различного оборудования: сканеры штрих-кода, фискальные принтеры, весы и др.
4. Сервисная технологическая библиотека
   Взаимодействие между конфигурациями SaaS (т. е. развернутыми в облаке) и сервисной инфраструктурой.
5. Библиотека интеграции «1С:Документооборот»
   Бесшовная интеграция с 1С:Документооборот: сквозные бизнес-процессы, общий список задач, управление файлами и электронной почтой и т. д., не покидая экрана ERP.
6. Библиотека расчета заработной платы и кадров (расширенная)
   Расчет заработной платы, кадровый учет, отчетность.
7. Онлайн-библиотека поддержки пользователей
   Уведомления об обновлениях, звонки в службу технической поддержки, загрузка и установка обновлений.
8. Библиотека электронного документооборота
   ЭДО с контрагентами (включая юридический ЭДО), DirectBank (прямой документооборот с банками), обмен данными с сайтами (CMS).
9. Библиотека интеграции ЕГАИС
   Учет розничной реализации алкогольной продукции, в том числе обмен с ЕГАИС.
10. Библиотека нормативного учета
    Кусок 1С:Бухгалтерия в ERP. Строго говоря, нормативный учет в ERP методологически похож на 1С:Бухгалтерию (за небольшими исключениями), но реализован по-другому и самостоятельно. Для ERP мы взяли бухгалтерскую отчетность и часть налоговой отчетности из 1С:Бухгалтерии.

Тестирование 1С:ERP

После того, как мы разработали три приложения на базе ERP (CA, TM и TMB), нам необходимо протестировать все четыре решения, поэтому мы проводим статический и динамический анализ конфигураций.

Частичный статический анализ проводится каждый раз, когда мы создаем конфигурации CA, TM и TMB на основе репозитория ERP и загружаем их в определенные репозитории (дважды в день).

Более детальный статический анализ выполняется с помощью 1С:Автоматической проверки конфигурации (1С:АКК), которая проверяет:

• Ролевой состав. Например, чтобы убедиться, что право только на чтение для каждой константы включено в роль «Основные права».
• Код соответствия существующим стандартам. Мы используем процедуры анализа кода для многих стандартов разработки приложений (несколько сотен). Например, проверьте, чтобы в запросах не использовалось полное соединение, или точность локализации отображаемых строк.
• Существуют также специальные проверки разработки ERP.
  Например, сделать так, чтобы каждый прикладной объект входил только в одну подсистему: «Объекты ERP, TM и CA», «Объекты ERP и CA» или «Объекты ERP».

Динамический анализ кода включает

регрессионное тестирование

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

• Открытие всех форм
• Обмен данными с другими приложениями (например, 1С:Бухгалтерия КОРП)
• Генерация учетных записей (проверить, создает ли документ правильные учетные записи после размещения в справочной базе данных)
• И более

Для регрессионного тестирования мы используем от 10 до 20 баз данных разного размера (от 15 до 70 ГБ) и типов предоставления.
Мы также используем эти базы для тестирования процесса обновления на новую версию с предыдущей, чтобы убедиться, что обновление проводится а) правильно и б) в разумные сроки.

Обновление базы 1С состоит из двух частей:

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