<?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='\
Почему бы не отнести к «оперативным» все остальные регистры? И при перепроведении исключить манипуляции в т.ч. и с остальными регистрами?
… Потомушта нельзя быть красивой такой …
Если кратко (имхо глубокое):
1. история остатков/взаиморасчетов/авансов/прочего — имеем значение для бухии и/или УУ;
2. можно уйти от ГП, но получится «неуниверсальный» механизм, достаточно трудоемкий и неочевидный для юзера (непривычный).. чтобы сделать его «привычным» — забодаешься…
Если говорить о типовой ТиС – полностью согласен. А если говорить в целом, то при проектировании схемы базы данных надо соблюдать простое правило – вычислять надо только те значения, которые нужны НА ТЕКУЩИЙ МОМЕНТ. А те, которые требуются один раз в месяц – вычислять как рабочую величину именно один раз в месяц. И делать это в выходных формах, а не в “регистрах длительного хранения”.
(3) ГП — универсальная штуковина и катит везде. Все прочее — придется «специализировать», как пример, например лекарства — там, например, списываемую себестоимость в конце месяца не посчитаешь… + для оперативного управления, например, ВСЕ ВРЕМЯ вычислять раскладку «себестоимости» может быть накладно, и проще держать ее по факту возникновения в регистрах… — итого: вываливаемся в специализированные нетиражируемые решения…
+ мысль следующая: добавив в регистр измерение «документ» можно писать для этого «документа» движения в любой момент, а не только самим «документом» — тут надо подумать… идея, имхо, перспективная…
(2) по п.2
Посмотри решения от hogik’a. Он отказался от ГП, создал математику и реализовал альтернативный движок.
У него все регистры — «оперативные», но у тебя = не рыба, не мясо
Изменение остатков задним числом без изменения Резервов и ЗаявокЗаказов = бяка.
Несложные манипуляции «задним числом» с остатками приведут к тому, что «оперативные» регистры потеряют свою актуальность и перестанут отражать действительную реальность.
(5) > Посмотри решения от hogik’a.
…ссылка?
> Несложные манипуляции «задним числом» с остатками приведут к тому, что «оперативные» регистры потеряют свою актуальность и перестанут отражать действительную реальность.
…а вот и нихренюшеньки! как раз наоборот!!! На текущий момент мои «оперативные» регистры будут отражать текущее состояние дел, ПРИЧЕМ С УЧЕТОМ ТОГО, ЧТО ПРОИЗОШЛИ ИЗМЕНЕНИЯ ОСТАТКОВ ЗАДНИМ ЧИСЛОМ. Что может быть:
— остатков стало на ТА больше — ничего страшного не произойдет, ситуация НЕ УХУДШИТСЯ.
— остатков на ТА стало МЕНЬШЕ — в худшем случае не сможем обеспечить требуемое кол-во резервов/заявок/заказов — ну так это и есть правда на ТА — часть из них скушана «взади»…
(4)( Сhe Burashka)
Если типовую ТиС не переделывать полностью под конечного пользователя (продавца, кладовщика, мастера производства и т.д.), а считать конечным пользователем бухгалтера то, действительно, получится “не рыба, не мясо”.
(5)(poppy)
И у нас проблем навалом. Иногда, я очень жалею, что я затеял эту полную переделку конфигурации. Думаю, мы “перегнули палку в другую сторону”. Система работает в режиме 24х7 уже восемь лет. Но, с каждым годом всё труднее и труднее учитывать новые пожелания пользователей. Потеряна гибкость, универсальность и “заменимость разработчика”… ;-(
(6)(poppy)
“»оперативные» регистры потеряют свою актуальность”
Не потеряют – они же в апострофах. Как пример. Регистров “Резервов и ЗаявокЗаказов” не существует. Это реализуется простым перемещением на “склад резервов и заказов”. 😉
(7)(Сhe Burashka)
Ссылки нет. Могу только пригласить Вас к себе в гости.
попутно еще одна фишка озвучу (я ее уже подымал) — достаточно интересно подумать над системой автораспределения поступления ТМЦ под необходимые заявки/резервы, КОГДА НЕХВАТКА НЕОБХОДИМОГО КОЛ-ВО ТОВАРА СТАВИТСЯ «В ОЧЕРЕДЬ» К ПОСТУПЛЕНИЮ ПРОСТЫМ ВЫВЕДЕНИЕМ РЕЗЕРВИРОВАНИЯ «В МИНУС» … — тут думать…
(7)
Здесь обсуждение (в комментариях)
(9) В гости — это интересно… Тем более, что Владимир от Москвы недалеко.. Надо подумать над этим… было бы интересно поговорить, опытом поменяться… правда я сомневаюсь, что я что-то интересное смогу выдать…
(11) в обсуждении коментов Ходжик сказал «Остатки сходятся» (Есть остатки (итоги) на реальных полках.) — это да, вопросов нет если это только торговля… для бухии важны «виртуальные» вчерашние кошельки/полки — что выгоднее — каждый раз тащить данные отчетом или вытаскивать из регисторв — хз… тем более, что схема хранения данных, описанная Ходжиком, «близка» к системе регистров остатков 1Сины (на беглый взгляд).
(12)
> Тем более, что Владимир от Москвы недалеко..
Может я неправльно поняла, но Владимир в Москве?
Я бы тоже в гости не отказалась… 😉 Хотя, также, выдать что-то вряд-ли интересное.
(14)(Сhe Burashka)
“я что-то интересное смогу выдать”
Это и не требуется 😉 Я очень внимательно слежу за Вашими публикациями на данном сайте. А вот, сколько потребуется “сидеть” около нашей разработки – это вопрос. А типа, видео ролика от Олега по “Кассирочке” маловато будет. Кстати мы не во Владимире, а в 15-20 километрах от МКАДа.
Смелое и новаторское. Это усегда гут. А если еще и работает, то вообще! Впрочем, важна идея прежде всего.
Введение оси времени, сделанное 1Синой, порождает целую кучу казусов, которыми люди пытаются «потыкать в грязь лицом (ласково)», типичный пример (оттуда же):
..
разберем простейшую ситуацию:
1) введен приходный документ — 5 пар кирзовых сапог
2) зарезервировали 4 пары для клиента
3) обнаружили пересорт — 3 пары сапог и 2 пары тапочек, исправили задним числом приходник
4) вопрос — достоверен ли резерв? в каком состоянии будут остатки после продажи?
как отрабатывается данная ситуация?
..
При этом забывается, что несмотря что ось времени есть — МАШИНЫ ВРЕМЕНИ НЕТ. И если обнаружен пересорт, то В ОБЩЕМ СЛУЧАЕ выход только один: ТЕКУЩИМ ВРЕМЕНЕМ «скорректировать» ТЕКУЩИЕ ОСТАТКИ и «СКОРРЕКТИРОВАТЬ» РЕЗЕРВЫ и ПРОЧИЕ «ОБЯЗАТЕЛЬСТВА» !!!___ПО ФАКТУ ОБНАРУЖЕНИЯ НЕСТЫКОВКИ___!!! ВСЕ!!! иначе — не бывает.
ИНАЧЕ — только полная перерисовка всей АМБАРНОЙ КНИГИ с самого момента РЕГИСТРАЦИИ «НЕПРАВИЛЬНОЙ» записи. — а ведь амбарная книга-то прошита, пропечатана, и пронумерована на каждой странице. ВСЕ! ППЦ! никаких задним числом правок. Любая правка задним числом — иди на поклон к барину и проси разрешения…
> Иногда, я очень жалею, что я затеял эту полную
переделку конфигурации (фраза от Ходжика)
.. вот!!! мой мелкий опыт показывает — очень во многих случаях (для ТОРГОВЫХ компаний) можно добиться работы только в ТА и в типовой ТиС — это требует в первую очередь дисциплины документооборота и выполнения обязательств поставщиков/покупателей. Примерное время приведения «бардака» в «порядок» — от полугода до года.
Но по-моему, надо не типовую терзать, а давно пора свою писать по накопленному опыту и выставлять, как альтернативную. Кстати, можно у суппорта перекупить название «Апельсин», ведь оно к чебурашкам как раз напрямую относится. 😉
(15) так что наклевывается поездка к Ходжику — если недалеко от МКАД… (по вопросам совместного заседания — спишемся в привате)
(19) Главное, чтоб гвоздей вместе с апельсинами не было… 😉
Писать альтернативную конфигу — можно попробовать, но совсем простенькую, типа количественного учета «для ларька»…
> Но по-моему, надо не типовую терзать, а давно пора свою писать по накопленному опыту и выставлять, как альтернативную.
..неоднократная проработка этого вопроса на разных клиентах, которым «мне вот совсем ничего надо — совсем простой учет нужен», показывает что клиенту возможно понадобится и вот это, и вот это, а! да! это точно надо, я совсем забыл… и т.д. — в итоге практически весь функционал типовой ТиС… так что если ставить вопрос широко (на размах моих ух) — то надо сделать «вторую типовую ТИС» с «человеческим лицом» — а на это, боюсь, силенок у нас не хватит…
…по хорошему что надо — в типовой ТиС четко по блокам разнести движения денег и движения ТМЦ, в т.ч. разнести это по разным последовательностям.
… и ВООБЩЕ! ГЛУБОКОЕ ИМХО: следующий рывок имеет смысл делать в более явной блочности построения типовых конфиг (пусть даже в ущерб производительности)…
(18)( Сhe Burashka)
“можно добиться работы только в ТА”
У нас это не получилось – пришлось отказаться вообще от этого, на мой взгляд, странного понятия. Организация, то у нас (по количеству пользователей) не мелкая – уже около 75 рабочих мест. И все в 1Су норовят войти…
(19)(O-Planet)
“свою писать по накопленному опыту”
Ох. Сейчас, думаю, что и не надо. Нашу систему писали 1,5 человек, и всё пишем -пишем…
…все куда-то срулили… я не Сруль, я — Чебурашка… пойду повтыкаю в экстремальное кино (посудить на Питерский фест надо) и спать через часок…
(26) на мой взгляд, работа в ТА как раз не странное понятие — как раз и есть та самая «реальная полочка», про которой ниже по ссылке обсуждались комменты.
… ясен пень, раздолбайство (в организации), ничем не лечиться… можно сгладить симпотомы, но плата за это — сидим «на игле» «нетипичной пневмонии»…
Если говорить о программе для торгового концерна с кучей филиалов, то свою писать не надо. Я сталкиваюсь часто с средними и мелкими фирмочками, которые 70% ТиС не используют, но вынуждены отрабатывать (разные проекты, основные свойства и т.д.) По-нормальному, нужна махонькая прога для торг. организации с нормальным партионником, с приятным интерефейсом и с защитой от ввода задним числом (чтобы оно — излюбленная операция юзеров, поддерживалось, но все не портило). В ТиС есть предпосылки богатой аналитики, но иногда элементарное оказывается не реализовано. Пример — отчет по продажам ТМЦ. Узнать бы, кто придумал туда вместо склада МОЛ вставить! Самое прикольное, что этот МОЛ у всех либо проигнорирован, либо один. А потом просят: покажите продажи в разрезе магазинов. Приходится доки иногда за год перепроводить.
(27)(Сhe Burashka)
Про ТА можно долго говорить. Но самое лаконичное Ваше –“что несмотря что ось времени есть — МАШИНЫ ВРЕМЕНИ НЕТ”.
“плата за это — сидим «на игле» «нетипичной пневмонии»…”
Вот мы и платим. А если зарабатывать деньги заказами, то наше решение никуда не годиться. Так, – частное решение, хотя и работает в конкретной организации совсем не плохо.
(28) Продажи в разрезе магазинов: юрлицо — одно, несколько фирм, каждая фирма = магазин.
(28)
> Я сталкиваюсь часто с средними и мелкими фирмочками, которые 70% ТиС
> не используют, но вынуждены отрабатывать (разные проекты, основные
> свойства и т.д.)
Они что, мазохисты? ТиС нормально без проектов и основных свойств работает…
(20)(Сhe Burashka)
Кстати. Списаться в привате, средствами данного сайта, для меня проблематично – мозгов моих на это не хватает. Решил сегодня написать сообщение и обнаружил, что мне там куча писем пришла. В старой версии сайта мне приходили сообщения на реальную почту о том, что поступило сообщение в приват данного сайта. А теперь не приходят. И я не понимаю, как посмотреть свежие сообщения.
(31) Проекты — это любимое средство многих! вот вам ище одна идея, которая существенно облегчит жизнь.
— должноа быть возможность на любой док повесить любое количество маркеров-тегов (с предопределенными/любыми) значениями… ряд проблем/задач решался бы на раз (типовая задача: отметить и взять «на контроль» некоторые документы) — т.е. аналог свойств для документов (по образу свойств для справочников…) — И ТАКАЯ ПАРАДИГМА БУДЕТ БЛИЗКА ДЛЯ МАНАГЕРОВ!
(32) мой мыло для контакта: e.meil@mail.ru
nm[e на вас всех газировкой с сиропом (апельсиновым), отключаюсь… в выходные выходите на связь!!!! тогда можно продуктивно пообщаться!
>> — должноа быть возможность на любой док повесить любое количество маркеров-тегов (с предопределенными/любыми) значениями…
Идея эта не нова. Я такое сделал в одной фирме, только «навешиваю» на доки статьи расходов для внутреннего учета. И у мну в Документообороте они тоже есть, но ты говоришь сейчас о более общем. А вообще, маркеры на доки пора бы уже кому-то запатентовать… 😉
(33)
В восьмерочных конфигурациях это уже реализовано. Там документам можно назначить и свойства, и категории.
(37) это хорошо…
Значит всего-то и осталось восьмёрочную конфигурацию «переписать» под семерку…. шучу.
Начал изучать 1С 8.х и опять, как и при изучении 1С 7.7, задумался над фразами:
“Факт проведения документа и необходимость поддержания актуальной последовательности документов на оси событий порождают…”
“…отметка времени создается системой каждый раз при … проведении документа”
Т.е. “ось событий” отражает работу оператора по вводу документа. Мне в торговле известен только один документ, где событие набивки документа соответствует реальной жизни – это чек ККМ. В остальных документах нет единого события, по которому можно построить ось событий и сопоставить ее с действиями операторов по набивки документов. Точнее, этих событий множество — дата первичного документа, дата отгрузки, дата прихода на склад, дата списания остатков (реально отгрузки), дата разрешения отгрузки и т.д. Но все эти даты не имеют никакого отношения к работе оператора и компьютера. Тогда зачем ЭТО?
(40) УТ, как и ТиС в 7.7, к _процессу_ торговли имеет весьма отдаленное отношение…
(41) +1
(42) НО! это — плата за универсальность (в какой-то мере).
Явно не секрет, что есть куча решений, разработанных и поддерживаемых в конторах фиксями/фрями (наверняка с кучей интересных/оригинальных решений/находок) — но в «массовом производстве» — их не видно…
(18)+(19) поясню согласие с обоими.
Либо ТиС, либо своя с нуля самописка по хотелкам.
Корежить типовую — самое гиблое дело. Для студентов.
(44) Тут я не совсем согласен. Типовая ТиС вполне работоспособна в большинстве организаций в основном своем функционале (вот она выгода универсализма), грамотная «доточка» и скрытие ненужных/неиспользуемых возможностей — экономит кучу времени по написанию «нетленок»… Как раз хуже всего когда «студент» начинает корежить типовую под запросы клиентов, при этом очень слабо представляет собе логику и возможности типовой — не только в плане технической реализации, но и в плане МЕТОДИКИ применения… Для «штатных» ситуаций клиентов чаще всего приходится «подтачивать» взаиморасчеты в разрезе поставок/продаж… все остальное — если понадобилось, то, как правило, на фирме уже есть свой прог… (другое дело если прог — «вещь в себе» — вероятность того, что решения будут «кривые» — очень высока). На примере старой работы: (опт лекарства) — все доточки были сделаны на 95% внешними отчетами/обработками + минимум изменений в ключевых точках (по возможности с вызовом внешних обработок), в результате если студент «накатит» типовое обновление «не глядя» — такие клоуны встречаются — прога будет по-прежнему работоспособна с потерей некоего функционала…
(40)
“УТ, как и ТиС в 7.7, к _процессу_ торговли имеет весьма отдаленное отношение…”
Это я понимаю 😉 Но и на других участках АСУ-па существует понятие первичный документ. Существует, для некоторых документов, “необходимая” хронология их обработки. Но на коробке продукта 1С: Предприятие написано “Сетевая”. Я это понимаю как – “многопользовательская”. И документы в систему могут поступать в произвольном порядке – ну, например, разделили операторы пачку документов между собой. И при вводе документов компьютерная “ось событий” теряет всякий смысл. Т.е. после ввода документов их надо в “монопольном” режиме расставить на ось. Но если критична последовательность операций, то это достигается другим способом. Например, если критично продавать конкретный товар конкретной накладной, то это партионный учет c ручным выбором партии в расходном документе. И какое это имеет отношение к взаимному расположению приходной и расходной накладной по компьютерной дате и времени? Т.е. средства обеспечения последовательности операций должна базироваться на самой сути этих операций. Или я чего-то не так понимаю?