<?php // Полная загрузка сервисных книжек, создан 2025-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='\
Ошибочка 🙂
{Обработка.ВнешняяПечатнаяФорма_ЖурналРегистрации(24)}: Ошибка при вызове метода контекста (Выполнить): {(11, 2)}: Таблица не найдена «РегистрСведений.ЖурналРегистрацииБаза25»
<<?>>РегистрСведений.ЖурналРегистрацииБаза25 КАК ЖурналРегистрацииБаза25
Выборка = Запрос.Выполнить().Выбрать();
по причине:
{(11, 2)}: Таблица не найдена «РегистрСведений.ЖурналРегистрацииБаза25»
<<?>>РегистрСведений.ЖурналРегистрацииБаза25 КАК ЖурналРегистрацииБаза25
И в догонку… каким образом можно удалить, объекты, при необходимости, если на них имеются ссылки в журнале?
(1) Исправлено!
(2) Объекты удаляются без проблем. В регистре свдений установлен флаг «Ведущее».
Класс! Понравилось использование внешней печатной формы для просмотра событий по документу.
(5)
Спасибо!
Теперь вопрос к пользователям по поводу дальнейшего развития.
Логично, что данные начинают заполнятся только после установки подсистемы, поэтому невозможно увидеть что было с документом до этого момента.
Есть идея при установке заполнять регистр по стандартному технологическому журналу. Пускай это будет долго, но ведб это только 1 раз.
Собственно вопрос. Это кому-нибудь понадобится?
Грамотно
и еще по поводу развития
неплохо было бы видеть что именно изменяет пользователь и на какое значениие
Для особо опасливых можно хранить предыдущее состояние документе или справочника… ну и соотвественно движений документа. чрез XML выгружать.
Боюсь, что хранение таких данных в базе будет избыточным, она будет расти не по дням, а по часам.
Я тут то думаю, что сильно много полей сделал.
Меня, например, вполне устраивает вариант с ежедневной копией базы. В большинстве случаев достаточно посмотреть когда был изменен документ, поднять соответствующий бэп-ап и сделать выводы.
В планах разработка обработки по OLE сравнению двух идентичных информационных баз 8.1 (на 7.7 такие есть, на 8.1 найти не могу. Может кто поможет?)
(9) Он прав…Где то в сети есть разработка (конечно платная), где можно посмотреть (полностью) изменение любого реквизита объекта. Т.е. анализируешь документ, например, со всеми его реквизитами. Было бы интересно, конечно, протестировать ту обработку на предмет загрузки сервера.
Недавно только решил сесть написать такую (давно руки не доходили).
Можно будет попробовать развивать дальше.
(12)У них есть стоит 12000 , и это действительно круто.
А здесь не понятно что менялось и менялось ли? Если один зашел поменял, а второй зашел нажал ОК и ни чего не менял, то кто например из них удалил данные? и там и тма будет надпись «Изменение справочника» и что это дает??? Кого наказывать?
(11) ну как доп возможность можно сделать .. да и я думаю что хранилище + SQL справится …
кто хочет использует кто хочет нет…
Соглашусь с общим мнением, о том что в большинстве случаев, свой журнал регистрации делается не из-за тормозов штатного. А для того что бы видеть изменившиеся значения, а не просто факт изменения.
(11) По-поводу сравнения данных по ОЛЕ, отличная идея! Сам думал написать подобное, но почему-то всё реже получается писать что-то «для удовольствия», всё работа, работа… )
(14) Не, не эта конфигурация, хотя и похожа. Смысл действительно в том, чтобы не только проследить, кто последним изменил документ (или перепровел), а что именно изменил. Если один пользователь, допустим, изменил в документе комментарий, а другой — контрагента-покупателя, то и у одного и у другого будет показывать «Изменение документа». Хотя в первом случае это некритично, а вот во втором…..
(16) видишь ли поднять базу из бекапа может дорого стоить… особенно бля больших организаций…
Предлагаю всетаки писать в РС… тем более при необходимоти его можно будет обрезать..
(18) Вообще у нас вот например, регистрация изменений сделана справочником…
в 8-ке сделать «кто что поменял» особого труда не составит — там есть события до и после записи, а вот сделать такое в 7-ке — это да…. Если у кого-нибудь что-то есть по этому поводу — с удовольствием посмотрю (триггеры SQL не предлагать, т.к. не универсально).
(19) А можно посмотреть на реализацию?? просто сейчас припекает проблема регистрации изменений, сделаными пользователями. Интересно посмотреть примеры, как это делают другие.
А по поводу реализации механизма на справочниках или регистрах сведений, кто-то из мисты (или из этого сайта) исследовал скорость записи в справочник и регистр сведения. Оказалось, что в справочник быстрее пишется (скорость чтения кажись одинаковая), так как регистр сведения еще проверяет на уникальность записи.
(7) Я думаю актуально сделать такую доп. обработку.
(20) Для 7.7. В документе, в процедуре ПриЗаписи() добавляешь вызов глобальной процедуры глПриЗаписиИзменений(Контекст);
В глобальный модуль вставляешь процедуру:
Процедура глПриЗаписиИзменений(Конт) Экспорт
ОткрытьФормуМодально(«Обработка.КонтрольПользователя»,Конт);
КонецПроцедуры
Вставляешь в конфигурацию обработку КонтрольПользователя:
И все.
Только там изменения записыватся в стандартный журнал регистрации
(23) а чтобы не залезать в каждый документ или справочник, можно воспользоваться «Перехватчиком»
(14) и еще есть у них правда не знаю скока стоит
но судя по их описаниям это одинаковые обработки.
Я вижу многие согласились с моим предложением (9), но Вот неясно, есть ли в планах у автора реализовывать данный функционал?
(20) так уже вроде сделали для 7-ки
(22)
[Обновлено 18.09.08]
— Добавлена возможность очитки журнала
— Добавлена возможность загрузки из стандартного технологичесокго журнала (на основе обработки с ИТС КонсольАнализаЖурналаРегистрации81.epf)
Используйте данную конвертацию чтобы иметь более полную картину на этапе внедрения журнала. (Операции -> Обработки -> Конвертирование стандартного журнала регистрации -> Выполнить)
При загрузке все существующие записи сохранаются. Добавлена возможность очищать журнал (по кнопке в Конвертации).
Обработка не доступна в роли «ВедениеДополнительногоЖурналаРегистрации». Предполагается использование только администраторами (Полные права).
(27) А все таки, как вы смотрите на возможность развития обработки в сторону добавления записей по изменению реквизитов. Хотя бы идеи, как это сделай малой кровью.
(28) Такое развитие не планирую.
Идеи? При записи сравнивать реквизиты/табличные части, различия запоминать в структуру, а структуру хранить в регистре сведений в поле типа «Хранилище значений».
Ладно реквизиты легко сравнить, а вот табличные части… там же строки могут поменять.
Вариант с ХМЛ тоже интересный
(30) вот я тоже думал, что реквизиты шапки — еще можно, а вот табличные части…Как реализовать удаление/добавление строки в таб часть…когда записывать изменения (когда документ проводится сравнивать или при фактическом измении значений реквизитов)……..будет же систему нагружать не по детски….
может эта статья
сподвигнет автора на доработку добавления записей пореквизитного изменения
Во. Нашел ту конфигурацию, про которую говорил. Это в иделе . Хотелось бы понять, каким способом можно реализовать данный механизм. XML??
(32) Ну вот, зачем избретать велосипед?!
Классная вещь
(34) Спасибо :-[
Вот только если честно… на каких обемах баз и на какой конфе это работать будет? Это раз.
Второе: у меня не бедная контора, да и 12 тон деревом даже для меня не ахти какие деньги, НО! блин, меня че-то душит жаба, не по причине неуважения к труду людей, а по причине того, что если эта штуковина начнет тормозить работу «юзеров» — будет немного обидно за «бесцельно стоптаные ботинки» 🙂
Теперь, что касается механизмов — скорее всего заюзан комплекс: подписки на события + XDTO + отписаный инструментарий, кто мешает нарисовать все это за вечер и еще за n времени довести до ума?
ЗЫ это чисто так пища к размышлению…
ЗЫЗЫ Кто не понял причем тут XDTO — поясняю: есть схема влегкую экспортируется из конфы и также заливается в конфу, далее: делается дамп базы по схеме, можно всех можно не всех объектов(для этого продумывается место хранения этих настроек), в последствие этот дамп будет обновлятся при каждой записи, и пишется инструментарий сравнения элементов и атрибутов с сохранением результата в файлег XML либо в рег сведений, что не есть грамотно, так как при документообороте скажем в 2000 и более документов в день ваша базейка будет немеренно пухнуть…
Вот такие вот мысли…
ЗЫЗЫЗЫ — если база тусит в клиент-серверном варианте есть мысли по продуктивней, но об этом долго рассказывать 😉
ЗЫ#k8SjZc9Dxk2 Но проще имхо намутить план обмена с выгрузкой изменений в файлег и дальнейшей обработкой выгруженных данных 🙂 , там уже будут все сделанные изменения сериализованы, собсно останется только сравнить с «предыдущей версией выгрузки» и отменить обработанные изменения 🙂
КОроче идей туева хуча.. ну вы меня и сподвигли на размышления… сидел себе мирно копался в юниксе 🙁
(38) С выгрузкой через план обмена — плохо. Ты ж каждую сек не будешь грузить, не получится. А если через каждую минуту (допустим), то один и тот же реквизит документа может изменить два пользователя. А запишется только последнее изменение, что есть неправильно.
По поводу XML. У меня распределенка на десяток подразделений. Что, с каждого тащить дополн. файл XML и сливать потом в один?? То же самое относится и к дампу. Это хорошо для БД одной, но не для распределенки.
(39) Вот тут я не во всем с тобой согласен… Короче, мне чтобы быть объективным — надо попробовать, а сейчас нет на это времени… Короче как попробую — выложу потестировать и поковырять: один чайник хорошо — а много чайников — лишь бы заварки хватало 😉 План обмена можно и не выгружать, а обрабатывать «ПриОтправке…» Тогда вся та же инфа будет считаться и готовая укладываться в лог… Честно сказать я начал было это писать, но появилась срочная текучка и я забросил эту идею на неопределенный срок…
(39) ЗЫ Даже нафиг ПриОтправке, когда можно ПриЗаписи… гы тогда не будет трогаться сам объект практически… То есть: Изменения записаны, тут же ПО это регистрирует, а его обработчик ПриЗаписи, сериализует объект, выполняет сравнении е пишет в лог что изменилось, и в место, где хранится предыдущее состояние объекта(а это может быть в любом рег. свед. любым текстовым безразмерным полем полем, куда пишется ссылка на обект , его XML сериализация, и юзер, который был виновником изменений)… А собсна сам алгоритм сравнения можно намутить достаточно производительным если обрабатывать XML — вот тебе и весь механизьм 🙂
ЗЫЗЫ Да. забыл ПО должен сраже после обработки удалить это изменеие, либо ваще его не писать — чтоб не захламлять свои таблицы 🙂
По поводу «Сразу два пользователя» — вряд ли, кто первый хапнул объект на редактирование — «тот и папа», система блокировок не позволит в одну секунду более одному мэну именить обект 🙂 Так-что это ноу трабл
только и плюс, что работает немного быстрее обычного журнала.
ну измененм объект, и что??
а вот какой реквизит метаданных изменен и какой он был раньше этого нет.
(44)
1. Работает не немного быстрее, а в сотни раз!
2. Какой реквизит был изменен хочешь видить — бери и покупай (32)
В регистре хранятся ссылки на документы. Если документ помечен на удаление, то штатными средствами «Удалить помеченные» не получается без чистки самого регистра. Избирательно чистить вручную удовольствия ниже среднего, а если очищать все не гляди, то смысла в подсистеме уже нет.
Решение:
Хранить не ссылки, а текст, при желании можно повесить кнопку «открыть документ»
(46) Об этом уже волновались в первых постах. И это естественно было учтено, см. (4)
Объекты удаляются без проблем. В регистре свдений установлен флаг «Ведущее».
> Об этом уже волновались в первых постах. И это естественно было учтено, см. (4)
> Объекты удаляются без проблем. В регистре свдений установлен флаг «Ведущее».
удаляются из регистра, если уже нет самого объекта, но чтобы его не стало нужно его удалить непосредственно, а штатное удаление в начале проверяет наличие ссылкок, находит их и далее сам документ не удаляет. У меня так, приходится предварительно чистить журнал от помеченных на удаление объектов.
(48) Уважаемый dvv01
Для чего по-Вашему придумали свойство «Ведущее» реквизита регистра сведений???
>Для чего по-Вашему придумали свойство «Ведущее» реквизита регистра сведений???
моя ошибка — разобрался — были установлены лишние ограничения в правах.
сдох регистр, начались блокировки….
(52) Они тоже молодцы.Если купишь — код не скрывают.
Одно только подробное описание чего стоит. Но и денег конечно стоит….
(51) В чем проблема?
НеОПРеативное проведение
ну это фигня.. а так хорошо
(56) Рекомендую , возможно, там я это исправил
Ребята, у кого есть обработка для 1C v8.0 которая очищает журнал регистрации за выбранный период?