Category Archives: Автоматизация предприятия

RemoteApp на Windows 2012 без домена

Привет, в Windows Server 2012, Microsoft сделали ограничение на использование терминального сервера, если он не введен в домен Active Directory. В частности, я столкнулся с тем, что из консоли управления сервером нельзя настроить RemoteAPP. Но к счастью, приложения можно добавить в ручную, ниже я покажу как это можно сделать.

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

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

Ниже описание этих файлов.

Создадим, или откроем из архива .rdp файл подключения.

Содержимое его, должно иметь такой вид:

redirectclipboard:i:1
redirectposdevices:i:0
redirectprinters:i:1
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:*
drivestoredirect:s:*
redirectdrives:i:1
session bpp:i:32
prompt for credentials on client:i:1
span monitors:i:1
use multimon:i:1
remoteapplicationmode:i:1
server port:i:3389
full address:s:192.168.1.112
alternate shell:s:||1cestart
remoteapplicationprogram:s:||1cestart
remoteapplicationname:s:1C Предприятие
allow font smoothing:i:1
promptcredentialonce:i:1
authentication level:i:2
gatewayusagemethod:i:2
gatewayprofileusagemethod:i:0
gatewaycredentialssource:i:0
gatewayhostname:s:
remoteapplicationcmdline:s:
screen mode id:i:2
winposstr:s:0,3,0,0,800,600
compression:i:1
keyboardhook:i:2
audiocapturemode:i:0
videoplaybackmode:i:1
connection type:i:7
networkautodetect:i:1
bandwidthautodetect:i:1
displayconnectionbar:i:1
enableworkspacereconnect:i:0
disable wallpaper:i:0
allow desktop composition:i:0
disable full window drag:i:1
disable menu anims:i:1
disable themes:i:0
disable cursor setting:i:0
bitmapcachepersistenable:i:1
audiomode:i:0
autoreconnection enabled:i:1
prompt for credentials:i:0
negotiate security layer:i:1
remoteapplicationicon:s:
shell working directory:s:
gatewaybrokeringtype:i:0
use redirection server name:i:0
rdgiskdcproxy:i:0
kdcproxyname:s:

Вам нужно изменить строчки, на ваши порт и адрес:

server port:i:3389
full address:s:192.168.1.112

А так же, в случае, если добавляете не 1С, то эти то же:

alternate shell:s:||1cestart
remoteapplicationprogram:s:||1cestart
remoteapplicationname:s:1C Предприятие

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

Дальше добавим наше приложение в список разрешенных, для этого нужно будет отредактировать реестр. Я сделал дамп ветки которую нужно добавить для 1С 8.2. В архиве, файл называется 1cestart.reg

Его содержимое:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications\1cestart]
«RequiredCommandLine»=»»
«Name»=»1C Предприятие»
«SecurityDescriptor»=»»
«CommandLineSettings»=dword:00000000
«IconIndex»=dword:00000000
«Path»=»C:\\\\Program Files (x86)\\\\1cv8\\\\common\\\\1cestart.exe»
«ShortPath»=»C:\\\\PROGRA~2\\\\1cv8\\\\common\\\\1cestart.exe»
«ShowInTSWA»=dword:00000001
«IconPath»=»%SystemRoot%\\Installer\\{D4895455-7B12-4E0B-B5F0-EFF6B9C3F93E}\\ShortCut_EnterprSt_41216A7DC6764F558CBAC68BC28BD550.exe»

Если вы будете заносить эти параметры вручную, то нужно в путях изменить \\\\ на \\.

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

«IconPath»=»%SystemRoot%\\Installer\\{D4895455-7B12-4E0B-B5F0-EFF6B9C3F93E}\\ShortCut_EnterprSt_41216A7DC6764F558CBAC68BC28BD550.exe»
«Path»=»C:\\\\Program Files (x86)\\\\1cv8\\\\common\\\\1cestart.exe»
«ShortPath»=»C:\\\\PROGRA~2\\\\1cv8\\\\common\\\\1cestart.exe»

