<?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='\
Не хочу быть категоричным и грубым, но — маразм… (или преубедите меня).
1) Нулевые или минусовые остатки, несут в себе информацию о хозяйственной операции, пусть не полно и частично искаженно из-за неправильного ввода, но несут…
2) Причем тут скорость запроса к регистру? Если удалять, то делать «свертку по остаткам» и удалять все без остатка «на закрываемый период»…
P.S. «Не давайте гранату обезьяне» — выкладывая такую обработку, стоить предупредить о её «опасностях» и подробнее описать …
(1) AnryMc, У меня ситуация такая: Операторы оформляют поступление товаров на Определённый перевалочный склад (почти всегда ток на него) и тутже в пределах дня делают перемещения (распределение товаров) на магазины. А затем получают накладную на транспортные расходы (Поступление доп расходов). Так вот после ввода этого документа получается, что на «перевалочном складе» появляется сумма по партиям! Количества уже давно нет! Все количественные остатки с себестоимостью перемещены! А чтоб избавится от этих зависших сумм нужно либо перепроводить абсолютно все документы по всем складам в последовательности !!! Что сами занаете не реально у компаний с большим документооборотом! Магазинов 10 штук. В каждом и розничные и отовые продажи! И что в магазинах набили — не реально за ночные 7 часов перепровести! да ещё с большим документооборотом пересорта полно при розничной продаже!
Если вы знаете как быть в моей ситуации подскажите плиз!?
(2)лучше бы ты придумал обработку, которая переносит время документа перемещения или время документа поступления доп. расходов.
в твоем документообороте, документ «поступление доп. расходов» получается нах…. не нужен.. зачем он вообще в таком случае? формировать зависшие суммы?
бред………
(3) SpartakM, Чтот я не понял ты о чём? Документы по доп расходам приходят парой через месяц! И причём тут обработка по изменению даты документа перемещения!? К примеру вначале товар весь переместили в одним магазин затем на следующий день другой магазин запросил тотже товар и ему уже делается перемещение с со склада магазин1 на склад магазин2 себестоимость при этот перемещается всё таже без доп расходов!! И все эти товары соотвественно благополучно продаются и тут приходят документы о доп расходах! Какая тут обработка поможет привести всё в порядок!? А документ доп расходов необходимо оформлять ещё и чтобы в дальнейшем перегрузить их в бухгалтерию. Вот тебе и бред? Сказал бы, что то дельное! что воздух то пустыми словами сотрясать!
У меня автоматически запускается обработка проведение по партиям каждую ночь. С флажком «Выполнять на сервере» за ночь проводится документов за период 1-1,5 года. У вас получается, что при продаже товара не учитывается его реальная себестоимость, за счет того, что в партии не учтены суммы доп. расходов?
(0), Поставил плюс для равновесия..
(2) А можно показать (скриншот) структуры этого вашего регистра и кратко написать какие документы в какой момент что двигают? Боюсь, что (5) sanches — прав. и ваши 10 магазинов могут продавать товары не по реальной себестоимости.
А это может не понравиться «хозяину бизнеса» когда «всплывет». (Налоговая посмотрит «сквозь пальцы» ведь вы не увеличиваете себестоимость на затраты)
(6) TMV, Ну и что это ваше «равновесие» дало?
С новым дизайном сайта не могу поправить свое предыдущее сообщение.
У меня очень часто задним числом могут править документы, порой в 2011 году меняют. Для полного восстановления последовательности партионного учета с 2011 года уходит 1-3 ночи. Это с учетом того, что при проведении может возникнуть ошибка блокировки и программа закрывается. Если блокировки не случается, то за одну ночь может восстановить с 2011 года по 2013 партионную последовательность.
Замечу, что я говорю не об обработке Проведение документов, которая находится в Операции. Эта действительно долго восстанавливает. Для выравнивания партий достаточно запускать обработку из меню Документы-Дополнительно-Проведение по партиям.
Привожу свои данные из 1С.
за 2012 год количество документов
Возвраты — 1062
Перемещения — 2814
Поступления — 1061
Реализации — 29322
Налоговая тут не причём — это упр учёт. Бухгалтерия себе доки перегручила и сама их там перепроводит как ей надо.
По поводу обработки «Документы-Дополнительно-Проведение по партиям» наверное штука хорошая, НО УТ 10.3 это не УТ 11.1 ! Здесь в 10.3 каждая секунда документа (раньше позже) играет роль! (Базе 3 года уже) Т.е. нужно вначале каким то образом воостановить всю хронологию документов в нужном порядке — к примеру из Москвы закупаемся у нескольких поставщиков (накладных 20!!!) ну и соответственной на этот весь товаро какой либо перевозчик везёт. Не сразу всё — всё не умещаяется да и постащики разом все товары к отгрузке подготовить не могут. И получается что 20 приходных накладных по товарам по мере поступления на наш склад операторами оформляются — распределяются по магазинам. И ток потом через месяцок Мы получаем приходную накладную по доп расходам на эти 20 накладных. Вот и подскажите пожалуйста как и чем все эти документы (поступление перемещения реализации поступления доп расходов) разместить в нужном порядке чтобы потом попытаться воспользоватся обработкой «Документы-Дополнительно-Проведение по партиям» ?
База SQL 45 GB
Если по цифрам то в моей базе Количество документов за 2012г.
Возвраты: 14600 в среднем по две строки.
Перемещения: 45000 — в каждом доке в среднем по 11 строк.
Поступлений: 22000 — в каждом документе в среднем по 20 строк
Поступлений доп расходов: 1500 — в каждом документе в среднем по 72 строки
Реализаций: 21800 — в среднем по 6 строк
Отчёты о розничных продажах: 7100 — в среднме ПО 450 строк.
Оприходований: 8300 — в среднем по 6 строк
Списаний: 10700 — в среднем по 7 строк
Для расстановки документов попробуйте воспользоваться обработкой
Конечно, это дело каждого как вести у себя учет. Но мне кажется что в УТ намного больше возможностей, чем в бухгалтерии, где посмотреть прибыль, суммовые показатели товарных запасов на складах.
По моему, в вашем случае, прибыль в отчетах 1С будет выше, чем на самом деле, а суммовые показатели товарных остатков на складах будут ниже.
Всё верно прибыль завышена! Суммовые остатки в 98% случаев занижены из за не учёта доп раходов.
Та обработка не пойдёт т.к. она располагает документы по порядку в пределах дня! (+перепроводит их) — не пойдёт.
Вот в примере, что описал я выше получается, что документ доп расходов по идее должы оформлятся задним числом до момента оформления первого поступления из 20! Как бы вначале по этим партиям должны образоваться суммы а зетем уже документы поступления товаров добавят в пратии количество…
Вообщем налаживать ситуацию с партиями лучше так: Свернуть базу и далее уже пытаться каким то образом проводить документы по партиям!
У меня моя обработка позволила избавится от 186 000 минусовых партий которые из месяца в месяц качуют и нагло увеличивают размер базы. Кстати это была первая причина (быстрый рост бызы) по которой я создал данную обработку. В месяц размер базы увеличивался на 1,6-2 ГБ !! Отключить всю ненужную информацию (Списаннные товары, Регистры НДС, ОбъектыДоступа, История обмена, Дубли по ценам номенклатуры и другое). Ну а вот с зависшими партиями пришлось бороться именно так!
Корректировка записей регистров, а не Удаление…
Корректировка движений только по регистру ПартииТоваровНаСкладах? Из описания непонятно.
Еще неплохо было бы сразу «двигать» и по другим логически связанным регистрам: ТоварыОрганизаций, ТоварыНаСкладах
p.s.(обработку не скачивал)
Да корректировка записей регистра «ПартииТоваровНаСкладах». Под понятием «Удаление» — Удаление минусовых остатков по ресурсу «Сумма» из служебной («виртуальной») таблицы «ПартииТоваровНаСкладахОстатки» !
Регистры ТоварыОрганизаций и ТоварыНАСкладах это количественный учёт и они тут не причём у них от перестановки мест слагаемых сумма (остаток количественный) не меняется !
(15) в Вашем случае не проще ли отключить движения по РН ПартииТоваровНаСкладах у документов «Поступление доп.расходов» (присоединяюсь к (3))? Зачем в вашем «бардаке» движения по этому документу? может и эта обработка больше не понадобится
удалятькорректировать ресурс «Сумма» у минусовых и нулевых остатков РН ПартииТоваровНаСкладах. У бухгалтерии своя себестоимость, у вас в упр.учете — своя) Смысл в доп.расходах в регистре ПартииТоваровНаСкладах в Вашем случае?Согласен, что движения по партиям у доп расходов можно отключить. НО для «старших» операторов (аналитиков) это было неожиданностью в прошлом месяце когда они формируя отчёт по прибыли вдруг увидили резкий спад процента прибыли! А оказалось, что они впервые спразу после поступления оформили поступление доп расходов и ток потом переместили товары по магазинам! Они и не думали что доп расходы должны отражатся на себестоимости. Сейчас там все думают, нужно ли их учитывать или по старинке прибыль смотреть без доп расходов (документу отключить движение по партиям)…..
Вот такая ситуация.
Почитал коментарии и захотелось и свои пять копеек вставить.Да можно делать как пишет автор но разве ето правильно любой приход того или иного товара имеет свою стоимость просто тупое списывание просто исказит показатели финансовых результатов. Для правильности нужно исправлять все ошибки вручную проанализировав их. тогда учет будет правильным. что и нужно для фирмы правда или ложь. Решать вам и думать вам. 1С делает то что нужно
(10)
Очень просто: ипользуйте ордерную систему на складах