Мастер создания копии информационной базы для отчетности

Публикация № 1285563

Администрирование - Производительность и оптимизация (HighLoad)

отчетность копия базы OLAP аналитическая нагрузка оптимизация

Прототип инструмента для подготовки реплики в режиме только для чтения к использованию. Позволяет использовать "read-only" реплики как обычные информационные базы 1С.

Небольшое введение

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

С тех пор по этой теме появилось несколько интересных новостей:

  • Механизм копий баз данных от фирмы "1С" (только для лицензии КОРП), который также позволяет перенести часть нагрузки на дополнительную реплику баз данных средствами платформы. О новой функциональности уже была публикация с дополнительными ссылками на Инфостарт.
  • Рассмотренные в статье некоторые способы работы с "read-only" репликами перестали работать, т.к. запуск клиентского приложения теперь всегда проверяет наличие этого ограничения. Проверено на 8.3.17 - толстый клиент в обычном приложении теперь запустить нельзя.
 
 Ошибки при попытке работы с "read-only" репликами баз данных

До появления новых "фишек" от фирмы "1С", функционал распределения нагрузки (как в автоматическом, так и в ручном режиме разработчиками) был доступен и ранее. Коллеги из Softpoint создали потрясающий продукт DataCluster для SQL Server, который отлично справляется с этими задачами. Если эта тема для Вас актуальна и важна, то пройти мимо их продукта было бы не правильно.

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

  • Можно опубликовать веб-сервисы и HTTP-сервисы информационной базы, связанной с этой репликой БД и обращаться к ней через них. Но все обращения придется реализовывать разработчикам. И не факт, что этот способ не перестанет работать в будущем.
  • Можно обращаться к копии базы через внешние источники данных. Также потребует значительных трудозатрат в разработке.

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

Как создать копию

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

Мы не будем рассматривать каким лучше способом создавать копию базы для отчетности. Частично эту тему затрагивали в предыдущей публикации. Кратко напомню, что есть несколько путей (все будет описываться для SQL Server, т.к. инструмент сейчас работает только с этой СУБД):

  • Простое бэкапирование и восстановление - медленно, дешево, сердито, неэффективно. Но если подходит, то нет смысла пробовать что-то другое.
  • Доставка логов транзакций - замечательная возможность SQL Server для создания "почти в реальном времени" копии базы данных. С определенными настройками позволяет создавать копию базы данных в режиме "только для чтения". Есть ограничения по обновлению, т.к. потребуется "отключение" сессий и связанные с этим проблемы.
  • Репликация. SQL Server позволяет использовать репликацию данных разных видов. На самом деле штатно использовать репликацию к базам данных 1С практически невозможно и нужны некоторые стероиды для этого.
  • AlwaysOn - группы доступности AlwaysOn позволяют создавать копии базы данных на других инстансах практически в реальном времени. О них мы также говорили в предыдущей публикации. Также там были ссылки по настройке.
  • Моментальные снимки - еще один интересный механизм SQL Server, но с огромными ограничениями для основной базы данных. Для использования на продакшене нужно любить рисковать и закрывать глаза на очевидные проблемы :)

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

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

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

Назначение и возможности

Наконец-то мы подобрались к инструменту. Главное его назначение - это помочь использовать реплику "только для чтения" как обычную информационную базу 1С. То есть к базе данных в режиме "read-only" можно будет подключить информационную базу 1С в кластере и работать с ней привычным образом:

  • Запускать клиентские приложения (тонкий и толстый клиент, обычное и управляемое приложение)
  • Формировать отчеты, печатные формы и т.д.
  • Для использования клиентского приложения чаще всего не нужны никакие доработки конфигураций. По крайней мере типовых конфигураций, про остальные надо смотреть по ситуации.
  • Часть функционала будет работать как обычно, не смотря на то, что база только для чтения:
    • Будут сохраняться настройки форм
    • Пользовательские настройки отчетов (НЕ ВАРИАНТОВ ОТЧЕТОВ!)
    • Можно открывать внешние отчеты и обработки
    • История работы пользователей будет работать как обычно
    • И многое другое.
  • Можно даже выполнять некоторые операции изменения данных, но при этом по факту в базе ничего не изменится:
    • Запись элементов справочников
    • Запись регистров
    • Некоторые служебные операции