И его имя в строке:

«Name»=»1C Предприятие»

А также ветку реестра, то есть если вы пробрасываете, например, калькулятор, то и ветка должна быть, не Applications\1cestart, а Applications\calc, и не забудьте, проверить, чтобы параметры названия приложения, в файле .rdp, соответствовали названию этой ветки.

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

Если же у вас что не заработало, проверьте ветку реестра, создалась ли она вообще, и правильные ли в ней пути прописаны, если в ней все верно на 100%, то попробуйте запустить файл termital.reg из архива.

Его содержимое, если кто захочет добавлять руками:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList]
«LicenseServers»=hex(7):00,00
«CertificateIssuedBy»=»»
«LicensingType»=dword:00000005
«fHasCertificate»=dword:00000000
«CertificateExpiresOn»=»»
«CentralLicensing»=dword:00000000
«fDisabledAllowList»=dword:00000000
«CertificateIssuedTo»=»»
«CustomRDPSettings»=»authentication level:i:2»

Источник: https://www.mytechnote.ru/remoteapp-na-windows-2012-bez-domena

Оптимизация скорости работы «1С:Підприємство». Процесс «1С:Підприємство» rmngr.exe грузит процессор

Один из серверов «1С:Підприємство», который я обслуживаю, очень странно себя вел. Загрузка процессора на машине с сервером «1С:Підприємство» почти всегда была 100%, даже когда на нем никто не работал. Базы хранились в MSSQL, их было относительно много, но реально людей, которые с ними работали — мало. Одновременно работало не больше 10-15-ти пользователей в очень вялом режиме.

Введение

Этот сервер привлек мое внимание сразу же, как только я стал с ним работать. Предыдущий администратор безрезультатно бился над производительностью, приобрел 2 внешних корзины для отдельного рейда под базы данных mssql и временные данные пользователя «1С:Підприємство», но существующую проблему по загрузке процессора это не решало, хотя немножко разгрузило диски, но реальная проблема была не в них.

На сервере размещались примерно 30-35 баз, в которых работали по 1-2 человека и пару баз были, где работали по 3-5 человек одновременно. Все это крутилось вместе с MSSQL сервером на отдельном железном сервере с одним стареньким ксеоном и 32 гб оперативы. В принципе, для этих задач железо было более чем.

Первое, на что я обратил внимание, это то, что процессор был загружен даже ночью, когда на сервере никто не работал. Полез в консоль администратора смотреть, что нагружает процессор. Оказалось, что это фоновые задачи. Для большинства баз они были не нужны и все лишнее отключил. Нагрузка процессора сразу упала до приемлемого уровня в 60-70%, а диски вообще полностью разгрузились. Я про сервер забыл на какое-то время.

Снова к нему вернулся, когда пользователи стали жаловаться на очень медленную работу баз «1С:Підприємство». Процессор к тому времени почти всегда был загружен на 100%. Лишних фоновых задач уже не было. Надо было разбираться более внимательно, в чем тут проблема.

Разбираемся что конкретно в rmngr.exe грузит процессор

Загрузку процессора в равной степени давал процесс rmngr.exe и rphost.exe. Rphost уже ранее был настроен и оптимизирован. Вот такие настройки дали стабильную работу без необходимости перезапускать сервер месяцами:

Борьба с торможением

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

Борьба с торможением 1С

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

Борьба с торможением 1С

После того, как вы поставите галку, агент сервера «1С:Підприємство» сам перезапустится с новыми настройками. После этого в диспетчере задач у вас будет порядка 15-ти процессов rmngr.exe с разными pid. Смотрите, какой из процессов больше всего использует процессор и в консоли управления «1С:Підприємство» в разделе Менеджеры кластера по pid смотрите описание процесса.

Борьба с торможением 1С

Борьба с торможением 1С

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

Блокирование торможения 1С

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

Сервис журнала регистраций «1С:Підприємство» нагружает процессор

