<?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) Из рисунков и текста я не понял, что означает колонка сумма в отчете. Это общая сумма продаж данного товара или что?
Мне вот кажется, что суммовой анализ тоже конечно нужно делать, но вот не просто сумму считать, а вот точно также как с количеством, т.е. относительные значения. А то ну вот получится, что спрос на копеечные гайки высокий, но выхлоп низкий (при этом просто сумма за гайки не будет особенно информативной).
2) Ну, еще мне кажется, что имеет смысл для маркетологов еще и среднемесячные/недельные показатели рассчитывать и помесячно/понедельно их выводить.
3) Я отчет конечно не скачивал, но помоему он не на СКД написан. На СКД мне кажется проще и удобнее его сделать. Да и пользователю больше возможностей будет.
Заинтересовало, скачал, посмотрел!
Не хватает анализа по розничным продажам без контагентов
(1) Идальго,
1. Да, «Сумма» — это сумма реализации данного товара за период.Собственно, по ней и вычисляется показатель спроса. Согласен, кому-то будет интересно посмотреть это в количественном выражении, а в некоторых случаях, возможно и в весовом (если, конечно, указаны веса штучных упаковок товаров). Но в данном случае задача была поставлена так. В принципе, могу реализовать и другие варианты.
2. Усредненные показатели по периодам наших маркетологов не интересовали. У них стояла задача отслеживать, как принимаются рынком новые номенклатурные позиции. Поэтому, набор товаров, среди которых происходит сравнение, и период они выбирают каждый раз по своему усмотрению.
3. Отчет не на СКД, так как мы работаем на УТ 10.3, а СКД более применима и удобна для управляемых приложений, ИМХО.
(2) rounder, По-моему, этот показатель вообще не применим для розницы. Его смысл и состоит именно в том, чтобы уйти от реальных значений объемов продаж, а значит, в равной степени учитывать потребности малых и крупных покупателей в данном товаре.
(3) ну я в принципе тоже могу. Мой пост был лишь ответом на ваше предложение про доработки и идеи.
Почему СКД более применима для УФ, или почему СКД менее применима для конфигураций на обычных формах?
Собственно непонятно почему нет разделение на виды номенклатуры.. ибо понятно что количество закупаемое клиентами зависит от этого самого вида номенклатуры.. ну например клиент покупает у нас носки и шубы.. купил 10 шуб, но носков 10 никто покупать не будет ) он будет брать их 1000.. у вас получится что «носки» имеют высокий показатель спроса, что в корне не верно.
ПС: подобные показатели должны основываться на темпах продаж (имхо), как во всех нормальных аналитических решениях
(6) AllexSoft, в пункте 2 ответа на (1) я писал, что исходя из конкретных задач наших маркетологов, применен ПРОИЗВОЛЬНЫЙ набор товаров и (или) групп товаров. Так как это относительный показатель спроса, то он и вычисляется не в целом по номенклатуре, а относительно каких-то сходных друг с другом позиций номенклатуры. Иначе в нем просто нет смысла. Изначально была идея отследить, как входят на рынок новые товары (реакцию на их появление в форме спроса среди некоторых других позиций).
(5) Идальго,
Видимо, просто по моим личным предпочтениям).
А за предложения — спасибо.
(7) понял) тогда нормально если по одной группе товаров отслеживать.. а почему не сделали на «темпах продаж» ?
(9) AllexSoft,
Насколько я понимаю, темпы продаж — это «Скорость», с которой продается товар, т. е. объемы продаж за период — день или неделя, или квартал, или месяц, или год.
А как это можно использовать для вычисления нашего показателя? Ведь он используется только для анализа текущей расстановки сил на рынке между определенными позициями.