Чтобы провести деноминацию в 1С на 1 июля 2016 года, нужно учесть, что желательно учёт вести в двух суммовых измерениях в белорусских рублях старого и нового образца. Однако, даже если Вы решите упростить задачу и проведёте деноминацию в программе вручную или с помощью обработки на 1 июля, то есть деноминируете итоги в соотношении 1:10000, то получите "кашу" в базе данных. Такие отчёты как ОСВ, акт сверки, карточка счёта, журнал-ордер и все остальные в программе 1С будут воспринимать данную операцию как "логичную". Обороты за период "поплывут", а итоги будут суммировать старые и новые деньги как равнозначные. Поэтому этот вариант исключим сразу.
Пять вариантов решения:
1)Корректный вариант!Разделить базу данных на две. Во второй провести деноминацию 1 июля.
Выполнить доработку форм и метаданных до копеек. Первое полугодие в первой базе оставить как есть. А учёт во втором полугодии, во второй базе, уже начать вести в денежном выражении нового образца. Перед разбиением базы на две, нужно доработать модуль и все метаданные, создать её копию и сделать свёртку обработкой WRAP.ert. Потом, этой же обработкой, в новой базе провести деноминацию - убрать из уже сделанных, во втором квартале, проводок и метаданных "0000". Но есть один недостаток. Разбивая базу на две Вы лишитесь оперативность при получении данных. Теперь, например, для того чтобы построить акт сверки за год по контрагенту - придётся делать это в двух базах! Выбирая этот вариант нужно понимать все нюансы разделения базы на полугодия.
2)Корректный вариант!Проведение деноминации в рабочей базе (без разделения):
Выполнить доработку форм и метаданных до копеек. Создать сторнированные проводоки с учётом коэффициента деноминации 10000 (то есть если на Сч.по Дт.=3.000.000 -> будет сделана проводка Дт. -2.999.700 -> в итоге Сч.Дт=300). Внимание! Нужно иметь ввиду, что отчёты желательно строить в двух экземплярах (до 1 июля и после).
Выполнить доработку форм и метаданных до копеек.
3) Корректный вариант, но очень затратный! Доработать все метаданные 1С для деноминации и провести её на 1 июля 2016 года.
Самый дорогой вариант для предприятия.
В версии 8.2 и 8.3 можно создать дополнительное измерение "сумма в рублях старого образца".
В версии 7.7 на невалютных счетах можно использовать вал.сумму или доп.забалансовый счёт (рубли образца 2009 года).
Плюс ко всему придётся переделать практически все объекты метаданных. Отчеты, справочники, документы, обработки, глобальный(7.7) и общие(8) модули, план счетов, регистры и т.п. Реализовать данный метод смогут лишь крупные предприятия с массивным штатом программистов 1С.
4) Признан некорректным!Продолжить вести учёт в старых денежных единицах.
Совершенно не затратный и для большинства компаний самый оптимальный, так как делать то ничего и не надо. Коротко говоря - оставить всё как есть. В шапке некоторых отчётов, например, акта сверки, для корректности, можно добавить фразу типа этой: "в расчётах используется белорусский рубль образца 2000 года".
5) Признан некорректным!Разделить базу данных на две. Во второй провести деноминацию 1 января.
"Закрыть" период (первое полугодие) в первой базе, чтобы больше не вносить туда изменения. Во второй базе сделать свёртку обработкой WRAP.ert на 1 января. Незабудьте предварительно создать копию. Соответственно с 1 января 2016г. учёт будет деноминированный. Помните, что вносить изменения (если таковые будут) до 01 июля 2016 придётся вносить в обе информационные базы. В начале 2017 можно будет свернуть и обрезать Вашу рабочую базу на 1 июля. Так у Вас будет две базы: 1-я до 1.07.2016 (без деноминации) и 2-я после 1.07.2016 (с деноминацией).
6) Признан некорректным! Доработать только отчёты в 1С для деноминации 1 июля 2016 года.
В отчётах, которыми чаще всего пользуются бухгалтера для отправки данных "внешним" контрагентам (акт сверки, деб.задолженность, отчёт по движению ДС и т.п.), выводить дополнительную строку с коэффициентом 1:10000 под суммой с названием "сумма в белорусских рублях образца 2009 года".
Одной из часто встречающихся причин не оптимальной работы системы является неправильное или несвоевременное выполнение регламентных операций на уровне СУБД. Особенно важно выполнять эти регламентные процедуры в крупных информационных системах, которые работают под значительной нагрузкой и обслуживают одновременно большое количество пользователей. Специфика таких систем в том, что обычных действий, выполняемых СУБД автоматически (на основании настроек) оказывает недостаточно для эффективной работы.
Если в работающей системе наблюдаются какие-либо симптомы проблем с производительностью, следует проверить, что в системе правильно настроены и регулярно выполняются все рекомендуемые регламентные операции на уровне СУБД.
Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan. Существуют так же другие способы автоматизации выполнения этих процедур. В настоящей статье для каждой регламентной процедуры дан пример ее настройки при помощи Maintenance Plan для MS SQL Server 2005.
Для MS SQL Server рекомендуется выполнять следующие регламентные операции:
Обновление статистикОчистка процедурного КЭШаДефрагментация индексовРеиндексация таблиц базы данных
Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур.
Обновление статистик
MS SQL Server строит план запроса на основании статистической информации о распределении значений в индексах и таблицах. Статистическая информация собирается на основании части (образца) данных и автоматически обновляется при изменении этих данных. Иногда этого оказывается недостаточно для того, что MS SQL Server стабильно строил наиболее оптимальный план выполнения всех запросов.
В этом случае возможно проявление проблем с производительностью запросов. При этом в планах запросов наблюдаются характерные признаки неоптимальной работы (неоптимальные операции).
Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.
Для обновления статистик по всем таблицам базы данных необходимо выполнить следующий SQL запрос:
Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.
Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день.
Приведенный выше запрос обновляет статистики для всех таблиц базы данных. В реально работающей системе разные таблицы требуют различной частоты обновления статистик. Путем анализа планов запроса можно установить, какие таблицы больше других нуждаются в частом обновлении статистик, и настроить две (или более) различных регламентных процедуры: для часто обновляемых таблиц и для всех остальных таблиц. Такой подход позволит существенно снизить время обновления статистик и влияние процесса обновления статистики на работу системы в целом.
Запустите MS SQL Server Management Studio и подключитесь к серверу СУБД. Откройте папку Management и создайте новый план обслуживания:
Создайте субплан (Add Sublan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач:
Настройте расписание обновления статистик. Рекомендуется обновлять статистики не реже одного раза в день. При необходимости частота обновления статистик может быть увеличена.
Настройте параметры задачи. Для этого следует два раза кликнуть на задачу в правом нижнем углу окна. В появившейся форме укажите имя базу данных (или несколько баз данных) для которых будет выполняться обновление статистик. Кроме этого вы можете указать для каких таблиц обновлять статистики (если точно неизвестно, какие таблицы требуется указать, то устанавливайте значение All).
Обновление статистик необходимо проводить с включенной опцией Full Scan.
Сохраните созданный план. При наступлении указанного в расписании срока обновление статистик будет запущено автоматически.
Очистка процедурного КЭШа
Оптимизатор MS SQL Server кэширует планы запросов для их повторного выполнения. Это делается для того, чтобы экономить время, затрачиваемое на компиляцию запроса в том случае, если такой же запрос уже выполнялся и его план известен.
Возможна ситуация, при которой MS SQL Server, ориентируясь на устаревшую статистическую информацию, построит неоптимальный план запроса. Этот план будет сохранен в процедурном КЭШе и использован при повторном вызове такого же запроса. Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план.
Таким образом, рекомендуется всегда после обновления статистик очищать содержимое процедурного КЭШа.
Для очистки процедурного КЭШа MS SQL Server необходимо выполнить следующий SQL запрос:
Этот запрос следует выполнять непосредственно после обновления статистики. Соответственно, частота его выполнения должна совпадать с частотой обновления статистики.
Настройка очистки процедурного КЭШа
для (MS SQL 2005)
Поскольку процедурный КЭШ необходимо очищать при каждом обновлении статистики, данную операцию рекомендуется добавить в уже созданный субплан «Обновление статистик». Для этого следует открыть субплан и добавить в его схему задачу Execute T-SQL Statement Task. Затем следует соединить задачу Update Statistics Task стрелочкой с новой задачей.
В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»:
Дефрагментация индексов
При интенсивной работе с таблицами базы данных возникает эффект фрагментации индексов, который может привести к снижению эффективности работы запросов.
Рекомендуется регулярное выполнение дефрагментации индексов. Для дефрагментации всех индексов всех таблиц базы данных необходимо использовать следующий SQL запрос (предварительно подставив имя базы):
Дефрагментация индексов не блокирует таблицы, и не будет мешать работе других пользователей, однако создает дополнительную нагрузку на SQL Server. Оптимальная частота выполнения данной регламентной процедуры должна подбираться в соответствии с нагрузкой на систему и эффектом, получаемым от дефрагментации. Рекомендуется выполнять дефрагментацию индексов не реже одного раза в день.
Возможно выполнение дефрагментации для одной или нескольких таблиц, а не для всех таблиц базы данных.
Настройка дефрагментации индексов (MS SQL 2005)
В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов». Добавьте в него задачу Reorganize Index Task:
Задайте расписание выполнения для задачи дефрагментации индексов. Рекомендуется выполнять задачу не реже одного раза в неделю, а при высокой изменчивости данных в базе еще чаще – до одного раза в день.
Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.
Реиндексация таблиц включает полное перестроение индексов таблиц базы данных, что приводит к существенной оптимизации их работы. Рекомендуется выполнять регулярную переиндексацию таблиц базы данных. Для реиндексации всех таблиц базы данных необходимо выполнить следующий SQL запрос:
Реиндексация таблиц блокирует их на все время своей работы, что может существенно сказаться на работе пользователей. В связи с этим реиндексацию рекомендуется выполнять во время минимальной загрузки системы.
После выполнения реиндексации нет необходимости делать дефрагментацию индексов.
В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов». Добавьте в него задачу Rebuild Index Task:
Задайте расписание выполнения для задачи реиндексирования таблиц. Рекомендуется выполнять задачу во время минимальной нагрузки на систему, не реже одного раза в неделю.
Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.
Реиндексация таблиц базы данных
Необходимо осуществлять регулярный контроль выполнения регламентных процедур на уровне СУБД. Ниже приведен пример контроля выполнения плана обслуживания для MS SQL Server 2005.
Откройте созданный вами план обслуживания и выберите из контекстного меню пункт «View History»:
Откроется окно с протоколом выполнения всех заданных регламентных процедур.
Успешно выполненные задачи и задачи, выполненные с ошибками, будут помечены соответствующими иконками. Для задач, выполненных с ошибками, доступна подробная информация об ошибке.
При написании небольших автоматизированных тестов часто надо обойти всю конфигурацию и проверить, например, для всех форм какое-нибудь свойство. Это всё легко делается через свойство глобального контекста "Метаданные", но чтоб дорбаться до обхода реквизитов надо написать кучу вложенных циклов. При этом код становится слабочитаемым и слабомодифицируемым.
Ниже приведен небольшой модуль, который решает задачу легко и удобно. Создана специальная функция РазвернутьСтрокуОбходаМетаданных, которая может по строке типа "Метаданные.Справочники.*.Реквизиты.*" построить массив строк с перечислением всех реквизитов всех справочников. При помощи этой и нескольких других функций в экспортных функциях модуля реализованы вполне прикладные задачи - получение всех реквизитов, всех макетов, всех форм конфигурации и построение таблицы всех составных типов.
Обработка демонстрирует возможности интеграции 1С с картографическими сервисами, в ней поддерживается работа трех поставщиков услуг / карт — Яндекс, Google. Рамблер.
Автор: Діма Головаченко - http://smaylukk.com.ua
но так вот сама обработка + еще 2 : Скачивать файлы может только зарегистрированный пользователь!
При обходе результата запроса нередко возникает необходимость получения всех значений группировок внутри какой-либо другой группировки. Такая возможность может понадобиться, например, при выводе кросс отчета. Для обеспечения такой возможности в объекте ВыборкаИзРезультатаЗапроса предусмотрен третий параметр функции Выбрать().
Рассмотрим пример. Пусть нам необходимо получить кросс-отчет по остаткам номенклатуры на различных складах. Номенклатуру необходимо вывести в строках, склады - в колонках. Запрос для получения остатков будет выглядеть так:
Для обхода номенклатуры воспользуемся выборкой из результата запроса:
Для обхода внутри номенклатуры всех складов, присутствующих в результате запроса, получим вложенную выборку от выборки номенклатуры, с указанием третьего параметра "ВСЕ":
В случае если необходимо построить несколько отдельных кросс-таблиц для каждого значения некой группировки, необходимо в качестве третьего параметра выборки указать имя группировки, внутри которой необходимо получить все значения, вошедшие в запрос.
Пример:
В данном примере будут получены все значения складов, присутствующие в ранее выбранной организации.
Грамотно построить работу и распланировать рабочее время сотрудников – задача не из легких, особенно в «горячую» пору очередных отпусков, ведь нужно сделать все необходимое, чтобы отсутствие «ценных кадров» никоим образом не отразилось на деятельности вашей организации. В этой статье мы затронем вопрос планирования отпусков персонала в программе «1С:Зарплата и Управление Персоналом 8.1».
Для начала необходимо создать документ «Планирование отпусков». В документе осуществляется планирование ежегодных отпусков работников предприятия, т.е. указывается список работников и периоды их отпусков.
В графе «Состояние» есть два варианта: «Утвержден» или «Не утвержден».
Проведение документа
При проведении документа производится проверка непротиворечивости получающегося графика.
После проведения можно открыть меню «Персонал» - «Отпуска» - «График отпусков». Перед вами появится табличное поле со всеми введенными отпусками.
Здесь можно отследить по цвету ячеек, кто из сотрудников уже был в отпуске, кто еще только запланировал, но еще не утвержден.
В шапке таблицы есть кнопка «Остаток отпусков». Справочник хранит остатки неиспользованных дней управленческого ежегодного отпуска за прошлые года без учета фактических отпусков текущего рабочего года. Остатки хранятся в разрезе календарных лет, с 01.01. по 31.12. В год, когда принят сотрудник, остатки хранятся с даты приема на работу по 31.12.
Заполнять справочник необходимо в двух случаях:
- При начале работы с механизмом остатков отпусков;
- Для ускорения времени проведения документов и формирования отчетов.
Начало работы с механизмом остатков отпусков
Если в программе уже есть документы фактических отпусков, использовать механизм остатков можно с того года, с которого в программе введены фактические отпуска. Порядок ввода данных в этом случае будет следующий:
1. Ввести остатки за год, являющийся предыдущим по отношению к тому году, с которого в программе введены фактические отпуска. Если данных об остатках нет, можно считать, что остатки нулевые, и ввести в качестве остатков нулевые остатки;
2. Заполнить регламентированный производственный календарь за все года, начиная с того года, с которого в программе введены фактические отпуска;
3. Перепровести документы фактических отпусков, чтобы программа посчитала количество дней, использованных каждым фактическим отпуском.
Если в программе данных о фактических отпусках нет, тогда необходимо ввести остатки за предыдущий рабочий год. Если данных об остатках нет, рекомендуется ввести нулевые остатки по каждому сотруднику.
Ускорение времени проведения документов и формирования отчетов
Если в процессе эксплуатации механизма медленнее проводятся документы или формируются отчеты по отпускам, заполнение справочника поможет решить эту проблему. Программа будет рассчитывать остатки каждого сотрудника не с даты приема на работу, а только для тех рабочих лет, для которых нет записей в справочнике остатков. Заполнять справочник можно вручную, вызовом команды заполнения или автоматически, настроив регламентное задание. Функция заполнения остатков заполняет остатки для тех рабочих лет, для которых еще не введены остатки в справочнике. Функция «Рассчитать» в форме редактирования остатков по сотруднику рассчитает остатки автоматически с даты приема сотрудника на работу, используя данные о фактических отпусках, введенных в программу и проигнорировав все остатки, введенные вручную. Увидеть информацию об актуальных остатках по сотрудникам можно из карточки сотрудника.
Также из окна «График отпусков» можно ввести дополнительные дни отпуска, нажав кнопку «Дополнительные дни отпуска». Документ предназначен для ввода дополнительных дней управленческого отпуска, обычно называемых «отгулами». Документ позволяет ввести дополнительные дни управленческого отпуска списку сотрудников. Дни отпуска записываются на дату документа. По каждому отпуску можно ввести примечание. Это примечание будет выводиться в справке по отпуску, которую можно открыть из обработки «График отпусков».
И последнее меню, которое можно вызвать из таблицы - это «Отчет по отпускам».
Отчет предоставляет возможность сформировать разнообразные списки отпусков и графики отпусков сотрудников, как по регламентированному учету, так и по управленческому учету. Данные списки можно формировать в разрезе подразделений и должностей организации и предприятия (режим формирования отчета), а также выбрать отпуска только руководителей. В отчете содержатся варианты, которые позволяют получить различные сведения об отпусках, не прибегая к дополнительным настройкам отчета. Вариант отчета «График отпусков» предназначен для вывода графика отпусков по данным управленческого и регламентированного учетов. В отчет попадают также и неутвержденные графики отпусков. Вариант отчета «Отпуска» предназначен для контроля исполнения графика отпусков. Вариант отчета «Отпуска руководителей» предназначен для вывода графика отпусков руководителей организации или предприятия. Вариант отчета «Фактические отпуска» предназначен для вывода фактических отпусков работников по данным управленческого и регламентированного учетов. В отчет попадают утвержденные отпуска.
Пишу дипломный проект, можете подсказать как можно сделать диаграмму в инете нашел но так и не понял 
Если в работающей системе наблюдаются какие-либо симптомы проблем с производительностью, следует проверить, что в системе правильно настроены и регулярно выполняются все рекомендуемые регламентные операции на уровне СУБД.
Создайте субплан (Add Sublan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач:
