Групповая разработка конфигураций в крупном холдинге
Разработка - Математика и алгоритмы
Трудности, с которым сталкивается бизнес в процессе адаптации ПО под себя
И прежде чем мы приступим непосредственно к теме нашей беседы, давайте вспомним о том, с чем сталкиваются практически все пользователи, практически любой бизнес, когда речь заходит о внесении изменений в рабочую конфигурацию.
- Это, естественно, приостановка работы, каких-то процессов.
- Это вмешательство в «живую» систему, необходимость пользователю привыкать к какой-то новой функциональности – это всегда стресс для пользователя, стресс для бизнеса. Пользователь на это, как правило, реагирует отрицательно, особенно, если в конфигурацию закрадываются глюки и баги.
- Ну и тот вопрос, который интересует непосредственно нас с вами – это внутренний контроль качества разрабатываемого программного продукта.
- Заказчик ни в коем случае не должен быть тестировщиком результатов нашей разработки. Он должен получить готовый, качественный продукт и радоваться результатам автоматизации своего труда.
- Ну а мы, как специалисты ИТ-отрасли, должны приложить все усилия для того, чтобы это качество обеспечить. Миссия нашей компании гласит о том, что каждый день мы работаем над тем, чтобы повышать качество оказываемых услуг и продаваемых товаров. И эту миссию мы стараемся выполнять не только в отношении внешних клиентов, но и в оказании услуг нашим внутренним отделам, службам, подразделениям. В том числе - услуги по разработке ПО.
История становления командной разработки в нашей компании. Как мы жили, когда были маленькие, и с чем сталкивались в процессе роста?
Какие виды групповой разработки могут быть, через что прошли мы.
- Это – ручная сборка конфигурации, чем занимаются практически все, кто сталкивается не только с групповой, но и вообще с разработкой в 1С.
- Это – использование хранилища конфигурации в различных его модификациях.
- И, поскольку мы не стоим на месте, движемся вперед, хотим развиваться, задействовать новые инструменты, то следующий этап, который мы планируем внедрять – это применение в разработке ПО системы контроля версий GIT.
Когда пять лет назад я пришел в компанию, не было департамента ИТ, был только небольшой ИТ-отдел из 5 человек. Это был просто отдел разработки. Никакого хранилища тогда не было, конфигурации собирались вручную – один или два разработчика конфигурационных единиц выполняли какие-то доработки, и вносили в конфигурацию новую функциональность. Потом либо эти доработки переносились в рабочую конфигурацию, либо изменения различных специалистов сверялись и объединялись, и уже результат объединения с помощью файла конфигурации натягивался на рабочую базу. Всё вручную!
Конечно же, у такого подхода были существенные недостатки:
- Во-первых, это время, которое должен затратить исполняющий обязанности архитектора на сверку всех изменений, и их консолидацию.
- И это – высокая вероятность внесения ошибки самим архитектором, даже если каждый разработчик выполнил свою часть работы идеально.
Но у такого подхода есть и свои преимущества.
- Это, во-первых, возможность редактирования одного объекта конфигурации одновременно несколькими разработчиками (то, чего мы лишены при использовании хранилища).
- И это – возможность проведения рефакторинга, ревью кода, его инспекции на этапе сборки результата разработки самим архитектором.
Но такая схема у нас просуществовала недолго. Как только на одной конфигурации появился третий разработчик, времени на консолидацию этих разработок стало затрачиваться неимоверно много, процент ошибок резко пополз вверх. Естественно, нужно было что-то менять. И мы приступили к использованию хранилища конфигурации в групповой разработке.
Роль хранилища конфигурации 1С в групповой разработке. Его плюсы и минусы.
Я думаю, не стоит повторяться и подробно объяснять, что такое хранилище – это и так все знают. Хранилище – это полезный инструмент для групповой разработки от фирмы 1С.
Схема использования хранилища выглядит примерно так, как показано на слайде. Это – классический подход, когда:
- К одному хранилищу подключено несколько информационных баз разработчиков.
- Также к этому же хранилищу подключается тестировщик, который в определенный момент времени забирает изменения из хранилища и тестирует разработанную функциональность.
- Затем файл конфигурации выгружается из хранилища, и архитектору остается только загрузить эти изменения, эту готовую разработку уже в рабочую базу.
Но и эта схема просуществовала недолго. Потому что очень быстро выявились ее существенные недостатки.
- Один из главных – это невозможность синхронизировать работу разработчика и тестировщика. Даже если разработчик с тестировщиком договорятся, в какой момент времени нужно забрать конфигурацию из хранилища на тестирование, то к тому времени, когда тестировщик спохватится это сделать, кто-то из разработчиков может уже успеть поместить туда изменения, относящиеся уже к последующим задачам.
- И в результате может возникнуть ситуация, что непротестированные изменения, а уж тем более изменения с ошибками попадут в рабочую информационную базу и нарушат работу бизнеса.
Поэтому следующим шагом было решено вынести тестовую базу из цикла разработки.
- Теперь тестовая база у нас стала существовать отдельно от хранилища разработки. В нее с установленной периодичностью (согласно графику загрузки) загружалась конфигурация из хранилища разработки.
- Поскольку тестировщик теперь работал независимо от разработчиков, количество ошибок резко сократилось. Если же во время тестирования тестировщик находил ошибки, то разработчику нужно было исправить эти ошибки одновременно в хранилище разработки и в тестовой базе.
Такая схема оказалась достаточно успешной, мы на ней проработали достаточно долго (больше двух лет). Свои слабые стороны она начала показывать, когда разработчиков стало достаточно много, и тестировщиков на одной конфигурационной единице стало больше одного.
- Теперь при нахождении ошибок тестировщиками (особенно, если это была какая-то критичная задача, которую заказчик уже ждет к загрузке в рабочую базу), исправить эти ошибки в одной тестовой базе двум разработчикам одновременно было невозможно, потому что в конфигураторе вдвоем одновременно работать нельзя.
- Из-за этого исправление ошибок растягивалось по времени и, как результат, затягивался план по выпуску релиза.
Долго так продолжаться не могло, поэтому было принято решение что-то поменять.
Ну и прежде, чем перейти к тому, к чему мы пришли на сегодняшний день, давайте подытожим те преимущества и недостатки, которые предоставляет нам использование классической схемы хранилища конфигурации.
Итак, преимущества:
- Первое – это то, для чего собственно и разрабатывался такой полезный механизм, как хранилище конфигурации, это – обеспечение целостности структуры конфигурации в любой момент времени.
- Также в хранилище есть очень полезная возможность в любой момент времени откатиться к предыдущей версии в случае ошибки.
- Полное отсутствие необходимости сверки, консолидации трудов различных специалистов. Хранилище конфигурации само прекрасно справляется с этой задачей, на это время уже тратить не нужно.
Ну и недостатки, с которыми мы столкнулись:
- Это невозможность одновременной работы с одним объектом конфигурации двум программистам. Это ограничение, которое накладывает само использование хранилища конфигурации – ради повышения качества разработки приходится идти на такую жертву.
- Это – трудность синхронизации работы разработчика и тестировщика.
- И отсутствие ревью и инспекции кода. Этот процесс при использовании хранилища уже нужно организовывать какими-то отдельными инструментами, какими-то дополнительными процессами в команде.
Организация цикла разработки ПО, взаимодействие специалистов различных сфер деятельности.
Говоря о каких-то технических моментах, мы неизбежно опираемся на то, как взаимодействуют люди, потому что техническая сторона дела отражает то, как налажен этот процесс в команде.
- Процесс разработки у нас циклический, где цикл разработки и релизного планирования занимает одну неделю. В течение этого периода выполняется доработка ПО согласно техническим заданиям, согласованным с заказчиком.
- После того, как разработка выполнена, программист в своей конфигурации, еще не помещая изменения в хранилище, демонстрирует результаты заказчику. И заказчик либо принимает эти изменения, либо вносит какие-то свои замечания, коррективы.
- Разработчик учитывает эти замечания, исправляет их, и эта результирующая функциональность передается на тестирование.
- Параллельно с этим запускается процесс технического документирования результатов доработки – в работу включается технический писатель.
- В это же время осуществляется циклическое взаимодействие разработчика и тестировщика по отлаживанию переданного на тестирование релиза, по выявлению и исправлению ошибок.
- И после того, как все доработки успешно протестированы, готовый релиз помещается в рабочую конфигурацию.
- Конечно, от всех «жучков» избавиться невозможно, поэтому также существует отдельный цикл по обработке инцидентов и избавлению от тех багов, которые не были выявлены ни во время разработки, ни на этапе демонстрации, ни в процессе тестирования.
Что если использовать несколько хранилищ? Как это помогает и вредит?
Наконец о том, как технически реализован цикл групповой разработки в нашей компании на сегодняшний день.
- Естественно, мы никуда не ушли от хранилища, в котором ведется разработка. В течение недели программисты вносят изменения в конфигурацию.
- Затем эти изменения передаются на тестирование, и здесь у нас в работу включается второе хранилище конфигурации – это уже хранилище тестовой конфигурации. Зачем нам нужно отдельное хранилище для тестирования?
- Во-первых, для того, чтобы у каждого тестировщика была возможность работать в отдельной информационной базе. Тестировщики в своей базе работают индивидуально со своими данными, никто друг другу не мешает, каждый работает на своих тестовых примерах.
- К тому же нет борьбы за конфигуратор – для того, чтобы поместить изменения в тестовую базу, достаточно их поместить в тестовое хранилище.
- Кроме того, есть возможность контроля истории изменений в тестовом хранилище – это тоже большое преимущество при такой организации работы.
- Отдельным моментом стоит отметить появление в нашем цикле разработки так называемого «тестового контура» (об этом - в следующем разделе).
- Есть и третье хранилище – хранилище рабочей информационной базы. Конечно, в этом хранилище уже никто разработку не ведет, оно нужно исключительно для того, чтобы проконтролировать историю изменений, внесенных в рабочую базу. При расследовании каких-то инцидентов и выявлении их причин такое устройство баз бывает очень удобным – хранилище хранит абсолютно всю историю внесения изменений в рабочую базу.
- А раз в неделю, в день, который установлен графиком загрузки конфигурации, архитектор переносит изменения из протестированного релиза в рабочие базы, а готовую разработку, полученную на данный момент, передает на тестирование.
Немного слов о том, как решаются различные коллизионные ситуации.
- Во-первых, это – исправление ошибок, выявленных при тестировании. Здесь разработчику достаточно просто внести изменения в два хранилища конфигурации – хранилище разработки и хранилище тестирования. Тестировщик забирает эти изменения и продолжает тестировать свою задачу, а разработчик продолжает работать независимо.
- Точно такой же подход используется при выявлении каких-то некритичных ошибок, выявленных в рабочей базе, когда работа пользователей не останавливается, но в ее процессе возникают какие-то мелкие неудобства (в интерфейсе, еще где-то), которые могут подождать несколько дней до следующей загрузки. Они исправляются и также передаются на тестирование, чтобы уже на следующей неделе отправиться в рабочую базу.
- Когда у нас появляются срочные заявки, когда заказчик не готов ждать две недели, ему эти изменения надо получить срочно – их исправления вне очереди передаются на тестирование и после тестирования сразу загружаются в хранилище рабочей базы.
Какие очевидные недостатки есть у этой схемы:
- Как видите, если у нас в рабочей базе появляются какие-то критичные ошибки, ситуация немного осложняется тем, что разработчику приходится помещать изменения сразу в три хранилища конфигурации. Почему я говорю «приходится»? Потому что существенным недостатком такой схемы является то количество времени, которое тратится на работу с несколькими хранилищами.
- И еще один минус – это возможность внесения ошибок, даже на этом этапе, когда разработчика что-то или кто-то отвлекает, он поместил изменения в одно хранилище, но забыл поместить в другое. В рабочей базе либо на следующей неделе, либо через две недели может не оказаться исправления данной ошибки.
В чем плюсы такой организации работы?
- Существенный плюс заключается в том, что благодаря хранилища у нас есть контроль истории изменения конфигурации (кто, что и когда менял) для любой базы, в любой момент времени.
- Также преимуществом является возможность тестировщикам и разработчикам иметь свои собственные конфигурации, свои собственные тестовые данные, не мешая друг другу работать в отдельной базе.
А если говорить про недостатки:
- То главный недостаток – это наша головная боль, с которой мы сейчас живем, и думаем, как справиться – это невозможность помещения в рабочую базу какой-то одной протестированной заявки или какого-то определенного перечня заявок. Мы вынуждены ждать окончания тестирования всего релиза, прежде чем поместить изменения в хранилище рабочей конфигурации.
- Ну и, как было сказано, это – вероятность ошибки программиста при внесении изменений в несколько хранилищ;
- И, наконец, затраты времени программиста при исправлении ошибок.
Организация тестового контура информационных баз для тестировщика и заказчика.
Вернемся к тому «Тестовому контуру», который у нас подключен к тестовому хранилищу наряду с базами тестировщиков. Что это такое?
Тестовый контур – это полная имитация (я бы даже сказал клон) той среды, которая развернута для реальной работы – на таких же серверах, с такими же операционными системами, службами и т. д. Ну и, естественно, туда подключены точно такие же базы 1С, более того, это – копии реальных рабочих баз, которые периодически обновляются.
Тестовый контур полностью изолирован от рабочей среды, чтобы тестовые базы не стали обмениваться своими данными с рабочими базами, а задействованы могут быть самые различные обменные процессы, не только "конвертация".
Каковы цели организации тестового контура?
- Во-первых, это – возможность протестировать любую задачу, провести любое нагрузочное тестирование любым пользователем – будь то аналитик или заказчик.
- Поскольку тестовый контур подключен к тестовому хранилищу, заказчик может посмотреть уже на этом этапе, что он получит в результате, когда новая функциональность будет загружена в его рабочую базу. Причем, на своих же реальных рабочих данных, которые он хорошо знает, с которыми он работает.
- Также существенный плюс тестового контура – это безопасность рабочих данных. Полностью оценив масштаб трагедии какой-то тестовой задачи, которую мы крутим на тестовом контуре, мы можем оценить, насколько она ресурсоемка, затратна по времени, может ли она заблокировать работу пользователя. Все это мы можем проверить в тестовом контуре, абсолютно не мешая при этом работе пользователей и не нарушая целостности их рабочих данных.
- Пользователем тестового контура может быть кто угодно, не только программисты и тестировщики, но также аналитики, заказчики, системные администраторы. Ведь настройки сети, имена компьютеров также в точности повторяют рабочую среду.
Дальнейшие планы по улучшению качества продукта. Какие еще инструменты и технологии можно задействовать?
Мы двигаемся дальше и не собираемся останавливаться на достигнутом, продолжаем бороться с теми трудностями, с которыми сейчас сталкиваемся, и продолжаем повышать качество результатов разработки.
- Во-первых, мы планируем внедрение системы контроля версий;
- А еще, спасибо фирме 1С, мы собираемся использовать в разработке новый полезный механизм расширений конфигурации. Он особенно интересен после выхода платформы 8.3.9, когда в расширениях нам стало доступно изменение уже абсолютно любых модулей. Использование этого механизма нам видится очень перспективным, потому что оно хорошо подходит к специфике организации нашего бизнеса.
Как происходит тестирование, исправление ошибок, разработка внешних отчетов/обработок и правил обмена в крупной компании при интенсивном использовании ПО?
В заключение расскажу о некоторых фишках, которые мы также используем в своей работе.
- Поскольку компания крупная, конфигураций много, они большие и используются очень интенсивно, бывает, что в рабочей базе в каком-то отчете, или обработке находится ошибка. Чтобы не прерывать работу пользователей для внепланового обновления, мы реализовали для всех отчетов и обработок механизм автоподмены. Теперь, если в отчете или обработке появляется ошибка, мы можем исправить эту ошибку у себя и сохранить этот отчет как внешний, поместив его в определенный каталог. После этого, пользователь будет уже пользоваться именно этим внешним отчетом, в котором нет ошибки, а со следующей загрузкой конфигурации эта ошибка уже будет исправлена непосредственно в конфигураторе.
- Ну и когда у нас задействовано больше одной конфигурации, естественно, между ними существуют какие-то обменные процессы, которые у нас также реализованы с применением правил обмена, написанных с помощью конфигурации «Конвертация данных». К сожалению, в «Конвертации данных» нет такой полезной функциональности, как версионирование правил обмена, поэтому мы используем похожую схему в самой структуре справочника «Конвертации». Там у нас существует несколько папок для рабочих баз, для тестовых баз, и те правила, которые находятся в разработке.
- Либо можно использовать немного другой подход, когда правила конвертации заливаются в общий модуль самой конфигурации, и вместе с конфигурацией разносятся по хранилищам согласно графику загрузки. Этот подход очень удобен для того, чтобы использовать правила конвертации в системе контроля версий, с чего мы и планируем начать использовать этот продукт.
Желаю всем качественного результата и довольного заказчика!
***************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER. Больше статей можно прочитать здесь.
В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.
Специальные предложения
См. также
[После]Новогодние задачи 5
30.12.2019 1160 Alxby 23
Базовый курс по разработке мобильных 1C-приложений для Android-устройств. Третий поток. Онлайн-интенсив с 11 февраля по 05 марта 2020 г. Промо
Данный онлайн-курс предусматривает изучение базовых принципов создания приложений для операционной системы Android, работающих на мобильной платформе “1С:Предприятие”. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие” при разработке прикладных решений для “обычных” компьютеров, но пока ещё не занимался разработкой 1С-приложений, предназначенных для работы на мобильных устройствах.
7500 рублей
Регистры бухгалтерии. Общая информация 116
05.09.2019 10370 YPermitin 22
"Хочу универсально!" [Часть 1] 67
02.09.2019 6431 SeiOkami 35
Перенос документов, остатков и справочников КА 1.1 => КА 2 / УТ 11. Обновлено до КА 2.4.12.х и УТ 11.4.11.х! Промо
Более 130 компаний выполнили переход на КА 2 или УТ 11 с помощью нашей разработки! Позволяет перенести не только остатки и справочники (как типовая обработка), но и документы за нужный период времени. Предоставляем техподдержку, оперативно исправляем замечания, выпускаем обновления при выходе новых релизов программ 1С. Вы можете проверить разработку до покупки: сделаем бесплатный тестовый перенос из вашей базы КА 1.1 и предоставим доступ к базе-результату через веб-клиент!
29700 руб.
Иерархия без "В ИЕРАРХИИ" 123
22.08.2019 6173 ildarovich 18
EnterpriseData – часть 3. Загрузка данных, идентификация объектов 65
22.08.2019 6315 ids79 7
Программы для исполнения 54-ФЗ Промо
С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.
Обработчики событий при записи объектов. Зачем и что за чем? 247
25.07.2019 19023 4 AlbinaAAA 24
Как проводятся документы в типовых конфигурациях от 1С 167
24.07.2019 19306 skv_79 35
Перенос данных КА 1.1 => ERP 2 (ЕРП) (обработка переноса документов, остатков и справочной информации из "1С:Комплексная автоматизация, ред. 1.1" в "1С:ERP Управление предприятием, ред 2"). Обновлен до КА 1.1.115.х и ERP 2.4.11.х Промо
Обработка позволяет переносить из КА 1.1 в ERP 2 документы за выбранный период и остатки. Типовая обработка от фирмы 1С документы не переносит. Также исправлены ошибки типовой обработки. При выходе новых релизов обновление высылается бесплатно в течение года. Разработка будет полезна фирмам-франчайзи, которые периодически выполняют такой перенос данных для заказчиков. Вы можете один раз приобрести обработку переноса, и потом бесплатно получать обновления в случае выхода новых релизов конфигураций 1С.
29700 руб.
FizzBuzz на 1С. Чем короче, тем веселее. Варианты принимаются... 8
24.07.2019 3514 vandalsvq 16
Управление качеством кода 144
22.07.2019 10501 Stepa86 33
Открыто голосование за доклады на INFOSTART MEETUP Krasnodar Промо
Выбирайте и голосуйте за самые интересные доклады, лучшие из них попадут в окончательную программу митапа. Голосование продлится до 30 января 2020 года.
Что делает "В ИЕРАРХИИ" в запросе? 102
16.07.2019 11291 YPermitin 34
Создание отчетов с помощью СКД - основные понятия и элементы 225
25.06.2019 27748 ids79 17
Онлайн-курс "Подготовка к экзамену 1С:Эксперт и 1С:Профессионал по технологическим вопросам" с 7 по 24 апреля 2020 г. Промо
На курсе вы получите практические навыки решения задач производительности 1С, в том числе характерных для высоконагруженных информационных систем (более 1000 пользователей). Подготовка к экзамену – только одна из составляющих курса. 70% слушателей приходят за знаниями, которые позволят расти и зарабатывать, делать сложные задачи на крупных проектах.
16450 рублей
Реализуем Стек, Очередь и Приоритетную очередь в 1С 52
24.06.2019 8820 RonX01 63
Организация хранения промежуточных данных 3
29.05.2019 2492 scientes 1
1C:Предприятие для программистов: Запросы и отчеты. Второй поток. Онлайн-интенсив с 17 марта по 16 апреля 2020 г. Промо
Данный онлайн-курс предусматривает углубленное изучение языка запросов и возможностей системы компоновки данных, которые понадобятся при разработке отчетов, работающих на платформе “1С:Предприятие” в рамках различных прикладных решений. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей различных прикладных решений, которые используют в своей работе отчеты разного назначения.
6500 рублей
Вычисление 200 тысяч знаков числа pi 74
28.05.2019 4736 Oleg_nsk 96
Регистры накопления. Виртуальные таблицы. Часть №1: Обороты 88
20.05.2019 14496 YPermitin 5
Новый раздел на Инфостарте - Electronic Software Distribution Промо
Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.
- Низкие цены, без скрытых платежей и наценок
- Оперативная отгрузка
- Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
- Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)
Даем названия переменным: как префиксы экономят наше время 10
06.05.2019 3989 Designer1C 69
Заметки по SQL: Срез последних - аналог запроса 17
15.01.2019 7244 IVC_goal 5
Программы для исполнения 488-ФЗ: Маркировка товаров Промо
1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.
Разработка и сценарное тестирование с Vanessa-ADD. Концепция, теория и сквозной пример создания сценария 236
09.01.2019 32091 Vladimir Litvinenko 69
Многопоточное восстановление последовательностей 42
05.12.2018 8348 _ASZ_ 29
Подборка решений для взаимодействия со ФГИС «Меркурий» Промо
С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.
Автоматические и управляемые блокировки применительно к типовым конфигурациям 1С 132
10.11.2018 25032 ids79 40
Основные понятия и механизмы оптимизации клиент-серверного взаимодействия в 1C 150
23.08.2018 26163 Rain88 44
Перенос данных КА 1.1 / УПП 1.3 => БП 3.0 (перенос остатков, документов и справочников из "1С:Комплексная автоматизация 1.1" / УПП 1.3 в "1С:Бухгалтерия 3.0"). Обновлен до версий КА 1.1.115.х, УПП 1.3.130.х! Промо
Разработка позволяет перенести остатки по всем счетам бух.учета в программу "1С:Бухгалтерия предприятия 8", ред. 3.0 на выбранную дату начала ведения учета. Также переносятся документы за период и вся необходимая справочная информация. Правила оперативно обновляю при выходе новых релизов. Рассылка обновлений правил бесплатно в течение 12 месяцев. Есть видеодемонстрация проведения переноса данных. Конфигурации при использовании обмена остаются полностью типовыми. Перенос данных возможен в Бухгалтерию 3.0 версии ПРОФ, КОРП или базовую.
24700 руб.
Теорема номер тринадцать 15
15.03.2018 10103 vasilev2015 24
Введение в CI для 1С 87
21.11.2017 20373 real_MaxA 22
Онлайн-курс «Практические аспекты внедрения регламентированного учета и расчета себестоимости в 1С:ERP на крупных промышленных предприятиях» с 17 февраля по 13 марта 2020 года. Промо
Курс рассчитан для подготовки экспертов по регламентированному учету и учету затрат для внедрения на крупных промышленных предприятиях с «исторически сложившимся» учетом
9000 рублей
Как работает серверный вызов в 1С 463
18.11.2017 46863 pahich 77
#Область ВНЕШНИЕ_ВЫЗОВЫ или MVC в 1С, библиотечность и упрощение интеграции кода 44
12.10.2017 15558 for_sale 58