<?php // Полная загрузка сервисных книжек, создан 2026-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) Я тоже в один момент подумал, что объединив два набора данных можно получить правильные итоги сразу, но, поскольку, роли полей настраиваются уже для Объединения, а не для отдельных наборов данных в него входящих — получим тоже самое
(3)
Просто такую же проблему у меня получилось решить именно объединением наборов… Причем в наборах поля ресурсов не пересекались.
Но может ситуация была немного другая =)
Во-первых чтобы СКД корректно рассчитывала остаток надо обязательно в ресурсах указывать поля Нач.Кон остатки
Прекрасно делается через Набор данных Объединение только там есть интересный момент следует учесть Значения разных ресурсов регистров под разныими именами!
А вот это диво-дивное и чудо чудное решается как с помощью Набора данных Объединение так и с помощью просто Объеденить в запросе. Но с одной особенностью, что роли необходимо самому указать и проверить для Измерений чтобы были измерениями, а для остатков остатками. Но можно упороться на одну интересную ошибку особенно если использовали к примеру одно поле КонОст и остатка и партии во тут получим ошибку.
Короче что тут разговоры говорить решал я подобную задачу и в конце увидил, что можно ее решить по-разному и оставил вариант как в обработке. Не обесудьте!
Оговорюсь только , что это делалось для конфигурашки на обычных формах 10..х под CRM.
(7) Все хорошо, пока не добавить группировку по регистратору.
При добавлении группировки — остаток по партиям для Номенклатуры и для Склада — 0
Эти грабли я и описал в статье, и как их поборол
p.s. В отчете, что вы скинули, нет никакого смысла делать объединение наборов, т.к. вы ничего не объединяете. И не совсем понятно, почему так сложно рассчитываются ресурсы
Спасибо большое, за вашу статью. Такая же проблема была, только я использовал три регистра в самописной конфигурации. Пришел к выводу, что при добавлении третьего регистра плывет остаток по конечному остатку по измерениям. Хотя по регистратору всё нормально. Проверял все роли, делал и в одном запросе и в объединении — ничего не помогало. Благодаря добавлению раздела всё стало на свои места. Нутром чувствовал, что СКД путает. Очень выручили )).
Для остатков по регистратору вы использовали вспомогательное поле период секунда?
(10) Да, псевдоним у поля — Период
(11)Тогда проблем с остатками по регистратору быть не должно, а если вы искусственно добавляете разрез (новое измерение) в набор, то это вроде как правило, именно правило а не фича какая то, что его нужно отметить измерением. Разработка сложных отчетов книга есть у Хрусталевой. Во второй редакции это должно быть описано.
(12) да на итс уже как 100 лет есть это — если регистратор то надо секунду добавлять и роли полей поставить правильно
(12)
— согласен. Но далеко не все разработчики это осознают, когда создают отчеты по нескольким разделам учета и хотят видеть корректные остатки.
Цель статьи — заострить внимание на том, что задачу решить можно, путем введения нового разреза и установкой роли — Измерение для этого разреза.
Ничего сверхестественного, просто тонкость, которую нужно понимать
Спасибо автору!!! Столкнулся я с проблемой этих остатков, когда объединял два регистра накопления, день бился не добился результата, пока не наткнулся на эту статью. Интуитивно было понятно, что надо что-то делать с разделами учета, потому что по-отдельности запросы считали корректно, а при объединении нет, но как сочинить сие действо мозгов не хватило)))
У меня несколько иная задача(. есть начальный остаток по регистру товары на складах и приход по нему материала. Но расход высчитывается как нормативный. Берется перемещаема продукция. по ней ищется спецификация, выбирается материал и рассчитывается нормативный расход. Общего из двух запросов получается только склад и номенклатура. А вот конечный остаток вычисляется как начальный остаток +приход-нормативный расход. Не получается подружить конечный остаток ни с одним периодом из регистра. Группировка склад и номенклатура — всё нормально, но как только добавляешь регистратор, день…остатки разлетаются. Искусственное измерение типа — раздела учета не помогает….
(16) И не поможет. Вам в итоге нужно получить выборку вида:
В одной строке выборки должен присутствовать начальный и конечный остаток.
Почему-то если добавляю поле Раздел, в поля группировки к Регистратору, выходит ошибка: Совместная группировка по периодам с другими выражениями запрещена, убираю Роль период у регистратора и периода — конечный остаток не правильный. Если не добавлять раздел в поля группировки и оставить Роль период как есть, все работает.
(18) И не нужно группировать регистратор с каким-то еще полем — посмотрите скриншот с настройкой структуры.
(19) Я хотел сделать также, как на картинке перед заголовком Немного красоты.
(19) Так как это сделать?
(21) Это не группировка Регистратор, Раздел. Это детальные записи, в которых выведены эти два поля.
(7) взял на вооружение +1
Запомнить — с чем то подобным сталкивался по поводу детальных записей
в консоли все нормально работало-
решил перенести в отчет
часа два ковырялся пока добился нужного результата
теперь немного понятно