Как быстро, при помощи расширений, доработать движения регламентированного учета в ERP 2.4 или KA 2




Принцип обмена данными из 1С с сайтом (на MySQL) и выдачи (публикации) этих данных по запросу.
PHP-Скрипт автоматической загрузки данных из файла данных в формате CSV в базу данных сайта работающего на WordPress.

В продолжение моей темы: 1С:Альфа-Авто Автосалон Автосервис: обмен с сайтом.
С помощью данного скрипта можно загружать в автоматическом режиме, по расписанию, данные сервисных книжек (ремонтов авто) из 1С:Альфа-Авто Автосалон Автосервис.
Также можно загружать данные в ручном режиме: для этого делается скрытая страница, где размещается специальная кнопка.
Комментарии размещенные внутри скрипта разъяснят логику и порядок действия.
Комментарии с "/////    echo" использовались для отладки.
Дополнительно создана таблица для журналирования результатов загрузки данных.
Скрипт включает в себя защиту от SQL инъекций (думаю безопасность соблюдена в полной мере).
В кратце:
1. Пишется скрипт, который запускает этот.
2. Создается регламентное задание в WordPress, по которому запускается скрипт из п.1. 
3. Этот скрипт осуществляет проверку на существование файла обмена в папке.
4. Если данные не новые, загрузка не производится.
5. Если данные новые, очищается таблица сервисных книжек.
6. Загружаются новые данные.

Собственно сам скрипт:

<?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='\

