<?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С в как можно большем количестве. Франч — это ж технология копирования определенного ведения бизнеса, прописанного в данном случае компанией 1С. Франч не может отклоняться от технологии работы по договору франчайзинга, которую кстати разрабатывает и контролирует сама же 1С.
Жаль что функциональные модели для типовых конфигурация пока есть только для «1C:ERP Управление предприятием 2». Ну и с расширениями текущая версия СППР работает, гм, весьма ограниченно. Пока отложили конфу «под сукно».
Автор, что вы думаете по поводу использования ?
Вроде позволяет больше возможностей. Есть и uml, и bpmn и документация тут же, и задачница.
(1) По поводу «зрелости объекта автоматизации» вы абсолютно правы. Тем не менее, заказчик/объект автоматизации может оставить за собой право не быть специалистом по проектированию и право нанимать на формирование своего «видения» сторонних специалистов. А тем, кто выполняет такие контракты, следует придерживаться какой-то технологии, ведь это их производственный процесс. И тут вы опять правы, такие технологии могут быть разные. В статье я предложил одну из них, но она имеет в базисе математический аппарат, что в потенциале позволит очень хорошо автоматизировать процесс проектирования и автоматизацию проверки качества проектирования.
Насчёт того, что франчи ограничены требованиями 1С в реализации проектов на типовых решениях 1С не согласен. Решений на чистых типовых конфигурациях 1С очень мало. Сложные проекты подразумевают существенную переделку конфигураций и системного ландшафта. Требования 1С сродни требованиям ISO — дают общие границы, но не настолько детальны, чтобы франчи были несвободны в выборе мтодик исполнени япроектов.
(2) Модель ERP я пробовал загружать и изучать в 1С СППР. Но эта модель малополезна, поскольку во-первых, она неглубоко и нетщательно написана, в частности бизнес-процессы «заказчика?!» в неё заложены примитивные. Фактически 1С в модели ERP описало функциональность конфигурации простым повторением подсистем ERP из конфигурации. Во-вторых, уровень детализации в модели недостаточен для корректной проектировки. Посмотрите, например, операции пользователей. В большей степени модель ERP от 1С — это демо. С её помощью проблемно автоматизировать проверку качества проектирования.
Я не встретил в СППР принципиальных проблем при работе с расширениями. СППР работает сразу с несколькими конфигурациями. Можно, при желании и проблемах, все расширения описывать в отдельной от основной конфигурации. Всё-равно эти конфигурации не будут переданы разработчику. Они нужны лишь для обеспечения общего языка для бизнес-аудиторов-методологов-проектировщиков-разработчиков-менеджеров проектов.
(3) Посмотрел инструмент по ссылке. Я никогда в нём не работал, поэтому сказать о нём могу немногое. Функционал, заявленный в нём, судя по сайту, шикарный. Но, в статье предлагается технология работы основанная на «общем языке». Заложено ли это в VisualParadigm мне не известно. Если общего языка в нём нет, то весьма проблемно организовать совместную работу бизнес-аналитика, методолога, архитектора, проектировщиков, разработчиков как технологию производства и так, чтобы проверку качества проектирования можно было автоматизировать.
VisualParadigm не единственный инструмент, таких достаточно, но у большинства из них очень сильный упор на графическое описание бизнес-процессов. Это значит, что человек рисует бизнес-процессы в том или ином формате. Это также означает, что возможность описывать сложные бизнес-процессы очень сильно ограничивается ментальными возможностями человека. Человек не в силах держать в голове сложные ментальные и процессные карты. А когда в эти карты следует вносить массовые изменения, то становится ещё хуже.
Это таже самая проблема, что и у программистов. Программист может написать миллионы строк кода и помнить многие взаимосвязи в своей программе, но со временем нити теряются и «целостное» понимание развитого и ветвящегося кода ускользает. Наступает время «заплаток». Это закон, обязательный этап развития в разработке ПО. И всё мгновенно ухудшается, если над кодом работает команда или идёт массив доработок, уже никто не знает всего. Вот и у аналитиков, проектировщиков тоже, если они пытаются держать в голове все ветви бизнес-процесса.
То что карту бизнес-процесса хранит компьютер помогает, но тоже имеет свой предел, поскольку «промотка» всего «футбольного» поля с бизнес-процессом занимает время.
Попробуйте в 1С EDT сформировать ER-диаграмму сразу всей конфигурации 1С:Управление холдингом или 1С:ЕРП, а потом посмотрите насколько удобно работать с промоткой объектов и просмотром взаимосвязей
и как быстро теряется нить связи, если объекты уезжают за границы экрана.
В 1С СППР нет функционала отрисовки бизнес-процессов. Там они заносятся в простой примитивный справочник 1С. Но эта простая иерархичная форма при соблюдении определённых правил заполнения справочника позволяет использовать формальный математический аппарат для контроля и управления изменениями в ней. Собственно в этом и состоит предложенная в статье технология. А сделать графический отрисовщик бизнес-процессов на основе заполнненого справочника «Процессы» в СППР нет проблем.
Поэтому VisualParadigm как и другие подобные инструменты будут хороши до определённого уровня сложности проекта и сложности самой проектной команды.
Для исполнение сложных проектов качественно необходимы математический аппарат и автоматизация управления качеством проектирования.
реквестируем более детальный обзор СППР и применимость его для внутренней разработки внутри холдинга
(7) Чем по вашему мнению этот детальный обзор должен отличаться от руководства от 1С и от статьи выше?
Касаемо применимости для внутренней разработки холдинга и любой компании, имеющей зоопарк учётного ПО, технология таже самая, что и предложенная в статье.
Разница между интегратором (франчайзи) и «холдингом» только в том, что для интегратора это доходная деятельность, а для холдинга — затратная. Хотя и необходимая.
Разница в том, что для интегратора это единственная доходная деятельность, а для холдинга — далеко не единственная затратная.
Любой интегратор является конкурентом всех подразделений холдинга за ресурсы и внешних интеграторов прогнуть гораздо сложнее, чем собственный отдел разработки.
(10) Хм, внешних интеграторов прогнуть сложнее? Призываю внешних интеграторов высказаться сюда о прогибании )
(9)
это больше «обзор» с брошюры. А хотелось бы поглазеть на разбор схемы (хотя бы минимальной). По части доходный/расходный это азбука. Интересна тема по части выхлопа. Можно ли получить больше контроля за доработкой в команде из 5-8 человек (у всех свои контуры правда), что бы не случилось как случилось у нас — два человека с разных сторон заавтоматизировали одну фичу,только для разных подразделений.
(12) Обзор сделан не из «брошюры». В брошюре от 1С совсем другая подача материала и другой подход, в частности 1С не даёт никаких предложений по математическому подходу и алгоритмизации и автоматизации проектирования и разработки. 1С СППР даёт прямой контроль за проектированием, но лишь косвенный контроль за разработкой, код то в 1С СППР не пишется. Команда из 5-8 человек означает что проектировщиков нет. Если хотите контроль за избыточностью фич, то надо проектировать прежде чем разрабатывать. А это удлинение времени исполнения проекта. Схема контроля за избыточностью фич-функционала есть, она простая и в статье в принципе описана: Проектировщик описывает функциональность системы, а разработчик пишет код с ограничением на создание объектов метаданных и с соблюденеим требований по написанию кода в части деления на процедуры. Исключение избыточных фич/функционала делается в 1С СППР через а) обязательное следование математическому описанию функционала в виде незамкнутых графов б) автоматическим контролем качества проектирования средствами СППР.
(13)
оке. Принял. Спасибо за информацию. Вы правильно подметили, что у нас нет проектировщика. Каждый разработчик держит свой блок разработки — производство, зп, бух, продажи. сейчас возникла идея реализовать что-то вроде листа фич под разработку в общем доступе, что бы перед тем как начинать реализацию проверять, а нет ли уже смежных решений от коллег.
(14) Лист фич — верное решение и вполне естественное. Но его будет недостаточно. Надо ещё вести реестр объектов и процедур, используемых под каждую фичу. Плюс ещё надо отслеживать потенциальные проблемы производительности из-за новых объектов и процедур. Плюс ещё отслеживать результат постоянных модификаций взаимосвязи фич/объектов/процедур.
(15) Дык, это и подразумевается под листом фич. Если разработка больше часа (то есть не «печатные формы») то регистрируется фича (по виду «регистрация проведения тендерных игрищ») и описывается или прикладывается инициализирующие документы (служебка, ТЗ и т.д.), формируется список работ и потом уже реализуется кодовая составляющая. Но тут уже есть проблема, когда коды накодены разработчику будет лень переносить их описание даже в СППР, тут надо пильнуть выгрузку метаданных…
(16) То, что вы называете «описанием кодов которые надо перенести в СППР» это не лень разработчика, а целая отдельная проблема. Которая не решается простым листом фичей. Поскольку помимо регистрации фичей (нового функционала) надо отслеживать пересечение объектов и процедур, как «типовых», так и вновь разрабатываемых. К примеру, одна и таже процедура может делать распределение затрат для типовых объектов 1С и быть частью доработанной процедуры по специфичному для заказчика алгоритму. Если для доработанной процедуры вы повторите типовой алгоритм как «независимый» в отдельной процедуре, то потом может встать вопрос как синхронизировать изменившуюся типовую процедуру с её клоном в фиче. И т. и т.п. Да и кодовая составляющая «фичи» может быть заключена в сонме разросанных по конфигурации объектов — и в глобальном модуле и модуле объектов и т.п. Для программиста выявить все связки и привязать просто к «фиче» это затратно по времени. А если фича будет разделена на две и более фич? Это всё к тому, что если ввязались в управление разработкой через проектирование, то лучше сразу изучить тему и использовать технологию целиком, а не её стартовую часть «лист фич». Постоянно будет запоздалая реакция на ошибки…
Думаю, основная проблема в том, что роли бизнес аналитика, методолога, архитектора и проектировщика на проектах часто выполняют одни и те же люди. В итоге они обладают недостаточной компетенцией и сильно ограничены во времени. Завести же «каждой твари по паре» мешает рыночная ситуация, в которой бюджеты проектов зачастую просто не выдерживают такой нагрузки на ФОТ команды.
(18) Согласен. Но причине не всегда в бюджетах проектов. Очень часто владельцы ERP не понимают, что к ней нужен совсем другой подход. Нельзя в ERP ставить задачи напрямую программистам. Только через предварительное проектирование.
Телеграмм канал для оперативного общения по теме 1С СППР