Я выяснил, что конкретно дает чрезмерную нагрузку на сервер. Посмотрел на объем журналов регистраций. У некоторых баз он достигал размера в 10-15 гигов. После чистки серверу стало заметно легче, нагрузка снова опустилась, но где-то до 80-90% и я на несколько месяцев забыл про сервер.

Он напомнил о себе тормозами и загрузкой процессора в 100%. Проделанные выше операции уже не давали результата. Баз стало немного больше и нужно было думать, как разгрузить сервер. Он работал на все 100% даже в нерабочее время, когда на нем не было ни одного реального пользователя. Сервис журнала регистраций потреблял 30-40% процессорного времени.

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

Переводим сервер на старый вариант ведения логов журнала регистраций

Какой-то одной настройки или автоматического решения для перевода лога журнала регистраций в старый формат lgf нет. Чтобы использовать старый формат необходимо остановить службу Агента Сервера 1С:Предприятия. Затем отправиться в папку C:\Program Files (x86)\1cv8\srvinfo\reg_1541, выбрать по id базу, в которой хотите изменить формат лога. У меня баз было много, мне лениво стало вручную в каждой менять формат. Я выбрал базы с самым большим объемом и изменил формат только у них.

Оптимизация работы 1С

В каждой папке с базой есть каталог 1Cv8Log, а в нем 2 файла: 1Cv8.lgd и 1Cv8.lgd-journal. Их надо удалить и вместо них в этой папке создать пустой файл 1Cv8.lgf. Проделать такую операцию нужно со всеми базами, где будете менять формат лога. Старый не обязательно удалять, лучше его перенести куда-нибудь, вдруг пригодятся записи из него.

После этого можно запускать службу Агента Сервера 1С:Предприятия. После перехода на старый формат журнала регистрации, нагрузка процесса rmngr.exe упала практически до 0, а сервера в целом до приемлемых 40-60%.

Заключение

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

В очередной раз я победил тормоза «1С:Підприємство» в виде 100% загрузки процессора сервисом rmngr.exe. С базами «1С:Підприємство» никогда не приходится скучать, постоянно решаешь какие-нибудь вопросы и проблемы, которые возникают чаще всего после обновлений. С настороженностью смотрю на рост потребления ресурсов процессами rphost.exe. Чутьем чую, что скоро придется решать вопросы загрузки процессора именно ими.

 

Источник: https://serveradmin.ru/1s-nagruzka-na-protsessor-protsessa-rmngr-exe-100/

 

Подводные камни при работе в «1С:Підприємство» c датами

Работа с датами в 1С

Работа с датой

Знал бы, где упасть – соломки бы подстелил

(Народная мудрость)

Довелось в практической деятельности разработчика в «1С:Підприємство» столкнуться со следующим явлением. В базе было создано наперед несколько тысяч объектов справочника «Информационные карты» — для последующего занесения в них и хранения информации о постоянных покупателях торговой сети. Объектов было создано примерно 10 тысяч, на момент возникновения инцидента заполнено данными было около 7 тысяч карт. Каждое утро одно регламентное задание находило именинников среди клиентов сети (данные о которых были занесены в базу), а другое рассылало им поздравительные СМС с приглашениями получить подарок в любом удобном покупателю магазине. Запрос, который выбирал именинников из общей массы, имел приблизительно следующий вид:

На место параметров «День» и «Месяц» подставлялись соответствующие день и месяц текущего дня. Всё шло своим чередом, именинников в среднем находилось по 10-20 с периодическими всплесками до 30, но тут наступило 1е января. Регламент вдруг посчитал нужным поздравить почти 3 тысячи человек (к счастью, телефоны были указаны только у 300 из этого количества).

Анализ ситуации показал, что причиной такого поведения процедуры стало своеобразное понимание понятия NULL создателями среды «1С:Підприємство» (а также нежелание привести это понимание к общему знаменателю с пониманием этого у авторов языка запросов SQL).

