<?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='\
>обуславливается тем, что изменения вступают в силу после перезапуска 1С текущим пользователем системы
смысл устанавливать если действия после перезапуска 1С пользователем?
дата запрета будет установлена, но пользователь не перезапуская сеанс может и поменять закрытый период
(1) Именно такой смысл имеется в конфигурации ЗУП 2.5. Это там организовано именно так и ни как иначе. Спорить можно до зеленых соплей. Если не нравится — можно пользоваться штатной. Но, если нравится, то:
допустим в базе данных работает куча бухов и уйти домой (всвязи с квартальным отчетом) скоро не собирается. Но кто-то самый умный уже закончил отчетность и желает выставить запрет.
У администратора три варианта:
— собачиться с отстающими и выгонять их из базы (пользуясь штатной обработкой)
— оставаться на работе до ухода последнего двоешники (буха)
— установить дату запрета данной обработкой (и на следующее утро дата начнет уже действовать)
Выбирать вам.
> … и на следующее утро дата начнет уже действовать)
двоешник бухгалтер обязательно сделает текущим днем, что нить в уже закрытом периоде…
если ночью не работают, то наверное имело бы место закрывать автоматически ночью тогда, есть же механизм регламентных заданий.
а есть бухгалтера которые не выходят, сеанс может висеть не сколько дней и когда же у него наступит утро?
(3) Ну уважаемый, если у вас все так запущено, то вам действительно противопоказана данная обработка….. Выбирайте пункт 1-й
(4) у нас все ОК, продуман механизм закрытия, а вот с вашим решением будут косяки (накосячат во время так называемого закрытия, а утром и не исправят), просто хочу сказать что бесполезная обработка, вот и всё.
если период закрыт, то не каких изменений не должно быть, а если открыт реально, а по обработке закрыт, бред. Виновный будет кто такое придумал, а не двоешник бухгалтер. ему то пофиг, если проводятся документы за какую то дату то и ладно.
оставил свое мнение, без рецензии. асталависта!
Для корректной работы данного алгоритма, необходима прописать периодическую процедуру на клиенте которая каждые 3 минуты если были изменения обновляет параметр сеанса с Границами запрета.
Была похожая проблема.
Убирал монопольный режим установки даты запрета.
Для контроля был создан регистр сведений, который содержал список пользователей с обновленной датой запрета.
При установке даты запрета регистр необходимо очистить.
Далее в подписке на событие организованной для даты запрета (в БУ это «ПередЗаписьюДокументаДатаЗапретаРедактирования») нужно добавить проверку, есть ли пользователь в данном списке.
Если нет запускаю процедуру установки даты запрета для конкретного пользователя. дальше идет все своим чередом, т.е. проверяется дата запрета и в зависимости от нее проводится или не проводится документ.
Как вариант реализации. Просто тогда показалось, что будет лучше так, чем нагружать систему каждые несколько минут считывать параметрсеанса пользователя, которые итак очень медленно работают.
Те кто не видит смысла в данной обработке, не забывайте что бывает распределенка основанная на организациях. То есть каждый филиал это отдельная организация. И когда нужно установить дату запрета в филиалах (то есть на работающих в главной базе сотрудниках это никак не отразиться, у них другая организация) то всё равно нужно чтобы сотрудники главной базы выходили, хотя они тут не сном, ни духом.
А разработчиков типовой БП нужно долго бить молотком по пальцам, за алгоритм, при котором дата запрета изменения данных считывается только один раз за сеанс работы.
А почему просто нельзя зайти в РС и установить ручками. И выгонять никого не надо
Спасибо очень пригодилась,особенно в общепите!
клево
Спасибо, после конвертации работает на 2.0
Добрый день, обработка действует только на самого себя. Со своего компа запустил себя заблокировал на дату, а на других пользователей не действует
(15) Другие перезайти должны. Потому и через монопольный доступ было сделано в БП.