<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Вопрос: обработка в УТ 10.3 будет работать?
(1) makas, да, будет — вопрос только в платформе. Работает на любой платформе выше 8.2.16.
«инструмент для онлайн-проверки данных» — это как понять? нужен выход в интернет и куда тогда инфа отсылается?
(3) TrinitronOTV, речь, конечно, идет не об интернете. Онлайн — значит проверка в реальном времени, т.е. при записи справочника/документа. Есть и офлайн, когда проверка идет не в момент записи, а к большому массиву документов.
Применено вот это значение слова «онлайн»:
Онла́йн (англ. online, от англ. on line — «на линии», «на связи», «в сети») — «находящийся в состоянии подключения».
(4) спасибо за разъяснение
Ничуть не умаляя достоинств Вашей разработки, скажу, что в приложении, в котором проверки реализованы лишь для того, «чтобы не падало», и проверок на правильность (адекватность) вводимых данных не проводится — в нем не проработана (или не доработана) бизнес-логика. К сожалению, многие недалекие пользователи именно за это и любят недоработанные системы: система позволяет делать что угодно. Пример тому — пресловутая бухгалтерия от 1С. Все кричали «верните нам семёрку» потому что в восьмёрку их абы как забитые документы не переносятся, нужно заполнять нормально (по крайней мере — хоть какая-то проверка). Теперь кричат то же самое относительно бухгалтерии 3.0. По той же самой причине — то, что бухгалтерия 2.0 пропускала — тройка перестала пропускать.
Живой пример из недавнего: «у нас документы по кассе проводок не делают. Раньше (в 2.0) мы ставили галочку ‘ручная корректировка’ и все работало». Вместо того, чтобы выяснить (или хотя бы спросить) почему не работает три бухгалтера три года вносили документы ежедневно по десяти кассам, и в каждом делали проводки вручную!
Тем не менее, надеюсь, что не все пользователи такие, и Ваш продукт не останется без внимания.
ОФФ: Жалко, что не нахаляву. ))
(6) ShantinTD, вы правильно подметили — есть программы с прошитой бизнес-логикой, есть с широкой свободой выбора. «Проверка данных» ориентирована на вторые.
Не берусь судить, правильно ли прошивать все проверки в коробочном продукте. Наверное, тут нет универсального рецепта — все зависит от конкретного предприятия, от его внутренних требований к качеству учета. Кому-то проще и лучше, чтобы все решили за них разработчики 1С, кому-то нравится решать самому.
Отдельно отмечу, что «Проверка данных» перед публикацией работала в течение двух лет на УПП, и отлично себя зарекомендовала.
(7) МимохожийОднако, если вы — представитель партнера 1С, то можно обсудить предоставление NFR-версии. Несколько таких версий было предоставлено партнерам до публикации продукта, на время тестирования, и они сильно помогли сделать продукт лучше.
А для клиента, кажется, цена не слишком высока. К тому же, стоит гарантия возврата денег.
А в каком виде пользователь получает сообщение об ошибке при сохранении документа? Попадает ли курсор в ошибочное поле?
Идея хорошая.
А сколько времени в рабочей среде занимает проверка, к примеру, одного поступления с сотней строк в табличной части по десятку правил, применимых в т.ч. и к табличной части?
И еще вопрос по производительности: чтение правил проверки для объекта производится в транзакции записи объекта или предварительно?
Часто встречаешься с ситуацией, когда правила должны применяться с определенной даты или по более сложному условию. Есть такая функция?
(9) очень нужна такая софтина для постановки учета клиентам, т.е. меня интересует перепродажа. Давно сам думал на эту тему, но, как обычно, руки не доходили.
Есть вопрос: существует ли переносимость единожды выполненных настроек?
P.S. Могу помочь с доводкой продукта и с продвижением.
(10) Evgen.Ponomarenko, пользователь получает сообщение, как правило, в том виде, в котором его написал создатель проверки.
Исключение составляют проверки табличных частей — там автоматически выводится название ТЧ и номер строки.
(11) asved.ru, хорошо что вы спросили — появился повод обновить описание и раскрыть тему производительности. Прошу вас почитать, что я там написал (раздел Производительность).
Исходя из того, что при записи одного объекта выполняется, как правило, один запрос, количество проверок роли не играет.
Обычно речь идет о единицах, иногда — о десятых долях процента.
Разумеется, когда речь идет об объекте, который сам по себе очень быстро записывается, процент может вырасти. Например, справочник Валюты.
(12) Evgen.Ponomarenko, такое сделать, разумеется, можно — проверку любой сложности, с которой справится СКД.
Самый просто и распространенный вариант — сделать ограничение по дате в отборе проверки. Для примера приложил скриншот — проверка выполняется для заказов поставщику, дата которых — 2014 г. и далее. Для более ранних заказов проверка не вызовет ошибки.
Конечно, бывают варианты, когда надо ограничить не по дате документа, а по дате исполнения проверки — очень редко, правда. В этом случае в вашем распоряжении вся мощь СКД. Можно включить в нее параметр, вычисляемый выражением ТекущаяДата(), и опираться на него в отборах. Но, повторю, на практике это бывает очень редко.
(11) asved.ru, забыл ответить про чтение правил проверки. Да, правила читаются в транзакции записи, и проверка выполняется там же. Конкретно речь идет о событии ПриЗаписи.
Для ускорения этого процесса добавлен специальный регистр сведений, чтобы не обращаться к справочнику. В регистре хранится уже максимально подготовленная информация для обработки, чтобы не было дополнительных обращений к БД.
В итоге чтение правил занимает 1-2 мс. При проведении документа 1-2 мс — это десятые доли процента времени проведения.
1c-intelligence, действительно хорошая идея.
Протестировав продукт, хочу сказать следующее:
1)За период тестирования непредвиденных ошибок не было (важно квалиифицированно использовать СКД),
2)предлагаю разделить на лёгкий вариант (без измерений производительности)и чуть дешевле(для нетребовательных заказчиков) и полный, представленный в данном варианте,
3)Предусмотреть видео-инструкцию с примерами реализаций сложных проверок (опционально), т.к. нельзя исключать вариант примением функционала не разработчиками 1С, а Гл.бухами.
4)решение безусловно важное и оправдывает свою стоимость для желающих навести порядок в учете.
(18) IgorroPadavan, спасибо что заглянул.
Для коллег поясню — Игорь как раз с того предприятия, на примере которого инструмент разрабатывался и обкатывался в течение нескольких месяцев.
Насчет разделения подумаю.
Коллеги, так делать НЕЛЬЗЯ!!!!
Проверки реквизитов должны быть только в «Обработке проверки заполнения», иначе это порушит половину системных механизмов
Проверки движений должны выполняться в транзакции проведения. С расстановкой необходимых управляемых и не управляемых блокировок, с контролем последовательности чтения и записи. Ну и уж конечно БЕЗ СХЕМ СКД В ТРАНЗАКЦИИ!
У нас была такая штука в своё время разработанная «умельцами» из какого-то франчайзи… Столько оно проблем несёт при многопользовательской работе…
(20) comol, расскажите, пожалуйста, поподробнее, какие системные механизмы порушатся, если выполнить запрос при записи справочника или документа?
На предприятии, на котором тестировался продукт, кто настраивал права? Пользователь, руководитель, программист?
Если программист, то почему нельзя было сделать это в конфигураторе.
Если руководитель, то руководитель чего? Откуда ему известно, что нужно заполнять, а что нет для функциональности системы?
(20) comol, Вы не могли бы пояснить, чем Вам так не нравится использование функционала СКД по генерации запроса на основании пользовательских настроек в транзакции в режиме управляемых блокировок, или, тем паче, на read_committed_snapshot? А то сдается мне, звон Вы слышали, а где он — не знаете.
(20) comol, о, и как Вы поставите «необходимую неуправляемую блокировку», тоже расскажите. Очень интересно.
(22) trand, о правах речи не идет — их проверка данных не касается. Настройка проверок доступна только с полными правами.
Технически настройка велась и ведется программистом/администратором системы — как единственным человеком с полными правами. Но придумывали проверки несколько человек, которых можно назвать самыми толковыми. Обычно это делается не разово, а при обнаружении какой-то систематической ошибки.
Например, при закрытии обнаруживается, что иногда передают вспомогательные материалы по статье ОПР на счет 25 — не по злому умыслу, а по невнимательности, «хотя и было говорено так не делать». Делаем проверку — и все, забываем навсегда об этой проблеме.
1c-intelligence, а никакого триального периода (3-5 дней) не предвидится? А то выглядит заманчиво, да может статься, что кто-то ну вообще не извлечет из этого для себя ничего полезного.
(26) ShantinTD, я подумаю насчет триального периода, спасибо.
(20) comol,
Согласен, рекомендуется проверки реквизитов делать в обработке проверки заполнения объекта — он вызывается при интерактивной записи (проведении) из формы вне транзакции. И заодно не будет проблем при групповом перепроведении документов (зато могут быть проблемы при групповой обработке, если не вызывается программно ПроверитьЗаполнение()).
(28) zqzq, обработку проверки заполнения я пытался использовать. Все прекрасно, кроме одного — проверка запросом не будет работать, т.к. на момент проверки заполнения изменения в базу не записаны.
Есть обходной вариант — передавать реквизиты в СКД через таблицу значений, и работать с ним. Но этот вариант значительно снижает быстродействие.
(28) zqzq, а для группового изменения/проведения добавлена возможность отключения проверок для конкретного пользователя.
Также, как есть возможность массового выполнения проверок для документов и справочников.
Продолжаем развитие инструмента. Тут обсуждали использование события ОбработкаПроверкиЗаполнения — решил дать возможность его опционального использования.
Как единственный вариант не подойдет, т.к. проверка заполнения не выполняется при неинтерактивном проведении документов и записи справочников.
Ну и в некоторых случаях может снижаться производительность, т.к. требуется передача объекта в запрос в виде таблицы значений.
Но опционально будет.
Один из партнеров, тестирующих NFR-версию, предложил несколько доработок, которые войдут в следующий релиз:
1. Когда выводятся сообщения об ошибках, надо бы в начале сделать заголовок, к какому документу относится сообщение, как в типовых конфигурациях.
Пример:
«Проведение документа: Передача оборудования в монтаж РР000032 от 03.06.2014 9:00:00
В строке номер «3» табличной части «Оборудование»: Не заполнено значение реквизита «Документ оприходования»! »
2. Причесать оформление страницы с настройками, сделать его интуитивно понятным. Сейчас понятно только после чтения справки;
3. Дать возможность опционально выполнять проверку в привилегированном режиме. Сейчас в привилегированном режиме читаются только сами проверки, а выполнение идет под правами пользователя. Иногда бывает потребность в проверке использовать недоступные для пользователя данные, поэтому такая возможность нужна.
(26) ShantinTD и все коллеги — опубликована триальная версия, со сроком действия до 31.07.2014 г.
Обновлена триальная версия, теперь со сроком действия до 31.08.2014 г.
Добавлено видео по созданию «сложных» проверок с ручным редактированием запроса — см. в конце статьи.
По просьбе одного из покупателей добавлена отдельная версия без использования модальности.
Пока будет идти отдельно, т.к. конструкции языка, применяемые для немодальной работы, недоступны в более старых версиях платформы — в той же 8.2.
Обновил файл с триальной версией, ограничение по сроку теперь до 30.09.2014 г.
Также, в предыдущей триальной версии (которая до 31.08.2014 г.) была допущена ошибка — не обновил дату ограничения, в результате чего проверки не выполнялись. Приношу извинения тем, кто скачал триальную версию в августе и при необходимости готов выслать обновленный триал, чтобы не тратить sm — пишите мне в комментариях или в личку.
Выложил обновленную версию:
1. Исправлены некоторые скрытые недочеты;
2. Появилась возможность делать проверки, которые будут действовать только для новых объектов, которые записываются впервые.
Благодарю пользователей, купивших и внедривших у себя проверку данных за качественную обратную связь. Сейчас продано более 10 копий, по разным каналам.
Конфигурации, в которых работает проверка данных: УПП 1.3, БП 2.0, УНФ 1.4, есть самописанные конфигурации.
Посмотрел топ продаж — оказывается, «Проверка данных» на первом месте по продажам за полгода. За год входит в топ-10. За весь период продаж — пока на 31 месте. Что ж, есть пока куда стремиться.
(6) ShantinTD,
Можно было запретить ручную корректировку на уровне прав.
С доп.реквизитами эта штука работает? Реальную пользу вижу только если пользователь сам добавил доп.реквизит и сам же добавил контроль на его заполнение.
Уточню — полезно будет, если эта штука будет работать с доп.реквизитами на базе БСП. Тогда она будет неоценима для всех новых решений 1С.
(41) FFelix, доп.реквизиты — это нетиповые реквизиты, добавленные в объект через конфигуратор?
Или какой-то прикладной механизм, типа свойств?
Уточню: полезно будет, если эта штука будет работать с доп.реквизитами на базе БСП. Тогда она будет неоценима для всех новых решений 1С, включая УТ11, ERP и т.д.
Я бы купил её, для своего прошлого проекта по УТ))
(43) FFelix, теперь понятно. Механизм доп. реквизитов аналогичен механизму свойств, который в УТ 10.3 и УПП 1.3.
Определенные проверки по этим механизмам «Проверка данных» позволяет делать уже сейчас, но есть одно ограничение, связанное со спецификой механизма: невозможно сделать проверку доп. свойств (или реквизитов), пока объект-носитель не записан. А когда объект записан, проверять уже поздно, т.к. пользователь просто закроет форму, и проверка не инициируется.
В УПП 1.3 еще как-то выкрутиться можно, т.к. там на прикладном уровне реализована «одновременная» (с т.зр. пользователя) запись и нового объекта, и его свойств.
Но, я думаю, решение будет найдено.
На своих внедрениях я для таких задач использую механизм «Автозадачи», коробочная версия которого сейчас проходит бета-тестирование. Там нет привязки к записи объекта. Правда, и запретов нет.
(44) не уверен, но в БСП (УТ, ERP) кажется запись доп.реквизитов тоже происходит одновременно с объектом.
Всё-таки, их подключение в ваш механизм сделает его на порядок полезнее, имхо
(45) FFelix, я специально проверил на УТ 11 — не дает редактировать доп.реквизиты до записи объекта. Проверял на демобазе, в справочнике номенклатуры.
Варианты решения есть, должно получиться. Это будут либо встраиваемые в «Проверку данных» шаблоны для типовых конфигураций, либо срединное решение — некоторый шаг в сторону от полной отчуждаемости конфигурации.
В любом случае, спасибо за направление развития инструмента.
Некорректное название «Онлайн», под этим обычно понимается необходимость подключения к Интернет, вы распугиваете потенциальных клиентов подразумевающих что им куда-то придется передавать свои данные, бухгалтер просто не имеет права разглашать информацию, есть более подходящие слова, «динамическая проверка», «проверка времени исполнения», «интерактивная проверка», и т.п.
(47) YanTsys, спасибо за замечание. Внес изменения в описание.
Выложена обновленная версия, доработанная по запросу одного из клиентов.
Расширены возможности отключения проверок.
Раньше можно было отключить только все проверки для конкретного пользователя. Предполагалось, что такая функция будет использоваться достаточно редко, для особых ситуаций. Например, на время группового перепроведения документов.
В реальной практике нашлись сценарии, когда нужно отключение некоторых проверок для конкретных пользователей на постоянной основе.
Теперь такая возможность есть.
Весьма интересная разработка, спасибо.
Мы только что встроили в ЗУП 2.5 и сразу возник вопрос: а существует ли возможность установить проверку на регистры сведений (с независимым режимом записи), план счетов, план видов расчетов, план видов характеристик?
(50) Tany_SH, такой возможности сейчас нет — просто не было таких задач. Если вам нужно проверять такие объекты, я добавлю возможность.
(51) такая возможность очень нужна, буду весьма признательна за добавление!
Спасибо за разработку! Очень удобно «на лету» менять права доступа к объектам и проверять правильность заполнения.
Впервые применили эту настройку в базе данных, которая получилась в результате слияния 7 баз различных юридических лиц. С помощью проверки данных решили 2 основные проблемы, которые возникли при начале работы в программах: корректность заполнения полей в документах/справочниках и разрешение на изменение или добавление данных только ответственными лицами. Только благодаря проверке данных удалось остановить бесконтрольное разрастание дублей и привести к стандарту ввод первичных данных.
Простая настройка проверки очень простая и интуитивно понятна, поэтому главный бухгалтер или руководитель отдела легко справляются с ней самостоятельно — и очень довольны, что никого просить не нужно.
Сейчас проверка встроена во все наши базы, не представляю как мы без нее обходились раньше))
Спасибо огромное!
Скажите, а работает только проверка данных или есть возможность установки нужных реквизитов объетков?
(53) Aletar, конкретно в этом решении возможности установки реквизитов нет.
Оно есть в решении Автоопределитель, я о нем рассказывал на конференции IE 2015. Оно пока не опубликовано.
Скажите, а решение «Автоопределитель» можно как-то приобрести?
(55) Aletar, вы прям приобрести хотите? Или вам рассказать суть и вы сами воспроизведете?
Оно просто не готово к продаже, т.к. создавалось под внутренние требования.
(56) расскажите суть, я думаю это не только мне будет интересно.
(57) Aletar, вот суть
Идея информатора развилась в новую тему — автоматическое заполнение реквизитов объектов. Рабочее название — автоопределитель.
Смысл прост — программа сама заполняет нужные реквизиты документа или элемента справочника, в зависимости от выбранных условий.
Как настраивается автоопределитель:
1. Выбирается объект (например, табличная часть «Товары» документа «Реализация товаров и услуг»);
2. Описываются условия для автозаполнения (например, Номенклатура в папке Продукция);
3. Указываются реквизиты, которые надо заполнить, и их значения (например, счет учета БУ = 43 и счет учета НУ = 43).
Главная фишка в том, что п.2 и п.3 описываются в виде таблицы, что позволяет делать последовательный перебор условий. Значения реквизитов при этом ставятся в соответствии с тем условием, которое выполнилось. Отбор, разумеется, СКДшный, что позволяет сравнивать реквизиты объекта как с абсолютными значениями, так и друг с другом (или, например, с реквизитами документа-основания).
Больше всего это похоже на настройку условного оформления отчетов. Там тоже можно сделать несколько оформлений одного элемента, в зависимости от разных условий. Например, если сумма <100, то цвет красный, если от 100 до 1000, то желтый, если больше 1000, то зеленый.
Вторая фишка — с реквизитами — их можно заполнять сразу по несколько штук. При выполнении одного условия — заполнить счета учета, при выполнении другого — еще и ставку НДС, и т.д. Большинство из нас работали с групповой обработкой справочников и документов и знают, как там этого не хватает.
Третья фишка — заполнение реквизитов значениями других реквизитов. При заполнении реквизита в качестве значения можно выбрать не только абсолютное значение, но и сослаться на другой реквизит. Например, заполнить ставку НДС основной ставкой из номенклатуры.
Разумеется, все настройки выполняются в пользовательском режиме без программирования.
Срабатывать автоопределители будут двумя способами, в зависимости от настроек:
1. Перед записью объекта — это железобетонные автоопределители, которые должны обязательно выполняться;
2. Интерактивно в форме объекта, по кнопке. На форму выводится подменю со всеми доступными автоопределителями, у которых настроен доступ через интерфейс. Это примерно как подключаемые обработки табличных частей.
Если наберется достаточно желающих — выделю автоопределитель в отдельную конфигурацию и сделаю публикацию.
Подскажите, пожалуйста, в Вашем примере — проверка на заполнение ответственного (ответственный не заполнено), какое надо ввести условие, чтобы эта проверка действовала только по некоторым организациям? Организация в списке? И все это одной строкой? Спасибо!
(60) МирославаЯсная, вы все правильно пишете — надо делать одну строку в таблице Проверки, и в отборе указать «Ответственный не заполнено И Организация В Списке <список организаций>». На всякий случай прикладываю скриншот.
(61) спасибо! За продукт и за ответ 🙂
(30) искала где отключать проверки. Нашла 🙂 Спасибо еще раз!
Доброго времени суток, есть вопрос. Мне надо проверить заполнение контактных данных элемента справочника «Контрагенты», к примеру «Юр.адрес контрагента», добавил в набор данных это поле из регистра сведений «Контактная информация» через СКД,, прописал проверку на заполнение, но проверка осуществляется не правильно, я так понимаю, из-за того, что на момент проверки, данные еще не записаны в регистр сведений из табличного поля на форме элемента. В этом случае, что-то можно сделать? или я что-то неправильно делаю в настройках проверки?
(63) МирославаЯсная, на всякий случай добавлю, что там есть справка, я постарался сделать ее максимально понятной.
(64) BSV, увы, такую проверку в общем случае не сделать, т.к. контактная информация хранится в отдельном регистре сведений и при первой записи контрагента ее там просто не может быть. Если запись не первая, то уже зависит от логики конкретно справочника контрагенты. Если, например, при записи контрагента идет полная перезапись набора регистра сведений, то проверка тоже не поможет.
Та же проблема, например, со свойствами и категориями.
1c-intelligence, спасибо за ответ, я в общем так и думал — но втайне надеялся, что не прав 🙂
Вышла обновленная версия.
Добавлен учет срабатывания проверок. Когда срабатывает какая-либо проверка, то информация об этом записывается в регистр сведений.
Сохраняется дата срабатывания, имя пользователя и текст сообщения.
Для анализа срабатывания проверок за период добавлен отчет «Эффективность проверок». Отчет показывает, какие проверки, у каких пользователей срабатывали в течение периода.
В отчете два предопределенных варианта — «По проверкам» и «По объектам».
Отчет может использоваться для разных целей.
Например, можно вычислять пользователей, которые натыкаются на одни и те же грабли и ничему их жизнь не учит.
Или проанализировать, на каких объектах (документах, справочниках) проверки срабатывают чаще всего и понять, почему так происходит — возможно, объект проверки слишком сложен для пользователей, и ошибки при его заполнении неизбежны.
Вопросы по
1. А можно ли настроить проверки для списка пользователей?
Пользователь1 — 4 проверки
Пользователь2 — 2 проверки
Пользователь5 — нет проверок.
2. А можно ли настроить проверки по ролям?
Если такого нет, то доработать самому получится? (не сильно ломая механизм).
(69) dj_serega, сейчас настроить проверки по ролям можно только косвенными методами — сделать проверку сложной, и в схеме компоновки вычислять текущего пользователя. Это делается несложно, через параметры и использование функции глЗначениеПеременной(«глТекущийПользователь»). Но этот метод косвенный, не очень удобный.
Мне нравится идея задавать конкретный список пользователей или ролей, я добавлю это в конфигурацию. Спасибо.
(35) не нашла, видео. «Ткните носом», пожалуйста) Спасибо!
(71) МирославаЯсная, ага, куда-то пропало видео.
Вот ссылка:
Используем эту разработку в рабочей базе уже пару месяцев, очень удобно настраивать, просто внедрять. Автору плюс.
(72) спасибо!
А в данной проверке реально сделать при каком-то условии запрет на изменение реквизита не нового элемента справочника?
(75) TapeFiver, запрет действует на весь объект целиком при определенных условиях, которые задаются отбором.
Кажется, вы имеете в виду, можно ли сравнивать старое и новое значение реквизита?
(76) да именно это имею в виду. Посмотрел видео из (72) и почему-то подумал что «ОбъектПроверки» и элемент справочника в запросе будут как «ЭтотОбъект» и «Ссылка» в процедуре ПередЗаписью.
(77) TapeFiver, сейчас такой возможности нет. У меня есть адаптированная под одно предприятие версия, там такое есть — можно использовать реквизиты объекта до записи.
Добавлю в текущую версию и выложу, спасибо за предложение.
(78) А есть пример проверки на заполненность свойства номенклатуры или контрагента? Пробовал и так и эдак, не смог победить. Прочитав (44) понял что вы пишете что как-то выкрутиться можно, но я реально в тупике.
УТ 10.3
(59) очень бы хотелось посмотреть «автоопределитель». Заранее благодарна.
(79) TapeFiver, выкрутиться лучше всего доработкой конфигурации, т.к. заполненность свойств, например, номенклатуры, выполняется через вывод табличной части подчиненной обработки на форму номенклатуры. Запись свойств выполняется при записи номенклатуры в форме.
Соответственно, перед вами и таблица свойств и их значений (ТЧ обработки), и контекст записи номенклатуры, а значит — и возможность в этом контексте остановить запись при незаполненных свойствах.
Могу помочь, если надо.
(80) МирославаЯсная, он в очереди стоит. Сейчас я дорабатываю проверку данных.
(82) спасибо! будем ждать)
(82) подскажите, пожалуйста, настроена проверка, затем вносятся изменения в структуру справочника (например, удаляется реквизит) и при попытке открытия проверки из справочника «Проверяемые объекты» 1с вылетает с ошибкой — «Ошибка получения информации набора данных по причине: Ошибка в запросе набора данных по причине: Поле не найдено». Возможны ли какие-то варианты решения? Спасибо!
(84) МирославаЯсная, такое бывает, увы. Посмотрю, что можно сделать.
(85) спасибо!
(85) у меня еще вопрос 🙂 как в сложной проверке по ВТ срез последних установить период равным дате проверяемого документа? Спасибо!
Добрый день!
Можно ли вашей обработкой делать сравнение не на конкретное значение, а на реквизит этого же документа?
Ну например Организация = ПодразделениеОрганизации.Владелец?
Или это лучше сделать через СКД?
С чем связана рекомендация
(88) ponaroshku,
можно, это стандартная функция СКДшного отбора. Надо в правом значении отбора нажать крестик, снова открыть выбор, в списке выбрать «Поле компоновки данных», и вам будут доступны все реквизиты проверяемого объекта.
Это рекомендация о том, как избежать стандартной ошибки — писать проверку в запросе таким образом, что он возвращает только правильный объект. В этом случае любая новая проверка, добавленная снаружи — через табличку в форме — не будет работать. Банальный пример — если вы в запросе проверяете пометку удаления и возвращаете только помеченные на удаление, а в таблице сделаете проверку вроде «Проведен = Истина И ОтражатьВБУ = Ложь», то вторая проверка никогда не сработает, а неправильные документы (проведенные без галки БУ) у вас в системе появятся.
Запрос должен всегда возвращать объект, на этом строится «многоздачность», или «многопоточность» проверки — запрос один, выполняется один раз, а проверок делается несколько.
Но, в принципе, никто не мешает делать по-своему, просто надо учитывать описанную выше особенность.
(90)
я думала, что это работает так, как вы описали — про отбор
но крестика нет
А при не заполненном левом значении в списке выбора отсутствует тип «Поле компановки данных», только примитивные типа строка, число и т д
Поставила «Использовать в качестве значения поле» и конечно все заработало)
Про рекомендацию я вас поняла, спасибо
P.S. при пометке на удаление элемента справочника «Проверяемые объекты» проверка по условию все равно выполняется
Внимательно смотрю вашу разработку
сейчас при проверке документа нет возможности задать текст с использованием реквизитов проверяемого объекта, т.е. написать «Неверно указана организация» можно, а «Неверно указана организация ИП Иванов» нельзя
Планируется ли расширить текст ошибок?
(91) ponaroshku,
такую возможность сделать несложно, но я сознательно не стал ее закладывать, чтобы не усложнять создание проверок.
Вообще, сделать можно, внесу в список доработок.
(92) спасибо, буду ждать нового «релиза»
Очень полезная разработка
Добрый день!
Подскажите, возможно ли сравнить текущий объект с ранее сохраненными данными?
Например, справочник организация — смотрим, если изменили наименование (сравнив его с ссылка.наименование?) выдать отказ?
Если да, то как это сделать, подскажите пожалуйста
(94) ponaroshku, сейчас такой возможности нет. Планируется в новой версии.
(70)А добрый день 🙂 Еще не пришло время новой версии конфигурации? :-))
(100) конечно пришло, и прошло уже давно 🙂
Может в новогодние каникулы получится.
(102) Просто в публикации нет инфы о моем предложении. Вот и спросил.
Вот-вот будем скачивать себе и адаптировать. О результатах доработок опишусь 😉
Спасибо за хороший и интересный продукт.
Иван, если я не пропустил релиз, то хотелось бы фичу из (78)
(118) спасибо, и это сделаю.