В общем, у Вас будет информационная база, работающая с копией рабочей базы в режиме "только для чтения" с минимальными неудобствами. Минимальными для текущей ситуации :). Вот пример работы с такой базой (Демобаза Управление торговлей 11), и когда можно все-таки нарваться на ошибки в работе.

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

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

Основными возможностями инструмента являются:

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

Требования к работе:

  • Платформа 1С версии 8.3.* (на 8.2 тоже будет работать, но потребуются адаптации скриптов).
  • СУБД Microsoft SQL Server 2008 и выше. Основная работа тестировалась на версии SQL Server 2014.
  • Служебная база данных создается на том же инстансе, на котором находится реплика только для чтения. НО возможно и на другом сервере через, например, создание связанных серверов. Все это уже другая история.
  • Возможность подключения через ADO c сервера 1С к экземпляру SQL Server с правами к копии базы данных.
  • Только управляемые формы. Для использования в обычном приложении используйте известные обходные пути.

Далее кратко опишем принцип работы.

Принцип работы

Сам принцип работы очень простой. Допустим, у нас есть два сервера: SQL-1 и SQL-2. На SQL-1 у нас основная база, в ней работают пользователи и все хорошо. На SQL-2 есть копия базы, сформированная через AlwaysOn и находящаяся в режиме "только для чтения". Обе базы имеют имя "ut_11_always_on". Просто для примера.

Напрямую подключить реплику базы "ut_11_always_on" с сервера SQL-2 в кластер 1С мы не можем. Точнее можем, но запускать клиентские приложения в обычном виде не сможем (ошибки см. в выше). Но можно пойти другим путем:

  1. На сервере SQL-2 создать служебную базу "ut_11_always_on_fake" вручную с пустым составом таблиц.
  2. Далее создать представления (view) для всех таблиц базы "ut_11_always_on". Представления будут созданы в служебной базе "ut_11_always_on_fake", но запросы будут выполняться к таблицам базы "ut_11_always_on".
  3. При этом часть служебных таблиц информационной базы перенести все же не представлениями, а обычными таблицами и скопировать в них данные из реплики. К этим системным таблицам, например, относятся:
    • V8Users
    • DBSchema
    • Config
    • ConfigSave
    • _UsersWorkHistory
    • И другие.
  4. При подключении информационной базы в кластере к этой служебной базе данных платформа 1С по факту будет работать с базой, которая не находится в режиме только для чтения. А системные таблицы и вовсе могут изменяться. Та же история работы пользователя спокойно будет записываться в таблицу "_UsersWorkHistory".
  5. Чтобы избежать ошибок с операциями INSERT, UPDATE, DELETE к нашей служебной базе мы создадим триггеры для представлений, которые позволят эти операции максимально игнорировать.
  6. Там где игнорировать нельзя - будет выдано исключение, но таких операций меньшинство и их легко избегать. В том числе и настройками прав на уровне 1С.
  7. Если системные таблицы изменяются в реплике, то их обновляем с помощью скриптов и в служебной базе (например, если мы обновим конфигурацию, добавим расширение или изменим права доступа пользователей - то один запуск скрипта и все данные в таблицах обновлены).

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

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

Примеры использования

Рассмотрим очень простой пример. Как и ранее, пусть будут два сервера SRV-SQL-01-VM и SRV-SQL-02-VM. На SRV-SQL-02-VM есть копия базы, сформированная через AlwaysOn и находящаяся в режиме "только для чтения". Обе базы имеют имя "ut_11_always_on". Вот как это выглядит на стороне СУБД.

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

