<?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='\
(0) 1. А это правильно, что в первом запросе «Остатки(&Дата, …», а во втором «ВзаиморасчетыСКонтрагентами.Обороты( , &Дата, «? Что будет, если будут обороты в момент &Дата?
2. Зачем во втором запросе «.Обороты» да еще и с периодичностью «Регистратор»? Не проще было прямо из движений их сформировать? Просто если посмотреть SQL-запрос, который при этим возникает, то он способен сбить с толку оптимизатор SQL.
(1) Спасибо за вопросы и замечания. Действительно, отчет совсем свежий и неточности еще могут быть. Уверен, определенный «тюнинг» запросу еще нужен.
1) Вопрос в голове был. Я действительно не проверил. Показалось, что конечный остаток с параметром 0:00:00 учитывает обороты в момент 0:00:00, а брал просто остаток. Проверю — исправлю (уже исправил! — взял остаток на следующую секунду — так кажется логичнее, если ищем отгрузки).
2) Думал про движения, но мне нужно было простым способом отобрать именно «отгрузки». Я решил, что считать отгрузкой удобнее всего факт, когда по документу в целом (регистратору) будет «плюс» долга. То есть расчет на случай, когда в документе несколько разнонаправленных движений по регистру. Возможно, в целевой конфигурации такого в этом регистре никогда не бывает, тогда действительно можно взять движения.
Добавил отчет «Просроченные долги». Изменился только последний запрос — потребовалось ввести несколько дополнительных полей. Допустимое число дней задолженности хранится в соответствующем реквизите договора контрагента независимо от установленной галочки «Контролировать число дней задолженности». Реквизит оказывается в отчете и меняется прямо из отчета как показано на скриншоте.
Да, предварительно делайте выборку по договору/складу (отбирая с остатком <> 0) и фильтруйте по этим данным, иначе в обработку попадут лишние данные, а в целом работает очень шустро
(4) Насколько я понял, Вы привели вариант реализация общеизвестного метода. Его основная отличительная особенность — соединение таблицы оборотов самой с собой по условию
Такое соединение называется «тэта-соединением». Оно приводит к тому, что в результате в выборке до группировки оказывается N#k8SjZc9Dxk2/2 строчек, где N — число документов по одному договору в рассматриваемом периоде. Это значит, что если у Вас 100 документов отгрузки, то потребуется просуммировать 5000 строчек, а если 1000 документов отгрузки, то 500000. Эта нелинейная квадратичная зависимость и невозможность ограничить интервал снизу приводит к тому, что со временем производительность отчета быстро деградирует. Это реальная проблема. В больших торговых организациях отчет может работать десятки минут и часы. Возможно, в Вашей организации нет контрагентов с большим количеством отгрузок по одному договору и эта проблема не чувствуется.
Мне долгое время казалось, что для реляционных СУБД — это неизбежность и сделать ничего нельзя, а при желании ускорить отчет нужно считать нарастающий итог в коде или в СКД или сворачивать базу. Относительно недавно удалось преодолеть квадратичную зависимость и снизить ее до линейной (метод «Баттерфляй»). Подобный подход применен и здесь: повторением большого количества очень простых запросов, не требующих самосоединения оборотов, удалось создать метод, время работы которого не квадратично, а ЛИНЕЙНО зависит от числа отгрузок по одному договору. Это актуально для больших организаций — не нужно ничего «сворачивать», чтобы отчеты работали с нормальной скоростью.
То есть это совершенно новый по алгоритму метод, отличающийся от всех известных, основное отличие которого — высокая скорость работы на больших базах.
Достойная публикация.
(6)»Мне долгое время казалось, что для реляционных СУБД — это неизбежность и сделать ничего нельзя». С полноценным, необрезанным TSQL и CTE — что нарастающий итог, что «глубина долга» решаются достаточно хорошо — быстро работает, лаконично, понятно.
А вот, кстати, LIFO — очень и очень непросто. Лет 7 назад я написал LIFO без курсоров на чистом TSQL, но после первой возникшей необходимости исправления, переписал на курсоры, чтобы можно было кому-нибудь объяснить, как это работает без бочки коньяка. Курсором, кстати, работает медленно, но линейно от количества записей.
(8) Есть сомнения, что оконные функции входят в стандарт T-SQL. Думаю, что когда стандарт расширяется, у каждого нововведения есть и сторонники и противники. А то, что эти функции реализованы в нескольких коммерческих СУБД и востребованы может быть еще недостаточно, если они противоречат каким-либо базовым принципам.
Говоря о реляционных СУБД я имел ввиду не какую-то конкретную СУБД, а принципы реляционной алгебры. Так вот, с этой точки зрения не то, чтобы оконные функции, а даже конструкция ORDER BY не является частью реляционной алгебры.
На стр.194 в строке 26 книги «SQL и реляционная алгебра» читаем
В связи этим считаю, что приведенное решение опирается на более глубокие и устойчивые фундаментальные принципы и должно получить свою область применения.
То есть Вы агитируете за то, чтобы использовать для готовки аэрогриль, например, а я говорю о том, что не на любом необитаемом острове он есть и нужно знать и более доступные рецепты. Хотя вообще я не против прогресса.
(9)
Если говорить про стандарты, то CTE вошли в SQL-99, оконные функции вошли в SQL-2003. В MS SQL начали появляться в 2005-м и 2008-м, но с некоторыми ограничениями. LAG и LEAD, которые есть в оракле и в MSSQL2012 кажется пока еще не в стандарте (а мощные функции, кстати).
А если говорить про реляционную модель, то тут же надо делать кучу оговорок:
Я прекрасно понимаю, что вы говорите, но если говорить об инструментах, то эффективные инструменты есть. А если говорить о теории, то тут надо подходить шире и не ограничиваться реляционной моделью (хотя бы потому, что она ничего не утверждает про производительность)
Все классно работает и быстро! Благодарю и уважаю.
(10) Спасибо за информацию про стандарты и функции. Возьму на заметку.
1) 2) 3) — согласен со всем этим.
Да, эффективные инструменты есть. Решая конкретную задачу, не стал бы отметать доступные инструменты, просто порадовался, что все «летает» и пошел бы дальше. Например, в статье «Опять двойка» в случае с использованием ЗаписьXML (Ваша находка) для быстрой конкатенации строк я явно попал впросак, просто не найдя этой возможности. Но тут пока оконных функций в запросах не появилось. И не думаю, что это в приоритетах у 1С. И может подойти данный метод.
Что же касается теории — можно было бы попытаться копнуть глубже, но кто это сейчас оценит? Тем более, кажется, что такого рода приемы должны были (не стал проверять) в свое время запатентованы как схемотехнические решения для построения быстродействующих АЦП, сумматоров и прочее (В IEEE Transactions нужно покопаться). То есть теоретическим изысканиям должны предшествовать обоснования новизны, а я в ней не уверен.
Интересны способ.
Но если отойти от чистой теории и спустится к тому что имеем на практике, т.е. 1С.
Надо вспомнить что для оптимизации 1С хранит итоги за месяц. Не будет ли эффективней механизм если будет опираться на эти итоги?
(13)
Вообще Вы правы.Но ускорение, которого можно добиться таким образом, не столь значительно, как может показаться на первый взгляд. Дело в том, что всего через примерно девять (меньше трети) делений, метод выходит на уровень, на котором интервал неопределенности меньше месяца, где итоги уже не работают. Оптимизировать можно первые девять делений. Я не стал усложнять запрос ради относительно небольшого выигрыша в 30 %. Причем этот максимальный выигрыш будет достигаться только когда месяцев существенно меньше чем документов.Но это вполне можно сделать. Нужно только добавить таблицу еще и месячных оборотов и первые деления делать по ней. В том случае, когда мы начинаем не с 17 лет, а, например, с трех лет (когда долги, по идее списываются), выигрыш будет только 20%.…
На этом пути есть одна «засада», на которую я уже натыкался, а сейчас забыл. Итоги хранят суммы всех движений, а для работы метода нужно выделять из них только «отгрузки», а они — не всегда «приход», а иногда «расход» с минусом.
Очень интересное решение, очень.
Золотые слова, ildarovich, золотые слова…
Подскажите, Шаг134217728 будет выглядеть так?
Показать
(16) Да, в точности так!
Коллеги, ваш интеллект потрясает, респект.
Я вообще ничего не понял из вашей дискуссии )
На базе УПП объемом порядка 80Гб отчет выполняется по 60 счету 32сек. а по накоплению итогов у меня шуршало минут 10 в среднем.
Как-будто еще одна особенность отчета есть: если в момент возникновения долга была переплата (аванс), то сумма просроченного долга считается неверно (в нее добавляется сумма аванса).
(20) У меня эта ситуация не воспроизводится. Но, возможно, такая ошибка была в самой первой версии размещенного отчета, которая была сразу же исправлена. Сейчас везде проверяется, что по регистратору
Поэтому суммы аванса в отчет попасть никак не могут. Попробуйте использовать последние версии отчетов.
А есть версия кредиторской задолженности?
(22) distorshion, если разговор о УТ 10.3, УПП 1.3 или КА, то сделать ничего не стоит — нужно поменять знаки в трех местах. Например,
поменять на
-Остатки.СуммаВзаиморасчетовОстаток КАК Долг
И в таком же количестве мест перевернуть условия. Например,
поменять на
Остатки.СуммаВзаиморасчетовОстаток < 0
Ну и протестировать, конечно.
Спасибо!!!!! Мегареспект тебе добрый человек.
(0) как много я пропустил ваших статей! (январь, февраль 2014)
плюс за идею
плюс за реализацию
круто
Все таки по моему отчет имеет одну особенность.
Я провел рад экспериментов, и вот что выяснил:
Завожу нового контрагента (для чистоты экперимента).
Далее:
Реализация — ПКО — Возврат товаров — РКО
, где СуммаРеализации > СуммыПКО И СуммаВозврата < СуммыПКО И СуммаВозврата > СуммыРКО
В отчет по какой то причине не попадает сумма РКО (сумма возврата ДС)
Сначала я решил, что просто не учитываются суммы возвратов денежных средств покупателям (возможно потому, что «Обороты.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг»)
Но потом ввел еще один такой же комплект документов:
Реализация_2 — ПКО_2 — ВозвратТоваров_2 — РКО_2,
и в отчете не учитывается уже сумма РКО_2, а сумма РКО — учитывается !
Тогда я решил, что это происходит тогда, когда последним регистратором ВзаиморасчетовСКонтрагентами по договору идет РКО с видом операции «Возврат ДС покупателю»: документ, который делает запись с видом движения «Расход» и отрицательным знаком. Но покопавшись глубже выяснил вот что:
1. Снимаю проведение со «второго комплекта» документов (проведенными остаются только Реализация-ПКО-ВозвратТоваров-РКО). Сумма РКО в отчет не попадает;
2. Провожу Реализацию_2. Сумма РКО в отчет не попадает;
3. Провожу ПКО_2, и… ОП! Сумма РКО попала в отчет!
4. Провожу ВозвратТоваров_2: сумма РКО в отчете.
5. Провожу РКО_2: сумма РКО по прежнему в отчете, а вот суммы РКО_2 — нет!
PS. Если кинете в личку адрес почты скину Вам УТ10 в которой смоделирована ситуация.
В(26) Pawlick,
ildarovich, все, вопрос закрыт. Ошибка не подтвердилась.
Простите бога ради за некорректную информацию и беспокойство.
(27) Pawlick, да не за что. — Я как раз за максимально критичное и недоверчивое отношение. Дополнительная проверка лишней никогда не бывает.
Я никогда не смотрел на решение таких задач со стороны математики, и поэтому офигел от написанного.
Автору огромное спасибо за отчет! Переписал его для складских остатков в своем УПП, получилась просто бомба! Потрясающее решение! Отчет по дебиторке хотелось бы для БП 2.0, может быть кто нибудь перепишет?
В обсуждении не заметил, но..
Неправильно отображается сумма долга по документам в следующей ситуации: есть предоплата, последующая отгрузка проведена двумя документами в одно время (бывает и такое…). Сумма долга распределяется на два этих документа, хотя, по идее должен отображаться одни. А в остальном супер.
(31) sam0511, как говорится, «это не баг — это фича». — Так и было задумано и я готов настаивать на том, что такое решение правильнее, чем отнесение оплаты на один из выбираемых случайно (на основе GUID) документов-односекундников. Потому, что пользователь не влияет на выбор оплачиваемого документа, а время у них одинаковое. Получается, что отчет при этом (при общепринятом подходе) ведет себя непредсказуемо, а этого быть не должно. Захотят поправить — передвинут нужный документ на секунду вперед.В статье об этом написано (где про ложку сахара).
Скажите пожалуйста могу ли в вашем варианте получить в отчете какой документ каким был оплачен ?
Т.е. чтобы увидеть с какой реальной отсрочкой платил клиент ?
(32) » «это не баг — это фича». — Так и было задумано и я готов настаивать на том, что такое решение правильнее, чем отнесение оплаты на один из выбираемых случайно (на основе GUID) документов-односекундников.»
Ну фича, не фича, но не баг так это точно. Нет никакой разницы на один или на два документа размазать. Тем более что в задаче дебиторской задолженности можно было округлить время документа до суток, а не до секунд.
(33) ZLENKO.PRO, нет, к сожалению.
Это немного другая и чуть более сложная по математике задача. Связывание оплаты с отгрузками (или приходов товара с расходами) по ФИФО запросом. В принципе, в статье показано, что первую часть этой задачи тоже можно решить за время, пропорциональное числу документов. Сейчас, кстати, у меня есть более легкая версия этого запроса. А также у меня есть решение второй половины этой задачи (связывание по ФИФО запросом). То есть быстрое решение запросом задачи 7 из статьи . Но пока массового интереса к этой теме не видно, поэтому с публикацией не тороплюсь.
(35) «Но пока массового интереса к этой теме не видно, поэтому с публикацией не тороплюсь.»
Массовый интерес может вызвать разве что какая нить доработка документа Счет-фактура 🙂
Кстати в задача 7 жаль что два года назад не попалось решение.
Сломал мозг пока написал распределение оплат и отгрузок в цикле 🙁
Получались проблемы с нераспределенными «хвостами»..
(0) спасибо за идею. На основе отчета реализовал поиск не зачтенных авансов. Т.е. мне надо было по ФИФО найти документ оплаты с которого возникает аванс.
Работает быстро. НО … при различных отборах разные суммы по одному и тому же контрагенту. По документу Корректировка долга.
(38) sea123, если подробнее опишете ситуацию, чтобы можно было воспроизвести, то буду разбираться. — Что за отборы? Возможно, отборами вы сами исключаете документы, которые должны влиять на остаток. Вот он и меняется. Попробуйте какой-либо другой (медленный) отчет, делающий то же самое. Не будет ли такого же эффекта и там?
Автор а не пробовали разбиение делать не фифти фифти а дветрети к одной трети и одна треь ближе к коцу периода
Такой вариант по идее должен существенно увеличить скорость
(40) CheBurator, нет, это не так. Метод золотого сечения и метод дихотомии довольно часто путают, но это разные методы — у каждого свои условия применения. Метод золотого сечения используется при поиске минимума (максимума) унимодальной функции. Один замер там не позволяет решить, где дальше искать — нужно обязательно два замера (располагающихся по золотому сечению), чтобы сравнить значения в двух точках и выбрать новый, меньший интервал неопределенности.
В нашем случае для определения нового интервала неопределенности достаточно одного замера — поэтому и используется дихотомия.
— Но, с другой стороны, зная закон распределения вероятностей числа дней просрочки, можно делить интервал в соответствии с ним, что действительно будет давать выигрыш! Такой вариант в голове мелькал, но потом как-то забылся на фоне того, что пришлось долго возиться с запросом (его начальный вариант вешал СКД).
Пожалуй, стоит реализовать не золотое, а «вероятностное» сечение. Спасибо, что помогли вспомнить про эту идею!
Спасибо за замечательный отчет!!!
Одновременно возникла проблема выбора, поэтому прошу совета.
Отчет позволяет видеть просроченную дебиторку, не раскидывая платеж по накладным (В приходнике или Платежке). Однако, для этого необходимо проставить галочкой «ведение взаиморасчетов по документам» и «контролировать число дней задолженности» в договорах.
При этом срабатывает контроль взаиморасчетов при проведении накладных. Его конечно можно преодолеть если разрешить «Разрешить проведение…» в Дополнительных правах пользователя. Но тогда фактически реального контроля нет тк он а) необъективен, ибо опирается на несуществующие просрочки, и б) преодолевается пользователем
Два дальнейших пути (оба не нравятся):
1. Отключить «ведение взаиморасчетов по документам» в договорах. Но этого сделать система не даст, тк есть документы сформированные «под галочкой». (Хотя и можно завести новые договора)
2. Не отключать «ведение» (да, будем мучаться с проведением накладных). И убираем «контролировать число дней задолженности» из договора. Но тогда теряют смысл сей замечательный отчет по просроченной задолженности, ибо он ориентируется на это «Число дней..» при определении просрочки.
А ведь хочется иметь и контроль за проведением накладных и работающий отчет по просрочке.
(42) Glemar, хочу уточнить, что данный отчет работает НЕЗАВИСИМО от состояния реквизита «ведение взаиморасчетов по документам». В основном расчет на ситуацию, когда эта галочка не проставлена, то есть учет взаиморасчетов по документам не ведется. При этом есть две проблемы:
1) при снятии этой галочки пропадает видимость реквизита «число дней просрочки»;
2) также не возможно запретить проведение очередной реализации при просрочке долга.
Первая проблема в данном отчете решена без изменении конфигурации. Дело в том, что хотя реквизита не видно, он в базе данных для договора тем не менее хранится. И просмотреть и поменять его значение можно с помощью данного отчета, щелкнув по соответствующему полю. То есть отчет еще обеспечивает доступ к скрытому (при отжатой галочке) полю «Допустимое число дней задолженности».
Вторую проблему можно решить только изменением конфигурации, создав аналог данного отчета для одного контрагента, который будет запускаться перед проведением реализации и рассчитывать просрочку, превышение которой может быть сигналом для отказа в проведении. Ничего сложного в этом нет — это легко сделать на базе того же запроса.
Если же в договоре галочка стоит, то просроченность долга легче определить по соответствующему регистру, обеспечив правильное соотнесение оплат с отгрузками. А данный отчет использовать как контрольный. Он будет показывать наилучший случай (для контрагента) разнесения платежей, когда первыми закрываются самые старые долги и штрафные санкции минимальны.
(44)
Спасибо!
2) — Действительно,доступ к полю «Допустимое число дней задолженности» творит чудеса. Реквизит сохраняется!
К сожалению у нас имеются проблемы к корректным подбором Реализаций в документах оплаты, тк отгрузка шла и идет по нескольким договорам, имеются возвратные накладные, клиенты могут сделать проплату на сумму, превышающую задолженность… Будем думать над обработкой, которая бы периодически восстанавливала корректность соотнесения оплат с отгрузками.
Либо пойдем по пути, предложенному Вами в решении «второй проблемы». Попробуем даже сделать проверку на этапе Сохранения реализации (до Проведения), чтобы Менеджер занялся просрочкой до передачи заявки на склад, а не в последний момент.
Скажите пожалуйста можно ли на основе вашего решения рассчитать пени по просроченной задолженности без запроса в цикле по дням? Фактически нужно получить график просроченной задолженности по дням.
(46) MakhoninMY, если я правильно понял вопрос, то вы хотите то же, что и в (33). Тогда тот же ответ — нет, приведенное здесь решение только для просроченных долгов на одну конкретную дату.
В принципе, у меня в планах есть сделать отчет, связывающий оплаты с отгрузками и, таким образом, дающий возможность определить по каждому документу, насколько была задержана уже сделанная оплата. В порядке демонстрации алгоритма «быстрого связывания» нарастающих итогов. Но это пока через три-четыре уже начатых статьи, то есть минимум через столько же месяцев.
(47) Да, динамическое определение дат оплаты документов отгрузки было бы самым подходящим решением для расчета пени. Но формально данным запросом можно получить информацию о просроченной задолженности за каждый день расчетного периода, рассчитать пени по дням и сложить. Конечно, это не эффективно.
ildarovich,
Добрый день, складывается впечатление, что расчет задолженности сопоставляет только оплаты с отгрузками, но не учитывает взаимозачетов в виде, например, Корректировок долга.
Или можно где-то настроить список документов, пронимаемых во внимание расчета??
(49) Glemar, тип документов никак не ограничивается — это все документы, делающие движения по регистру ВзаиморасчетыСКонтрагентами,
Фактически сопоставления оплат с отгрузками не происходит. На сумму долга набираются последние отгрузки.
Если корректировка имела тот же знак в движении, что отгрузка, то она будет считаться «отгрузкой» и так же может посчитаться просроченной. Если корректировка имела другой знак, то она в отчет просто не попадет, повлияв на его содержание косвенно — через сумму долга.
Но вообще, если что-то непонятно, готов разбираться. Для этого мне нужно по сомнительной ситуации:
1) список движений регистра ВзаиморасчетыСКонтрагентами по конкретному договору;
2) выдача моего отчета;
3) выдача «правильного» с Вашей точки зрения отчета или мнение «что должно быть».
1. всякий раз говорю «круто» — и собираюсь проработать и остальные статьи автора )) (приятный научный глубокий подход и остроумный стильный текст.)
2. Собственно сейчас сам мучаюсь с тем как раскидать документы.. по другим документам. (у меня сейчас не типичная задача позакрывать расходы приходами по ФИФО — но очень близкая). Есть ли возможность в 2х словах направить куда смотреть..? (пардон за наглость)
(У меня пока и тета-соединением не прорисовывается запрос, а благодаря Вашим статьям есть ощущение, что запросом разом можно сделать почти все 🙂 и эффективно). Хотя у меня немного нетипичная проблема — под отгрузки подложить наипозднейшие но предшествующие отгрузкам поступления.. Т.е. понятие типа «аванса» нет — отгрузить виртуально то, что получим позже нельзя :). И вот тут пока не могу уловить идею как конструировать соединения, которые в итоге приведут к «закрыванию» отгрузок более ранними поступлениями. (это похоже на дебиторку — только разворачиваем ось времени в прошлое и стартуя с отгрузок и считая их «приходами», закрываем их поступлениями, полагая их расходами).
(51) Vodoley, если вы имеете ввиду партионный учет, то на Инфостарте было много статей на эту тему. Достаточно набрать в поиске ФИФО (FIFO). В тех статьях были примеры запросов и описание того, как они построены. Речь об оптимальности не шла, но, возможно, на ваших данных этого не потребуется.
Вообще эта задача (связь приходов с расходами) решается примерно так: все приходы по порядку складываются в столбик (как кубики). Величина секции столбика, соответствующего конкретному приходу, берется равной величине этого прихода. Все расходы также складываются в столбик рядом. Затем приходы с расходами связываются горизонтальными линиями. В комментарии приведен пример подобной схемы.
Если речь идет не о запросе, то функция, получающая таблицу связей приходов с расходами приведена в статье в разделе 7.
Пытались пользоваться этим отчетом и наткнулись на такое поведение: при отсутствии отборов по контрагенту А показывает одну сумму задолженности, при отборе только по Контрагенту А — другую сумму. Причем иногда было так, что реальная задолженность по РН взаиморасчетов не совпадала с данными отчетами.
(53) sea123, хотелось бы больше информации об обстоятельствах появления расхождений.
Были ли у проблемного контрагента взаимозачеты между договорами, с другими контрагентами, смотрелись ли остатки в максимальном разрезе договоров или только целиком контрагента, были ли корректировки регистра по нему, с «правильным» знаком ли они делались, были ли корректировки реализации.
Вообще гибкость настроек, обеспечиваемая СКД может иногда сослужить плохую службу: можно попробовать в любом типовом отчете поставить регистратор не на последний (нижний) уровень группировки и попробовать понять, что выдает отчет. Возможно, возникает подобная ситуация, но, чтобы разобраться, нужны подробности.
Хотя бы скриншот с разворотом движений по регистратору регистра взаиморасчетов по проблемному контрагенту, скриншот результата моего отчета по нему и скриншот результата «правильного» отчета. Буду очень благодарен за эти данные.
Очень бойко можно применить сей метод для построения отчета задолженности по периодам прострочки. Есть такой штатный отчет в десятой УТ «Дебиторская задолженность по периодам». Последний пакет запроса только изменить надо.
Сергей, невероятно. Я вот посмотрел Ваши статьи… Мало таких людей я в жизни встречал (одного, кроме вас, если быть точно). Ну круг общения у меня, конечно, не научная элита, но все равно, чувствуется незаурядный склад ума. Это не лесть. Действительно хотелось выразить признание. А сколько времени на проработку материала ушло у Вас? Ну, в частности этого.
(56) Prometeus2011, спасибо, надеюсь на то, что материалы публикаций будут полезными не только в теории, но и на практике. Собственно говоря, работа с 1С мне и нравится, в основном, своей близостью к практике.
Чистого времени ушло не так уж много: неделя-две. А так, наверное, месяц-полтора заняло. Если тема интересная, то работа идет быстро. Задержка там была в том, что первая версия запроса хорошо работала в консоли, но «вешала» СКД (из-за ошибки в платформе). В итоге запрос получился еще проще.
Спасибо.
Спасибо! Алгоритм очень помог при реализации похожей задачи!
Преклоняюсь перед вами, гении!
Спасибо. Очень круто.
Но вот сейчас мне надо отбор сделать по реквизиту регистратора, а реквизиты регистратора недоступны для отбора. Не могу понять толи я что-то не так делаю.
Может кто подскажет?
Всем комментаторам в этой ветке термин «Тупой одинэсник» неприменим.
(60) sapsan322, сомневаюсь, что в данной задаче имеет смысл делать отбор по реквизиту регистратора. Это специально не разрешено. Так вы можете «выдернуть» из цепочки взаиморасчетов отдельные документы, исказив их логику. Если интересует «проект», сделка, то эта информация должна в регистре отражаться, а к отборам по его измерениям вроде бы доступ есть. Если речь идет об ответственных (менеджерах), то объясните подробнее логику бизнес-задачи — можно будет подумать, как это сделать. Возможно, подтолкнете решение следующей задачи.
(62) Стоит задача сделать отбор по Ответственному менеджеру и ТипуЗаказа.
ТипЗаказа — это реквизит с типом перечисление и в нем имеется 3 значения: Продажа, Ремонт детали и Ремонт Автомобиля.
Попробовал сделать через сделку, и тоже не доступны измерения для отбора.
С позволения автора выкладываю переделку отчета под УТ 11.1.
(64) ОК
Использовал ваш алгоритм в отчете. Применить как описано в публикации не получилось из за «ложки сахара» — при реальном использовании отчета расчет по ФИФО делается по дате оплаты, а не дате отгрузки. Можно добавить к дате оплаты время из даты отгрузки, но по факту оказалось что в эту самую секунду оформлено до 20 документов отгрузки или поставки. Данные документы появляются при массовом вводе документов прошлым числом (реализации за период оформляются на одну дату), поступают из БД поставщика и т.п. И все бы ничего, но округление в такой ситуации вызывает расхождение между конечным остатком по регистру и результатом в отчете. В итоге ваш алгоритм использую для выборки оборотов с небольшим «запасом», а дальше уже обычным перебором. Пока не было времени протестировать причину, но на действительно большой БД время выполнения запроса вашего алгоритма и «стандартного» примерно одинаковое. Оставил ваш, так как в итоге все равно потребовалась промежуточная ТЗ.
(66) sapit,
1) выигрыш в скорости будет тем больше, чем больше отгрузок у ОДНОГО контрагента. Если на каждого контрагента отгрузок сравнительно немного, то и выигрыш не будет заметен;
2) вопрос одинакового времени легко решить, добавляя секунды ко времени ОПЛАТЫ, взятые из номера, например. Но я все же еще раз подчеркиваю. Если много отгрузок стоят на одно и то же время оплаты, то с точки зрения неоплаченности их не нужно разделять — лучше рассматривать их как одну большую отгрузку и находить общий процент неоплаченности этой отгрузки и применять затем этот процент к каждой составляющей. Погрешность округления можно исключить, отнеся копейки на последнюю отгрузку в пачке;
3) в запросе, приведенном в статье и в приложенной обработке до сих пор не исправлена небольшая неточность, которую я выявил в процессе «закадрового» общения с пользователями отчета. В предпоследнем запросе пакета вместо
нужно писать
Это исключит лишние ошибки округления!
(67) по пункту 1 -проверю. 2 -все таки много минусов. Пояснить поставщику(покупателю) что мы оплачиваем пропорционально 10 поставок невозможно. Считать отдельно что оплачено, а что нет — возврат к ведению учета по докуменам расчетов. Отчет в этом случае теряет часть функционала — можно посмотреть ситуацию по компании в целом, но на основании полученных данных решить что оплачиваем именно эту поставку становится невозможным. 3 — проверю.
Спасибо, отчет помог. И что главное, его удалось доработать под нашу измененную конфигурацию (Количество дней отсрочки реквизит справочника Торговые точки) не сломав голову.
спасибо, попробую
Спасибо, действительно очень быстро работает!
Божественно!
Думаю приспособить под расчёт прибыли по оплаченным реализациям
p.s. На Уралмаше улицу, на которой есть остановка «Веер» именуют Вейерштрасса
(68) попробуйте не лепить все документы за день в одну секунду.
Вопросы поставщиков/покупателей исчезнут автоматически.
В сутках 86400 секунд, у вас что, по одному контрагенту в один день больше документов??
(72) Ibrogim, учтите, пожалуйста замечание в (67). Сделал «детскую» ошибку: сначала поделил, потом умножил, когда всегда для избежания потери точности нужно сначала умножать, потом делить. В этой задаче это иногда (редко) проявляется в виде копеечных расхождений. Рецепт исправления в (67).
Уважаемый Сергей! Применил вашу обработку к старенькой УППшечке — все летает, алгоритм великолепен. Но мне нужно рассчитывать дни просрочки и даты получения денег как дата документа + отсрочка в рабочих днях. Попробовал пару способов, описанных на инфостарте — сразу начинаются резкие тормоза, при попытке исполнить отчет без отборов так и вовсе оут оф мемори! Пожалуйста подскажите как лучше всего реализовать мою задачу! Ссылочку бы на наилучший способ прибавления рабочих дней к датам в запросе!
(75) сначала количество рабочих дней по производственному календарю перевести в календарные. далее штатно.
вдобавок есть толкование (встречался разное) — например 1. если календарная дата (острочка в календарных днях например) платежа попадает на нерабочий ден, то дата платежа переносится на первый рабочий день. или 2. попало на календарный нерабочий день — значит так и есть, банк не работает платеж пройдет позже. получится просрочка. поэтому платить надо думать раньше.. 😉
для уточнения надо смотреть НПА
Реально быстрый отчет.
(77) Оказывается этот алгоритм применяют школьники в игре угадай число. Один загадывает число до 10. Другой пытаясь его отгадать называет: 5. Первый должен ответить больше оно загаданного или меньше. Далее отгадывающий говорит: 3 если меньше 5 и 7 если больше 5 и т.д.
Хотел бы воссстановить историческую справедливость. Я был автором первого отчета в 2009 г. на infostart с использованием методики FIFO в запросе. Сейчас представлено бесплатное доработанное переиздание этого отчета Сам отчет был написан в 2007 г. Просьба добавить в раздел «Некоторые ссылки». В качестве доказательства прилагаю скриншот 🙂
Еще один proof link исторической справедливости прилагаю
(79) Сделано
(81) Спасибо 🙂
Мда надо потрогать и подумать …
Здравствуйте!
Мне кажется в запросе есть ошибка в конце.
В оборотах могут вернуться документы оплаты, если они совпадают по времени с документами отгрузки. Скорее всего надо получать обороты во временную таблицу, убирать документы уменьшающие задолженности и уже потом работать с таблицей. Или я ошибаюсь?
(84) Сейчас отвечу наспех, по тексту в статье, не заглядывая в текст отчета в обработке. Наверное, вы правы. Видимо, о том же было замечание в (20). Учитывая еще (67), концовку действительно следует переписать. Но умозрительно кажется, что указанная вами неточность, должна приводить не к искажению суммы долга в строке, а к появлению в выдаче лишних строк с отрицательным долгом, которые легко убрать настройками в СКД.
Вспоминая свои тогдашние размышления, хотел для статьи написать запрос покороче, без лишних временных таблиц. А так, конечно, до временной таблицы Обороты нужно получить таблицу оборотов с регистратором, которую затем соединять с таблицей Шаг0.
(84) + (85) Скачал отчеты, посмотрел как в них. Все оказалось гораздо проще. Оказалось, что в статье по сравнению с отчетом не хватает условия
То есть условие было просто пропущено не в обработках, а именно в статье.
Исправил теперь в статье, учел комментарий (67) про точность в статье и в обработках.
За статью большое спасибо, я не мог решить проблему по просроченной дз. С вашей помощью вроде получается, и все гораздо проще чем кажется на первый взгляд.
Есть ли вариант переделанного отчета под БУ?
На данный момент у меня такого отчета нет, его необходимость для меня сомнительна. Вроде бы и счет 62 и 60 имеют аналитику по «документу расчета», откуда без труда можно увидеть просроченность. Да и штатный отчет имеется (ЗадолженностьПокупателейПоСрокамДолга).
В общем, укажите точно конфигурацию, для которой ищете отчет, и причины, почему типовой отчет не подходит. Если причины будут вескими, отчет можно доработать. Это не долго — достаточно переписать первый подзапрос в запросе.
Этот же отчет, только с анализом уже оплаченных документов. Цены бы ему не было. Чтобы видеть как закрываются документы в срок или нет и в какой срок с условием отсрочки… А так да скорость поражает. Спасибо за отчет очень интересный.
Тот же вопрос, что и в (75). Как переписать запрос для расчета просрочки по рабочим дням (точнее 2 варианта в зависимости от реквизита договора) с сохранением быстродействия?
Автора однозначно в лауреаты нобелевской премии!
У автора очень грамотные посты, интересно, чем он занимается в повседневной жизни, профессор, доктор математических наук?
(93) на самом деле доцент, кандидат технических наук, в повседневной жизни занимаюсь внедрением 1С, программирую
Спасибо огромное! На базе приведённого автором алгоритма сделал невозможное: отчёт, который формировался часами и нередко вываливался из-за переполнения памяти на скуле, теперь формируется всего 2 минуты! Фантастика!
(14)
…
На этом пути есть одна «засада», на которую я уже натыкался, а сейчас забыл. Итоги хранят суммы всех движений, а для работы метода нужно выделять из них только «отгрузки», а они — не всегда «приход», а иногда «расход» с минусом.
Коллеги, кто сталкивался с этой «засадой», как вы боретесь с этим? У нас ,например, есть и приход с минусом и расход с минусом.
Добрий день!
Подскажите пожалуйста почему когда добавляеш сделку и пробееш сделать групировку по сделка суми не сходятся с стандартним отчетом «Взаиморасчети с контрагентами»
Здесь будет работать?
Управление торговым предприятием для Казахстана, редакция 2.0
Не знаю. У меня этой конфигурации нет и не знаю, на основе чего она написана. Если на базе УТ10, то будет.