23 Comments

  1. karshev

    Хорошая статья, актуальная

    Reply
  2. KVIKS

    Пора вкуривать расширения

    Reply
  3. acsent

    полностью выносить процедуру в расширение — обернется потом проблемой, что вы не будете знать когда основной код поменяется, а в вашей доработке нет.

    И еще хорошо, если сразу упадет, а если просто данные будут не те выдавться

    Reply
  4. katenok86

    (3)Да за это не люблю использовать в расширении конструкцию вместо. Лучше пусть ух будет не совсем типовое обновление, зато при обновлении видно ляжет ли корректно доработка в типовой релиз

    Reply
  5. logarifm

    Чушь. Куда и что упадет. Для этого делается ОДНО расширение в конфигурации — с типом «Исправление». Например ИсправлениеШтатногоФункционала и только в такие расширения пихать блоки ВМЕСТО. И при обновлении учитывать такие блоки!!!

    Reply
  6. Shmell

    (5) добавлю — даже если разработчиков несколько — можно сделать хранилище расширения с таким типом…

    Reply
  7. Vladimir Litvinenko

    (5)

    При переходе на новый релиз сложнее увидеть что изменилось и требует адаптации. Нужно именно отдельно «учитывать такие блоки», то есть самостоятельно сравнивать тексты методов.

    При этом часто нужно трехстороннее сравнение-объединение кода из нового релиза, старого релиза и нашей версии кода. Это легко обеспечивается KDiff3 при изменениях модулей исходной конфигурации, но с расширениями пока не работает. Большие подвижки в этом без применения внешних инструментов обещает EDT, но опять же не в отношении расширений конфигурации. Их придется дорабатывать для нового релиза опять же вручную.

    Иными словами автоматика в этом случае не помогает выполнить процесс обновления. Когда измененных методов немного, то это не проблема, но если доработки серьезные, то риск учесть не все изменения сильно повышается. Проблема возникает и при изменении сигнатур методов, даже платформенная проверка конфигурации на некорректные вызовы не отлавливает все ошибки, в то время как при проверке основной конфигурации отрабатывает корректно. Сталкивался с этим при переходе с ERP 2.2 на 2.4 c обновлением БСП.

    Reply
  8. kozlov.alians

    Да, механизм расширений имеет некоторые недостатки, но в любом из таких случаев мы можем поступить двумя методами:

    — отказаться от использования;

    — что-нибудь придумать.

    Не плохой вариант использовать АПК (автоматическая проверка конфигураций). Для каждой такой доработки создать правило, по которому можно проверить контрольную сумму исходной и обновленной процедуры/функции. Для скорости определить настройки проверки, где указать только нужные объекты конфигурации и только нужные правила. Тогда после обновления в отчете мы увидим какие из таких «опасных» процедур были изменены.

    Да, при этом останется риск, что кто-то забудет это сделать, но это уже организационный вопрос.

    P.S. Расширения динамично развиваются, так что есть вероятность, что и этот недуг будет скоро побежден. Думаю отличный повод написать на партнерский форум.

    Reply
  9. kozlov.alians

    (10)

    если АПК уже умеет работать с расширениями

    умеет.

    Хотелось бы увидеть пример реализации ))

    Почему бы и нет, думаю тема будет интересной, можно написать статью. 🙂

    Reply
  10. HAMMER_59

    //+ Некоторый комментарий

    // Операция.Подразделение КАК ПодразделениеДт,

    | Операция.Подразделение КАК ПодразделениеДт,

    //- Некоторый комментраий

    | РеализацияТоваровУслугТовары.ИС_Подразделение КАК ПодразделениеДт,

    Какой интересный запрос.

    Reply
  11. SanchoD

    (6) У меня расширения просто игнорируются при запуске базы, если в них какие-то рассогласования с новым релизом. Ни разу база не падала. Максимум появлялась ошибка при каких-либо манипуляциях с объектом, функционал по которому вынесен в расширение.

    Reply
  12. kozlov.alians

    (12) Благодарю.

    Reply
  13. the1

    Я в таких случаях использую конструкцию &После (вместо &Вместо))))

    Пусть конфигурация сделает все по-своему, а уж расширение что-то доделает по-своему, а что-то переиначит в результатах работы конфигурации. Да, производительность пострадает, зато совместимость выиграет.

    Reply
  14. Tavalik

    А потом вы обновляетесь на 2.4.6 и внезапно обнаруживаете, что тексты движения запросов в регистры поменялись чуть более, чем полностью, а текстов запросов для формирования проводок больше НЕТ в модуле менеджера документа. Вам, по ходу, это еще предстоит пройти )

    А по вашему методу, будет отрабатывать старый, не актуальный текст запроса, так же как и с проводками.

    Поэтому, мы все же делаем вставки в типовой код, хоть это и ведет к усложнению обновления.

    Но за статью спасибо.

    Reply
  15. Lukich66

    Только начал осваивать Ка2 и чем дальше,тем интереснее. А тут сразу доработать движения регламентированного учета? Т.е фирма 1с уже все новые вещи выпускает недоделанными, а для тех кому хоцтса- расширения? М-да-а-а.

    Reply
  16. artfa

    (4) и я того же мнения, если расширение, то при каждом обновлении нужно будет отслеживать изменения в коде конфы, тогда как если изменения в самой конфе, при обновлении их сразу увидишь.

    Расширение, очень любят клиенты, мол конфа на поддержке, обновим сами, ага, обрадовались, как только изменения коснутся расширения, то база либо упадет, либо ещё хуже, расширение будет работать, но не правильно.

    Reply
  17. katenok86

    (16)А куда они делись? Еще не обновляли ни кого на 2.4.6

    Reply
  18. Tavalik

    (19)

    Вынесли в общие модули.

    Reply
  19. ikolegov

    (16) Только что с превеликим трудом почти перешли с 2.1 на 2.4.5 (конфа сильно переписана). Хотите сказать, что и переход на 2.4.6 будет мучительным?

    Reply
  20. Alexjas25

    (16)Виталий, ну комментарий Ивана про АПК и отдельное правило для данной функции как раз об этом. После обновления автоматическая проверка сразу оповестит, что «что-то пошло не так».

    Без АПК, конечно, это будет сложно отловить.

    Reply
  21. user619273_alevtina

    Хорошая статья, актуальная

    Reply
  22. TimurD

    Использование расширений вещь соблазнительная, но не без изъянов. По моему мнению, гемора с расширениями меньше, чем с доработки на живой базе. Вот пару пунктов при обновлении:

    1. Найти и сравнить все &Вместо (а если Вы ведете тех. документацию по изменениям… Вы человек?) через тот же KDiff 3 или другие приложения. CTRL+V CTRL+C.

    2. С формами сложнее. Сам недавно столкнулся в УТ 11, что форма была взята из основной конфы (на расширение забило). Но все же. Если требуется ДОБАВИТЬ новые элементы формы, то лучше это сделать через МодификацииКонфигурации. А обработчики элементов описать в расширяемой форме (а когда можно будет указывать Общий клиентский модуль в действии, в качестве источника процедуры (как ОписаниеОповещения), тогда форму в расширении не будет нужды заимствовать). Да, я сам так еще не делал, но при случае обязательно так сделаю). Если у нас не предусматривается особых обработчиков элементов, тогда и заимствовать форму не нужно.

    P.S.: Как-то в одной организации (при переходе с ПУБ 7.7 на Бух 3.0) рабочий коллектив отказался использовать расширения (вообще). Я написал по собственному.

    Reply
  23. ellavs

    Давно начали пользоваться механизмом расширений. Штука крайне удобная для дополнения логики типовой конфигурации. Однако иногда требует доработки при обновлении конфигурации (но не всегда, а при существенных изменениях в расширяемых компонентах).

    Одно замечание: к Вашему лирическому отступлению добавила бы: не вносить изменения непосредственно в конструкторе форм, а делать это только в коде. Т.е. если надо добавить что-то на форму, добавлять не через конструктор — типа «добавить группу/надпись/…», а коде (например, при открытии формы).

    Поясню, почему мы пришли к такому правилу. При обновлении конфигурации несколько раз сталкивались с ситуацией, когда разработчики так меняли форму, что автообновление не срабатывало и приходилось воссоздавать расширение «с нуля» на новом релизе. Когда у Вас в расширении только код — это делается за пару минут, а когда надо еще воссоздать элементы на форме в конструкторе — это уже ведет к вероятным ошибкам — можно что-то забыть/пропустить. Или же нужно заранее это подробно документировать, чтобы можно было легко воспроизвести.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *