<?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:
как раз таки требования к функциональности возникает из понимания процесса, процесс обязательно должен быть отражен где-либо, хоть первоначально на обрывке бумаги.
Абсолютно верно, что он не должен быть зацементированным, но лучше когда все участники процесса итеративно его рефакторят.
Т.е. собрались обсудили и переложили штрихами на бумагу (не нужно тратить времени на его графическое представление в ПК);
Переспали с этими мыслями, еще раз пересмотрели логику и когда более менее логично, формируем требования к каждому этапу процесса.
На основании этих требований и приемка, и тесты и, как не печально, разбор полетов.
(0)
чаще всего «рисователь» и разработчик — один человек
А «рисователь» процесса хочет, чтобы у него получилось красиво: вот заявка, вот действие над заявкой, вот время выполнения процесса. Его волнует только внутренняя логика и непротиворечивость процесса.
….
не совсем согласен , имо
, в любом случае должна стоять на 1 месте , все остальное — вопросы «удобного» предоставления информации снабженцу
Вот я такой Бэтмен, руковожу отделом/службой/департаментом. Мой здравый смысл решает задачи, в срок, без факапов, все довольны. Через некоторое время я захочу поменять место работы, или занозюсь с кем-нибудь и меня уйдут.
Как в этом случае передавать этот здравый смысл в каком-то стандартизированном виде, чтобы его могли дать преемнику, и он в свою очередь его понял и принял?
(4) передадут описание процесса, которое вы нарисуете после его отладки.
(6) бывает и такое «Г» приходится «автоматизировать» , далеко ходить не нужно
возьмем например ндс с авансов по договору комиссии
это имо более подходящая иллюстрация к (3)
(7)
Процесс хорошо. А методологию разработки процессов с использованием «здравого смысла»?
Это получается зависимость компании от личности. Пока она есть — все здорово, но стоит ей уйти, остальные не факт, что смогут продолжить в том же русле. Со здравым смыслом у людей проблемы в общей массе.
К сожалению, еще ни в одной компании не встречал описанных процессов, пусть даже неактуальных.
Когда задаю вопрос почему, ответ всегда один — Процессы часто меняются нет смысла описывать.
(10) вопрос не в самом описании, а в затратах на выполнение этой работы — описания.
Традиционный подход — долгий и дорогой.
Собрать процесс автоматически, по автозадачам, например — быстро и дешево.
(10) не в каждом «описании конфигурации» можно найти описание процесса. Мне встречалось только одно — «ЗИК 7.7». Процесс начинался из переноса начального сальдо и завершался выгрузкой проводок в бухгалтерию. Это описание занимало полторы страницы. Остальное (включая подробности каждого пункта) — все и так прекрасно знали или могли воспроизвести по данным базы.
Прочесть в соотвествующем пункте описания конфигурации кому, когда и сколько начислить премии невозможно. В мануале можно узнать только одно: куда это все записать когда оно уже есть. Или, в случае отсутствия возможностей в программе принять решение (а) отказаться от премирования (б) изменять оклад/применить сдельную оплату
Процесс включает в себя наличие/отсутствие возможностей программы отразить определенный факт.
Возможно я ошиблась в понимании этого термина.
Опыт показывает, что:
1. Если не написать описание до разработки, то после его никто не напишет.
2. Если не связать себе руки бумажкой, то после внедрения окажешься виноватым.
2. Достаточно утвержденных требований на короткий спринт, чтобы они самые требования не успели «протухнуть». Как показывает практика, громоздкие ТЗ успевают стать неактуальными еще до выпуска первого релиза.
(15) На старте мы должны иметь «черный ящик», зная только что есть на входе, и что должно быть на выходе. На финише мы должны иметь самодокументирующийся процесс, собираемый на основании задач этого процесса, так?
(16) А если следующий спринт изменяет требования к предыдущему, тогда как?
(17) старт может быть разным, в том числе и таким, как вы описали.
Но, обычно, хоть какое-то понимание процесса появляется быстро — вам его за 5 минут устно расскажут.
Самодокументирующийся процесс на выходе — это не идеал. Идеал — работающий процесс. Автодокументирование — это замануха для СМК. Реальным людям он не особо нужен. Так, чтоб не приставали с бумажками.
(19) Документированный процесс нужен для понимания его сотрудниками, которые начинают работу с процессом. Утверждения/согласования документации не нужны для продуктивной работы, но это требует определённой зрелости организации.
(18)
и вот как раз для исключения подобных ситуаций и нужно понимание всего процесса хотя бы на…читайте (1) для того, чтобы требования к следующему спринту не вступали в противоречия с уже выпущенной функциональностью.
есть 3 разных профессии: кодер, инженер-программист и разработчик, причем если последние 2 могут в себе объединять обязанности остальных, то первый -кодер, никогда, и последний при этом может быть представлен группой лиц.
раздражает немного когда люди путаются в этих понятих, хотя мне кажется само разделение на исполнителя и «описателя» архитектуры, произошло по вине последних, от чего людям которые фактически не пишут код, кажется что они прекрасно все понимают, хотя это очень часто не так, элементарно как человек может разрабатывать базу данных если не отличает кластерного индекса от некластерного, ну это так из банальных, то есть люди зачастую пишут инструкции без понимания, и когда приходит новый программист он с умиление как на записки юродивого смотрит на документацию, один из перлов слышал совсем недавно. Наш аналитик слава богу не по 1С, сказал естественно без присутствия разработчиков, что оказывается программист не понимает иногда чего он пишет, сам механизм, ему этого и не нужно знать, все знает аналитик, к слову это сугубо ее личное мнение, знает она куда меньше тех людей которые занимались разработкой, хотя и они там пишут что попало
(22) А как иначе? На словах сотрудники должны друг-другу рассказывать?
(25) причем тут программирование и код?
(26) ни при чем. Причем тут мозги когда думать некогда.
(11) Аналогично. Только добавлю, что лучше использовать 2 направления:
1. Максимальное упрощение всех процессов.
2. Максимальное документирование всего. Лекции для ключевых сотрудников предприятия. Периодическое их обучение и экзаменация (конечно же в игровой форме).
(23)
Понимаете, многие ведь именно ничего абсолютно не понимают. Просто подумайте, много ли из знакомых программистов понимают как добавление функционала возврата на десятку с МЦ.04 повлияет на самодурство (мотивацию и эффективность) начальника склада? Вот-вот. А там кроме начальника склада под удар попадает вся бухгалтерия, генеральный директор и потом всё спускается на простолюдинов.
Вот и представьте какая пропасть между аналитиками и бездумными программистами. Поэтому зря злитесь на своего аналитика. Скорее всего она права.
(29) опять же есть 2 понятия прикладное программирование и программирование как создание отдельных механизмов и связей, рассуждать что программист повлиял на мотивацию директора создав отдельный механизм, это как обвинять Калашникова конструктора в убийстве миллиарда человек, инженер, конструктор, создает только механизм как им пользоваться решают другие люди, вопрос в том что только они знают что доконца может система, возвращаясь к автомату я о том знании конструктора что пороховые газы способны пробить стену, а аналитики без этого знания. а появиться ему элементарно не от куда, будут пытаться придумать сложный механизм по пробитию стены из рогатки кожурой от орехов, даже иногда выходит им что то придумать но результат это стыд
(30) Хм, я примерно понимаю про что Вы пишите (ключевое слово — примерно) и именно поэтому немного не соглашусь. Нарисованный Вами программист может хорошо знать устройство автомата и уж точно не будет применять рогатку для пробития стены. Тогда как аналитик знает сколько стен надо пробить и куда они упадут после выстрелов. При этом аналитику не надо знать чем будут пробивать эти стены, а программисты (не всегда) не знают сколько стен пробивать придётся и что будет после этого и что случится когда они упадут. Мне кажется ваш аналитик как раз это и имела в виду — разные уровни абстракции. Очень разные.
(31) глобально может и так, то есть когда работает конвейер каждый выполняет свою работу, я лишь о том модель аналитик-кодер нежизнеспособна, наконец выразил свою мысль) если есть просто исполнитель — кодер и заказчик — аналитик (который сам уже посредник между конечным пользователем и разработчиком), должен быть архитектор, кто на мой взгляд тоже псевдопрограммист, так как не пишет код, значит не может считаться программистом в полном смысле, с каждым годом количество менеджеров увеличивается, а копает Вася как на той картинке))
(32) Ну Вы уж прям нарисовали картинку «три толстяка». Зря, очень зря. Простите, но за свою карьеру уже не мало видел людей, которые снизу рассуждали о бездарности манагеров, а как забирались чуть выше, так сразу материли работяг за безделье и лень. Работяг, а не себя! Другими словами, попробуйте обладать знаниями аналитика и использовать их в реальности, а потом сравните с текущим мировоззрением. Уверяю, будете очень удивлены.
«аналитик-кодер » Ну не знаю, сколько не видел програмистов, всегда одно и тоже — без аналитика заказчик не может внятно сформулировать хотелки, а программист вообще не знает как правильно делать. К сожалению как раз такие конторы постоянно и выправляю. Каждый год одно и тоже.
(33) ваше предположение было бы верно, но я не снизу)) конечно польщен тем что в рассуждения я беспечен и молод, но это далеко не так)) аналитик — это больше пользователь, который знает пользовательский функционал, под словом пользовательский я первоначальные представления о программировании, то есть использование «Справочники.Номенклатура.НайтиПоКоду()» это пользовательский уровень, программист имеет представление об механизме поиска, индексах задействованных, и стоит ли его применять в данном случае или лучше сделать запрос к справочнику. Про OLAP системы это отдельный разговор
(34) Упс… простите, если обидел. Значит мы просто чуть-чуть про разное говорим. Предлагаю найти более-менее аксиомы.
Например, я рассматриваю роль «аналитик» в виде человека, который знает бизнес-процессы предприятия, смотрит на них сверху. Он абсолютно не знает программирования и даже системы на которой производится автоматизация. Он оперирует объектами бизнеса, а не объектами учётной системы или понятиями языка программирования. Аналитик хорошо знает все виды учёта и умеет читать (т.е. ему не лень проштудировать консультант+, например, для того, что бы знать, что удерживать с работника можно только в текущем месяце). При этом аналитика внимательно слушают начальники отделов и всякие заместители генерального.
Программист же наоборот отлично знает все тонкости программирования, алгоритмы и прочие непонятности для остальных людей. Как правило программиста не слышат всякие начальники и поэтому постановка задачи от них происходит как общение глухого с немым.
Может я ошибаюсь, но я всегда так представлял эти роли (укрупнённо конечно же)
Примечание: Я не знаю, что такое индексы и ОЛАП системы видел только на картинках, но это не мешает более-менее успешно автоматизировать предприятия разных масштабов. Хотя для души пишу на PureBasic-е и Fasm-е, но в работе это забываю полностью.
у нас наверно неправильный смк. Точнее 1 человек.
исполнение процессов спрашивают, помогают. Смотрят эффективность, запускаются процессы корректировки если показатели падают.
А вот с руководителями отделов беда. Им мало что надо. Это простые исполнители.
Фактический смк или отдел развития могут одной мыслью заставить работать остальных по другому.
Пока конечно это в стадии старта. Т.е. все руководители описывают что у них твориться. и пытаемся все измерять.
Посмотрим что выйдет.
Все, почти поголовно, руководители реагируют на события, а не выстраивают систему. Исключения единицы.
Очень хочется от Ивана статьи как затащить руководителей исполнять их прямые обязанности, что бы смк стал не нужен.