В данном конкретном случае дело было в следующем. Даже незаполненное данными поле типа ДАТА вовсе не равно NULL, как можно было бы подумать. Среда «1С:Підприємство» в пустое поле ДАТА записывает значение Дата(“00010101”), то есть 1 января 0001-го года (видимо, нашей эры, хотя я не был бы столь уверен – имея опыт работы с «1С:Підприємство» больше недели), при этом никак не отражая это на форме. В то же время – хотя какие-то данные в поле (и соответствующую ячейку памяти) записаны, функция ЗначениеЗаполнено(Дата) возвращает Ложь. Это обстоятельство стоит учитывать при разработке операций с датами (хотя тип ДАТА вовсе не единственный, где NULLи не заполненное значение вовсе не тождественны) – во избежание подобных затруднений.

Конкретно в данном случае можно либо при обработке результатов запроса проверять значение ДатаРожденияКлиента на заполненность (что менее производительно), либо задавать в запросе отбор еще и по году рождения клиента (например с 1800 – чтобы наверняка)

 

Автор: Виталий Моргун

«Обнаружено потенциально опасное значение Request.Path», полученное от клиента (веб доступ)

web_development

Ни с того ни с сего перестало работать веб-приложение на «1С:Підприємство». Начал искать, оказывается на локальном компьютере (на сервере) выводит ошибку, подобную:

[HttpException (0x80004005): Обнаружено потенциально опасное значение Request.Path, полученное от клиента (:).]
System.Web.HttpRequest.ValidateInputIfRequiredByConfig() +9023209
System.Web.PipelineStepManager.ValidateHelper(HttpContext context) +59

В процессе поиска причины, нашел решение проблемы:

1. Открываем IIS.
2. Открываем наш «сайт»
3. Идем в сопоставления обработчиков
4. Ищем ISAPI-dll, выделяем строку.
5. Справа нажимаем «Добавить сопоставление сценария»
6. Путь запроса — «*», Исполняемый файл — «C:\….\wsisapi.dll».
7. Да
Все работает.

Урезание логов в SQL Server 2012

Логи транзакций в MS SQL имеют обыкновение разрастаться, что иногда может привести к окончанию места на диске. Чтобы этого не происходило, в SQL Server существует операция урезания логов (Truncate). Урезание логов производится автоматически, в зависимости от модели восстановления:

• В простой модели (Simple) — после достижения контрольной точки;
• В модели полного восстановления (Full) — после создания бэкапа логов, при условии что со времени предыдущего бэкапа была достигнута контрольная точка.

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

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

Для урезания лога открываем Management Studio, выбираем нужную базу, кликаем на ней правой клавишей мыши и в открывшемся контекстном меню выбираем пункт «Properties». Переходим на вкладку «Options» и изменяем модель восстановления базы (Recovery model) на Simple.

shrink1Затем в том же контекстном меню переходим в раздел Tasks -> Shrink -> Files. В поле File type выбираем Log, в поле File name указываем имя файла логов. В поле «Shrink action» выбираем «Reorganize pages before releasing unused space», задаем желаемый размер файла и жмем ОК.

Обрезание базы данных MsSQL

После завершения операции возвращаем режим восстановления базы обратно в Full.

Тоже самое можно проделать из Query Analizer с помощью скрипта:

Это всего лишь  один из способов быстрого уменьшения размера логов. Не самый красивый ? но наиболее простой и эффективный.

Источник: http://windowsnotes.ru/database/urezanie-logov-v-sql-server-2012/

Услуги программирования в 1С. Киев

Логирование в «1С:Підприємство»

linux_and_windows

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

Использовать для этих целей логирование «1С:Підприємство» чрезвычайно не эффективно и не удобно.

В таких случаях удобно использовать подход применяемый в Unix-системах: писать логи в обычные текстовые файлы, а потом делать их обработку через эффективно работающие Unix-команды: grep, tail, cat, less и т.п.

Итак, рассмотрим программную реализацию в «1С:Підприємство»:

Название модуля — К2_Лог

Примеры применения команды:

Фиксация времени выполнения регламентных задач:

В данном примере мы фиксируем время выполнения регламентного задания и записываем данное время в лог. Причем, записываем и начало регламентного задания и окончания. Таким образом, если регламентное задание не завершилось — мы видим, что 2-я строка не записалась.