Далее определяемся с именем служебной базы данных, через которую мы будем работать с репликой основной БД. Пусть для разнообразия это будет "ut_11_always_on_writetable_fake_ver2". Почему? Да просто так :). Установим это имя в настройках адаптированной базы и нажмем "Заполнить настройки объектов базы по умолчанию".

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

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

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

Именно эту базу мы можем подключить в кластере 1С и использовать ее в обычном режиме. В самом начале публикации мы уже видели как это смотрится в клиентском приложении. Посмотрим еще раз: сверху основная база, снизу "read-only" копия.

Профит!

Вместо заключения

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

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

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

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

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

  • Расширение настроек объектов служебной базы.
  • Более умное обновление объектов базы.
  • Автоматизация обновления после изменения основной базы или реплики.
  • Добавлена поддержка PostgreSQL.
  • Значительно улучшить удобства работы со служебной базой и инструменты автоматизации.
  • И многое другое.

Если будет интерес сообщества, то инструмент будет развиваться. Также как это постепенно делается с последними выпущенными обновлениями других разработок:

А Вы бы использовали такой подход? Или знаете другие более простые альтернативы?

Другие ссылки

Авторские разработки

 
 Другие разработки (бесплатные и за $m)

Скачать файлы

Наименование Файл Версия Размер
Мастер создания копии информационной базы для отчетности:

.epf 33,35Kb
28.08.20
1
.epf 1.0.0.0 33,35Kb 1 Скачать

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. starik-2005 2198 28.08.20 17:31 Сейчас в теме
Мы делали в конторе прям вот так, как нельзя, но если очень надо, то можно ))) Выпилили все попытки записать что-то в базу при создании сеанса для web-сервиса. В итоге любой отчет можно было выполнить как в текущей базе, так и в реплике (снапшот 300 ГБ базы делался менее 10 сек трижды в день и туда мы запускали всех озверелых бухов и это ОЧЕНЬ СИЛЬНО сократило загрузку SQL-сервера).

В общем достаточно было добавить в модуль любого (у нас все отчеты были на СКД, но многие из них компоновались вручную - отчеты для сравнения разных баз, например) отчет ПЯТЬ строк кода, и он появлялся в списке отчетов, которые можно было бы выполнять в реплике. Более того, даже роботы, которые формировали отчет, формировали его в реплике, если он был прописан в настройке, и даже не догадывались об этом. Более того, расшифровки прекрасно работали и тоже формировались в реплике. И всего-то пять строк кода на модуль любого отчета и никаких строк кода в форме отчета, его менеджере или даже в общей форме - только модуль )))
YPermitin; +1 Ответить
2. YPermitin 9689 28.08.20 17:33 Сейчас в теме
3. starik-2005 2198 28.08.20 17:37 Сейчас в теме
(2) обычным мелкоскуловским снапшотом.
4. YPermitin 9689 28.08.20 17:57 Сейчас в теме
(3) я помню, что мы об этом год назад говорили.

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

Плюс то что это на том же инстансе со всеми вытекающими и т.д.

Но если помогло, то круть :)
5. starik-2005 2198 28.08.20 21:19 Сейчас в теме
(4)
А если все, что-то из написаного в разделе "Ограничения по базе данных-источнику" по ссылке мешает их использовать, то это уже проблема.
Сдается мне, что в этом разделе мало что можно применить к 1С. А сам моментальный снимок - это версия состояния БД, в которой хранятся лишь измененные в основном инстансе страницы. Если в БД минимум изменений, то для снапшота нужно минимум дискового пространства. И чем чаще делается снапшот, тем меньше дисковой памяти на его поддержание уходит. Ну и никаких блокировок при чтении.
6. YPermitin 9689 29.08.20 00:47 Сейчас в теме
(5) На тех системах, где производительность была важна, я бы не смог применить снимки.

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

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

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

