<?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='\
Я в свое время делал хак для обмена с помощью функции «ПровестиДокументы» модуля «ОбщегоНазначения» (запускал фоновое задание для проведения документа «ПослеЗаписиОбъекта»), чтобы обмен не останавливался на контроле ДЗ. В принципе, эту функцию можно использовать и для такого распараллеливания. Можно даже использовать «ДлительныеОперации», чтобы совсем «кошерно» было )))
Вообще за очередное поднятие темы многопоточности однозначно плюс. Главное — чтобы документы проводились последовательно в рамках своей роли. Т.е. и чтобы бабочки на 60-62-76 не возникали (разделение по договорам контрагентов на разные потоки), и номенклатура корректно отрабатывала (разделение по номенклатуре, поступление товара должно произойти раньше, чем продажа — чтобы они не попали в разный поток).
ЗЫ: Кстати, тут теперь плюсик самому себе можно поставить — пользуйтесь! ))
осталось дождаться для БП 3.0
Не удивлюсь если будет штатно реализовано
(2) не будет, делали только без многопоточности
(2) Заметил, что при использовании помощника закрытия месяца или учета НДС, после запуска перепроведения документов можно переключиться на другие окна и продолжать работать. И никто пока не отменял запуск второго сеанса пользователя. Этим и пользуюсь. Это в БП3.0
Распараллеливание восстановления последовательности… вы серьезно?
Автор явно не знаком с «цепным распадом» по восстановлению партий товаров и последовательности взаиморасчетов.
По-этому только полное перепроведение документов по порядку.
Цепной распад — это когда измененный одной цепочки приводит к изменению других цепочек последовательностех (казалось бы независимых).
Например: изменение прихода/расхода одного товара может повлечь изменения себестоимости других товаров (через пересортицы/комплектации),
по контрагентам тоже самое (через тройственные взаимные зачеты и уступки долгов).
Простая прямолинейная последовательность это единственная гарантированная процедура. Можно еще как РАУЗ- в конце месяца считать все разом, однако там часто возникают коллизии, так как механизм, прямо скажем, содержит кучу условностей.
Так что, эти обработки- от лукавого, до первого случая ветвления последовательности… хотя иногда счастье в неведении. ))
Что реально можно… это запускать последовательность автоматически по ночам условно в монопольном режиме, с автоостановом утром перед началом работы. У нас последовательность за месяц восстанавливается по ночам за неделю.
Реализовали у себя последовательный и непрерывный механизм перепроведения. База (клиент-сервер) проводится непрерывно фоновым заданием с отслеживанием границы перепроведения. Задается размер пачки документов для перепроведения.
Мне интересно как при ФИФО будут списываться партии в многопоточном перепроведении ?
С этим утверждением полностью согласен
как по мне так автор вообще не понимает что такое последовательности, зачем они нужны и зачем их восстанавливают… подозреваю что в его базах о таком не слышали
У себя сделал регламентное задание закрывающее месяца до текущего -1 запускающееся каждую ночь.
Непрерывное проведение в фоне…. если вы это делаете при работе пользователей то это не хорошо….
Я так и не понял, эта обработка просто берет указанное количество документов и проводит в фоновом задании? Без всяких разделителей и поисков зависимостей в документах? Проще тогда сразу выводить сообщение «Все документы перепроведены!» эффект будет такой же, а времени займет сотую долю секунды.
(5) в свое время реализовывал как раз с учетом этого «цепного распада». Весьма нетривиальная задача, но в 6 потоков удавалось достигать увеличения скорости проведения в 4-6 раз.
если нет товаров, а только услуги или отключен партионный учет, то нормально должно пойти
(10) И то героизм. Мне вот жуткими извратами и логическими гримасами удавалось добиться 4 потоков, чтобы не уродовать последовательности, но не более. А автор и правда, походу, о таких вещах не задумывается. Ну, до первых граблей)))
Вот если б автор написал, например, произвольный универсальный менеджер фоновых заданий, когда можно выбрать любое ресурсоёмкое действие системы, пригодное к вызову фоновым заданием, и этот менеджер умел бы собирать последовательности таких задач, запускал бы их, логировал итд, было б круто. А так — опасная и неоднозначная игрушка, с неочевидной полезностью. Где тут можно минуснуть, кстати?
(13) зачем минусить? Надо дисклеймер прописать (по-сути, в комментариях он уже есть) об опасности. Те, кто на грабли наступит — заработают нехилую экспу и получат очередной левелап. А левелап чем плох? ИМХО, крайне хорош для развития экономики. Ведь пока на грабли не наступишь — не научишься.
(14) Плохо то, что на грабли как раз наступит не автор, а те невезучие, которые, доверяя авторитету ресурса ИС, эту фигню скачают и применят. Или репутация ИС никому не интересна?)) Это ведь посмотри кому предназначено — не программисту, а бухгалтеру. По-твоему, бухгалтер должен эту экспу получать?)
Ну и знаешь, рейтинг на то и сделан, чтоб реальность отражать, а не по комментариям судить о публикации.
Большое количество знатоков многопоточности и восстановления последовательности собралось. Это хорошо. Прокомментируйте, пожалуйста, это: ? Всегда было интересно насколько это реально …
(11) Окромя партий много чего есть, если влёт — да хоть зачет авансов… Смотрите (5) — там суровая правда жизни описана)))))
Всколыхнули слова : перепроведение удобно выполнять встроенной обработкой «Групповая обработка справочников и документов» — и в душу закралось нехорошее предчувствие. Разве там всегда документы в хронологии проводятся? Это кому удобно и в чем сие удобство?
Хотя бы применимость обработки автор описал и в каких случаях ее применять нельзя. Жуткая жуть заключается в том, что работа сделана с любовью и времени потрачено…
(17) это в принципе разные счета/регистры (партии/остатки/взаиморасчеты/…) — все это можно распараллелить отдельно. Те, кто говорят, что нельзя параллельно что-то провести, просто не знают, как это сделать. Да, нетривиальная задача, но вполне решаемая. При том если кешировать данные партий/взаиморасчетов/прочего — можно добиться очень высокой производительности, другое дело, что 1С в принципе не умеет организовывать доступ быстрый к общим данным — для этого их нужно записать в СУБД и заблокировать — это весьма снижает возможности 1С в плане оптимизации. Но если вынести логику проведения во внешний по отношению к 1С контур, то скорость проведения может достигать десятков тысяч документов в секунду. Но это не для 1С-ников задача, конечно.
(19)
— снимаю шляпу, если Вы сумеете это сделать не внешним контуром, а средствами 1с, особливо в той же бухгалтерии на базе обработки группового перепроведения документов. Или хотя бы расскажете, как Вы это видите…
Мы разрабатывали механизм многопоточного перепроведения для нашей компании, нюансов в таком механизме очень много. Автор похоже решал только проблему взаиморасчетов (закрытия авансов), а себестоимость товара и партионный учет (при использовании раздельного учета НДС) прошли мимо. У нас реализована многопоточность в бухгалтерии КОРП по подразделениям, при этом оставалась проблема взаиморасчетов, которую удалось решить только разнеся документы по типам на разное время.
(20) не поверите, но я распараллеливал проведение. При том основная проблема была в агентских документах, в которых контрагент был указан в табличной части. Алгоритм сначала разбирал непересекающиеся по договорам с покупателями документы, потом среди них выделял документы с отдельными принципалами, после чего уже скармливал потоку проведения. Механизм действительно сложный. После проведения никаких «бабочек» на 60/62/76 не наблюдалось в разрезе документов расчета.
(22) Круто, но как это реализовано не расскажете? Реально интересно, каким образом средствами 1с решить задачу параллельного проведения документов, чтобы взаиморасчеты, партии НДС (или КУДиР для УСН 15%) и пр. пр. пр. при параллельном проведении документов вставали куда надо, ежели при проведении каждого документа решаются разные задачи, и если не проведён (не перепроведён) один документ, результаты проведения другого могут быть различны? Поделитесь алгоритмами, я то же так хочу)))))
(23) то есть Вы хотите, чтобы Вам за бесплатно кто-то дал обработку, которая так делает? А рассказать — я уже рассказал в общих чертах.
(24) ну про уровень интеллекта 1С-негов ходят легенды, конечно )))
Типа 1 экскаватор копает котлован 100 часов, за сколько часов выкопают котлован 10 экскаваторов. Действительно не видите разницы?
(25) Да нет, не хочу, и даже не сумлеваюсь, что она у Вас есть…наверное — людям надо верить))))))
(5) аналогично, по ночам последовательность гоняем. Добавил только вывод сообщений при проведении в текстовый файл, сохраняемый в специальную папку на сервере.
(22) А при раздельном учете НДС с экспортом? Все прокатывало?
(29) а в чем, собственно, разница? Нужно организовать потоки так, чтобы документы проводились по-возможности параллельно. Вариантов организации — великое множество, но проблема 1С — это невозможность обращения потоков к быстрым общим данным, поэтому «кеширование», как метод оптимизации, можно реализовать лишь через запись в СУБД. Но и без кеширования вполне возможно обойтись. Но подчеркиваю — это весьма не простая задача, недостаточно просто тупо разбить документы на Х потоков по У штук.
(30) то бишь решения нету?
(31) у Вас, как я понял, решения действительно нету. У меня, как Вы бы уже могли догадаться, дело обстоит иначе.
(32) всё, что я понял,это решение есть, но никому не скажу какое, потому как намекнул, что типа есть, но токо за бабки))))))… В обчем — я Вам верю, потому как людям в принципе надо верить))))))))))))))))))))))))