Фиксация ошибок

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

 

Анализ логов с помощью команд Linux

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

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

Для того, чтоб команды Linux поддерживались в Windows, необходимо сделать ряд вещей:

Необходимо распаковать в системный каталог, доступный в путях пакет UnxUpdates: http://unxutils.sourceforge.net/

После этого в командной строке, будут восприниматься команды Linux.

Вывод на экран последних поступающих строк в логе:

Данная команда полезна для мониторинга поступающих строк в лог-файл.

Поиск нужной строки в логе:

Команда cat — выводит на экран текстовый файл. Команда grep — фильтрует вывод по заданному условию. Таким образом, соединение 2-х данных команд позваляет отфильтровать данные в текстовом файле по заданному выражению.

Вывод на экран строк по заданному слову

Данная команда выводит поступающие строки, в которых заданы указанные слова.

 

Автор: Рудюк С . А. https://corp2.net

 

 

 

 

 

 

Отправка http и https-запросов в «1С:Підприємство»

Возникла необходимость отправлять http(s) запросы через интернет и получать ответ от удаленного сервера. Как оказалось, в «1С:Підприємство» это реализуется стандартными средствами:

Резервное копирование баз данных Postgresql в Linux

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

Вот вариант резервного копирования для 3-х баз данных:

Сохранение бекапа на удаленном сервере по ssh

В условиях отсутствия локального или сетевого тома для хранения резервных копий (несколько натянутое условие, но мне пришлось столкнуться), пришлось доработать скрипт; отличие от изначального скрипта — результат дампа не сохраняется локально, а передаётся на удалённый сервер по ssh и там же производится удаление устаревших файлов:

Предварительно надо создать авторизационный ключ для пользователя (в приведённом скрипте пользователь — backup) на сервере резервного хранения и разместить приватный ключ в каталоге, доступном на чтение только пользователю root (в приведённом скрипте ключ лежит в файле /root/nbs01/backup) и настроить sshd удалённого сервера на авторизацию по ключам — об этом весьма подробно написано, например, в этой статье.
Да, трафик будет весьма серьёзным, несмотря на возможность сжатия ssh, но конкретно данное решение работает в виртуальной среде, где 3 гигабайта дампа передаются примерно за полторы минуты, что вполне приемлемо.

Восстановление базы данных из дампа

Тут всё просто — если владелец (имя «роли входа» или пользователь postgresql, указанный владельцем изначальной БД) уже существует, но нет самой базы данных, команда восстановления будет выглядеть примерно так:

/usr/pgsql-9.2/bin/pg_restore -e -j 8 -U root -W -d upp /root/files/upp-2013-11-20.pgdump

Восстановление будет выполнено в 8 потоков (для ускорения процедуры, в документации pgsql рекомендуется использовать потоков не меньше, чем доступно ядер CPU) от имени пользователя root с интерактивным вводом пароля. Файл /mnt/arc/1C8/upp-2013-11-20-09-45-51.pgdump — распакованный .gz из второго примера или изначальный дамп из первого. Целевая база (в данном примере — upp) должна уже существовать, и быть созданной из template0.

Если пользователя-владельца создать нет возможности/желания, можно добавить ключ --no-owner да и вообще, почитать что пишут на http://www.postgresql.org/docs/9.3/static/backup.html

И ещё, если на создание дампа в пару гигабайт (несжатых) уходит пара минут, то на восстановление данного дампа в один поток (если не указать ключ распараллеливания — «-j 8» в примере выше) потребуется уже полчасика, на том же железе. А если использовать текстовые дампы (не указать «-F c» при создании дампа, и для восстановления использовать стандартную команду psql dbname < infile или использовать конвейер типа pg_restore infile.pgdump | psql), времени потребуется ещё больше — данные методы целесообразно использовать не для полного восстановления, а когда требуется восстановить только определённую часть базы данных.

Для восстановления БД с удалённой машины (сервера хранилища) можно использовать конструкцию вида:

