<?php // Полная загрузка сервисных книжек, создан 2026-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) anig99,
в публикации методика не описана — мне её «на пальцах» объяснил наш экономист…
конечно правилнее отделный регистр, но слишком затратно)..
По поводу статей — на этом сайте?
Отчет актуальный. Делали подобный но не с таким глубоким анализом. Изменения в конфу не вводили, а разрешили корректировку реквизитов Договора из формы отчета.
Данный отчет особенно актуален потому что заставить сбытовиков работать по документам расчетов практически нереально по двум причинам, разносят деньги не они и даже не бухгалтерия а финслужба и там то все и виснет… ну а сбыт любит работать прошлым периодом (только не говорите про закрытие периода, всегда есть что-то или кто-то архиважный и архипипецвнеправилзапретов)
При попытке открыть, ругается на компоновку данных:
{(20, 20)}: Таблица не найдена «РегистрСведений.АгентыПоДоговорам.СрезПоследних»
ЛЕВОЕ СОЕДИНЕНИЕ <<?>>РегистрСведений.АгентыПоДоговорам.СрезПоследних(&ГраницаКонца, ) КАК АгентыПоДоговорамСрезПоследних
Точно для ред. 10.3? Может с какого то определенного релиза?
(6) Нет в УТ 10.3 никакого релиза такого регистра.
(6) IDija,
мой промах… у меня в конфе это применяется, а сюда я выложил с вырезом этого регистра… но видимо «недовырезал» сейчас исправлю. Кстати в статье текст запроса — верный, можно просто перенести, ну и внастройках отчета убрать упоминание «агента»
При попытке открыть, ругается на компоновку данных:
{(20, 20)}: Таблица не найдена «РегистрСведений.АгентыПоДоговорам.СрезПоследних»
ЛЕВОЕ СОЕДИНЕНИЕ <<?>>РегистрСведений.АгентыПоДоговорам.СрезПоследних(&ГраницаКонца, ) КАК АгентыПоДоговорамСрезПоследних
Точно для ред. 10.3? Может с какого то определенного релиза?
Перезалил файл.
Собственно кидаться какулями не буду.
Просто есть несколько моментов:
— ссылка на описание методики нерабочая (возможно ещё неотмодерировали)
— оптимизация запроса за счет ограничения выборки по времени по дате последнего перехода в минус — это лучше, чем тупое ограничение выборки по общей дате, но всё же далека от цели… В реальности постоянные контрагенты НИКОГДА не оплачивают долг полностью, а только просроченный. Таким образом, оптимизация работать не будет.
— жаль, что привязка только к договорам.
— ознакомьтесь с материалами по теме. Есть мои статьи и отчеты (правда запросы там путаные), есть и другие (лень сейчас искать)
Посмотрел Ваши публикации по поводу оптимизации, «буду курить»,
У меня клиенты достаточно часто оплачивают долг до нуля, иногда даже авансируют… + договора действуют максимум 1 год.
Привязка к договорам — как в мне требовалось. потенциально можно реализовать любую, что есть в регистре.
>> Кстати в статье текст запроса — верный, можно просто перенести, ну и внастройках отчета убрать упоминание «агента».
Вставлял текст запроса, после двух ошибок исправлять далее не захотелось… разочаровывает статья…
(7) тогда не понятен ваш плюс…
(11) IDija, файл уже правильный, его достаточно скачать.
«после двух ошибок исправлять далее не захотелось» — кроме отборов там нет упоминаний об агенте.)
кстати предыдущий файл, тоже правильный только при наличии доп регистра… возможно поздне опишу для чего он нужен…
Пару лет назад ваял на эту тему:
Сейчас вспомнил и добавил с с просрочкой по интервалам:
(14) urbanist, всетаки инфо о доп днях и сумме правильнее брать из договора. а вот решение показывать — по интервалам — красиво. я в свое время исходил из того что отчет должен нормально печататься на а4 и раздаваться менеджерам-селянам (т.е. быть прозрачным и понятным)
(15) Если информацию о доп.днях и суммы брать из договора,то этот отчет не нужен,т.к.эти поля доступны в случае ведения взаиморасчетов «по расчетным документам» и можно обойтсь штатным отчетом.
В случае ведения учета без установки флага «по расчетным документам» без изменения конфигурации(хотелось бы обойтись) число дней не проставить.А отчет сделан как раз для таких ситуаций и реже,где учет по документам установлен,но запущен.
(16) urbanist, про правку — это да…, но по опыту торговлю чаще всего приходится «затачивать»… вот бухию — обычно оставляю в первозданном виде.
ммм, спасибо! интересно и достаточно подробно, добавлю в закладки
Для УТ11 аналогичный отчет: (основная группировка по АналитикеУчетаПоПартнерам)
Спасибо за отчет.
Клиент попросил нечто подобное, только в разрезе клиентов (без учета договора, ибо менеджеры, разносящие банк, часто и договор неправильно указывают). Ну и еще прикрутил к нему интервалы задолженности. Получилось то, что надо!
Правда не понял, что есть поля
НО и КО — если не сложно, опишите.
(20) Stas-ch, НО = Начальный остаток, КО = Конечный остаток, по логике отчета вроде это видно. Если модифицировали — смело выкладывайте, возможно кому-то нужен именно Ваш отчет.
Данный отчет актуален потому что заставить сбытовиков работать по документам расчетов практически нереально по двум причинам, разносят деньги не они и даже не бухгалтерия а финслужба и там то все и виснет…
(16) urbanist, в принципе и без правки можно обойтись… нужно только сделать некую внешнюю обработку в которой будут доступны для записи нужные реквизиты договора… но с правкой — проще.
Мир этому дому!
Статья интересная, возможно скоро воспользуюсь обработкой, но пока взял на заметку. Хочу разобраться с запросами.
Обсуждение похоже затихло…
Однозначно плюс за расписанную процедуру.
Но хочу заметить строить отчет погашая по фифо — очень нерационально. Берем ТЕКУЩИЙ ДОЛГ (+ или — ) и разворотом от сейчас назад по документам-регистратором задолженности. Набераем требуемую сумму — будет в 10 раз быстрее… Тем более если есть задача сохранить «девственность» кода 1С и не использовать для накопления регистры, то зачастую на средней фирме уже через год внешний пересчет всех долгов по ФИФО занимает прилично времени, и блокирует работу…
А пересчет разворотом от сейчас успешно используется со времен 7.7 (здесь примеров полно).
И второе. Количество дней просрочки часто используют для СТОПа отгрузок.
А в случае с задачей оперативного изменения этого параметра, (для — например- предоставления акционных условий в рамках одного договора, на определенный период) использовать параметры отсрочки из «договора» очень неудобно.
Да и при сохранении «девственности» кода 1С лучше использовать свойства объекта(справочник «Контрагенты»).
(25) serge_focus,
Согласен с Вами. А есть соображения как можно сделать эффективнее с использованием регистров?
Общая идея: записи в регистрах (самопальных) фомируются фоновым заданием (скажем ночью), со сдвигом соответствующей последовательности. А в процессе работы производится «склейка» результатов по регистру и остатка по fifo, непосредственно из документов.
Предлагаю другое, гораздо более быстрое решение той же задачи: . Не требующее, к тому же, изменений в конфигурации.
Все это здорово, но вот незадача:
этот отчет и от ildarovichа разные результаты показывают…
или это только у меня одного?
И кстати результаты отчета от ildarovichа более похожи на правду…
(28) Pawlick, у Вас нет документов введенных одной датой и одним времением по одному контрагенту? Всмотритесь в алгоритм: оптимизированный отчет имеет некоторые особенности.
Ошибок в запрос как минимум 2:
1. И (ВЫБОР
КОГДА ДоговорРеализации.ДатаОплаты = ДАТАВРЕМЯ(1, 1, 1, 0, 0, 0)
ТОГДА ВЫБОР
КОГДА ДоговорРеализации.ДатаДокумента = ДоговорРеализацияКО.ДатаДокумента
ТОГДА ДоговорРеализации.Регистратор ИНАЧЕ ДоговорРеализации.ДатаДокумента КОНЕЦ
ИНАЧЕ ВЫБОР
КОГДА ДоговорРеализации.ДатаОплаты = ДоговорРеализацияКО.ДатаОплаты
ТОГДА ДоговорРеализации.Регистратор ИНАЧЕ ДоговорРеализации.ДатаОплаты КОНЕЦ
КОНЕЦ)
2. ГДЕ
ВзаиморасчетыСКонтрагентамиОстаткиИОбороты.СуммаУпрНачальныйОстаток И ВзаиморасчетыСКонтрагентамиОстаткиИОбороты.СуммаУпрКонечныйОстаток > 0
(31) 20tanush, Как-то не очевидно, что в приведенных фрагментах есть ошибки. Логику запроса — вижу, а вот ошибок — нет. Ткните, как говорится, носом.
Да, на вид все вроде очевидно. Но конструктор запроса спотыкается на этих местах.
В 1. конструкция И (Выбор…) Неверные параметры «И»
Во втором: получаю вот такую ошибку: «Операция не разрешена в предложении ГДЕ
Уважаемый автор! Я прошу прощения, что все время вроде как нахожу ошибки. Но вот в третьем запросе, кроме реализаций попадают еще и платежки исходящие. Думаю, тут надо еще условие поставить, потому что платежки вроде не нужны. Поправьте меня, если я ошибаюсь.
(33) 20tanush, во втором случае следует читать ВзаиморасчетыСКонтрагентамиОстаткиИОбороты.СуммаУпрНачальныйОстаток <=0 И ВзаиморасчетыСКонтрагентамиОстаткиИОбороты.СуммаУпрКонечныйОстаток > 0,
Видимо «<=» — «съел» редактор, в самом тексте обработки все в порядке. В основном тексте — это уже исправлено. Спасибо.
Актуальный и доходчивый алгоритм. Хотя быстрее в 3 раза.
Вопрос к автору или тем кто скачал. (Конфигурация УТ 10.3)
1.Тут как-то возвраты учитываются?
2.Если да, то если в документе ВозвратОтПокупателя в табличной части указан документ РеализацияТоваровиУслуг по которому был Возврат, то будет ли это учитываться как уменьшение долга по указанной Реализации? Или все возвраты учитываются как погашение самого старого долга?
(37) Возвраты учитываются как уменьшение суммы долга контрагента по конкретному договору (не по реализации, которая указана в ТЧ возврата)
здесь учитывается ввод начальных остатков: Расчеты с покупателями и заказчиками (счета 1210, 3510)?