Еще важное ограничение:
>> Моментальный снимок базы данных должен создаваться и оставаться на том же экземпляре сервера, что и база данных-источник.
Обычно копию базы для OLAP-нагрузок создают на отдельном сервере. Обосновывается это тем, что один инстанс имеет единый буфферный кэш. Тяжелые аналитические отчеты и их запросы этот кэш быстро вымывают, что влияет на скорость выполнения операций транзакционной базы. Влияет негативно. Если мы выносим отчетную базу на отдельный сервер, то это влияние исключается. Можно посмотреть показатель производительности "SQLServer:Buffer Manager\Page life expectancy". Если страницы не задерживаются в кэше, то значит есть тяжелые запросы.
Я это к тому, что если основная база и снапшот продолжают располагаться на одном сервере, то проблемы вымывания кэша никак не решаются.
Плюс отдельный инстанс позволяет для отчетной базы изменить те же настройки параллелизма, что даст отчетам новую жизнь.
Снапшоты плюсов в этой части не дают.

Поэтому я вижу использование там, где:
1. Система не находится под постоянной нагрузкой в части изменения данных.
2. Простейшая стратегия бэкапирования.
3. Нет цели разделения оперативной и отчетной нагрузки.
4. Есть цель решить проблему избыточных блокировок СУБД при чтении. Но это уже не так актуально с появлением RCSI и управляемых блокировок.

В общем, как-то так.
Unknown31; Lansi; +2 Ответить
7. starik-2005 2198 29.08.20 10:48 Сейчас в теме
(6)
Поэтому я вижу использование там, где:
1. Система не находится под постоянной нагрузкой в части изменения данных.

У нас как раз было более 100 запросов к системе в секунду периодически (множество запросов из веб-приложения). До того, как стали использовать отчетность из снапшоте, все очень сильно проседало по производительности.

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

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

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

3. Нет цели разделения оперативной и отчетной нагрузки.

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

4. Есть цель решить проблему избыточных блокировок СУБД при чтении. Но это уже не так актуально с появлением RCSI и управляемых блокировок.


Факт остается фактом: включили снапшот изолейшн - стало чуть лучше, но нагрузка на сервер осталась очень высокой - из-за механизмов обеспечения консистентности СУБД. Вынесли отчеты в снапшот - нагрузка УПАЛА В ДВА РАЗА.

Юрий, Вы на проблему не как DBA посмотрите, а как программист, который бы делал СУБД. Что нужно для того, чтобы обеспечить параллельность работы? Чтобы между разными сеансами не было чтения и записи одних и тех же данных в один и тот же момент, чтобы данные были изолированы друг от друга при работе с ними из разных потоков для одной базы данных. В итоге наворачивается вокруг этого сотни семафоров и мьютексов, которые и тратят достаточно большое количество ресурсов, ибо многие реализации "мгновенных" операций (т.е. без отработки операций по прерыванию таймера с возвратом спящему сеансу управления) делаются "бесконечным" циклом (вон постгресовцы писали в блоге, что переписали с С на |ссемблер мьютексы - и "все стало летать" - относительно, конечно).

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

НО! Основная замута в том, что многие товарищи покупают себе память - она сейчас сравнительно не дорогая, - но не получают от этой памяти никаких преимуществ. Она просто выдирается мелкософтовским скулом до порога ограничений, а когда ее вдруг перестает хватать, то часть информации скул теряет, освобождая для новых пачек данных (был, кстати, мастеркласс на эту тему на митапе про постгрес и скул). Вот у тебя много памяти, вот ты и пишешь, и читаешь, и читаешь много. Вот начал ты много читать - скулу не стало хватать памяти для поддержки оперативного кеша с данными об остатках взаиморасчетов и товаров, и он просто освободил эти данные для того, чтобы загрузить туда данные отчета - все эти миллионы временных таблиц, сворачиваемых в финальном блоке запроса, как любят это делать 1С-неги, получившие степень "спеца по платформе". В итоге у тебя при следующей транзакции происходит чтение оперативных данных с диска, а для их размещения в памяти еще что-нибудь нужное освобождается в этой конкретной базе. Когда все в этой базе закончится, начнется освобождение того, что было поначитано в другой базе. Ну и т.д. А разделил инстанс, и большую часть времени отчетная база освобождает себе данные себя самой от предыдущих отчетов, а не данные оперативной базы, которые этой оперативной базе понадобились бы. Ведь внутри одного инстанса у скула нет приоритета, какие данные важнее, а какие можно освободить - он просто грохает, что более старое, и все.
8. YPermitin 9689 29.08.20 11:39 Сейчас в теме
(7) как и год назад Вы проигнорировали все факты что я написал и просто сказали, что у Вас все хорошо :) Только оьщие слова.

