<?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='\
Для реального использования неудобно, но за идею плюс.
Согласен, не совсем удобно. Но в помощь пойдет. В планах сделать более удобную вещь, которая будет делать такой контроль автоматом и отсылать результаты по почте или другим способом информировать.
в любой типовой можно отключить проверку на оперативность и получим тоже систему контроля (со своими недостатками, но с громадным плюсом — минимальные изменения в конфе)
Такой системы контроля, которая контролирует все последующие движения, ни в одной типовой конфигурации нет. И хотелось бы узнать, что вы имеете ввиду, когда говорите про отключение проверки на оперативность?
(4) в типовых есть процедуры контроля остатков. они вызываются только при оперативном проведении документов. если отключить проверку на оперативность проведения документа, то процедуры будут вызываться всегда. При этом все запросы выполняются на текущее время. Таким образом, получаем контроль за тем, чтобы исправления прошлых периодов не вогнали в минус текущие остатки. Минус, естественно, в том, что не проверяется возникновение минусов на всем временном промежутке, а только в конечной точке.
Но уж лучше такая проверка, чем идеалистическая логика 1с об оперативном проведение.
(5) Я так понимаю, что отключать вы собрались изменяя код типовой конфигурации. Это самое страшное, что может сделать разработчик. Мне и в страшном сне не приснится менять код типовой конфигурации. Вы представляете себе, что вам постоянно придется контролировать, чтобы при обновлении не затереть все свои изменения? Овчинка выделки не стоит — изменить код типовой конфигурации, чтобы получить «недоконтроль». А 1С в этом случае не надо ругать, логика оперативного контроля абсолютно правильная. Если проверять все движения при проведении — это нагрузка на базу, поэтому 1с его и не делает.
(6) хее… волков не боятся — в лес не ходить…
Доработка конфигурации под конкретные нужды — нормальная практика. Если Вы боитесь менять типовую — значит Вы плохо знаете основы и конкретную конфигурацию, а также механизмы её работы. Лично я, а также многие другие здесь не боятся дорабатывать конфигурации и потерять что-то при обновлении. Работаю и обновляю 1с УПП, Бухгалтерию, Комплексную с 8.0 версий (если поискать на инфостарт можно найти несколько статей о том, как можно эффективно вносить изменения для дальнейшего облегчения обновления)
В 1с сидят идеалисты, которые разрабатывают конфигурации для каких-то мифических компаний с неким шаблонным учетом. Практика контроля остатков только при оперативном проведение не выдерживает встречи с реальностью. Как и многие другие механизмы 1с. Не это ли Вас сподвигло на написание этой статьи?
Оперативный контроль остатков ВООБЩЕ не работает на практике, более того, он ВРЕДЕН. Я сразу указал, что мой способ имеет много минусов, но он уже ЛУЧШЕ для конкретного учета, чем преложенный способ от 1с, возросшая нагрузка, по сравнению с Вашим способом ничтожна, а изменения в конфигурации — минимальны.
Вопрос не в том, чей подход правильнее (1с, мой, Ваш), а в том, какой из них больше подходит для каждого конкретного случая.
Ишь ты какой ! «идеалисты !»
Ты создаешь частное конкретное решение («Для сэбэ») .
1с создает универсальное решение («Для всех»).
Разницу чувствуешь ?
Ты предложи общее решение и мы вместе похихикаем над его «идеальностью».
1с создает универсальное решение («Для всех»).
Разницу чувствуешь ?
Ты предложи общее решение и мы вместе похихикаем над его «идеальностью».
Решения от 1С совсем не универсальны, для универсальности необходимо делать возможность параметрических настроек, причем делаются они достаточно элементарно, так что «ругать» 1С есть за что (имхо)
(9) Параметрические настройки в 1с ЕСТЬ : Главное меню-Сервис-….
Потрясающее открытие.
Достаточны ли они ? Возможно , нет.
Поругаем 1с ? Давайте …
(8) в (9) правильно сказано… Делали бы решения «для всех», то в некоторых местах логика построения модуля была бы другой.
Для примера:
система резервирования… Тупо нет переключателя, чтобы отключить контроль резервов для реализации и оставить его для заказов — забыл менеджер снять резерв, ушел домой, а ночью отгрузка остановилась — не могут провести и распечатать документы.
Система скидок — скидки ВСЕГДА считаются от суммы, а те же торговые сети скидки считают от цены
Возможность штатного проведения будущим числом — ОЧЕНЬ иногда нужная вещь.
Указание цены при операциях с ответхранением
Отсутствие связи «Документ основание» между требованием-накладной и Отчетом производства
Механизм создания документа реализации на основе заказа — НАФУЯ НЕЛЬЗЯ ОТКЛЮЧИТЬ ТАМ КОНТРОЛЬ ОСТАТКОВ???
Возможность печати для непроведенных документов только определенных печатных форм — как мне печатать задание на погрузку? из заказа не подходит — некоторые заказанные товары грузить нельзя…из заказа их убрать тоже нельзя — нужно контролировать выполняемость заявок…
ещё раз. 1с пишет не «для всех», а для «идеальной» торговой компании… которая в реальности загнется из-за отсутствия необходимой гибкости. Её просто обгонят конкуренты.
(10) ДА! Мало параметров! ОЧЕНЬ МАЛО.
(13) Отвечу тебе тяжелым плюсом.
(10) Спорить не вижу смысла, так универсальные системы не пишут… Это не универсальная система получается а заготовка — мол вот вам ребята шаблончик дальше сами (шаблончик согласен — для всех) (имхо)
(8)
Прошу прощения, бред. Если бы 1С выделила нечто общее (для всех) и добавила варианты надстроек — цены б ей не было. А на самом деле решения 1С «заточены»: зарплата — под офис (в табеле не факт, а отклонения), УПП — под «отверточное» производство. И все моноблоком.
Параметрическая настройка функционала должна была бы подключать к общему ядру нужную надстройку и отключать ненужную. А тут в лучшем случае дается возможность что-то выключить, причем без гарантий, что при этом заодно еще что-нибудь не отключится.
(16) Не будет тебе прощения. Ты передернул .
В посте (8) был призыв понять разницу в сложности решений «для сэбэ» и «для всех».
Но вовсе не утверждалось , что решения от 1с («для всех») не обладают недостатками.
(17) Я же утверждаю, что решения 1С — это «для сэбэ». Они придумали некую модель (модели) фирмы, и пишут для нее. Тут речь не о недостатках идет, а об отсутствии методологии.
(6) «Мне и в страшном сне не приснится менять код типовой конфигурации.»
ноу комментс 🙂
(11) «Механизм создания документа реализации на основе заказа — НАФУЯ НЕЛЬЗЯ ОТКЛЮЧИТЬ ТАМ КОНТРОЛЬ ОСТАТКОВ???»
имхо, если создаешь рнк на основе заказа И если он тебе помешал — он сделан не зря
(18) В точку!
Опять сформулировал мои мутные мысли 🙂
(21) Обращайся 😀
(7) вот как раз те, кто «не очень знает» основы и типовые конфы и стремятся перепахивать типовой код и изменять его налево-напрово. Высший пилотаж — это когда вы без изменений типовых функций достигаете целей и заказчик с чувством полного удовлетворения платит вам деньги за работу. Заявления о том, что «я УПП обновляю» ничего не говорят… ну я тоже УПП обновляю и прекрасно знаю, что такое в УПП доработать тот или иной блок. Несмотря на то, что в конфе уйма доработок я обновляюсь в полностью автоматическом режиме, зная, что обновление ничего моего не затрет.
То, что вы не боитесь «потерять что-то при обновлении» — это похвально, но дело то не в боязни. Интересно, что скажет клиент, когда после вашего обновления он лишних пару миллионов налогов заплатит.
А насчет подхода, что каждая ситуация требует своего решения — с этим абсолютно согласен. И я допускаю, что могут быть ситуации, когда действительно нужно менять что-то типовое, но этого нужно избегать — так всем проще и правильнее жить — разработчику проще обновлять и поддерживать, клиенту спокойнее.
Обработка правильная, жаль не для конечного пользователя.
Недавно пришлось решать именно эту задачу, изменение документов задним числом и контроль остатков уже проведенных документов, не много конфигурацию поменял на регистре «ТоварыОрганизаций» сделал ругалку и запрет записи.
За идею полюс.
(7) Смотри-ка, в (23) тебя похвалили 😀
(24) а как бы вы ее видели для конечного пользователя? только именно обработку, без изменений в типовой конфигурации. мне кажется не очень хорошо, делать такой контроль именно при проведении документа, т.к. все-таки нагрузка на базу 1с — это слабое место, особенно в УПП и особенно когда много пользователей одновременно работают — сразу же риск нарваться на блокировки (снижается параллельность работы).
(20) а мне вот нужно, чтобы заказ полностью переносился в реализацию — дальше разбираться будет склад и производство. Заказ менять нельзя — как иначе контролировать процент выполнения заказов? А в типовой этот долбанный контроль мешает мне в той ситуации, когда заказ есть, в производство товар запущен, через час выйдет и пойдет сразу в машину, а операторы вынуждены вручную набивать реализацию, чтобы подготовить её вовремя к отправлению машины. Вручную — потому что товар ещё не оприходован (производство то ещё не закончено), а ввод на основании не видя остатков трет им всё… И в типовой НЕТ галочки, чтобы отключить это.
(23) вообще-то к этому тоже стремлюсь, но стержень в за…це разработчиков типовых 1с сидит глубоко — гибкость конфы в некоторых местах нулевая, а возможность того или иного вида операций начисто отрицается — приходится комментить и добавлять пары строчек своих. Все мои изменения не носят глобальных характер. Если интересно — почитайте мою статью об облегчении обновления.
(27) проблема «набивать» тупо по-1сному решается заполнением тч. или у тебя 77?… «ввод на основании не видя остатков трет им всё» — ни разу ни понял. тебе надо отпустить клиента или списать непроизведенное?
(26) Как внешнюю обработку скорее всего никак:
— Внешняя печатная форма не пойдет, вряд ли будут запускать
— Отчет за период, смысла вроде нет, есть «Проведение по партиям»
У меня задача была довольно простая:
в течении дня делают что хотят, а вот задним периодом надо проверять. Права с «полных прав» понижать нельзя.
а дальше все просто: проверка только на прошлую дату, проверка на открытую форму ну и потом проверка на коллизии.
А блокировки как-то вроде привилегированным режимом вроде и вылечиваются.
(27) если память не изменяет, то у документа реализации есть кнопка заполнить, где можно заполнить составом заказа, но даже если ошибаюсь, то всегда можно сделать свою обработку и не нужно будет вносить изменения в типовой код.
Насчет негибкости в некоторых местах — согласен. Уже долго 1с уговаривают, чтобы сделали подписки на события формы. Ну вроде бы для 8.2 Сергей Нуралиев обещал подумать. Скорее всего сделают. А вообще-то разработчиков платформы и типовых конфигураций тоже можно понять. Они разрабатывают не какую-нибудь филькину грамоту, а финансовые системы учета и думают о таких вещах, которые нам с вами и подавно в голову не придут. Бывают и ошибки. А вы мне покажите хоть какую-нибудь систему, где никогда не бывает ошибок.
(28) Всё сводится к тому же — допиливать… Ведь можно было дописать 5 строчек кода… Нет. Возможности выбора не оставили. Нужно или править конфу или писать заполнение табличных частей, которая уже и так содержит 4-5-10 таких вот «доработок»…
А что нужно… Нужно, чтобы заказ остался нетронутым, а операторы получили реализацию, которую они отредактируют «по факту».
Процесс выглядит так:
1. Поступил заказ
2. Заказ проверен на наличие, если надо формируется заказ в производство (устный или в 1с — не важно)
3. На основе заказа формируется реализация (не проводится) откуда убирают заведомо недогруз (нет на складе и производить не будут).
4. Печатается наряд на погрузку (реализация не проведена — тут как раз и нужны печатные формы, которые можно печатать даже с штатным запретом на печать непроведенных…1с сейчас запрет поместило грамотно в соответствии со своей логикой — легкой правкой конфы не обойдшься — пришлось Заполнение табличных частей использовать).
5. Пока товар грузится проверяются цены и скидки, заполняются доп.поля (водитель, машина и т.д.)
6. Во время погрузки из цеха выходит продукция и её тоже грузят в машину. В это время мастер забивает отчет производства и кладовщик оприходует этот товар.
7. машина погружена
8. корректируется неучтенный недогруз, накладные проводятся и печатаются…
9.Машина ушла.
Накладных не 1-2, в а несколько десятков в день, по 10-20-40 позиций штучного и весового товара.
(29) позиция понятна. скорее всего моя обработка действительно неудобна в тех случаях, когда изменения задним числом имеют массовый характер и являются нормой. но я ее для этого и не писал. она скорее подойдет для людей, которых хотят подстраховаться в случае нечастых неоперативных проведениях.
«Они … которые нам с вами и подавно в голову не придут»
однозначно плюса 🙂 :{}
(31) звучит как УПП 🙂
(30) именно поэтому разработкой занимается КОМАНДА. И в этой команде должны быть люди, которые отвечают за юзабилити… А они там лапти вяжут…
На уровне платформы юзабилит делают, а в конфе косячут…
Вот на кой ляд нужно ставить «Пропускать при вводе» на поле характеристика????
Заказ и реализацию обычно вводят на одной клаве…
Из заказа очень удобно формировать реализацию — одна кнопка… А в реализации указывать заказ уже неудобно — создать реализацию, проставить контрагента и договор, выбрать заказ, а потом уже щелкать мышью. Если из заказа делать реализацию, то нифига не эргономично снова нажимать на кнопку «Заполнить по заказу» — тем более, что она вызывает всё ту же обработку с контролем остатков
(31) Именно…
Штатные механизмы — неэргономичны… Приходится допиливать по мелочи… В реализации уже несколько заполнялок табличных частей для разных целей. А иногда легче закомментить 1 строчку, чтобы работало как хочется.
З.Ы. Ещё раз. Я не говорю о доработках и изменениях идущих в разрез с законом или основных процессов. Просто некоторые мелочи очень затрудняют жизнь при вводе первички.
(32)
Если рассматривать постановку задачи как
> «..для людей, которых хотят подстраховаться в случае нечастых неоперативных проведениях.»
в этом случае мне кажется больше бы подошел отчет за период (с момента границы последовательности) с выводом коллизий и вариантами их разрешений по всем цепочкам документов. Но хлопотно это.
В этом виде, имхо, обработка интересна только специалистам. В типовых конфигурациях есть «Универсальная обработка справочников и документов», замечательный инструмент, но используют её, по моим наблюдениям, ничтожно малое количество пользователей. 🙁
Обработка не жизнеспособна 🙁
Как правило, пользователям совершенно неудобно контролировать каждый документ 🙁
Намного проще сделать какой-то отчет, который покажет минуса в остатках по документам за какой-то период.
(0), (38) А ежели так: при проведении задним числом проверяем еще и остаток на «на сейчас», вычитаем количество, списываемого товара данным («задним») документом.
И если получаем отрицательный результат — запрещаем проведение.
Или сразу не запрещаем, а выводим вопрос с двумя кнопками: «Пох» и «Нах» 😀
(39) схему двойного контроля народ пользует давно. К сожалению, она не дает гарантии, что в промежутке датаДока-ТекущаяДата не появятся минуса.
ЗЫ: Вообще стоит задуматься, почему 1С изменила схему контроля остатков при работе задним числом, и попробовать понять эту логику.
(40)
Это точно, но хотя бы на текущую дату будем иметь нормальный остаток
(39) чего можно достичь отключив проверку на оперативность проведения. В типовых проверка остатков при оперативном проведении осуществляется на текущий момент. А значит проводя задним числом будем проверять остатки на сейчас.
(42) Я немного не про то. Надо остатки и на документ, и на сейчас
(43) в принципе это достигается минимальными изменениями в конфе…
(44) Ну и я про то же 😉
(40)
«Вообще стоит задуматься, почему 1С изменила схему контроля остатков при работе задним числом, и попробовать понять эту логику.»
— Они решают задачу учета документов, а не учета остатков… 😉
(46)
Вот ответ одного из разработчиков 03.11.2004 22:24
б)Для того, чтобы определить, что в какой-то момент остатки товаров вышли «в минус» совсем не обязательно перепроводить все документы с контролем остатков. Достаточно построить отчет (оборотную ведомость).
в) Не целесообразно останавливать работу оператора по вводу документов отказом от проведения документа, если ошибка отнюдь не в этом документе. Оператор, скорей всего, все равно не сможет найти ошибочный документ.
И еще: конечно, для правильного учета надо стремиться вводить документы оперативно. Например, если накладные от поставщика придут только в конце месяца, то при реальном поступлении товара рекомендуется оформить приходный ордер.
(47) оператор, видимо, для него — это кассир в магазине…
(47)
Мне кажется, что «ответ одного из разработчиков» подтверждает моё «предположение» 😉 из #46 сообщения. Т.е. они «автоматизируют» процесс «ввода документа». Раньше это называлось «перфорация» — операторы тупо колотили с бумажки (первичного документа) на перфокарты. А потом, в пакетном режиме, прогоняли через табулятор для подведения итогов. Это и есть автоматизация учета документов образца 1960 года. Непонятно, зачем тогда городить вот этот «огород»: И, думаю, не имеет смысла пытаться сделать автоматизацию, типа, из #32 сообщения. Кроме «гимора» пользователям это ничего не даст — не «документами с проведением» решаются подобные задачи… 👿
(47)
Извините, не в тему напишу.
Этот «ответ одного из разработчиков» мне напомнил мой разговор с одним бухгалтером по поводу восстановления последовательности документов. Обсуждали «странное», на мой взгляд, отношение 1С-овцев к «заднему числу». Этот бухгалтер, вроде, со мной согласился и «пожаловался», что ему не удалось восстановить последовательность. Типа: «Она мне чЁто сказала. Я не понял. Больше не пытался восстановить.». На мой вопрос: «А как у них, при этом, обстоят дела с остатками». Я получил ответ: «А они и так никогда не сходятся на реальных складах. Зачем утруждаться — разбираться с восстановлением последовательностей?».
P.S. Этот бухгалтер, по совместительству, является хозяином фирмы. 😉
— дает, надо только правильно кошек приготовить.
.
как отмеченов (43): надо остатки на документ и на сейчас… добавлю: небольшой доделкой при приавльных исходных остатках на документ можно гарантировать неотрицательность (или по крайней мере мгновенно об этом уведомить) всей истории остатков…
делаем просто: осцилирующую на оси времени функцию поведения остаткоа (по какой либо одно йноменклатуре) надо всего лишь разложить на сумму монотонно убывающих функций… в этом случае при проведении задним числом можно не только получить состояние остатков «на сейчас» (положительный или отрицательный), но и однозначно утверждать неортицательность остатков на всей истории…
(52) Ух ты… «Монотонно убывающие» .
Ни слова не понял.
Пример приведи или тему создай э..э.. «про кошек».
Обещаю прочитать.
(52) извращенец 😉
(54) Он еще может поместить себе в карман металлический предмет, нагретый до полутора тысяч градусов. Я тоже 😉
(53) Возврат = отдельная партия 🙂
(55) И ты , Арчибальд .. про «кошек» ?
» Возврат = отдельная партия» — Это о чем ?
(56) Это гарантия невозрастания остатка по каждой партии. А сумма остатков по партиям = остаток по номенклатуре.
(57) Спору нет — вы с Чебуром знатоки по остаткам.
Так вы бы и разжевали нам «про кошек» , то бишь про использование «монотонно убывающих».
Дай Бог , чтобы после разбора примера в остатке остался смысл .
вот сразу видно, что жизненный опыт — он есть у Арчибальда… 😉
в (57) он правильно изложил.. и отсюда мгновенно при включении мозга вытекает, что если остатки по каждой «партии» убывающие — то имея на сейчас положительный остаток по партии — автоматом гарантируется положительные остатки на любой промежуток от возникновения партии до ее финиша… отсюда осталось немного до практической реализации: изменив в заднем числе (изменив количество в существующем доке или вставив новый расходный док) — можно практически мгновенно определить — выведет он СУММАРНО все партии остатков на сейчас в ноль — или нет (ясен пень, из остатков партий «на сейчас» надо выкинуть партии которые образовались позже редактируемого документа или например смягчить условие — в пределах дня считать ок)… на таком алгоритме у меня построен партионный КОЛИЧЕСТВЕННЫЙ учет ГТД у импортера… — все прекрасно работает с февраля месяца… А вот с суммовым учетом — тут в 7.7. сложнее — я не могу корректировать суммы проведенные по регистрам другими доков… в 8-ке — это вроде как можно и тогда корректировку сумм по партионному учету при проведении доков задним числом может быть можно и реализовать… — вполне возможно что это как раз будет похоже на идею РАУЗ…
.
просьба данные обсуждения/мысли не распространять направо/налево — все-таки это достаточно хорошее ноу/хау… и по крайне мере такого подхода к контролю остатков в заднем числе — нигде не озвучивалось… данный подход позволяет исключить расчет временных итогов при контроле остатков в заднем числе и заменить их получением остатков «по партиям» с отсечкой «ненужных» партий… т.е. на момент проведения дока выгружаем в ТЗ итоги по регистру (что на порядок быстрее расчета временных итогов) и отсекаем ненужные партии… получается очень быстро…
.
(58) Мне партии и остатки глубоко фиолетовы — не занимаюсь я торговлей. Чисто созерцательная позиция, как в кино — ага, вот здесь хорошо сделано, а вот тут — не очень. А там вон задумали как лучше, а получилось как всегда…
(59) Принимается. Как ЧАСТНЫЙ случай учета по количеству ГТД.
Такой контроль , как я понял, нужен и для прих. накладных.
В накладной нельзя уменьшить приход , если это приведет в последующем к отрицат. остаткам. Так ?
Теперь общий случай. Проконтролировали — разрешили проводить — и что ?
Что делать с последующими документами ? Потом перепроводить по последовательности ?
Или при проведении текущего документа корректировать только движения последующих документов по регистру партий (в 8-ке это можно )?
Цитата :
«А вот с суммовым учетом — тут в 7.7. сложнее — я не могу корректировать суммы проведенные по регистрам другими доков»
Постой , а что в 7-ке с количественным учетом проще ? и можно корректировать ресурс «Количество» у других проведенных документов ?
(61) это действует не как частный случай учета по количеству ГТД, это, по идее, работает в общем случае КОЛИЧЕСТВЕННОГО учета. Т.е. если ставить «акдаемическую» задачу беспроблемного поведения/контроля количественных остатков при работе та/задним числом, то ясно, что в последующих документах ничего делать не надо. Перепроведение последовательности остается, но чисто как 1.технологическая процедура 2.последовательность будет стопроцентно проводимой (затыка не будет) 3.и служит только для технологического закрытия регистров.
.
Речь о том, что имея в момент времени две партии остатков, может получиться что по первой партии =10, по второй =-2, итого = 8 — и это правильное количество. восстановление нужно только для технологического закрытия вот ситуации (10-2) котрое после восстановления будет =одна партия на 8 шт. в принципе последовательность можно и не восстанавливать вообще, но тогда будет туговато при открытии периодов.
.
по суммам — тут у меня решения нет пока…
(62) Согласен. Для задачи контроля отрицательных остатков предложенный алгоритм является общим (при напоминании Арчиабльда и при условии контроля и приходных накладных).
Обычное перепроведение (для расчета сумм) тем не менее необходимо.
(63) приходные накладные если они введены задним числом — хуже не сделают. если изменены задним числом (точно также как и расходные и возвраты и все прочее) — контроль один и тот же — если итоги на ТА (с учетом положения на оси времени исправляемого дока см.примечание ниже) — суммарно по всем партиям положительные — то значит ОК. если суммарно по всем партиям отрицательые — то бяка.
.
прим*: на Так анализируются только те партии, которые имеют смысл. т.е. для расходных накладных анализируются СУММА по партиям, которые были образованы до этого расходника… все…
сейчас буду перетачивать фармацию кардинально — буду заодно весь партионный учет на этом строить — там даже проще, так как автосписания партий нет…
=)
Если изменять типовую конфигурацию отключив проверку на оперативное проведение, все равно останется проблема когда при вводе документов задним числом эти остатки уже списаны в будущем. К сожалению проводить только оперативно документы в нашей действительности нереально. Поэтому самым лучшим вариантом на мой взгляд будет регламентно запускаемая обработка, которая проверяет остатки и еще сравнивает их с остатками по партиям. Тогда можно быть уверенным, более менее, что и остатки верные и себестоимость правильная
идея хорошая, но мало применимая.
При групповом создании документов реализации ну хотя бы штук 500-600 такую вещь в топку. Но! Вот когда какой косяк операторов-менеджеров найти — идея нравиться. Поковыряю код.
хорошая обработка) помогла)
правда немного переписала под нашу базу
Доработка конфигурации под конкретные нужды…. — это очень удобно при почасовой оплате.
Идея хорошая, но не рациональное исполнение. Короче не очень удобно.
(31) anig99, факт! Контроль отрицательных остатков ведётся с использованием отчёта «Ведомость по учёту МПЗ» (используется РАУЗ). Особых проблем нет.
Спасибо 1С!, что в программах не все полностью автоматизировано, спасибо что не все так идеально. Спасибо что код понятный. Спасибо, что вы есть! Именно это нам и дает работу, деньги и смысл в этой работе.
И спасибо пользователям, что ленятся думать, а то и совсем не думают, каждый раз нас вспоминают.
Напомнило как в 10.3 дорабатывал контроль остатка текущего момента при не оперативном проведении. Конечно это не спасает если приход был позже, но помогает избежать грубых ошибок. А на 7.7 сто раз уже так делал. Идея вполне рабочая.
димагогия)
Спасибо за обработку. В плане концепции все классно. На продакшене в подписке на событие повесил ее на требуемые регистры. Добавил возможность игнора измерений, немного изменил вывод лога (все ж после массовых перепроведений документов легче все в одном месте видеть). Теперь хитропопые юзвери плачут.
Неплохая обработочка, и идейка хорошая, но всегда есть минусы:
согласен с мнением одного из коллег:
а)Неоперативное проведение не может помочь проконтролировать правильность ввода документа, потому что ошибка может быть (а чаще всего и есть) в другом документе, а не в том, на проведении которого остаток ушел «в минус» .
б)Для того, чтобы определить, что в какой-то момент остатки товаров вышли «в минус» совсем не обязательно перепроводить все документы с контролем остатков. Достаточно построить отчет (оборотную ведомость).
в) Не целесообразно останавливать работу оператора по вводу документов отказом от проведения документа, если ошибка отнюдь не в этом документе. Оператор, скорей всего, все равно не сможет найти ошибочный документ.
И еще: конечно, для правильного учета надо стремиться вводить документы оперативно. Например, если накладные от поставщика придут только в конце месяца, то при реальном поступлении товара рекомендуется оформить приходный ордер.
Спасибо за обработку! Немного модифицировал для своих нужд- работает супер.
(23) — Это точно :). Порой такого наменяют — диву даешся. А потом при обновлннии лупят с бухгалтеров и директоров…
Если кому нужнен контроль отрицательных остатков, а также запрет проведения (при неоперативном проведении, и оперативном тоже), по складам и партиям. Опробовал на рабочей, доволен. Подсистема «Контроль отрицательных остатков» . Поянение методики для подключения есть, спрашивайте.
Автору спасибо. Хорошая обработка, необычный подход, важный момент, контролирует остатки всех последующих периодов,
попробую в работе, тогда отпишусь по конкретным достоинствам в рабочем процессе. В настоящее времи для запрета отрицательных остатков пользуюсь обработкой ( Подсистема «Контроль отрицательных остатков»).
Спасибо большое за подсистему. Очень полезная вещь. Интегрирую, проверю, отпишусь.
К сожалению не всегда работает подсистема, так как ен учитывает свойство документа «Удаление двиежний».
В КА, чтобы поправить это дело проще всего дописать одну строчку кода, см. картинку во вложении.
Это увеличит время проведения документа, но зато функционал заработает корректно.
Спасибо за обработку, хорошая вещь.
Эту вещь положу в свой золотой фонд.
Маст би фарева! Ну до тех пор, пока не усовершенствуют, конечно.
Из предыдущих комментариев зубров Инфостарта понял что у всех свое мнение, но общий знаменатель такой — Нужно иметь инструмент, и голову на плечах иногда включать.
Если есть знания типовой конфы, смело пользуемся инструментами, если уверены, что такое действие для данной конкретной организации подойдет лучше, чем типовой.
Я за 7 лет практики повидал множество предприятий и НИ В ОДНОМ типовую конфигурацию в исходном виде не используют!
Обязательно дорабатывают, потому что правильно тут заметили, идеальных предприятий нету, такое просто не выживет…
В УПП/КА1 загружаем документы из Альфа-Авто по месяцам, кварталам. Раньше при обмене (файловый) все ошибки проведения документов выводились в сообщения, оперативно исправлялись в базе источнике Альфа-Авто. Теперь (около 7 лет) перестали. Ваша обработка устранит этот недостаток?