<?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='\
как-то не очень верится в такой результат
с 1 час до 1 сек
кстати 1с выложила тестовую БП 1.6.19.1 с оптимизацией этого отчета
временные таблицы
но до 1 сек. сомнительно
tuning1c, Ulcer, предлагаю вам, дабы развеять сомнения провести сравнительные тесты. тест делался на реальной базе данных предприятия 1С БП 1.6.17 на выделенном сервере БД под управлением Linux+PostgreSQL. В БД более 12 организаций, активных пользователей порядка 20 человек.
по поводу «тестовой БП 1.6.19.1», буду только рад штатному исправленному отчету, так как бухгалтерам привычнее открывать этот отчет из общего места расположения отчетов в интерфейсе.
(4) как проводилось тестирование?
у меня только один вопрос, почему бы результатами не поделиться с 1С? или так слишком легко и любой дурак может, и надо чтобы они теперь мучались и искали инфу на инфостарте )))
Зачем упоминание 12 организаций, если всего «153 основных средства»?
К тому же стоит выделить, что замеры только на «PosgreSQL», на MSSQL ничего не замерялось.
(6) очень просто, штатный отчет сохранил как внешний, добавил запоминание времени начала и окончание и вывод разницы. это и былпоказатель затраченного времени. «доработанную» так же слегка модифил и сравнивал результаты по полученным секундам.
(8) говорю как есть, если какие-то данные, по ваше мнению лишние, опускайте их при чтении 😉
MSSQL у нас нет, поэтому не тестировал. Буду рад, если кто-то сделает сравнительный тест на MSSQL и выложит результаты.
(7) мог бы любой дурак, я был бы не первым на этом сайте с данным отчетом. =)
Давно закралось сомнение, что 1С плохо тестирует свои продукты перед релизом. Будет не плохо, если 1Совцы начнут читать инфостарт и прочие подобные ресурсы, глядишь и качество продукта у них увеличится =)
Более того — файловый вариант тоже приветствуется.
А вы заметили, что и типовой и этот отчеты дают неверные результаты, если формировать их по МОЛ и ОС. Например, если ОС в каком-то месяце (не в начале месяца) переместили с МОЛ1 на МОЛ2, отчет показывает, что на начало этого месяца на МОЛ1 нет этого ОС, зато на МОЛ2 оно есть, хотя это не было так. На самом деле должно показываться уменьшение и увеличение стоимости ОС для соответствующих МОЛ.
Мои замеры: Количество ОС — 704.
MS SQL: стандартный отчет — 34,02 сек.
Opex-отчет — 3,78 сек.
Файл-серверный вариант:
стандартный отчет — 36,13
Opex-отчет — 8,05 сек.
(14) вы делали отчет сразу за год или за 1 месяц? у нас за год штатный формирует за 14 секунд, за месяц — за 1 час.
(13) нет, не обращали внимания, была проблема со скоростью, ее и решили =)
А насчет Linux+PostgreSQL — когда встал вопрос о переходе на клиент-сервеный вариант работы, мы эту связку пробовали: при работе 1-3 пользователй все было хорошо, а когда 15-20 вошли начались частые блокировки. При этом если кто-то что-то тяжелое делает (закрытие месяца например), остальные могли даже отчеты формировать. Так что руководство купило MS SQL
Судя по тому, что обычный отчет на 153 ОС формируется больше 1 часа PostgreSQL только для небольших организаций.
За январь 2009:
MS SQL: стандартный отчет — 2,5 сек.
Opex-отчет — 1,17 сек.
17 — в своем посте ошибка, на PostgreSQL — «остальные НЕ могли даже отчеты формировать»
(17) К сожалению, на данный момент, не могу с вами согласиться. У нас сервер БД — Intel, всего 8 ядер, 16 Гб оперативы, более 20 пользователей одновременно (и перепроводят, и закрывают месяца, и отчеты делают, в общем, активные). Все работает стабильно и без тормозов. На сервере включили автовакум, специально настраивали постргре на оптимальную работу и прочие мелкие шаманства.
(13) я думаю, здесь отчет работает правильно. В ПБУ 6/01 «Учёт основных средств» все сроки учета и отчетности фиксируются с первого числа месяца, таким образом, следует предположить, что перемещение ОС с МОЛ1 на МОЛ2 так же должно осуществляться первого числа месяца.
(20) У вас 12 юрлиц, 20 пользователей, 153 ОС — все таки не такая уж большая нагрузка.
В моем случае 1 основное юр. лицо и 6 «вспомогательных» на УСН в одной базе. Сервер БД примерно сопоставим, совсем недавно поставили — HP, 2 х Xeon5530, 16 Gb оперативы…
При этом закрытие месяца на MS SQL главной организации занимает 1,5 часа. Сколько мы не пытались настроить железо и SQL — все бестолку, тормоза по сравнению с файловым вариантом в несколько раз, на всех форумах народ на этом шишек много понабил. Кое-где закрытие месяца проводится и 3-4 часа, где-то и целую ночь.
Эти трудности возникают в случае многопередельного производства со множеством цехов, встречного выпуска продукции, собственным изготовлением материалов, множеством списания материалов в производство (которые несколько раз корректируется как раз в ЗакрМес)… Еще есть монстровидный документ ОтражениеЗплВРегламентированномУчете (выгр. из ЗиУП), который после обрабатывания самописной обработкой распухает до 27 000 проводок.
Opex, у вас 12 юр. лиц чем занимаются? Если услуги или несложно производство — то понятно, тормозить не должно.
(22) Поставь постгрее под винду ради интереса
(22) у нас торговля. Безусловно, сравнивать нас тут сложно, масштабы и сферы работ разные. В течение этого года планируется перевести и торговлю на 8, там уже всякие «хитрые» (читай сложные) схемы будут. Количество пользователей вырастет в 2-3 раза, тогда сможем с вами сравниваться.
(21) А что если МОЛ1 уволился посреди месяца…с него же надо передать все ОС другому.
(25) нельзя оформить передачу первым числом следующего месяца? Тем более, что обычно человек отрабатывает 2 недели перед тем как уйти, отсюда следует, что, если человек написал заявление в начале месяца, тогда следует делать передачу ОС первыми числами этого месяца иначе, человек все равно уходить из компании в конце месяца (если он написал заявление в середине месяца) и передача оформляется первого числа следующего. Но это лишь мое предположение, тут нужно бы спрашивать опытных бухгалтеров либо искать официальные документальные подтверждения (или описания).
Спасибо за отчет!
Вот мое тестирование:
PosgreSQL на винде, пользователей — до 10 активных.
Количество ОС-340
Стандартный отчет — выполнялся 2.5 часа, не закончился, надоело ждать — вырубил
Opex-отчет — 2 сек
…
Пожалуйста 😉
Работает гораздо быстрее, единственное что хотелось бы посоветовать- это выводить итоговые цифры по предприятию. Согласен что в типовой ведомости этого то же нет, ну так в этом и минус стандартного отчета.
итог по всем колонкам есть в данной обработке
Собрался с силами и сам переписал через временные таблицы. Если надо кому помогу