zcat upp-2014-10-22-07-30-03.pgdump.gz | ssh 192.168.1.2 «psql upp-copy > /root/files/log-create»

Здесь zcat — команда вывода содержимого архива на stdout, upp-2013-10-22-07-30-03.pgdump.gz — имя восстанавливаемого архива, 192.168.1.2 — сервер postgresql, на который восстанавливаем дамп, upp-copy — имя базы данных, в которую разворачиваем дамп (на момент восстановления должна существовать, быть пустой, и иметь необходимые права для «роли входа», использованной в изначальной БД); чтобы не засорять экран выводом psql о процессе создания объектов, перенаправим вывод в файл (сообщения об ошибках, в случае их наличия, будут выводиться в терминал). В данном примере предполагается, что у пользователя, от имени которого мы подключаемся по ssh к серверу postgres есть право работать с базами данных, поэтому авторизация в БД не описана.

Резервное копирование MySQL

Вариант для реализации резервного копирования MySQL:

 

Еще один способ резервного копирования Postgresql

Источники: http://www.bubnov.su/stati/rezervnoe-kopirovanie-baz-dannyh-postgresql

http://habrahabr.ru/post/82278/

Управление торговлей, Бухгалтерия

Диалог позволяет осуществлять групповое проведение документов и восстановление последовательностей проведения документов.

Открываем «1С:Підприємство» (в режиме предприятия)  – Операции – Проведение документов.

9f6e394758ee77135fc83377047e5a5b

Проведение документов

На закладке «Проведение документов» осуществляется проведение выбранных документов в указанном интервале. Если Вы хотите чтобы какой – либо документ участвовал в проведение необходимо правой клавишей мыши поставить пометку 6.JPG слева от наименований таких документов.

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

fc0d2a1696bb4ef0772aff812401582fПри необходимости проведения документов без ограничения по дате, необходимо установить флажок «Не ограничивать«

614563d3a87e36665a09d8763629af92Также необходимо выбрать какие именно документы будут участвовать в проведении:
·        Проведенные
·        Непроведенные
·        Проведенные и непроведенные

c235ea8de310604e5f544c0d88c62d00После установки всех необходимых параметров для выполнения проведения документов следует нажать кнопку «Выполнить».
Если проведение прошло успешно, будет выдано сообщение «Проведение документов завершено!».

Если Вы хотите выйти из режима проведения документов необходимо нажать на кнопку «Закрыть».

Восстановление последовательности

На закладке «Восстановление последовательности» осуществляется восстановление последовательности проведения документов.

9b7f508610115e01658467bcc4ca03b3

В списке «Восстанавливать последовательности» выводится список всех существующих в конфигурации последовательностей. Те последовательности, которые должны быть восстановлены: слева от наименований таких последовательностей необходимо клавишами или мышью проставить отметку 6.JPG.

В графе «Актуальна» для каждой последовательности выводится текущая позиция границы последовательности.

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

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

Источник: http://esodin.by/main/smallbusiness/Enterprise_8/untitled10.php?option=com_content&task=view&id=108&catid=24

Регистры сведений в языке «1С:Підприємство» (в примерах)

Регистры сведений

Описание:

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

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

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

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

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

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

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

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

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

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

Эти два варианта влияют на способ внесения информации, а не на основную логику работы регистра.

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

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

В программных модулях для общих действий над регистром сведений (поиск, выбор и создание записей регистра) служит объект РегистрСведенийМенеджер.<Имя регистра сведений>. Для чтения, записи и удаления отдельных записей регистра сведений, не управляемого регистраторами, служит объект РегистрСведенийМенеджерЗаписи.<Имя регистра сведений>. Для считывания и занесения набора записей в базу данных по определенному условию отбора служит объект РегистрСведенийНаборЗаписей.<Имя регистра сведений>. Для динамического обхода записей регистра служит объект РегистрСведенийВыборка.<Имя регистра сведений>.

Источник: http://helpme1c.ru/registry-svedenij-v-yazyke-1s-8-v-primerax