<?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='\
Отличая от «подситемы УПП» 😉 только в периодичности и галочке использовать… Так что похоже на плагиат…
Я извиняюсь.
Пока не будем касаться качества составления запроса в Вашем модуле.
Но в теме явно не хватает обоснования такого подхода.
В каких случаях по-Вашему стоит пойти на изменение конфигурации БП ради контроля некорректности проводок . О реализации такого подхода в УПП мне, к сожалению , ничего неизвестно.
Опять же не касаясь подробностей реализации , не кажется ли Вам что функционально следует добавить включение/выключение контроля некорректности проводок. Если количество записей в модуле набора очень велико (ВводОстатков) , то разумнее отключить этот контроль.
(3) Ish_2, а что Вам не понравилось в запросе? Неужели можно реализовать как то лучше, оптимальнее? Критика и конструктивное обсуждение — это ценно среди коллег (специалистов). Жду Ваши замечания на тему запроса. И буду за них благодарен (если они появятся, конечно).
Включение/выключение контроля можно сделать настройкой пользователя, а в процедуре при невключенной опции, просто не проверять ничего. Я не реализовывал это, при необходимости сделайте сами.
(3) Изучите продукт, а потом кричите большими буквами. 😎
идем в настройки пользователя и видим контроль корреспонденции счетов.
(4) Про запрос — потом.
Всё-таки хотелось услышать обоснование такого подхода к контролю некорректных проводок. Предлагая пользователю изменение конфигурации, необходимо как-то минимально обосновать это деяние.
На мой взгляд , введение флага включения/выключения контроля функционально совершенно необходимо. Следовательно , нужны допонительные изменения в конфигурации для хранения этого флага.
(5) Ну да, пользователя в УПП …что спросили (и он ответил Ок). И влетела проводка Дт60.1 Кт41.1 — см. картинку 🙂
Я показал механизм БЛОКИРОВАНИЯ некорректных корреспонденций. Задача из реальной жизни возникла — и оказалась очень полезной в бухгалтерии (не я ее придумывал).
В дополнение к (7) перед тем как …я не забыл включить контроль 🙂
(6) хотелось бы увидеть конструктивную критику запроса, если она у Вас есть 😉
(9) Я , к сожалению, не знаю УПП. И насколько понял отличие Вашей подсистемы именно в том , что она именно БЛОКИРУЕТ некорректные проводки. И необходимо прямо в модуль НабораЗаписей передавать значение флага . Вы не видите здесь дополнительных затруднений ?
Теперь по тексту запроса.
Итак , Вы хотите соединить две таблицы левым соединением.
Вначале рассмотрим условие соединения.
Две таблицы 1.Ткор- текущие записываемые корреспонденции набора записей
2. ТНеКорр — регистр свелений некорректных проводок
Показать
Левое Соединение по такому условию смотрится затратным.
В условиях соединения лучше избегать фильтрации одной из таблиц.
Условие соединения должно быть максимально простым и коротким
(чтобы оптимизатор запроса использовал только индексы для выборки нужных записей).
Конкретно это означает :
Правдами и неправдами избавится от сложных конструкций в условии соединения (не понятных оптимизатору) .
ТНеКорр должна быть не таблица регистра , а временная таблица полученная дополнителным запросом (отфильтрованная)
Согласитесь симпатичнее смотрится условие соединения
ПО ТКор.СчетДт = ТНеКорр.СчетДт
И ТКор.СчетКт = ТНеКорр.СчетКт
И ТКор.ПериодЗаписи >= ТНеКорр.ДатаНачалаДействия
И ТКор.ПериодЗаписи <= ТНеКорр.ДатаОкончанияДействия
ТНеКорр — это временная таблицы полученная из регистра сведений с фильтром Использование = Истина и преобразованными колонками ДатаНачалаДействия и ДатаКонцаДействия
(11) соединять с отфильтрованной временной таблицей из регистра сведений, действительно лучше (и я об этом знаю). По решаемой задаче блокируемых проводок мало, поэтому я и не стал этого делать.
Спасибо, коллега!
(12) Желательно пользователей предупредить , что при большом количестве проводок будут наблюдаться жестокие тормоза.
И это еще не все .
Ваша цель найти и отобразить ТОЛЬКО некорректные проводки.
У Вас две таблицы ТКор с корреспонденциями и ТНеКорр — с некорректными проводками. Зачем мы применяем левое соединение ТКор с ТНеКорр , в результате которого в выходную таблицу попадают ВСЕ записи таблицы ТКор ? Правильнее и гораздо эффективнее применить внутреннее соединение , в результате которого в выходную таблицу попадут ТОЛЬКО нужные записи .
сделать неправильно можно тысячью способов. сделать правильно — способов гораздо меньше. Описать правильные проводки — это правильно! — это порядок на фирме, это учетная политика и т.д. Так что (5) — бооольшой плюс.
(14) Чего-то ты того .. Не разобрался.
Речь шла о том , плагиат это или не плагиат ? Это не плагиат.
Обвинение должно быть снято.
Забирай своой «Бооольшой плюс» для (5) обратно.
(13) внутреннее соединение — это будет правильнее, безусловно согласен.
…ну и, наверное, тогда еще и индексы стоит расставить на поля временных таблиц, по которым будет проходить соединение.
Еще раз СПАСИБО за грамотную методическую поддержку, коллега.
блин я не пойму. чем список некорртекнтых проводок лучше списка корректных проводок?
(17) Сергей, разница здесь такая:
1. корректные проводки — это то, что МОЖНО. И если в этом списке не окажется чего то что нужно сделать, то или будет ненужная блокировка неизвестной (еще) проводки или пользователь сам принимает решение (что эти проводки можно) или надо ждать пока глав.бух добавит в список новую корректную проводки и только тогда можно будет провести документ.
в моем примере для Германа на скриншотах я как раз и смоделировал такую ситуацию… программа контролирует, но то, что простой бух сам для себя решает правильным… и такой контроль это уже не контроль.
А особенно если сеть филиальная, да еще и распределенная 😉 концы найдешь, но исправлять замучаешься. Это жизнь…
2. некорректные проводки — это список запрещенных проводок. Те которые всю жизнь использовали (и привыкли к ним), а теперь новый глав.бух их может запретить! и программист должен ему помочь в таком механизме БЛОКИРОВАНИЯ НЕПРАВИЛЬНЫХ ПРОВОДОК.
Итог: корректные — это правила, на которые пользователь опирается и может их «по ходу пьесы» расширять, а Некорректные (запрещенные) — это те, которые пользователь не сможет сделать никогда (даже если рука «по привычке» потянется к таким корреспонденциям). Такой механизм может быть полезен для больших (огромных) организаций, для маленьких, наверное, это проще решить на организационном уровне (и здесь ты абсолютно прав).
(0) Работа с бух.регистром и так не слишком быстрая, а после введения подобной системы производительность может еще сильнее упасть.
Производительность решения тестировал ?
Если тестировал, то каким образом?
Жду ответов.
(19) контроль выполняется перед записью, и скорее всего на производительность не влияет.
Замеров не делал, было некогда, а визуально для пользователя после реализации ничего не изменилось, все летает как и раньше.. Это хорошая мысль — надо померить! Сделать групповое перепроведение и сравнить оба варианта: С… и БЕЗ…
Спасибо.
(18)
.
Андрей, твое решение — это «затычка» от «реальной тупизны» — это хорошо. Если главбух может их запретить — то почему не может их «запретить» для себя сам пользователь? — потому что привык?
.
И С КАКОГО БУДУНА ___пользователь____ (т.е. рядовой оператор или бух) МОЖЕТ РАСШИРИТЬ СПИСОК КОРРЕКТНЫХ ПРОВОДОК??? расширение корректных проводок — это исключительно преррогатива ВЗУ/ЛПР — это должно быть установлено «учетной политикой». И если учетную политику может менять ПОЛЬЗОВАТЕЛЬ — то про что говорить? (это типа как торговля оптом в конторе идет, а рядовой.бух принимает решение поторговать в розницу).
.
ну запретит сегодня главбух «некорректную» проводку какую-нибудь, ну завтра пользователь набабахает новую некорректную… тупо если приянть что 100 счетов в плане счетов и счет можеть стоять в Д или К — то получим 10 тыс возможных корреспонденций. Подмножество ПРАВИЛЬНЫХ проводок — гораздо меньше подмножества неправильных проводок.
.
и если вдруг буху действительно понадобилось сделать «нестандартную» проводку — то не ГБ должен потом искать — какие там неправильные проводки у меня бухи сделали чтобы я мог их запретить, а бух, которому нужна нестандартная/неправильная проводка — бежит к главбуху и обосновывает необходимость — и ГБ либо пошлет НА! либо сделает сам (так есть права), либо внесет проводку в список разрешенных…
.
а то эта схема работы с «неправильными проводками» напоминает по типу «не знаем, чем больной болеет — давайте полечим от всего подряд» — тут или больной от лечения загнется или стоимость такого лечения будет астрономической.
.
так что СУЩЕСТВЕННЫМ имхо в описании обработки будет сказать — данная схема применима там, где в организации бардак и ни у кого не доходят руки до настройки/постановки учета. Тогда да — разработка будет на своем месте и востребована.
.
конечно было бы хорошо чтобы на эту тему высказался реально практикующий ГБ. У меня такой есть — я на неделе постараюсь изложить концепцию по типу «что правильно: составлять список неправильных проводок или составить список правильных проводок»… — возможно моя точка зрения и неправа…
(21) я даже не знаю как лучше… Все сильно зависит от организации и ее людей, ты прав.
Проводки (все возможные) можно поделить на 3 категории:
1. Правильные (все хорошо, проводить)
2. Запрещенные (точно нельзя, блокировать)
3 Новые (еще неизвестные системе) — тут наверное решение принимает пользователь, с авто-уведомлением ГлавБуха…
Нам, программистам, ставят задачи — мы их решаем (и так как их просят решить). Мне была поставлена задача — блокировать некоторые корреспонденции (их мало, но которые определены как некорректные).
Ага, и о любом чихе в пару строк надо обязательно оповестить инфостарт десятком скриншитов. 😀
на (23) — это личное, со стороны этой (безусловно очаровательной) девушки. Она меня преследует 🙂 и везде пишет «не совсем» по теме 🙂 Я не знаю, что делать… 🙂 А игнорировать или послать нельзя (девочек не обижают, тем более хороших).
Лариса, да, вот такой я нехороший — взял и написал тему, и даже выложил реализацию механизма (может и не нужного, но полезного кому то).
Лариса, могу дать совет: Не надо читать мои темы, не надо заходить на мою страницу в одноклассниках, не писать комментарии к моим глупостям на Инфостарте… все просто! Мне такое безразличие станет невыносимо и я анрегистрируюсь с ИнфоСтарта. (не обижайся)
(21) Тактичный Чебур не сделал контрольного выстрела.
Т.е. не сделал завершающего вывода : (Да , простит меня автор)
Если с точки зрения учета правильнее использовать возможности типовой конфигурации по контролю корректности проводок , то представленная система «Некорректные проводки» не только бесполезна для пользователей , но и может принести им серьезные проблемы .
(24) Мне фиолетово твоя личность, мне не нравится твое отношение к читателям инфостарта (активные нулевисты и пр.).
Ты начал свою пиар-компанию со стыренной и, выданной за свою, идеи, это уже обсуждалось. После чего моя симпатия по-дефолту ко всем новичкам, улетучилась.
В одноклассники пришлось сходить, чтобы выяснить масштаб личности, после чего личность была помещена в черный список.
Советы мне давать не надо, я сама решаю, где мне писать, а где нет, если тема обсуждается в прямом эфире.
(26) Мне наплевать, что вы обо мне думаете. Я о вас не думаю вообще. (Коко Шанель)
(25) спасибо за участие в обсуждении — оказалось очень полезным (завтра обсудим с Заказчиком эту тему).
(27) Ну в принципе, ничего другого ожидать и не приходится, кроме цитат и копипаста, свои мысли — удел не каждого. 😉
(7) ну если пользователь имеет права на запись в регистр корректных проводок то тут никакого ограничения быть и не может… см роль Настрока НСИ (рег) 😉
Для larisab: Считаю, что не все программисты одинаково «сильны», поэтому любое законченное (или даже незаконченное) решение может быть размещено на тематическом портале.
Возможно кому то поможет или натолкнет на идею. В конце концов, можно всегда поставить «Злобный минус» (желательно обосновать)
А по сабжу: Согласен с German — типового механизма на мой взгляд, вполне достаточно.
(30) Заказчик сегодня четко обозначил, что типового функционала (при его ситуации) не достаточно, необходимо обеспечить блокирование некоторых проводок.
ИМХО, тут весь дискусс свёлся не столько к самой разработке, сколько, подспудно, к профессионализму ГБ и порядку в бухгалтерии её запросившей.
«Если звёзды зажигают, значит, это кому-то нужно».
Если исходить, что данная надстройка была написана под нужды конкретного буха, то она имеет место быть.
Как бух-практик, давно занимающийся бухгалтерией: мне бы и в голову не пришло попросить написать разработку запрета НЕкорректных проводок, учитывая, что в программе уже есть перечень корректных проводок. Однако, не удивит, что кто-то из бухов эту надстройку скачает и будет благодарен разработчику.
P.S. форум мониторю давно, но высказываюсь впервые.
(32) спасибо за Ваше мнение — во многом с Вами согласен. Очень понравилось Ваша цитата :), без привязок к личностям
Если запрет действует, когда бух проводит документ — это ЛОЛ.
Если всё это ради возни в ручных проводках — флаг им в руки.
20.11.2009 добавил текст основной процедуры — там заменен запрос на более оптимальный (за что спасибо Игорю Исхакову за его комментарии под ником Ish_2)
Достаточно в картинке из поста 8 поменять местами корреспонденцию и поменять знак суммы и все запреты отправляются лесом.
(36) плохо быть таким невнимательным 🙂
на рисунке в посте №8 показано, как в типовой …УПП (не в Бухгалтерии предприятии, о которой идет вообще то здесь речь) обойти механизм (о котором писал Герман), контролирующий корректность проводок.
в (34) «…Если запрет действует, когда бух проводит документ — это ЛОЛ…»
ЛОЛ — это что такое? думаю многим, не очень понятно ЧТО ты имел ввиду 🙂
Может быть я невнимателен в номере картинки, но сделать нужные мне движения при запрете я могу. Механизм с дырой.
(39) ты можешь сделать при запрете нужные тебе движения ГДЕ?
…в типовом механизме контроля корректности проводок в УПП (то что изображено на рисунке в посте №8)?
…или ты «нашел дыру» в механизме блокирования некорректных проводок (который я представил)?
Научись ясно выражать свои мысли, для начала… 🙂
Программист пишет обычно также как думает — …ты опасный (для Заказчика) программист 🙂
Замеры производительности, получилось сделать пока только в файловом варианте — за работой просто некогда 🙂
Документ ввода остатков материалов ~1500 строк, некорректных проводк 49 штук.
Скрин 1 теста — это первый вариант запроса, первый запуск программы (кеша еще нет).
Замерялась производительность только записи в регистр бухгалтерии. Это всего 6% от всего того, что делается типовое в УПП при записи проводок в регистр.
это тоже самое — но повторно. В этом случае используется кеш. Время на скрине чуть меньше.
4,8%
Сегодня протестил в серверном варианте, скриншот во вложении. Сверху на рисунке первый вариант запроса, снизу второй, «более оптимальный», но на практике он в 3 раза более тормознутый.
Так что все авторитетные заявления по поводу «убивания производительности», «ужасных тормозов для пользователя» …пустое. Я в этом убедился.
Время в секундах при замере производительности (на 1500 строк проводок х 49 некорректных)…. как видно из рисунка 0,02 или 0.06. При том что типовое проведение этого огромного документа в УПП реально ооочень долго выполняется.
(13) «…Желательно пользователей предупредить , что при большом количестве проводок будут наблюдаться жестокие тормоза…..»
Тормозов нет — мнение было ошибочно. Хотелось бы также услышать мнение, почему вариант запроса с внутренним соединением оптимальных таблиц, работает хуже. И рекомендации (может быть) как все-таки получить более высокую производительность на втором запросе.
😀
(44) Чтобы хоть как-то определиться , нужно представить корректное описание эксперимента в виде статьи :
Текст запроса Вариант 1 . Вариант Куканова
Текст запроса Вариант 2 . Вариант Исхакова
Описать тест и привести сравнительные характеристики по поизводительности.
Сделать вывод (или предположение): почему вариант Куканова оказался более производительным в реальном испытании.
Иначе мы будем очень долго препираться : а все ли мы учли ?
Обещаю только одно — буду заинтересованным читателем и ,возможно, оппонентом.
(45) Думаю, для себя я проведу дополнительные эксперименты по вопросам производительности запросов с разными вариантами соединений, с моими друзьями-коллегами. Этот вопрос меня интересует. Если будет интересно можно будет потом обсудить полученные результаты.
На сегодняшний момент оба запроса объективно …не являются «жестокими тормозами» ни в файловом, ни в серверном варианте. Второй вариант не оказался почему то более эффективным. Обсуждения темы исчерпаны. Алгоритм, представленный здесь, использовать можно.
Всем спасибо.
(46) А всё-таки эффектным завершением дискуссии являлась бы статья с аргументацией и опровержением предложений оппонентов.
Где бы и приводились пусть кратко результаты эксперимента.
Читателей будет немного , но будут .
Желательно только предупредить о выходе статьи.
очень хорошие скины и много!
«некорретных» наверное некоррекТных всё же.