<?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='\
Прикольно, как такого плана отчет может не учитывать договора ? Нужно учитывать, что у некоторых ведение взаиморасчетов может быть в разрезе договоров, в данном случае как минимум в вашем отчете надо такие оплаты по fifo распределять, как максимум в самой организации подход надо менять, если надо в разрезе заказов учитывать, значит надо менять ведение взаиморасчетов. В таком случае все сводится к просмотру отчета взаиморасчеты.
Навряд ли кому-то интересно, пропорционально оплате пересчитанные показатели себестоимости и наценки, как правило всегда интересует итоговая валовая прибыль, маржа, при этом некоторые прибегают к подходу — если заказ оплачен частично, значит считаем его оплаченным полностью.
Насколько известно, безошибочно в УТ 10.3 это возможно тогда, когда в договоре стоит признак «Вести по документам расчетов с контрагентами» и в платежных документах указывается документ расчетов — реализация. А в Вашем отчете по какому принципу осуществляется привязка документа оплаты к реализации?
(0) реализация конечно непонятна, и как в СКД реализовать распределение по ФИФО?
(3) Ну как обычно два варианта, либо при помощи функций скд, но тогда не получится отбросить реализации на которые ничто не попало по итогам, либо сразу в запросе отчета, разве трудная задача нарастающего итога и распределения оплаты по нарастающему итогу ?
(1) Согласен, договора нужны, но пока задача стояла разобрать контрагентов в целом без договоров. и отчет больше предназначен, для того чтобы посмотреть что оплата перекрыла себестоимость товаров или нет + в моем случае менеджеры получали зарплату не от валовой прибыли документа, а именно от того сколько клиент оплатил этой прибыли, поэтому пропорционально рассчитывается оплаченная наценка. А то реализации можно выписать много, а живых денег нету.
(2) Если «Вести по документам расчетов с контрагентами» и в платежных документах указывается документ расчетов — реализация — это супер. Но практика показывает, что не все придерживаются данной схемы. им главное быстрее продать, отбить товар, и трясти оплату, и все смотрят общую сумму долга, поэтому отчет который о фифо рассчитывает задолженность по документам
(3)Там не только СКД, а в нее передаются внешние источники расчитанные и подготовленные
(7) вот-вот, и я об этом. ну значит, заранее подготовленные данные. понятно.
(5) А то реализации можно выписать много, а живых денег нету — Обычно это жестко контролируется, например при проведении реализации, как правило, а печать первичных из не проведенных запрещается.
В целом может и корректно поступаете, отгружаете, когда клиент оплатил себестоимость как минимум.
(6) Так же можно контролировать, если не подтянуты документы оплаты в платежные документы, либо в реализации не подтянуты платежки, можно давать не проводить. На момент проведения смотреть, есть ли отсутствующие в регистре Взаиморасчеты по документам расчетов документы, если таковые есть в разрезе текущего договора, выдавать сообщение и не давать проводить. Но тут все от специфики предприятия зависит, надо ли такое вообще и насколько критично, чтобы по документам расчетов велись взаиморасчеты.
В целом, возможно отчет и будет интересен широкой аудитории, но не хватает распределения оплат по договорам у которых по договору в целом. Грубо говоря, вы выложили, то что актуально и специфично для конкретно вашего учета.
(4) я думаю, что с помощью запросов ФИФО не реализуется.
Я к платформе отношусь так:
1) есть набор инструментов платформы — с помощью которого реализуется та или функциональность;
каждый из инструментов предназначен для своего применения — как молоток и пила — для разных целей.
СКД не исключение — СКД не является универсальным инструментом, с помощью которого можно реализовать сложные алгоритмы распределения вроде ФИФО. И помните, что в ФИФО есть «задача копеек».
2) и есть алгоритмы, которые универсальны и с платформой не связаны — чаще всего сложные алгоритмы реализуются именно через заранее подготовленные данные, затем они обрабатываются;
ФИФО — это один из самых распространенных способов решать ту или иную экономическую задачу, чаще всего ФИФО
реализуется через алгоритмы, а не через запросы.
(3) фифо можно в запросе сделать.
(1) частично прав, надо отдельно рассматривать взаиморасчеты по заказам и по договору в целом. Но идея отчета правильная, много кому такой нужен.
(11)
есть ссылки на примеры?
мы с вами, возможно, о разном говорим….
(10)
Прямо тут в псевдокоде обьяснить могу, берете таблицу реализаций и реализуете нарастающий итог, по методу мадам Баттерфляй, ildarovic’а ))) или по классическому, далее левым соединением соединятесь с таблицей где договор и оплата, по условию : ТаблицаРеализаций.договор = ТаблицаоплатПоДоговорам.Договор И ТаблицаРеализаций.договор = ТаблицаоплатПоДоговорам.СуммаОплаты > ТаблицаРеализаций.СуммаНакопленныйИтогБезУчетаТекушей. Затем через выбор когда тогда «отщипываете» от оплаты по договору необходимую сумму на данную реализацию, думаю смысл понятен. В целом никто не мешает в коде реализовать, но задача не архисложная, недавно реализовал распределение резервов и свободно ожидаемых заказов поставщиков по потребностям, в запросе, по принципу фифо.
(12) я сам делал
ссылок вообще-то полно
выстраиваешь отгрузки и оплаты по порядку дат, делаешь таблицы с нарастающими итогами, потом соединяешь.
(14)
нарастающий итог на каждый день или как? на какую дату наращивать итоги?
(14) отгрузки и оплаты — начиная с какой даты или какой отгрузки? с начала года?
(14) как узнать по каким реализациям долг закрыт? чтобы не пересчитывать лишний раз в запросе?
(13) вроде как поверхностно подходит, есть же подводные камни. мне вот пока не нравится нарастающий итог — с какой даты наращивать, до какой ?
Ребята не спорьте, фифо сделать в скд можно, но мудрено, и может не для всех задач. Для этого отчета фифо в скд очень проблематично, потому что незакрытый долг у каждого клиента на разные даты висит. Была бы общая отправная точка то можно сделать,а поскольку в долгах общая дата это ввод остатков, то делать это в запросе не целесообразно.
В данном примере подготовлены таблицы для СКД
Кому интерсно для ут 11 тоже готовлю такой отчет, скоро будет.
(15) за все время ессно. Если у договора есть реальные даты, то надо по каждому договору собирать во время его действия.
Что такое ФИФО? Выпиши в столбик оплаты, в соседний столбик отгрузки. Совмести столбики, увидишь, что чем оплачено. Вот точно так же и пишем о)
(18)
До какой, думаю вопрос не совсем корректен, а то, как именно отправная точка ФИФО будет определяться, тоесть порядок, зависит от того какое у вас соединение в условии запроса будет где собирается нарастающий итог, сделаете по моментВремени >=, будет фифо, обратный знак — лифо, можно по каким-то другим критериям
(19) Вы про какой не закрытый долг ?
Насчет фифо в скд, встроенными функциями, я уже сказал что реально и не мудрено, единственное все строки попадут, в то время как если в запросе если формировать, попадут только распределенные.
Что за дата ввода остатков ? давайте проясним — если вы ввели остатки, вы как правило занесли итоговый остаток по контрагенту в разрезе какого-то договора, наш долг ему или его нам, какие ещё отправные точки ? Как итог, в вашем «продукте» не хватает распределенных оплат по тем договорам, у которых ведение по договору в целом, без документов расчетов, сделать это не сложно, соответственно логично, что если по договору целом, то мы распределяем по методу ФИФО, а не каким-либо другим способом, если это не совсем так с точки зрения бизнес логики предприятия, значит у такого договора не должно стоять по договору в целом.
Добрый день!
Не подскажите,можно ли переделать отчет если взаиморасчеты ведутся строго по документам расчетов с контрагентами.
Заранее спасибо)
(24)
Добрый, при желании все можно, добавится еще 1 аналитика
(25)А не подскажите поподробнее,пробовала переделать запрос,но не получила нужный результат.
Интересует именно отчет,который по номенклатуре.
годный отчёт! ещё бы вариант на выбор фифо и стандартный по разноске платежей