<?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='\
В формате этого портала данный материал я бы рассматривал как демонстрацию некоторых возможностей 1С:Предприятия 7.7.
Не поняла шутки.Что смотреть? закачка 7.70.507 закончилась ошибкой,а в 7.70.012
одни шапки. Такое мы богато бачили. Лучше бы сало показали…:)
Не понятно за что плюсы ставят DSshark и support если даже не смотрели.
(2) (3) По поводу 7.70.012. Документы Перерасчет, Исправление, ОказаниеУслуг и ПоступлениеДенежныхСредствПКО появились только в версии 7.70.201. В демонстрационную сборку на базе версии 7.70.012 они добавлены опционально. Т.е. без модулей проведения. Это же и в отношении других добавленных в эту версию объектов из старших версий.
В версии 7.70.507 все есть и все работает. Нет только некоторых текстов модулей.
(2) По поводу закачки. Проверил. Все качается. Дистрибутивы устанавливаются. Библиотеки регистрируются.
И вообще вы с работниками водоканалов общались? У нас они работают на старой
досовской версии.И им «ничего не надо,нас и так всё устраивает».Сколько интересно стоит Ваша программа?
(6)
Посмотрела — 9500 рублей.Довольно не плохо. И вопрос : Коммерческая версия открыта
или там ничего не изменить?
(8)
Полностью открыта.
Внедрение Респ Удмуртская, г Глазов, Январь 2004
МУП “Водопроводно-канализационное хозяйство города Глазова” МО “Город Глазов”
АВТОР: 1С:Франчайзи Дельта Ай-Ти, Ижевск
Расчеты с частным сектором
Конфигурация построена на основе оригинальной конфигурации ООО «Информ Сервис» (г.Лысьва), использующей компоненту 1С:Зарплата и Кадры 7.7, и предназначена для ведения расчетов с частным сектором по услугам водоснабжения.
Прежде чем предлагать кому-то ,нужно знать с чем имеешь дело.
Один предприниматель купил конфигурацию за 21 000 рублей.В итоге — это был мыльный пузырь. Было жалко на него смотреть.Эта конфа у меня есть и скажу я вам она вообще ничего не стоит. Можете зайти посмотреть к деятелям ,которые ее двигают.(дурят — другого слова не подобрать).
(10) «География пользователей» это холодные продажи. Т.е. пользователи сами на нас выходят. Узнают друг у друга или еще как-то…
Чтобы это был не «мыльный пузырь» — смотри материал. Именно поэтому документация и две конфигурации:
7.70.012 — с текстами чтобы понять общие принципы.
7.70.507 — полнофункциональная версия. Сомневаешься — проверяй. Не понятно — спроси…
Хотя здесь материал был опубликован с несколько иной целью… (см. пост 1)
Неа. Подождем…
каковы размеры клиентских баз? есть ли проблемы с производительностью?
Именно из-за производительности делал подобные вещи на MySQL и PostgreSQL.
(13) Встречный вопрос. А какие показатели вы считаете приемлимыми, ну, например, для базы данных на 10000 абонентов?
(14) ну .. для 1с это уже немалый размер. У меня например базы 25 000 — 30000 полностью пересчитываются за 1-1.5 мин, в базе всегда актуальные данные (как правило включен авторасчет). Базы никогда не резались — т.е. в системе данные за весь период эксплуатации системы.
По моим скромным ощущениям 🙂 при увеличении числа пользователей в десятки раз база на Postgres покажет почти линейное увеличение времени расчета.
Действительно интересно — есть ли проблемы с производительностью, что пришлось сделать для решения проблемы.
(15) К сожалению у меня нет таких больших баз. Поэтому тренируюсь на базе в которой 11600 активных абонентов. Размер базы за 4 года ~ 350 Mb.
На моем компьютере в монопольном режиме полный расчет по 11600 абонентам за 1 месяц занимает 28 секунд (10 секунд отмена проведения, 18 секунд проведение). При этом удаляется, а потом формируется 25000 записей в журнал расчетов. Программа использует около 30 Mb оперативной памяти.
+16 «всегда актуальные данные» — не совсем понятен тезис.
Разумеется при работе по сети и в многопользовательском режиме показатели производительности будут хуже.
+16 Немного покривил душой. 28 секунд это лучший показатель. т.е. по свежим индексам. Стабильный показатель — 32 секунды.
Со сменой всех тарифов в середине месяца при 60000 записей полный расчет — 51 секунда (21 секунда отмена проведени
Структура базы / состав данных — продиктованы жизнью.
В своих проектах дела все очень похоже. На 1с скорее всего конфигурация так и выглядела.
Молодцы 🙂
Еще один вопрос — льготники.
Откуда берется/как вводится в систему информация о льготниках?
Сталкивался с тем, что файлы, формируемые собесом, не всегда актуальны и могут содержать ошибки в ФИО и адресах. Пришлось сделать инструмент для сравнения и сопоставления тек. состояния базы и файла собеса.
(19) Льготники — ручками. собес ничего не дает — только требует отчетности в «своем» формате. Сделана выгрузка в 2х «своих» форматах…
Есть обработка для загрузки справочников с диска ИТС. Можно воспользоваться ей. После загрузки есть обработка в конфигурации, которая проверяет справочники и дозаполняет, исправляет или выводит предупреждения…
Я обратил внимание на обработки.
Мне удалось «автоматизировать» :). Благодаря моим пользователям, в собесе поддерживается относительный порядок — обратная связь работает: нашли ошибку — звонок в собес.
У меня базы города и районов вытягивают на 8 и более тысяч льготников. Раньше «расчет льгот» + «отчет для собеса» требовал: «программиста» + неделю работы.
После внедрения время обработки сократилось до нескольких часов.
Могу поделиться «концептуальными» наработками.
(21) Всегда за. А какой у вас регион?
(22) Программы используются в Ростовской области, но я думаю сути это не меняет. Набор данных собеса (Уник. номер, ФИО, Адрес, количество человек, количество льготников, проценты начислений) — одни и те же.
(23) не надо! Я работаю плотно с собесами, сибсидиями,монитизациями — данных они требуют гораздо больше и разноообразнее. 🙂
В продолжение пост (64, 66, 67)
Мне не хотелось бы сравнивать эти две конфигурации. Мне кажется, что они имеют разную направленность. Но раз Арчибальд привел этот пример , то замечу, что приведенная в качестве примера эталонная конфигурация предусматривает создание регламентных документов по расчету домов. 1 дом — 1 документ. 10000 домов — 10000 документов в месяц. Средний «вес» 1 начисления в эталонной конфигурации около 3500 байт. Средний вес 1 начисления в конфигурации Абонентский отдел водоканала около 350 байт.
Я не могу сказать, что приведенная в качестве примера эталонная конфигурация плохая. Просто она рассчитана на другой сектор рынка, другие бизнес процессы, другие объемы обрабатываемых данных. В данном случае, мне кажется, что это не очень удачный вариант для сравнения.
Что будет, если база 100000 абонентов и у каждого в среднем 3 начисления + оплата. База данных за месяц будет увеличиваться на 1,3 Гб (за год на 15,6 Гб).
…или не так?
(25)
Задержался с ответом – связь вырубилась.
Итак: я привел пример решения похожей задачи на движке Бухучет. Для водоканала архитектура решения (структура данных, порядок ввода) не очень подходящая, конечно, ибо не учтена многочисленность объектов (аб. точек) и единственность начисления. О трех в среднем начислениях я речь не веду, поскольку расчеты ведутся не по людям, а по точкам отбора. Люди и поменяться могут, а кран остается.
Касательно объема базы. В самом деле, в бухучете объем данных по одному движению больше, чем в журнале расчетов. Но примерно вдвое, а отнюдь не в 10 раз. Зато данные и более информативны (движение + итоги, а не только движение), и извлекаться могут независимо, поскольку не лежат в одной куче (журнале расчетов), а распределены по их природе (по «счетам»).
Что осталось? Оптимизировать обработку справочника аб. точек и заставить начисление за месяц формировать не один документ-монстр, а дюжину операций.
На 10000 аб. точек в месяц будет порядка 30000 проводок (вместе с платежами, льготами и субсидиями). Это порядка 100 Мб в год прибавления к объему БД. И никаких проблем со сверткой базы.
(26) В 10 раз получилось случайно. Я скачал демку и тупо померил результат до и после проведения документов начисления, и поделил на количество строк начислений. Конечно все зависит от структуры данных абонентской базы. Если льготников много (а на каждого делается по 3 дополнительных проводки по каждому начислению), то размер базы значительно увеличится. Если говорить об «информативности данных», то учет раздельно ведут по водоснабжению, водоотведению, поливу, на скот в разрезе размера скота (крупный, средний, птица) и еще автомобиль (на помыв) и разовые работы. Раздельно по счетчикам и по норме. Раздельно горячую и холодную. Раздельно льготируемые начисления и без льгот. Раздельно по тарифным ставкам. Так что формула 1 абонент — 1 начисление не соответствует реальности. 3 начисления я взял из демонстрационного примера чтобы быстрее клонировать документы и набрать объем эталонной базы. В реальных базах может быть в среднем и более 10 начислений. Я видел базу где только по скоту было 26 начислений у одного абонента и тарифы разные.
А дюжину операций будет формировать обработка? Чем такое решение лучше регламентного документа? Несколько тысяч проводок в одной операции. Насколько удобно будет искать в таком объеме проводки по конкретному абоненту. И что будет с ручными изменениями при повторном регламентном расчете?
(27)Т.о. мы имеем разные типы абонентскик точек = различные счета начисления (Дебет). Различные варианты льгот, субсидий и платежей = различные счета кредита проводок. Плательщик (абонент) — это атрибут справочника абонентских точек. Возможно, второе субконто в проводках по абонентским точкам.
Начисление (регламентный расчет) проводится однократно. Все изменения — документом «Корректировка», формирующим проводки по требуемым отклонениям.
Вся информация в перечисленных разрезах получается стандартными бух. отчетами типа «анализ субконто» или «ОСВ», поскольку данные автоматически хорошо структурированы.
(28) «Начисление (регламентный расчет)» — это обработка?
Что делать в случае, если через неделю работы обнаружили, что новые тарифы установили не по всем начислениям?
Как получить отчет в разрезе тарифных ставок?
3.15, 3.62, …
(29) Нормативное требование в сфере коммунальных услуг — периодическое (ежемесячное) выставление счетов потребителям. А когда через неделю выяснится, что выставлены неправильные счета — это не повод для повторного выставления оных. Делается коррекция начислений.
Ну, а «отчет в разрезе» как то за пределами нашего обсуждения — мелкая техническая задачка. Тариф, например, может быть атрибутом справочника абонентских точек с возможностью сортировки/отбора.
(30) Счета выставляются за прошлый месяц, а платежи собираются за прошлые месяца и за текущий. Т.е. расчет выполняется в начале месяца — предварительный и в конце месяца — окончательный. Окончательный это после поступления от почты и банков данных по показаниям счетчиков.
По периодическим реквизитам справочника нельзя сделать отбор или сортировку. Если реквизит будет не периодический, то отчет за прошлый период будет неверный. Нужно добавить субконто?
(30) Теперь у меня есть версия под компоненту «бухгалтерский учет». Над ней набо еще поработать, но регламентные начисления уже работают. Однако сомневаюсь что найдутся энтузиасты купить данный продукт, но попорядку…
— проводил только регламентные документы по начислениям, т.к. остальные документы еще неготовы, то их не сравнивал
— потерял немного аналитики в проводках и типовыми бухгалтерскими отчетами этого не вернуть — придется разрабатывать что-то специально
— 4 файла для работы с журналом расчетов (ЖР) заменили 20 файлов для работы с бухгаллтерскими итогами (БИ) + 6 справочников для восстановления аналитики
— объем 4 файлов ЖР — 300 Мб, объем 20 файлов БИ — 2 Гб (основной объем 2 файла — проводки и итоги)
Все отборы отключены, содержание проводок и разделение по журналам удалены. Можно поработать над оптимизацией внутренней структуры итогов, а также поработать над быстродействием, но я не уверен, что получится выйти хотябы на паритет с журналом расчетов по объему и по скорости.
(32)Могу посмотреть и чего-нить посоветовать. Один ум хорошо, а два сапога — пара.
(33) Однажды я уже пытался это побороть, но в то время техника была слабая, а на большое количество экспериментов небыло времени.
Я использовал план счетов из приведенной в качестве примера конфигурации. Добавил аналитику по тарифам и нормам. Получилось 5 субконто.
Мне кажется основная проблема в самой структуре проводок, плане счетов и выбранных корреспонденциях. Проводки должны быть другими и разрезов аналитики как можно меньше. Больше оборотных субконто чтобы облегчить итоги.
В данном случае должен быть другой план счетов и соответственно другие коррепонденции. Также необходимо продумать проводки всего документооборота чтобы не накапливались лишние итоги.
(34)Сваял иллюстрацию к некоторым идеям по минимизации итогов и количества субконто. Куда послать?
Версия 7.70.521.
Обнаружена ошибка при использовании фильтров в отчете «Справка по источникам поступления денежных средств» в случаях, когда условие накладывается по реквизиту не выбранному в группировке.
Исправлена в 7.70.522
Даже смотреть не стал . На 8 — ке когда будет ?