Не помню откуда у меня эта обработка. Автор доработал типовую "Универсальный подбор и обработка объектов" Добавлены возможности: 1. Работа в управляемом приложении 2. Отбор по значениям из табличных частей. В том числе отбор по агрегированным значениям (количество строк, СУММА(поле), КОЛИЧЕСТВО(поле) и т.п.) 3. Обработчики табличных частей в "Установка реквизитов" (замена по выбранному значению, добавление строк, удаление по выбранному значению)
Мной доработан обработчик табличных частей "Удаление по выбранному значению" в режиме обычного приложения. В авторской обработке происходил вылет с ошибкой
Делаю задачу. В рамках задачи надо было получить некоторые данные из НН из базы Медок. Клиент не покупал модуль интеграции, поэтому пришлось разобраться как получать данные из Медка прямыми запросами. Хочу поделиться
Для отладки SQL запросов к базе Firebird использовал программу "SQL Manager for InterBase/Firebird". Входит в пакет "SQL Management Studio for InterBase/Firebird", использование 30 дней бесплатно
Запрос, которым можно получить список таблиц базы и их объем
SELECT I.rdb$relation_name RELATION, cast(1/I.RDB$STATISTICS as integer) RECORD_COUNT FROM RDB$INDICES I JOIN RDB$RELATION_CONSTRAINTS C ON (C.RDB$INDEX_NAME = I.RDB$INDEX_NAME) AND (C.RDB$CONSTRAINT_TYPE = 'PRIMARY KEY') AND (I.RDB$STATISTICS > cast(0 as double precision))
С документами все проще. В Медке при открытии документа он открывается на отдельной странице. Заголовок страницы - это часть имени таблицы БД
Документ в Медок состоит минимум из двух таблиц. Имя таблицы с реквизитами документа заканчивается на _MAIN, имя таблицы с табличной частью заканчивается на _TAB1, _TAB2 и т.д. Связь между этими таблицами по полю CARDCODE Пример запроса для получения данных из НН
select MAIN.* , T.* from FJ1201002_MAIN AS MAIN INNER JOIN FJ1201002_TAB1 AS T ON T.CARDCODE = MAIN.CARDCODE
Вот тут у человека возникла похожая проблема. Скопирую ответ оттуда:
Цитата
Краткое резюме сути вопроса: 1) Период хранения 5 дней. 2) Регистр Покупатели не закрывался по измерению СтавкаНП (стандартная ошибка) + был "Основной покупатель" по которому в регистр шел только приход. 3) Регистры КнигаПокупок и КнигаПродаж не закрывались (регламентные документы не формировались).
Ход устранения: 1) При помощи 1С++ очищено значение измерения СтавкаНП в таблице движений регистра Покупатели 2) Удалены движения по регистрам КнигаПокупок, КнигаПродаж 3) Удалены движения из регистра Покупатели только по договорам Основного покупателя. 4) Добавлен признак в справочник Договоры "Не вести взаиморасчеты". 5) Изменены процедуры ГМ для отключения движений по регистрам КнигаПокупок, КнигаПродаж. Изменены процедуры движения долгов. 6) Обработкой с использованием 1С++ ТА двинута назад, вперед. 7) Обновлена статистика занимаемого места и произведено переиндексирование базы. 8) Результат сдан вопрошающему.
Добрый день. Нашел решение как восстановить зашифрованную базу 1С 7.7 после вируса Возможно эта информация кому-то пригодится
Для восстановления нужен поврежденный архив базы (сохранение 1С) и сама поврежденная база Вирус повреждает архив в его начале. В начале архива находится MD-файл. Делаем тестирование/исправление архива. WinRAR восстанавливает его без первого файла. К восстановленым файлам копируем MD-файл из самой поврежденной базы. Там он не поврежден. Архивируем файлы в ZIP и получается восстановленный бэкап. Полученый бэкап загружаем в конфигураторе 1С в новую базу.
Работодатель: Энерджи сервис Направление деятельности: строительство и ремонт электрораспределительных сетей. Адрес: Киев, ул. Суворова, 4/6
Необходимые навыки: Опыт работы с 1С 8 от 3-х лет. Умение общаться с людьми Знание конфигурации УТП Наличие сертификатов 1С необязательно Уверенное знание предметной области бухгалтерского учета Знание производственного учета на уровне УТП Желательно знание зарплаты Написание сложных SQL запросов Настройка ограничений прав доступа на уровне записи (RLS)
Необходимые качества: Системность при разработке и написании программного кода Умение выстраивать работу с пользователями (быть немного бюрократом)
Профессиональные обязанности: Поддержка нескольких баз в конфигурации УТП, обычное приложение Разработка отчетов Небольшие доработки документов Количество пользователей: 17 бухгалтерия, около 40 прочие
Условия работы: Работа в офисе Рабочий день с 9:00 по 18:00, обед 1 час Количество коллег программистов - 1 Командировок нет.
Условия собеседования: Предоставьте пожалуйста примеры ваших разработок. Желательно документы. С кратким пояснением для чего служат эти документы/обработки/отчеты. Возможно какие-то красивые решения, которые вы использовали. После этого два собеседования: с программистом, с начальником ИТ
Контактные данные для связи: Резюме высылайте пожалуйста на: d.zaytsev@esfmc.com Для доп. вопросов по вакансии тел.: 095 271 38 66
Я понимаю как механизм ограничений доступа к данным. Т.е. если выполняется условие: ТекущийПользователь = "Пользователь_1" тогда есть право на добавление.
RLS, Record level locking - Блокировка на уровне записи
Применяется если надо ограничить доступ к справочнику/документу/регистру по значению определенного реквизита. Например ограничить по организации. Три пользователя: у первого - доступ к Орг1, у второго - к Орг2, у третьего и к Орг1 и к Орг2.
Хорошо, если по группам не правильно, как лучше сделать. Как бы сделали Вы? Через какой реквизит? Т.е. нужно добавить еще один реквизит к элементу номенклатуры, ну назовем его допустим "Запрет доступа" и если реквизит установлен, то элемент не виден, а если нет, то виден. Опять таки через RLS ограничение создается. Я правильно понял Ваше предложение?
Да, добавить еще один реквизит "Уровень доступа". Ссылка на справочник "Уровни доступа к номенклатуре". В справочнике "Уровни доступа к номенклатуре" два элемента: "Продажа" и "Учет". При записи номенклатуры, если "Уровень доступа" не установлен - два варианта: ругаться и не давать записывать инициализация в значение "Продажа" или "Учет", в зависимости от прав пользователя, который создает номенклатуру
Дальше RLS ограничение
ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПравДоступаПользователей КАК ПраваДоступа ПО ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Номенклатура) И ПраваДоступа.Пользователь = &ТекущийПользователь И ТекущаяТаблица.УровеньДоступа = ПраваДоступа.ОбъектДоступа
ГДЕ (НЕ ПраваДоступа.ОбъектДоступа ЕСТЬ NULL)
Объект доступа - это элемент из справочника "Уровни доступа к номенклатуре"
Добавьте в перечисление ВидыОбъектовДоступа значение Номенклатура В измерение ОбъектДоступа регистра НастройкиПравДоступаПользователей добавьте тип Номенклатура
Роли - Все ограничения доступа - Шаблоны ограничений Добавьте шаблон: ОграничениеНаНоменклатуру Текст шаблона:
ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПравДоступаПользователей КАК ПраваДоступа ПО ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Номенклатура) И ПраваДоступа.Пользователь = &ТекущийПользователь И ТекущаяТаблица.Родитель.Ссылка = ПраваДоступа.ОбъектДоступа
ГДЕ (НЕ ПраваДоступа.ОбъектДоступа ЕСТЬ NULL)
Для всех основных ролей настройте RLS (используя созданный шаблон) для справочника Номенклатура
В приложении заполните регистр НастройкиПравДоступаПользователей. Для пользователей администраторов дайте права и на "Продажа" и на "Учет". Для всех остальных - только на "Продажа". (Объект доступа - это группа из справочника "Номенклатура")
Кроме прав доступа непосредственно справочника - проверьте работу отчетов, которыми пользуются пользователи. Скорее всего часть из них перестанет работать с ошибкой "Недостаточно прав доступа". Необходимо подобавлять слово РАЗРЕШЕННЫЕ в запросы.
Есть. Перенос из Бух. для Украины 1.2.11.2 в УТП 1.2.12.3
Там возможен нюанс при переносе документа "Ввод начальных остатков". Этот документ конвертируется в документ : "Ввод начальных остатков по ОС" - для ОС "Корректировка записей регистров" - для всех остальных документов "Ввод начальных остатков"
При формировании документа "Корректировка записей регистров" есть исполняемый код при событии "После загрузки". Смысл этого кода - делает видимыми закладки в "Корректировке записей регистров". Нюанс в том, что этот код может не срабатывать. Если это произойдет - просто закомментируйте его в "Конвертации данных". Загрузка "Корректировки записей регистров" пройдет успешно - все необходимые движения документ будет делать, но не будут отображатся закладки.
По первоначальному вопросу не было понятно - это надо один раз или постоянно.
Проще всего наверное поискать утилиту командной строки, которая может совершать такую конвертацию. Написать обработку - пользователь выбирает файл DBF, нажимает кнопку. При этом вызывается эта внешняя программка с нужными параметрами, которая конвертирует DBF-ник.
У меня был опыт с подобным - модификация и запись одного документа (ДокументДляСозданияПлатежногоТребования) при записи другого документа (ПлатежноеТребование) Какие при этом я получил грабли.
Грабли №1. Пользователь с полными правами на ПлатежноеТребование и с правами "только чтение" на ДокументДляСозданияПлатежногоТребования вносит изменения в ПлатежноеТребование. И эти модификации должны попасть в ДокументДляСозданияПлатежногоТребования.
Грабли №2. При записи ПлатежноеТребование иногда пробегала некая барабашка (подозреваю что конфликт блокировок, но точно так и не выяснил). В результате у ПлатежноеТребование и ДокументДляСозданияПлатежногоТребования шла рассинхронизация реквизитов, которые должны были совпадать. Другими словами - по одновному документу запись произошла, а по подчиненному - нет.
Проблема типа Грабли №2 - очень каварная. Идут тысячи документов. Никому и в голову не прийдет проверять - а все ли там хорошо? Всегда ли создается ДокументДляСозданияПлатежногоТребования ?
Поэтому для себя сделал вывод: создавать/модифицировать один документ из модуля другого - это зло. Надо стараться этого избегать. Например "выкручиватся" при помощи регистров сведений не подчиненных регистратору. Заполнять их из ПлатежноеТребование и потом использовать в комплексе с ДокументДляСозданияПлатежногоТребования (или вообще без него).
То о чем вы спрашиваете - настраивается в регистре сведений "Отражение взносов на ФОТ в регл. учете". Но настроить разделение проводок только по аналитике, без разделения по счетам - у вас не получится. При формировании проводок по ФОТ происходит проверка только счетов затрат. Предложите бухгалтеру использовать счета 2311 и 2312. Тогда будут проводки:
Я бы выбрал второй - потому что по коду сразу понятно, что автор ставит ставит защиту от ситуации, если ТекущаяСтрока = Неопределено. Первый вариант для непосвященного будет загадкой.
Создаете обработку. Реквизит обработки - ссылка на документ №1. ТЧ обработки = ТЧ документа №1 (только те реквизиты, которые нужны для формирования документа №2) + ссылка на документ №2 Заполнить ТЧ обработки - заполняется из ТЧ документа №1 (реквизит обработки) Сформировать - формируются документы №2 на основании данных ТЧ обработки, после записи документа №2 - ссылка на него устанавливается в ТЧ обработки Можно предусмотреть открытие формы конкретного документа №2 (например ТекущаяСтрока ТЧ обработки) Можно предусмотреть запус обработки из контекстного меню формы списка документа №1, при этом заполнять реквизит обработки - ссылка на документ №1
необходимо провести обновление индекса полнотекстового поиска, а сам полнотекстовый поиск оставить?
Что такое индекс полнотекстового поиска. Когда вы заполняете документ и вносите в поле первые буквы контрагента/номенклатуры/физ.лица - вам по этим первым буквам "выскакивает" соответствующий контрагент/номенклатура/физ.лицо. Обращали внимание ? Это результат работы полнотекстового поиска. Почему обновление индекса полнотекстового поиска установлено в 2,5 мин. Наверное для того чтобы если вы создали нового контрагента - то максимум через 2,5 мин. он начал использоватся в полнотекстовом поиске. Если у вас вносится новая номенклатура/контрагенты/договоры контрагентов и т.п. относительно не часто - поставте обновление индекса полнотекстового поиска на раз в 2 часа, вместо 2,5 мин. (с помощью консоли заданий)
Людина прийнята, і накладна набагато пізніше прийнятя))
Запрос, который получает ФИО и должность "Представителя организации", написан таким образом, что если у этого сотрудника ФИО не установлено на дату накладной - так и получится, что на печать ничего не попадет. Проверьте: Справочник "Физические лица" -- карточка физлица -- в конце строки ФИО кнопка "Подробнее..." -- или поле "запись действует с:" или кнопка "История...". Период, на который установлена детализация ФИО должен быть меньше даты документа.
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!