<?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='\
Полностью согласен с мнением автора. Я сам в техзадании обычно ограничиваюсь проработкой концепции проекта. Главное отразить общую картину, чтобы было понятно заказчику, что он получит в результате. Детали прорабатываешь уже в процессе выполнения проекта. А толстые тома, которые иногда мне попадают на рецинзирование, там как правило за частностями теряется общее, а бывает что его и вообще нет.
Согласен с автором.
Справка, документация полезны, а техзадание больше нужно когда предполагаются конфликты, претензии.
У меня был случай когда я делал техзадание, которое в последствии делал другой программист. Мозг он мне на счет него вынес 🙂 прилично «не ясно написано», «не все моменты узнал» в результате что то сделал в разрез задания (естественно никто не пошел даже на дополнение к заданию). ТЗ часто просто повод взять деньги, нужно на крупных проектах (где много разработчиков) и там где этого требует заказчик.
а я не согласен. иногда клиент по ходу дела начинает петлять — то то добавь, то это наоборот сделай и т.д…..
так вот ТЗ вылечили практически все проблемные ситуации… просто их теперь нет — проблем
Согласен. Обратное тоже верно: даже при отсутствии ТЗ разработка может быть оплачена клиентом полностью. Около года назад у меня так и было: написал индивидуальную конфу для местного института вообще без ТЗ. И оплатили.
В статье опущено одно определение. Масштаб проекта. Одно дело. если ты пишешь обработку или отчет простенький, и другое — если разрабатываешь учетную систему… Хотя и там и там ТЗ больше добро чем зло. формулируя и согласовывая ТЗ и Заказчик и Исполнитель начинают понимать ЧТО в конечном итоге получится и КАК ЭТО будет работать, что в будущем поможет и в расчетах….
ситуации бывают разные, но в принципе без ТЗ нельзя… с другой стороны писать тома как для заказчика так и для исполнителя не совсем целесообразно… это связано в первую очередь с тем, что на этапе технического задания могут быть не учтены важные детали которые по ходу дела выплывут… с другой стороны остается в этом случае вопрос оценки проекта… опять же все зависит от задачи.. .как по мне, так ТЗ должно быть кратким, а оплата поэтапная… за каждый этап 100% предоплаты… тогда исполнитель не работает авансом и клиент рискует не всей суммой проекта. закончился этап, акты подписали, получили предоплату, дальше работаем…
например, какое ТЗ должно быть написано при постановке управленческого учета? регламентированные документы которые должны быть разработаны и есть это ТЗ… хотя это может быть этапом… однако в практике часто выясняешь детали на этапе формирования отчетности… 😉
100% истина в том, что — население умственно недоразвито — действует без Договоров.
Выводы:
1. Лень писать ТЗ, так как не могут понять, для чего это нужно.
2. Без детального ТЗ, и, соответственно, Договора выигрыш получает недобросовестная сторона.
Так заказчик может начать говорить, что надо было сделать ещё 100 связанных задач, если изначально устная договорённость может давать различные трактовки.
3. Умственно недоразвитое население не знает ни нормативов сроков, ни договоров, ни детального ТЗ — поэтому выходит всё через Ж0пу.
Что мешает заключать договора согласно ГК?
1. Договор нужен всегда, это единственное доказательство что ты им что-то делал.
2. По окончании задания (или периода обслуживания) требовать акт выполненных работ.
3. Можно перестраховаться, ограничивая в коде период дейсвия функционала, а при оплате снять ограничение. Муторно конечно, но или вы с деньгами и они работают, или и вы без денег, но и они остануться на чем сидели.
Это больше похоже на запись в блоге а не на статью 🙂
Полностью согласен …
Перенёс материал к себе на ресурс
Есть ещё один способ оценки: количество строк кода + сложность выводимых форм.
(0) Ни какой гарантии, что клиент заплатит за работу при наличии ТЗ нет и не будет.
А ТЗ и не представляет из себя никакой гарантии. Кто вам такое сказал?
Здесь на ИСе уже все разжевали много раз.
Большинство все-таки за ТЗ. Потому что ТЗ это то с помощью чего исполнитель и заказчик находит решение возникших проблем. Естественно, что каждой задаче свое ТЗ. Иногда можно обойтись и без ТЗ.
Но попробуйте начать внедрение большого проекта, да еще и не типового? Без единой схемы?!
(12) «… Без единой схемы?!»
Нет, конечно. Речь в данном случае не об этом. Безусловно, беседуя с заказчиком приходится что-то писать карандашом или ручкой… т.с. «на салфетках» 🙂
В дальнейшем эти записи могут вылиться в ТЗ, а могут и не вылиться. Оплата, как было отмечено, от этого не зависит.
P.S.
Что-то мне Ваша фраза напомнила «ни единого разрыва» 😀
(13)Не очень удачно выразился.
Хотел сказать, что как минимум должен быть общий план действий, последовательность и содержание работ, исполнитель и ответственный. Это может быть на салфетке или на финской бумаге А4 или на туалетной бумаге это каждый решает для себя сам. 😉
Главное то что все эти вопросы являются частично ТЗ(в том или ином виде), а ГОСТ-ом не регламентируется четко объем ТЗ.
Грубо говоря ТЗ может уместится на одной салфетке если спец такой профи — краткость сестра таланта.
К сожалению, я такого не встречал 🙂
(13) вот, блин, к «салфеткам» придрался 😀
Я же — образно…
Я тоже считаю, что делать чертежи перед постройкой дома — глупость. Прораб с заказчиком всегда на месте решат куда кирпичи класть 😉
(16) Угу! Прораб с заказчиком решат, а каменщик с подсобником по своему решат.
Вот так они и работали — каждый выполнял свою работу. Главное — добросовестно.
И придраться не к чему — стена то стоит. 😀
При любом, самом хорошем отношении с заказчиком есть вероятность возникновении спорных ситуаций. Например, чтобы доказать, что мы — самые крутые франчи во Вселенной, и что взятие программиста на постоянную ставку или переход к другим франчам клиенту не поможет.
Аккуратно оформленная документация, описывающая наши достижения является очень даже хорошим подспорьем в этом деле. И бывает полезно иметь документальные подтверждения проделанных работ с их кратким описанием.
Эти краткие описания не обязательно должны быть такими же подробными, как классические ТЗ. Более того, даже лучше, если они будут краткими и понятными далеким от автоматизации людям (директорам, замам, президентам компаний и др.).
Кроме того, такие краткие описания могут помочь даже руководсву самого франча быстрее вникнуть в ситуацию по работам с каким-то клиентом, если возникнет необходимость.
Ну всё в кучу… И деловые отношения общего партнёрства, и психологические моменты общения, и гражданско-правовые, и технологические… Ни терминологии прописанной, ни ясности изложения, один сумбур из серии «нас всё равно кинут, зачем писать ТЗ».
Абсолютная истина!
Полностью согласен…
Необходимое условие — у заказчика должно быть достаточно авторитетное лицо — заинтересованное в успехе проекта. А самое лучшее это как поддержка со стороны руководства, так и со стороны ведущего по теме специалиста.
Невозможно сделать и даже внедрить бухгалтерскую программу, если главбух против.
точно также нельзя ни сделать ни внедрить технологическую программу, если этому противится технолог
тоже самое по кадровикам….
По сути статьи не согласен.
Тех задание не есть гарантия оплаты. Оно скорее конкретизирует темпы, объемы работ и оплаты. Более ближе к гарантии оплаты находятся акты. Там конкретно указываются выполненые работы и их сумма, стоят подписи и печати.
Гарантией своевременной оплаты вашей услуги может быть желание клиента её получить и сотрудничать дальше.
Другими словами клиент должен созреть для конкретной автоматизации, тогда с ним можно практически работать. Либо дать откат лицу, принимающему решение. 😀
Скорее всего в данном случае это опыт общения именно с неполностью зрелым в отношении к вашей услуги клиентом. Т. е. при определении задания о был как бы не против, ну за тоже особо не выступал.
Совет: работайте с «готовыми» клиентами.
На 100% согласен.
Для многих кстати является открытием что по ГОСТ, техническое задание НЕ содержит детального описания, что и как будет сделано, а содержит лишь требования к системе по которым можно будет понять сделана система или нет