Исправление резервов. Сверка остатков с резервами. Проверка на зависшие резервы. Заполнение документа списком кодов товаров. 1С 7.7
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
следует отметить что документ "снятие резерва" - закроет только резерв (Регистр резервов). При этом Заявка покупателя - останется активной (регистр заявок). Если заявки не закрывать - будут пухнуть таблички итогов (что приводит к лишним затратам при приведении документов), замедлению каждого открытия месяца (замедление до какого то момента проявляется слабо, потом - нарастает лавинообразно).
.
Поэтому - если вам не нужна ЗАЯВКА ЦЕЛИКОМ (она устаревшая, неактуальная, резервы по ней - верные или неверные без разницы) - для закрытия таких заявок следует воспользоваться штатным документом "Отмена заявок" - он и заявку закроет и резервы тоже закроет.
.
Уточняю - закрытие заявок (оно может выполняться как минимум двумя способами) - надо делать ДЛЯ ВСЕХ ЗАЯВОК. Даже для Неподтвержденных.
.
Вдобавок документ "Снятие резерва" чувствителен к указанному количеству для снятия резерва и если при исправлениях задним числом резерв поменялся, то при восстановлении ГП документ "Снятие резерва" может не перепровестись, что (в зависимости от дальнейших действий) может снова породить неверные резервы (у себя я модифицировал алгоритм "Снятие резервов" так, что если указано в документе 100 шт, например, а текущи резерв всего 90 (ну вот так вот получилось) - то снимается все доступное количество резерва, не превышающее указанное в документе, это упрощает восстановление ГП (хотя у меня этим документом не пользуются, все заявки закрываются менеджерами полуавтоматом через "Отмену заявок"
.
И помогалка: разу уж тут речь в публикации о резервах.
В типовых есть "ошибка" в алгоритме операций с резервами (писалось, это видимо, для тех кто работает безошибочно) . Проявляется ошибка неявно (если есть работа задним числом постоянная с корректировкой документов поступления\отгрузки заявок, при нормальной работе в ТА вероятность такой ошибки практически нулевая). Ошибка ведет к тому что менеджеры успешно принимают заявки и резервируют товар, а склад этого не находит. Расписывать особо не буду, суть в том, что вычисляется
СвободныйОстаток=Остаток-Резерв, 70=100-30
При отрицательных резервах (что есть ненормально), внезапно из ниоткуда появляется свободный остаток
Остаток=100, Резерв=-30, СвободныйОстаток=100-(-30)=130.
Рекомендуется поправить код во избежание таких ситуаций.
.
Вроде все изложил что помнил навскидку.
Для тех кому интересна данная публикация - возможно будет интересна у меня в профиле обработка "Автозакрытие просроченных заявок".
.
Всем успехов.
.
Поэтому - если вам не нужна ЗАЯВКА ЦЕЛИКОМ (она устаревшая, неактуальная, резервы по ней - верные или неверные без разницы) - для закрытия таких заявок следует воспользоваться штатным документом "Отмена заявок" - он и заявку закроет и резервы тоже закроет.
.
Уточняю - закрытие заявок (оно может выполняться как минимум двумя способами) - надо делать ДЛЯ ВСЕХ ЗАЯВОК. Даже для Неподтвержденных.
.
Вдобавок документ "Снятие резерва" чувствителен к указанному количеству для снятия резерва и если при исправлениях задним числом резерв поменялся, то при восстановлении ГП документ "Снятие резерва" может не перепровестись, что (в зависимости от дальнейших действий) может снова породить неверные резервы (у себя я модифицировал алгоритм "Снятие резервов" так, что если указано в документе 100 шт, например, а текущи резерв всего 90 (ну вот так вот получилось) - то снимается все доступное количество резерва, не превышающее указанное в документе, это упрощает восстановление ГП (хотя у меня этим документом не пользуются, все заявки закрываются менеджерами полуавтоматом через "Отмену заявок"
.
И помогалка: разу уж тут речь в публикации о резервах.
В типовых есть "ошибка" в алгоритме операций с резервами (писалось, это видимо, для тех кто работает безошибочно) . Проявляется ошибка неявно (если есть работа задним числом постоянная с корректировкой документов поступления\отгрузки заявок, при нормальной работе в ТА вероятность такой ошибки практически нулевая). Ошибка ведет к тому что менеджеры успешно принимают заявки и резервируют товар, а склад этого не находит. Расписывать особо не буду, суть в том, что вычисляется
СвободныйОстаток=Остаток-Резерв, 70=100-30
При отрицательных резервах (что есть ненормально), внезапно из ниоткуда появляется свободный остаток
Остаток=100, Резерв=-30, СвободныйОстаток=100-(-30)=130.
Рекомендуется поправить код во избежание таких ситуаций.
.
Вроде все изложил что помнил навскидку.
Для тех кому интересна данная публикация - возможно будет интересна у меня в профиле обработка "Автозакрытие просроченных заявок".
.
Всем успехов.
(1) нет времени обдумывать и дискутировать пока, спасибо за дополнение но по началу поста сразу возникает такое желание, вот лишь - снятие делается документом "сторнирование резервов заявок" и по всем 3м регистрам делаются одинаковые движения - заявки, резервы и выполнение. В даанном случае комментарий дополняет тему, за что я благодарен оппоненту, но мой пост вообще не подтверждает и не опровергает его правоту.
это я сам делал такой документ из документа сторно, отличная штука вышла, у него движения противоположное движению заявки, но только исключительно по не-списаным, вот такое у него движение:
Процедура ОбработкаПроведения()
Если ПустоеЗначение(СторнируемыйДокумент) = 1 Тогда
глНеПроводить(Контекст, "Не выбран сторнируемый документ.");
Возврат;
КонецЕсли;
ВыбДата = НачМесяца(ТекущаяДата());//Резервы зависшие ранее
ВыбДокумент = СторнируемыйДокумент;
Если СторнироватьТолькоЗависшийРезервНаДатуСторно=1 Тогда
Запрос = СоздатьОбъект("Запрос");
ТекстЗапроса =
"НомКод = Регистр.РезервыТМЦ.Номенклатура.Код;
|Штрихкод = Регистр.РезервыТМЦ.Номенклатура.ОсновнаяЕдиница.Штрихкод;
|Номенклатура = Регистр.РезервыТМЦ.Номенклатура;
|ЗаявкаПокупателя = Регистр.РезервыТМЦ.ЗаявкаПокупателя;
|Количество = Регистр.РезервыТМЦ.Количество;
|Функция КонОстКоличество = КонОст(Количество);
|Группировка ЗаявкаПокупателя;
|Группировка Номенклатура без групп;
|Условие(ЗаявкаПокупателя В (ВыбДокумент));";
Если Запрос.Выполнить(ТекстЗапроса) = 0 Тогда
СтатусВозврата(0);
Возврат;
КонецЕсли;
ТЗ = СоздатьОбъект("ТаблицаЗначений");
Запрос.Выгрузить(ТЗ,3,0);
Если ТЗ.КоличествоСтрок()=0 Тогда
Возврат;
Иначе
ТЗ.ВыбратьСтроки();
Пока ТЗ.ПолучитьСтроку()=1 Цикл
Если СокрЛП(ТЗ.Номенклатура.ОсновнаяЕдиница.Штрихкод)="" Тогда
Сообщить("Нет ШК основной единицы товара "+СторнируемыйДокумент.Номенклатура.Код+" "+СторнируемыйДокумент.Номенклатура.Наименование);
ТЗ.Штрихкод = "";
Иначе
ТЗ.Штрихкод = СокрЛП(ТЗ.Номенклатура.ОсновнаяЕдиница.Штрихкод);
КонецЕсли;
КонецЦикла;
ТЗ.УдалитьКолонку("ЗаявкаПокупателя_2");
ТЗ.УдалитьКолонку("Номенклатура_1");
ТЗ.УдалитьКолонку("Количество");
глПечатьТаблицы(ТЗ,"Не списано по "+СокрЛП(ВыбДокумент));
КонецЕсли;
КонецЕсли;
// Проверка сторнированности документа.
Объект = СоздатьОбъект("Документ");
Объект.ВыбратьПодчиненныеДокументы(,, СторнируемыйДокумент);
Пока Объект.ПолучитьДокумент() = 1 Цикл
Если (Объект.Вид() = "СторноЗаявокРезервов") И (Объект.Проведен() = 1) И (Объект.ТекущийДокумент() <> ТекущийДокумент()) Тогда
глНеПроводить(Контекст, "Сторнируемый документ уже сторнирован документом № "+Объект.НомерДок+" от "+Объект.ДатаДок);
Возврат;
КонецЕсли;
КонецЦикла;
Если Метаданные.Документ(СторнируемыйДокумент.Вид()).ОперативныйУчет = 1 Тогда
Для Сч = 1 По Метаданные.Регистр() Цикл
Рег = СоздатьОбъект("Регистр." + Метаданные.Регистр(Сч).Идентификатор);
РегСторно = Регистр.ПолучитьАтрибут(Метаданные.Регистр(Сч).Идентификатор);
Если не((РегСторно.Вид()="Заявки") или (РегСторно.Вид()="РезервыТМЦ") или (РегСторно.Вид()="ВыполненыеЗаказы")) Тогда
продолжить;
КонецЕсли;
Если Рег.ВыбратьДвиженияДокумента(СторнируемыйДокумент)=1 Тогда
Пока Рег.ПолучитьДвижение()=1 Цикл
Если СторнироватьТолькоЗависшийРезервНаДатуСторно=1 Тогда
НомСтр = 0;
ТЗ.НайтиЗначение(Рег.Номенклатура.ТекущийЭлемент(),НомСтр,"Номенклатура");
Если НомСтр = 0 Тогда
Продолжить;
КонецЕсли;
КоличествоСпишем = ТЗ.ПолучитьЗначение(НомСтр,"КонОстКоличество");
//добавить строку в заявку
МДОперация = ?(Рег.Приход=1,"Приход","Расход");
// заполняем измерения
Для Сч2 = 1 По Метаданные.Регистр(Сч).Измерение() Цикл
РегСторно.УстановитьАтрибут(Метаданные.Регистр(Сч).Измерение(Сч2).Идентификатор, Рег.ПолучитьАтрибут(Метаданные.Регистр(Сч).Измерение(Сч2).Идентификатор));
КонецЦикла;
// заполняем реквизиты
Для Сч2 = 1 По Метаданные.Регистр(Сч).Реквизит() Цикл
ЗначениеРеквизита = - КоличествоСпишем;
РегСторно.УстановитьАтрибут(Метаданные.Регистр(Сч).Реквизит(Сч2).Идентификатор, ЗначениеРеквизита);
КонецЦикла;
// Номер строки документа-основания
РегСторно.ПривязыватьСтроку(Рег.НомерСтроки());
// заполняем ресурсы
Для Сч2 = 1 По Метаданные.Регистр(Сч).Ресурс() Цикл
РегСторно.УстановитьАтрибут(Метаданные.Регистр(Сч).Ресурс(Сч2).Идентификатор, -КоличествоСпишем);
КонецЦикла;
Если Рег.Приход = 1 Тогда
РегСторно.ДвижениеПриходВыполнить();
Иначе
РегСторно.ДвижениеРасходВыполнить();
КонецЕсли;
Иначе
...
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецПроцедуры // ОбработкаПроведения()
Показать
.. и если закрывать только резервы - высока вероятность что и минуса и прочие непотребства остаются висеть по регистру заявок(обрабатывается в вышеприведоде, ок) и заказов-заявок (не обрабатывается). За ними тоже надо следить\чистить. И вполне возможна ситуация, когда "проблемных" резервов нет, но сама заявка не закрыта, хотя давно уже "мертвая".
.
но это все советы.
каждый сам кузнец своих баз.
.
но это все советы.
каждый сам кузнец своих баз.
чисто попутно незначимые наблюдения, чисто поворчать
.
- много излишнего кода и лишней нагрузки на базу внутри транзакции. Штрихкод тянется в запросе.
.
.
хотя может я чего и не понял\не уловил
.
.
Если СокрЛП(ТЗ.Номенклатура.ОсновнаяЕдиница.Штрихкод)="" Тогда
Сообщить("Нет ШК основной единицы товара "+СторнируемыйДокумент.Номенклатура.Код+" "+СторнируемыйДокумент.Номенклатура.Наименование);
ТЗ.Штрихкод = "";
Иначе
ТЗ.Штрихкод = СокрЛП(ТЗ.Номенклатура.ОсновнаяЕдиница.Штрихкод);
КонецЕсли;
- много излишнего кода и лишней нагрузки на базу внутри транзакции. Штрихкод тянется в запросе.
.
ТЗ.НайтиЗначение(Рег.Номенклатура.ТекущийЭлемент() - излишнее обращение к ТекущийЭлемент().
.
хотя может я чего и не понял\не уловил
.
(7) во-первых отмены заявок у нас нету, возможно старая комплексная. Во-вторых Вы отлично умеете найти какашку даже в маленьком зернышке, всегда придираетесь к коду который работает несколько секунд в году. Спасибо что объяснили, что я никому не помог, выходит тема на которую я отреагировал здесь лишняя.
(8) ну это очень старая комплексная должна быть чтобы там не было того, что штатно года с 2006 как минимум.
.
насчет какашек - зря.
я вполне понимаю, что работает - и хорошо. у самого тоже разного неоптимального хватает.
.
однако если кто смотреть будет из несильно подкованных (что, конечно маловероятно) - то лучше все-таки дать еще и какой-то минимальный набор знаний - пригодится. и учить пользоваться штатным инструментарием по-возможности, а кнештатным прибегать при недостатках штатных интрументов
.
успехов!
.
насчет какашек - зря.
я вполне понимаю, что работает - и хорошо. у самого тоже разного неоптимального хватает.
.
однако если кто смотреть будет из несильно подкованных (что, конечно маловероятно) - то лучше все-таки дать еще и какой-то минимальный набор знаний - пригодится. и учить пользоваться штатным инструментарием по-возможности, а кнештатным прибегать при недостатках штатных интрументов
.
успехов!
(9) по коду видно что он не для отмены заявки целиком. Код предназначен для решения проблем, возниуающих при работе задним числом по выполненным заявкам. Релиз в публикации указан, отмена заявок покупателей в нем действительно есть, но она не обладает функционалом моего документа и описанных в публикации проблем не решает.
(10)
м.б. я не совсем понял, какие проблемы возникают при работе задним числом по выполненным заявкам..?
.
если заявка выполнена, но по ней задним числом "проехались" и выполненная заявка поплыла - то есть стала незакрытой - по ней будут в общем случае висеть незакрытые остатки по 3 регистрам: резервы, заявки и заказы-заявки. Эти подвисшие хвосты надо закрыть. С закрытием всех подвисших хвостов прекрасно справляется штатный документ "Отмена заявок" (исходим все-таки из того что в комплексной конфигурации таковой документ есть, с ходу дату выпуска озвученной конфигурации не нашел).
.
Какие еще проблемы озвучены и решены в публикации - я с ходу что-то не уловил.
Да, есть отчеты (заявлены в публикации) для выявления таких незакрытых заявок - это хорошо.
.
Но привлекать какие-то самописные документы для закрытия хвостов по заявкам - мне это странновато при наличии штатных возможностей. Я завтреца постораюсь посмотреть древний релиз комплексной, который у меня есть, на наличие типового документа "Отмена заявок". Если такового документа нет (я сомневаюсь, но допускаю) - тогда да, смысл есть в самописном документе. Хотя и без "отмены заявок" подвисшие заявки можно закрыть корректировочной заявкой (с пустой табличной частью) - хотя, надо признать, не всегда это удается (определяется тем что зависло)
отмена заявок покупателей в нем действительно есть, но она не обладает функционалом моего документа и описанных в публикации проблем не решает.
м.б. я не совсем понял, какие проблемы возникают при работе задним числом по выполненным заявкам..?
.
если заявка выполнена, но по ней задним числом "проехались" и выполненная заявка поплыла - то есть стала незакрытой - по ней будут в общем случае висеть незакрытые остатки по 3 регистрам: резервы, заявки и заказы-заявки. Эти подвисшие хвосты надо закрыть. С закрытием всех подвисших хвостов прекрасно справляется штатный документ "Отмена заявок" (исходим все-таки из того что в комплексной конфигурации таковой документ есть, с ходу дату выпуска озвученной конфигурации не нашел).
.
Какие еще проблемы озвучены и решены в публикации - я с ходу что-то не уловил.
Да, есть отчеты (заявлены в публикации) для выявления таких незакрытых заявок - это хорошо.
.
Но привлекать какие-то самописные документы для закрытия хвостов по заявкам - мне это странновато при наличии штатных возможностей. Я завтреца постораюсь посмотреть древний релиз комплексной, который у меня есть, на наличие типового документа "Отмена заявок". Если такового документа нет (я сомневаюсь, но допускаю) - тогда да, смысл есть в самописном документе. Хотя и без "отмены заявок" подвисшие заявки можно закрыть корректировочной заявкой (с пустой табличной частью) - хотя, надо признать, не всегда это удается (определяется тем что зависло)
1) делаем проверку на зависшие резервы;
картинка1
2) делаем поиск заявки от которой завис резерв
картинка2
3) делаем отмену заявки
картинка 3
4) смотрим движения - оказывается ненужные нам позиции сторнировались которые не вызывали проблем, делаем вывод что документ не пригоден
картинка4
извините меня за нервозность, ответ на замечания оппонента заставляет тратить непредусмотренное время, ведь он пишет по своему желанию а я отвечаю подневольно, мне сложнее вести переписку чем ему и я не могу тщательно подготовиться к ответу рассмотрев все факторы
картинка1
2) делаем поиск заявки от которой завис резерв
картинка2
3) делаем отмену заявки
картинка 3
4) смотрим движения - оказывается ненужные нам позиции сторнировались которые не вызывали проблем, делаем вывод что документ не пригоден
картинка4
извините меня за нервозность, ответ на замечания оппонента заставляет тратить непредусмотренное время, ведь он пишет по своему желанию а я отвечаю подневольно, мне сложнее вести переписку чем ему и я не могу тщательно подготовиться к ответу рассмотрев все факторы
Прикрепленные файлы:
Если речь идет о корректировке ЖИВЫХ заявок с целью скорректировать неверные, допустим, резервы - то вполне возможно использовать механизм автора (здесь, в зависимости от задачи, может подойти штатная возможность создания коректировочной заявки- но не все клиенты к этому готовы/подходит, и корректировочные заявки имеют тонкости).
.
"Заявки старого периода от которых не сформированы накладные имеет смысл контролировать отдельно."
- такие заявки (устаревшие/ненужные) следует закрывать именно "Отмена заявок"
.
"Заявки старого периода от которых не сформированы накладные имеет смысл контролировать отдельно."
- такие заявки (устаревшие/ненужные) следует закрывать именно "Отмена заявок"
Вакансии
Ведущий разработчик 1С / Team lead отдела разработки 1С
Москва
зарплата от 300 000 руб. до 300 000 руб.
Полный день
Москва
зарплата от 300 000 руб. до 300 000 руб.
Полный день