<?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). Регистр «КурсыВалют» взят для краткости и для разнообразия. Для скорости лучше использовать «календарик» на основе []. Классический вариант (5) проигрывает по быстродействию предложенному примерно в 1.5 раза (проверялось на файловой базе УПП). Похожая математика используется в [].
(7) ildarovich,
…
Сумма(ВЫБОР
КОГДА Движения.Период = &НачалоПериода
ТОГДА Движения.КоличествоНачальныйОстаток
//{LRS: Если не начальный остаток, то NULL. Необходимо заменить его на 0, иначе мы получим Начальный остаток на каждую дату
ИНАЧЕ 0
//}
КОНЕЦ + Движения.КоличествоОборот) КАК КоличествоКонечныйОстаток
…
(7) ildarovich, Вы поторопились группировать по номенклатуре, ведь движение на дату может быть null, запрос топикастера более верный. Но он не учитывает варианта, когда товар вообще появился на складе после начала периода, во-вторых, остатки обачно нужны на конец дня, а не начало, в этом случае поможет отнимание оборотов от конечного остатка(&КонецПериода оканчивается на 23:59:59):
ВЫБРАТЬ
ТоварыНаСкладах2Обороты.Период,
-ТоварыНаСкладах2Обороты.КоличествоОборот КАК КоличествоОборот,
ТоварыНаСкладах2Обороты.Номенклатура
ПОМЕСТИТЬ Движения
ИЗ
РегистрНакопления.ПартииНоменклатуры.Обороты(
&НачалоПериода,
&КонецПериода,
День,
Номенклатура = &ном
И склад = &склад) КАК ТоварыНаСкладах2Обороты
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
ДОБАВИТЬКДАТЕ(&КонецПериода, СЕКУНДА, 1),
ТоварыНаСкладах2Остатки.КоличествоОстаток,
ТоварыНаСкладах2Остатки.Номенклатура
ИЗ
РегистрНакопления.ПартииНоменклатуры.Остатки(
&КонецПериода,
Номенклатура = &ном
И склад = &склад) КАК ТоварыНаСкладах2Остатки
;
////////////////////////////////////////////////////////////
ВЫБРАТЬ
Дни.Период КАК Период,
Движения.Номенклатура КАК Номенклатура,
СУММА(Движения.КоличествоОборот) КАК КоличествоОстаток
ИЗ
тДаты КАК Дни
ЛЕВОЕ СОЕДИНЕНИЕ Движения КАК Движения
ПО (Движения.Период > Дни.Период)
СГРУППИРОВАТЬ ПО
Дни.Период,
Движения.Номенклатура
Ещё добавлю, что только таким способом можно средствами скд брать остатки в нужном нам разрезе, а не использовать запрос по ВСЕЙ номенклатуре при левом соединении.
(7)(10) kuzyara, Вы совершенно правы, я допустил неточности в этом запросе. Но их можно исправить в рамках того же подхода, когда используется только один виртуальный регистр, не увеличивая число строк в запросе. Нужно было предусмотреть ситуацию отсутствия товаров на складе в начальный момент. Вот исправленный запрос
Показать
… здесь также есть недостатки. Окончательный вариант приведен в комментарии (14)
(11) ildarovich, почему вы упорно не замечаете ЕстьNull(Движения.Номенклатура, ?)
(12) kuzyara, упс — сообразил, наконец: если входящего остатка нет, то номенклатуру до первого прихода при таком подходе не показать — возьму, пожалуй, пока паузу на обдумывание…
(12) kuzyara, переписал запрос еще раз. Получилось так
Показать
Обнаружил, что если мой старый вариант не отображал номенклатуру до ее первого появления на складе, то ваш не отображает после последнего. То есть, если в течение периода товар ушел со склада, то в таблице остатков его не будет и возникает та же проблема, что и в моем старом запросе. Ну и исходный вариант в статье тоже этим страдает.
Так что, когда у вас появится таблица движущейся номенклатуры, то ваш запрос станет еще сложнее и дольше.
Недостатком моего последнего варианта является «двойной» обход оборотов, но, скорее всего, при группировке при нахождении движущейся номенклатуры будут примерно те же затраты, да еще и затраты на запись и соединение. Так что предполагаю победу своего варианта и в соревновании по быстродействию.
Ну а вообще спасибо за критическое отношение и внимательность — впредь буду тщательнее тестировать предлагаемые запросы.
клёво!
Вот пример на виртуальной таблице остатков и оборотов, а также таблице дат («Календарик»). Добавил отбор по номенклатуре, для тестирования. Можно смело копипастить и тестить в УТ 10.3. При добавлении характеристик и прочих измерений, надо добавить их в виртуальные таблицы (с этим проблем быть не должно)
Показать
(14) ildarovich, Работает, но не пойму как. Нет правила по которому соединяются таблицы. Как тогда они правильно соединяются?
(14) ildarovich, 🙂 всё понял.
(14) Да, классно, конечно!
Но мне понадобилось выбрать и начальный, и обороты (и приход, и расход) и конечный. Выкрутился так, в подчиненном запросе все кроме начальных остатков, по приниципу как в 14-м комменте у ildarovich, а уже из подчиненного по конечному и обороту вычисляю начальный в «верхнем» запросе, т.е. так:
Показать
Но может можно красивее или еще какую критику кто-то выскажет?
(19), я не стал городить подзапрос для начальный остатков, а обошелся разностью сумм КолВоКонОст и КолВоОборот
(14) ildarovich, А кто ни будь смог получить остатки на начало и на конец дня одним запросом? Я так и не смог этого добиться… Если кто это получил, не подскажите как?
(21) olbu, попробуйте добавить в запрос приведенный в (14) для вычисления начального остатка следующую конструкцию
Показать
Хотя могу и ошибаться — желательно еще протестировать.
(22) ildarovich,
Не работает на начало. Сейчас ковыряюсь.А может и работает. Непонятно 🙂(22) ildarovich, насколько я понял, это не работает, т.к. не учитывает Движения.КоличествоОборот за &НачалоПериода. Например, нач.остаток на второй день будет рассчитан как Движения.КоличествоНачальныйОстаток, а должен быть рассчитан как «Движения.КоличествоНачальныйОстаток + Движения.КоличествоОборот» (т.е. остаток на &НачалоПериода + оборот за &НачалоПериода).
Видимо должно быть что-то вроде этого:
Показать
(24) q_i, Мой вариант:
Показать
(14) ildarovich, Спасибо! Работает, только остатки по записи сделал.
(16) Прошло больше двух лет, не хочу сказать — решение по получению таблицы дат очень красивое 🙂
(14) Можно проще
Показать
(28) Да, так будет лучше
Чуть модифицировал (16) для случая, когда периоды нам нужны исключительно до указанной даты… Так же в запросе добавил выборку регистраторов, которые двигали указанную номенклатуру в пределах дня:
Показать
(30) Хороший запрос, но используя его можно как-то вытащить расход и приход?
У меня выводится , но если не было движения например по расходу он берет последний расход, допустим от 10.01, и до конца месяца его проставляет, хотя должно стоять по нулям, так же и с расходом (.
(33) суть та же 🙂
(34) в принципе да ))