Бессмысленое обсуждение получилось. Вы либо меня троллите, либо просто игнорируете:)))

Продолжать смысла нет.
9. starik-2005 2198 29.08.20 21:11 Сейчас в теме
(8)
Продолжать смысла нет.
Так и Вы все мои аргументы игнорируете, даже не пытаясь понять.

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

См. также

daСклонение: склонение ФИО, должностей, чисел, прилагательных, существительных на языке 1С + ТестЦентр Промо

Универсальные функции v8 1cv8.cf Абонемент ($m)

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

1 стартмани

14.02.2015    103360    98    daMaster    90    

Сравнение реального дохода со средним доходом из API.HH.RU

Зарплата Управленческие v8 v8::СПР ЗУП3.x УУ Абонемент ($m)

Внешняя обработка на управляемой форме для 1С:Предприятие 8.3 по интеграции с HH.RU используя HH REST API. Ключевые функции: получение списка вакансий по должностям (Ключ для работы не нужен); расчет среднего дохода; Тестирование проводилось на платформе 1С:Предприятие 8.3 (8.3.13.1513) Зарплата и управление персоналом, редакция 3.1 (3.1.11.68) совместно с API.HH.RU.

1 стартмани

11.11.2019    4128    5    solaru    2    

Конфигурация для рекламного агентства

Управление услугами и сервисом Управление взаимоотношениями с клиентами (СRM) Производство готовой продукции (работ, услуг) Управление взаимоотношениями с клиентами (СRM) Производство готовой продукции (работ, услуг) v8 Реклама, PR и маркетинг УУ Абонемент ($m)

Данная конфигурация выполнена для решения тестового задания: Цель задания: 1) Понять, на каком из клиентов сколько мы заработали;  2) Понять, по какому виду СМИ сколько мы заработали;  3) Проследить по каждой услуге: у кого за сколько купили и кому за сколько продали, с возможностью перейти в соответствующий документ. Реализовано с помощью: 1. Справочники - контрагенты, номенклатура 2. Документы - Поступление услуг, реализация услуг 3. Отчеты - отчет по контрагентам, номенклатуре и движений.

1 стартмани

21.05.2019    4935    0    solaru    0    

Загрузка номенклатуры в УТ 10.3 из Excel файла с генерацией штрихкодов

Загрузка и выгрузка в Excel Обработка справочников Оптовая торговля Розничная торговля Учет ТМЦ Оптовая торговля Розничная торговля Учет ТМЦ v8 УТ10 Россия Абонемент ($m)

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

1 стартмани

24.03.2017    8015    7    solaru    0    

Под капотом управляемых форм

Практика программирования v8 1cv8.cf Бесплатно (free)

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

26.08.2013    267944    Evil Beaver    271    

[NotaBene] Универсальный отчет по таблице значений

Практика программирования v7.7 1cv7.md Россия Абонемент ($m)

1C v.7.7 Готовое решение. Не требует настройки. Не требует допрограммирования. Данная обработка решает часто встречающуюся задачу вывода в "красивом" виде таблицы значений (полученной, например, из запроса). Поддерживается произвольное группирование данных, отключение/включение группировок, в т.ч и создание "шахматок" (типа "продажи понедельно"). Обработка может использоваться как и в отладочных целях (для нормального просмотра ТЗ), так и в составе вполне рабочих отчетов. По крайней мере, я неоднократно клиентам данную обработку ставил вместо того, чтобы каждый раз писать замороченные выводы данных. И клиенты довольны, и мне - проще...

2 стартмани

07.05.2007    29183    3    CheBurator    63