В первой из них затрагивается вопрос о «контроле товарных остатков».
Как система контролирует превышение остатка.
В терминологии 1С существует два вида проведения документов Оперативное и Неоперативное проведение.
Оперативный режим проведения означает, что факт хозяйственной операции регистрируются в текущий моментом времени а неоперативный же режим означает, что хозяйственная операция отражается в прошлом, пусть даже и секунду назад от текущего момента времени.
Не открою большой секрет что в идеологии типовых конфигураций программ 1С, не считается нужным проверять остатки товара в неоперативном режиме.
Не буду сейчас в даваться в причины отсутствия полноценных механизмов контроля остатков в ранних версиях систем, отмечу лишь тот факт что контролировать остатки только в оперативном режиме мало подходит для реального документооборота. Зачастую документы вносятся по мере их поступления и как правило задним числом.
Как это работает.
В своей статье в качестве базовой конфигурации я буду рассматривать УПП (управление производственным предприятием) так как она содержит наибольшее количество подсистем. Представленный метод подходит и для других систем 1С в которых есть регистр «Свободных остатков».
В системе присутствуют демо данные и включен механизм контроля «Свободных остатков».
Немного о самом регистре СвободныеОстатки.
Данный регистр не так давно появился в УПП и его появление обусловлено необходимостью консолидации данных о товарных остатках в одном месте, также он отделил товарных остатки от регистров партий ввиду стратегического продвижения РУАЗ(расширенных учет аналитики затрат) где не использовались партии.
В дальнейшем развитии весь контроль товарных остатков базируется именно на нем.
Но вернемся в нашей проблеме. Проведя несколько документов в прошлом периоде с заведомо завышенным количеством можно обнаружить что система никак не реагирует на превышения.
Давайте разберемся что же происходит на самом деле.
Для всех документов системы в модуле проведения существует блок обрабатывающий контроль остатков. Обычно он выглядит следующим образом:
Все хорошо. Контроль вроде бы есть. Но проваливаясь в реализацию (клавиша F12). Видим все то чем написано выше. Система контролирует только оперативный остаток.
Система без контроля пропускает большую часть документов, которые заводятся в прошлом периоде. Было бы логично сообщать о ошибках данных в момент ее появления, когда у оператора есть первичный документ на руках, а не в момент закрытия месяца, когда документы в архиве и узнать правду не представляется возможным.
Каждый раз начиная совершенно разные проекты, первым делом что приходилось закрывать именно эту брешь в контроле остатков. Только это одно действие может значительным образом повысить качество данных системы и ее полезность в целом.
Дополняем обработку не оперативного проведения.
Теперь хорошие новости.
Ничего существенного дорабатывать не нужно все доработки сводятся к 4 строкам.
1.Блокируем выход из процедуры если проведение не оперативное.
//Если РежимПроведения <> РежимПроведенияДокумента.Оперативный Тогда // Возврат; //КонецЕсли;
2.Добавляем в запрос параметр определяющий на какую даты мы хотим получить остатки.
| РегистрНакопления.СвободныеОстатки.Остатки(&МоментВремени,
3. Дополнительно передаем этот параметр в запрос.
Запрос.УстановитьПараметр("МоментВремени", ?(РежимПроведения=РежимПроведенияДокумента.Оперативный,Текущаядата(),Новый Граница(СтруктураШапкиДокумента.Ссылка.МоментВремени(),ВидГраницы.Включая)));
Проверяем.
Сформируем документ в прошлом периоде и убедимся что системы блокирует его проведение при превышении остатка. Дополнительно используем отчет «Анализ доступности товаров на складах».
Выводы.
В данной статье освещается один из методов усовершенствования типовых систем 1С. Рассказано о методах проведения документов и их особенностях. Показано как несколькими штрихами можно значительно повысить качество данных системы.
Спасибо за внимание.
P.S. Предложенное автором решение характеризуется простотой и доступностью, но не претендует на 100 процентную гарантию о чем в следующих статьях.
ссылка на оригинал статьи http://habrahabr.ru/post/174673/
Добавить комментарий