<?php // Полная загрузка сервисных книжек, создан 2025-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='\
Ждем откликов…
прикольно, 570 бачей за 20 минут, ай малаца
+1 я не жадюга :))))
Тьфу, блин… 1500 руб.. конечно…
Я думаю продуктивность сотрудничества между твоим клиентом и его клиентами значительно бы возросла, предложи ты им обмен данными в электронном виде — это первое. Второе — а что будет когда количество подобных клиентов станет расти? Итог — решение на коленке долго не проживет, грамотный подход принес бы тебе больше презренных бумажек, а клиентам больше сервиса
Че, ты чему народ учишь ? Исходно был выбран идеолгически неверный путь в данной задаче. Завтра появится 5, 6, 7 я сетка у клиента и что ?
Низачод короче
«NN — числовой код клиента в справочнике контрагентов»
ужас !!! ужас !!!!
Тьфу на вас всех, собаки бешеные! 😉
Вероятность появления у клиента новых сетей в течение года — весьма мала… так что
NN — числовой код клиента в справочнике контрагентов — В ДАННОМ СЛУЧАЕ — практически оптимальное решение… особенно, если клиенту завтра припрет вставить колонку артикула Ашана в ТЧ документа реализации — это я смогу и по телефону разрулить… а вот при выборе идеологически верного Варианта 1 — придется телепаться на другой конец москвы…
Естественно, к выбору варианта решения надо подходить обоснованно… Ясен пень, что при первой же возможности следует переделать под Вариант 1, но работы там будет — раз в пять больше… потому что внешне для клиента — все должно быть максимально просто…
.
> а что будет когда количество подобных клиентов станет расти?
сразу видно, что народу лень думать… БОЛЬШИНСТВО клиентов, которые работают с сетями — имеют СВОЕГО программиста 1С. Поэтому — ничего не будет…
..
> решение на коленке долго не проживет
Согласен… Только предложенное выше как выразились «решение на коленке» — встраивается в систему за 15 минут… и уж поверьте — грамотные «коленчатые» решения — живут вполне себе успешно…
> продуктивность сотрудничества между твоим клиентом и его клиентами значительно бы возросла, предложи ты им обмен данными в электронном виде…
Сапсем больной, да? 😉
Обмен в электронном виде не исключает необходимости предоставления твердых копий документов. Пока я еще не встречал, чтобы налоговая принимала для проверки логи/электронные документы.
Низачот.
-1
Ужос н@х… Такого изврата я ещё не видел.
Особенно «необходимость править структуру данных конфигурации при появлении новых «сетей», + не забывать при обновлениях.»
Ок, Специалисты.
Ставим задачу:
— решить сабж
— уложиться в общем случае в 10 строк кода.
— избежать программирования при вставке артикула сети в табличную часть документа.
…
критиканские высказывания без обоснования будут приравниваться к флуду… 😉
imaster’у: а ты, что, никогда структуру данных конфиги не модифицировал?
>>обойти матюги так называемых «специалистов 1С»
Бугоганах, ну-ну, пиши еще!
Не обжайте Чебурашку, он хороший. И его решение, более чем грамотное.
Сам работал с сетями, и знаю, что это такое, более придирчивого покупателя не найти, но это сеть, и она диктует условия.
Добавления нового реквизита в карточку номенклатуры самое простое и грамотное решение. Многие программисты не понимают, что 1С дала прекрасный инструмент, чтобы решать именно такие задачи. Создал реквизит, добавил на форму и все. Больше ничего делать не надо. А создание сложных систем по вводу дополнительных артикулов только усложняет процесс ввода, вывода и т.д. Потом научить оператора создавать такой артикул сложнее, чем научить создавать дополнительный реквизит в справочнике. 🙂
И еще, сетей, которые кодируют сами, в России можно пересчитать по пальцам, все остальные используют коды поставщиков. Создавать сложную систему для максимум десяти клиентов просто глупо.
Плюсы данное решения.
— Дополнительный артикул легко выводится в форму списка справочника (опять же заложено 1С), соответственно оператор может искать по нему.
— В любом универсальном отчете можно легко вывести код сети, т.к. это просто реквизит справочника.
— Добавить реквизит в табличную часть документа так же просто, как в форму списка.
— Можно осуществлять упорядочивание 1С запроса по данному реквизиту.
— Можно осуществлять поиск по реквизиту, отбор и т.д.
Я бы обошлась без попытки:
ПечКод = ""; Если глЕстьРеквизитШапки("БВК_Артикул"+Число(Докум.Контрагент.Код), Докум.Вид()) = 1 Тогда ПечКод = Докум.Номенклатура.ПолучитьАтрибут("БВК_Артикул"+Число(Докум.Контрагент.Код)); КонецЕсли;Показать полностью
Что-то много всего намутил. Конфа, насколько я понимаю имеет типовой функционал с аналогами и каталогами. в этом случае вообще ничего не надо в структуре менять. У меня код (артикул) покупателя хранится в реквизите «ИдентификаторВКаталоге» справочника «Аналоги». При печати документов используется глобальная функция, которая возвращает код покупателя, в случае наличия аналога из каталога данного контрагента. В некоторых случаях используется не только код, но наименование товара, принятое у клиента (хранится в реквизите «Наименование» справочника «Аналоги») — есть и такие клиенты…
При условиях, которые заданы в задаче
Цитата
«(плюс к этому попутно: франч, обновлявший конфигу клиенту, умудрился «потерять» внесенный по другой доработке новый код в глобальный модуль — хотя ему был перед добавлением выдан «протокол» изменений — что уж тут говорить о более серьезных доработках кода… — при очередном обновлении — все рухнет… франчи — они такие…)»
ни один из способов не является оптимальным.
Реализованный вариант 3 при подобном обновлении пострадает также, как и остальные варианты!!
Наиболее правилен все-таки вариант 1, пусть он клиенту и обойдется дороже 🙂
Только я бы не использовал встроенный справочник Аналоги, а сделал бы спец. подчиненный справочник, который не пострадает. Объем клиентского кода, в принципе, примерно тот же 🙂 Необходимо только написать пару методов для работы с подчиненным справочником 🙂
При «плохом» обновлении/объединении в этом случае по крайней мере данные клиента (коды) не будут потеряны, как при использовании варианта 3 🙁
Также 100% твой доп. слой будет потерян 🙂
ЗЫ а вообще подобная схема у меня лично давно реализована с помощью классов 1С++.
И подобные фичи легко добавляются в спец. подчиненный справочник, в котором соответствие один-один к справочнику-хозяину.
Для клиентского кода все прозрачно, только вместо
Спр = СоздатьОбъект(«Справочник.Номенклатура»);
используется
Спр = СоздатьОбъект(«Общие.СправочникСДополнительнымиРеквизитами»);
Спр.НазначитьВид(«Номенклатура»);
Про франча… С какой стати он обновляет конфу, которой занимается сторонний спец? Я бы на его месте не стал её сопровождать. Сопровождение типовой или не типовой совсем разные вещи, деньги и специалисты. Да и сопровождать то, за что ты отвечать не можешь на кой фиг?
2 artbear: > Только я бы не использовал встроенный справочник Аналоги, а сделал бы спец. подчиненный справочник,
Хотелось бы узнать — чем неустроил справочник «Аналоги» — чисто интересно.
То, что при обновлении потеряется доп.слой — это да… но его по тлф. «внедрить» легче, чем большой кусок программного кода по вар.1. Понятно, что по варианту 3 код тоже потеряется — но его всего вообщем-то 3 строчки 😉
…
> При «плохом» обновлении/объединении в этом случае по крайней мере данные клиента (коды) не будут потеряны,
// ну это надо так постараться, чтобы доп.реквизиты убить — это только если загрузить обновление…. 😉 хотя и такое могут отчудить… 😉
..
> с помощью классов 1С++.
… отдавая дань возможностям 1С++ на широкое масштабное применение 1С++ не иду ввиду отсутствия внятной целной документации — и не надо давать ссылки на «обрывки», которые лежат на известных ресурсах… — это нельзя назвать документацией… ну и не надо экскаватором копать ямки для заборныз столбиков… 😉
2 Ioann: совершенно верно, согласен. у сеьбя в конторе сделано так же. Но при «внедрении» к клиенту требуется соотноситься с «возможностями» клиента. Как я писал ниже — такой вариант ДЛЯ КЛИЕНТА непрозрачен. Для нормальной работы требуется «прописать» фишку для заполнения аналогов. Вариант типовой работы с заполнением подчиненого справочника — весьма неудобен с практической точки зрения…
2 poppy: ок. код только длиннее получается 😉
Я, все сделал бы на свойствах номенклатуры. Сделал бы сервисную обработку на подобии обработки группового изменения св-в справочника, это для тех, кто должен отслеживать артикулы сетей. И внешнюю печ.форму torg12.ert подправил бы по своему усмотрению.
Нет геммора с обновлением и с печ.формой.
Угум.. а a бы сделал на аналогах, ибо по сути это и есть аналоги…
> 2 poppy: ок. код только длиннее получается 😉
Букавак больше, но строчек = меньше. 😉
Использование конструкции «Попытка» для определения наличия атрибута смахивает на почерк программистов из Раруса. Не буду разводить здесь антирекламу, но такой почерк вызывает у меня рвотные рефлексы.
Ты сам утверждал, что учился кодить у одноэсовых программистов ( ). Видать, плохо учился…
Не хочу обсуждать, на сколько решение = обосновано. Считаю, что Саппорт его обосновал.
Немного покритикую.
По вопросу обновления и франчей.
Не думаю, что мы доживем до 950 релиза. Если и доживем, то не скоро.
ИМХО очередные релизы пишут какие-то «студенты». Они вносят больше ошибок, чем исправляют. Поэтому, новый релиз + неумелый франч = взрывная смесь.
Если уж «решение» создает Че, то клиенту выгоднее обратиться к нему же за обновлением. Другое дело, что мотаться по Москве, выпоняя обновления = неблагодарное дело.
Как вариант: автор решения готовит очередное обновление, но обновление конкретной базы выполняет ближайший франч.
> Да, привязываться к коду контрагента в наименованиях реквизитов
> конфигуратора может показаться на первый взгляд некомильфово
Не то слово. Очень большое ФИ по этому вопросу.
В восьмерке, например, есть преопределенные элементы, но в серемерке, иногда, приходится принимать непопулярные решения.
> Да, привязываться к коду контрагента в наименованиях реквизитов
> конфигуратора может показаться на первый взгляд некомильфово
Продожение.
Я бы предложила другое решение:
В справочнике контрагентов добавить реквизит: "КодСети" (типа строка(2)). В справочнике Номенклатура, нужно добавить реквизиты "БВК_АртикулХХ", где ХХ = от 00 до 15 (или 20, или другое число).
В коде пишем:
Показать полностью
В рассмотренном варианте мы можем "привязать" несколько контрагентов к одному коду номенклатуры.
> нужно добавить реквизиты «БВК_АртикулХХ», где ХХ = от 00 до 15 (или 20, или другое число).
ну это — ваще отстой…
лучше уж как сделано в статье.. или на налогах/свойствах…
а вот почему Попытка — рвет на родину — непонятно…
Я считаю использование такой конструкции РАЗУМНО ТАМ где срабатывание по ветке «исключение» — не приводит к каким-либо траблам — как в примере вывода печатной формы… Другое дело, что при вычислительном каком-нить алгоритме применение Попытки не есть хорошо — так как БЕЗ ДОЛЖНОЙ ОТРАБОТКИ ИСКЛЮЧЕНИЯ приводит к иллюзии что все есть гуд…
В любом случае — все предложенные решения (кроме описанного в статье) являются существенно БОЛЕЕ ЗАТРАТНЫМИ.. имхо…
А то, что 950 релиза ххз когда дождемся — это да… я у себя в конторе до сих пор на 933 сижу (книги продаж/покупок только из 941 подтянулл в всое время…)
Автор видимо мало работал с крупными розничными сетями. Многие из них еще требуют, чтобы в Торг-12 были ИХ НАЗВАНИЯ ТОВАРОВ, их артикул, их отпускные цены, их цены для промоакций , их штрих код. (Остальное добавьте после внимательного прочтения договора) Помимо Торг-12 могут потребовать еще кучу документов типа протокола согласования цен, разные формы для ввода новых товаров и прочее. Плюс практически все сети требуют отдельно ведения списка товаров, поставляемых им. Некоторые трепетно относятся даже к порядку следования строк с товарами! Добавление новых товаров в их базу почти всегда платное (от 50 до 300 евриков за строку). Рекомендую очень внимательно читать договор с торговыми сетями. Я бы сделал справочник «Товарная матрица», подчиненный справочнику «Контрагенты», в котором для каждой розничной сети вёл бы свой список товаров с их названиями, артикулами, возможно ценами и проч. реквизитами. Решение автора простое, в лоб, но не универсальное.
ИМХО: такое публиковать нельзя, решение простое и работающее, но ничего из себя не представляет.
Подход к решению задачи в корне не правильный! Все три предложенных варианта — не правильные!
2 topasha: все верно. в данной конторе, которая описана выше — необходимости в реализации полной схемы «работы с сетями» как описано тобой ниже — необходимости нет… в другой конторе — там, все посложнее и по полной программе, как грится…
> решение автора простое, но не универсальное…
именно, речь ведь не шла о написании мегаконфиги для работы с сетями…
> Я бы сделал справочник «Товарная матрица», подчиненный справочнику «Контрагенты», в котором для каждой розничной сети вёл бы свой список товаров с их названиями, артикулами, возможно ценами и проч. реквизитами.
я бы не стал плодить излишеств и по максимум воспользовался бы «Аналогами» — тем боле что туда вполне можно впихнуть и артикул, и наименования, цены для каждой сети свои — тоже нормально реализуется штатными возможностями… доп.реквизиты — в свойства — все это, конечно, если работа с сетями не составляет ОСНОВНОЙ доли деятельности. Тогда имхо точить конфигу надо именно под автоматизацию работы с сетями…
2 angro: т.е. лучше публиковать навороченное решение с кучей ошибок…? 😉
смысл именно такой и был — прсо, без заморочек… суть уловлена верно.
Вот, блин, тоже сейчас начну статьи писать, как я разным клиентам реквизиты добавлял! Вот статьей-то наваяю… 😉
зы: Но минусовать не буду, потому что принципиально против минусов 🙂
В моём решении как раз заморочек меньше всего, а наворотов нет вообще. Можно даже и интерфейсов не мутиит никаких. достаточно показать клиенту, как штатно открыть форму списка подчинённого справочника и всё! Можно даже типовые обновления ствить без боязни что-либо утерять. Просто предложенные решения задачи методологически не верны в принципе, даже для маленькой конторы!
> > нужно добавить реквизиты «БВК_АртикулХХ», где ХХ = от 00 до 15 (или 20, или другое число).
> ну это — ваще отстой…
Не отстойнее, чем исходное решение… ИМХО 😉
Я даже не осуждаю то, что автор в своей статье многочисленно оправдывается за принятое решение.
> В любом случае — все предложенные решения (кроме описанного в статье) являются
> существенно БОЛЕЕ ЗАТРАТНЫМИ.. имхо…
Не существенно и не БОЛЕЕ.
Бюджет моего решения соизмерим с исходным. А если учесть перспективу «разруливания» ситуации по телефону, то значительно ниже как для заказчика так и для исполнителя.
Мое решение является более универсальным. В частности:
— у разных магазинов одной сети могут быть разные реквизиты. В этом случае разным контрагентам можно назначить одинаковые коды товаров;
— при появлении новых магазинов (сетей) пользователь добавляет данные в привычном для него интефейсе в т.ч. и без консультации по телефону.
В развитии решения можно добавить следующее.
Создать справочник «Сети». Тип реквизита КодСети справочника Контргаенты установить этот справочник. В форме элемента справочника Номенклатура показывать только те реквизиты, ХХ которых совпадает с кодом одного из элементов справочника Сети. Надписи для них брать из нового справочника.
«Коленчатые» решения действительно иногда жывут «успешно» и долго. Но в большинстве случаев из-за того, что уйти от них бывает дороже, чем выполнять разовые доработки.
Складывется впечатление, что заказчик и автор решения не знакомы с известным правилом: Я не настолько богат, что-бы покупать дешевые вещи.
Единственный плюс исходного решения отмечаю использование иднтификаторов реквизитов ПРЕФИКС_АртикулNN вместо БВК_АртикулАшан.
> а вот почему Попытка — рвет на родину — непонятно…
Потому что в аналогичных ситуациях эту конструкцию используют программисты из известной большой франчайзинговой фирмы.
Конфигурации от них у меня ассоциируются с неработающими поделками.
Складывается впечатление, что свои решения они создают на «коленках», распостраняя их потом на всю страну. Вот и рвет на родину.
Я не против использования конструкции Попытка в целом и в рассматриваемой ситуации в частности.
Кстати, если бы такое решение (Вариант 3) предложил какой-нибудь новичок, что Чебур первый бы его зачморил ИМХО.
Ух! 🙂
Как я понял автор хочет защититься от дурака-обновляльщика.
Думаю что добавленный реквизит с точки зрения обновляльщика мало отличается от добавленного справочника.
Можно использовать префиксы для добавляемых объектов матаданных. Например, реквизит назвать ЧЕБУР_КодыСетей или назвать справочник ЧЕБУР_АналогиСетей.
Вариант2 наиболее защищён от дурака-обновляльщика, поскольку на первый взгляд требует меньше изменений в коде.
Вариант1 vs Вариант3
Трудоёмкость написания кода для разбора строк не меньше чем трудоёмкость написания кода для работы с подчинённым справочником. Кроме того для облегчения обновления форму элемента лучше трогать поменьше. Я бы навесил на неё только кнопку с вызовом справочника аналогов или формы обработки по заполнению аналогов. Получается что разница в объёме кода между первым и третьим вариантом исчезающе мала, а вот разница в ссылочной целостности и лёгкости доработки — значительная.
Вариант2 vs Вариант3 vs Вариант1
До сраки как сделать, главное чтобы работало и чтобы пришедший после тебя не сильно матюкался.
Любителям универсальных решений — в сад. Лучше неуниверсально и просто, чем универсально на сложно и с множественными переломами мозгов при попытке использовать где-то ещё.
Касательно комментариев. Лучше писатьтак
а так
//(( Чебурашка 07.07.2007
//)) Чебурашка 07.07.2007
Автору плюс за поднятую тему.
спасибо Трактору за комент. единственное с чем не соглашусь
> то разница в объёме кода между первым и третьим вариантом исчезающе мала,
— на мой взгляд разница в коде — весьма существенна… хотя кто как считает…
> ЧЕБУР_КодыСетей
ну так и названо — БВК_Артикул…
Зачетная статейка. Конечно про «правильность» подхода мы тут говорить не будем, ведь для определенного решения это есть гуд.
Вот слова истинного Дао!
Кстати, задача, изложенная в (11) все еще актуальна…
Программистам может и не нравится, что ж их мнение…
Но ведь нравится пользователю. Мне как пользователю — это удобно. Это комфортно.
Мало того, я знаю, что если вдруг возникнет проблема, мне её сразу решат. Серёжа, спасибо, с тобой очень комфортно работать!
43) Полностью присоединяюсь!
Спасибо за статью — ваше зерно опыта в нашу копилку!!!
в комментах товара ввел для клиента правило на заполнение первых символов типа !М3253!А5643! и создал отдельные печатные формы расходных, счетов, ттн (пришлось повозиться с группировкой товара по их единому коду), от !Мдо! — Метро, от !А до ! Ашан … в печ.форм. подставлял кода — печ.ф. М — метро, А — ашан..
МЕТРОимся и АШАНимся… захитали… особенно МЕТРО…
+