Материалы курса «Подготовка к Аттестации по Платформе 8.2» — Раздел 1, задача 1.32
Еще одна задача раздела «Оперативный учет» — задача 1.32
- Изучите материалы задачи.
- Вопросы, возникшие в ходе изучения этих материалов, задавайте в комментариях на текущей странице. Ответы преподавателя и комментарии других участников будут Вам доступны, только если Вы залогинены и у Вас есть доступ в Мастер-группу.
- Общие вопросы по курсу (в т.ч. организационные) задавайте на стартовой странице.
К сожалению, у Вас недостаточно прав для дальнейшего просмотра.
Если Вы приобрели курс, но еще не активировали токен — пожалуйста, активируйте доступ по инструкциям, высланным на Ваш email после покупки.
Если Вы не залогинены на сайте — залогиньтесь, вернитесь на эту страницу и обновите ее.
Если Вы залогинены, у Вас активирован токен доступа, но Вы все равно видите эту запись — напишите нам на e-mail поддержки.
Комментарии / обсуждение (88):
Комментарии закрыты
Здравствуйте, Павел!
Я не согласен с Вашим решением.
1. Вы построили отчёт, где присутствует 3 оборотных показателя, на основании РН с видом «Остатки»;
Если база будет большой, 1с при такой структуре — «ВСТАНЕТ».
2. Структуру регистров выбрали вообще загадочной. Если провести аналогию с УПП, тогда тут должны были быть:
— ОстаткиТоваров (Остаточный) для учёта себестоимости в разрезе заказов + контроль отгрузки;
— ЗаказыПоставщикам (Остаточный) для контроля приходной накладной, чтобы не заприходовать слишком много;
— ЗаказыПокупателей (Остаточный) чтобы была возможность получить список недоотгруженных заказов;
— Заказы (Оборотный) для формирования отчёта;
— Закупки (Оборотный) для формирования отчёта;
— Продажи (Оборотный) для формирования отчёта.
На основе такой структуры задача решается элементарно и всё красиво, у Вас запутанное решение, и Вы сами в нём ошиблись при контроле приходной накладной, т.к. решение запутано.
Видимо ответ тут не предполагается.
Добрый день!
1) Вопрос по параметрам отчета: в отчете используется таблица ЗаказыОбороты, из которой выбирается Приход(Заказано) и Расход(Отгружено). При этом параметры начала и конца периода не задаются. По Приходу понятно — у нас заказ происходит единожды, поэтому итог будет одинаков в любой момент времени. Но для Расхода этот оборот уже будет зависеть от даты, ведь отгрузка может происходить несколькими документами в течении произвольного периода. Тогда получается, что мы должны в параметрах СКД в параметр КонецПериода задать выражение &Период.Верно ли я рассуждаю?
2) Я реализовал три регистра,:
Заказы(остатки), где хранятся остатки заказанной номенклатуры, регистратор: Заказ. Всегда остатуи будт положительными, т.к. по нему не будет происходить списание;
ЗакупкаОтгрузка(остатки), тут хранятся остатки номенклатуры при Закупке/Продаже, регистраторы Приходная и Расходная накладные;
СтоимостьТоваров, здесь у нас соответственно стоимость товаров, регистраторы Приходная и Расходная накладные
Я руководствовался рекомендацией: 1 показатель = 1 регистр. У нас здесь: Заказы, Приход/Расход, Стоимость
Имеет ли такая реализация право на жизнь?
3) Не имелось ли ввиду в условии задачи, где требовалось закупать или продавать оборудование , которое есть только в Заказе, что нужно добавить отбор списка номенклатуры в форме выбора спр. Номенклатура? Или такие вещи могут быть только в разделе Управляемые формы, а в Оперативном учете — все проще и достаточно проверки?
1. Не понял зачем нам ограничивать выборку концом периода.
2. Нет. Первый регистр будет пухнуть.
3. Это условие на облегчение задания, а не на реализацию.
1. У нас был ЗаказПокупателя на 01.12 на 20 ед. товара. Затем 05.12 проводится Расходная на 10 ед., 20.12 — Расходная на 5 ед.
Если в параметрах виртуальной таблицы ЗаказыОбороты не задаем КонецПериода, то:
Отчет формируем 31.12, указываем период в отчете — 13.12: в оборотах Приход регистра ЗаказПокупателя: 20 ед., в оборотах Расход: 15 ед.(хотя тут должно быть 10)
Отчет формируем на 22.12: в оборотах Приход регистра ЗаказПокупателя: 20 ед., в оборотах Расход: 15 ед.
Данные будут одинаковыми в колонке Отгружено при разных значениях периода. Вот я и не совсем понимаю, почему мы не ограничиваем период выборки?
Теперь понял. Возможно пропустил этот момент. Спасибо.
Павел, здравствуйте. Можно ли использовать для этой задачи такую архитектуру:
1. РН «ЗаказыПокупателей», два ресурса: КоличествоЗакупить, КоличествоОтгрузить
Документ ЗаказПокупателя делает приход по КоличествоЗакупить, документ ПриходнаяНакладная делает расход по КоличествоЗакупить (контроль остатков) и приход по КоличествоОтгрузить, документ РасходнаяНакладная делает расход по КоличествоОтгрузить (контроль остатков)
2. РН «Себестоимость», два ресурса: Количество, Себестоимость. Классическое проведение ПриходнаяНакладная, РасходнаяНакладная для расчета по средней
Подобное решение (когда документ делает по одному регистру одновременно и приход и расход, но по разным ресурсам) можно встретить в типовых конфигурациях, но в разборах экзаменационных задач я такого не встречал
1. Нет нельзя. Показатели разные, закупка и отгрузка. Это сразу -3 балла.
2. Не понял, что имеется в виду. Расходная пишет расход, приходная приход, какое одновременное + — там? Не понял.
я написал комментарий еще 19.04.2016, но сегодня его почему-то удалили
1. РН выйдет в «ноль» после отгрузки, аналитика у двух этих ресурсов одинаковая: Заказ, Номенклатура. можно сказать что это один показатель, который переходит из одного ресурса в другой. такой подход позволяет упростить запросы на проверку остатков и построение отчет. почему же нельзя? понятно, что например нельзя вести в одном регистре себестоимоть и складские остатки, но здесь ведь совсем другая ситуация
2. приходник делает (+), расходник (-). то что я написал ниже относится к первому пункту: документ ПриходнаяНакладная делает расход по КоличествоЗакупить, но приход по КоличествоОтгрузить
0. По вопросу удаления комментариев обратитесь в службу поддержки, они проведут расследование, кто когда и зачем удалял комментарии.
1. В ноль он выйдет, возможно, но это два разных показателя! Можно в одном регистре хранить «Сумму покупок по контрагентам» и «Продажи товаров по номенклатурным группам» — можно. Но это не правильно. У вас регистр заполняться и считываться будет «лесенкой». 1 регистр = один показатель.
По условию задачи:
«Для каждого устройства устанавливается срок годности и срок использования. Срок годности считается с момента приобретения оборудования и указывается в документе поступления, а срок эксплуатации с момента его ввода в эксплуатацию и указывается непосредственно для оборудования и не меняется.
Поступление оборудования отражается документом «Приходная накладная». Через некоторое время оборудование вводится в эксплуатацию документом «Ввод в эксплуатацию». При передаче оборудования в эксплуатацию в первую очередь передается оборудование, у которого минимальный срок годности…
Себестоимость оборудования рассчитывается как средняя.»
Вопрос: В решении себестоимость считается как средняя по номенклатуре или средняя по срокам годности?
считаю списывать себестоимость нужно по номенклатуре, просмотрела много решений этой задачи,
в половине решений себестоимость списывают по срокам годности, как правильно?
Считать как средняя по номенклатуре.
ЗЫ: А как это к нашей задаче относится?
Добрый день!
Если в задании требуется добавлять движения по уже сделаным движениям, пример: «если товар был уже продан, то его себестоимость должна быть скорректирована (добавлены движения) без перепроведения самих документов продажи.» Можно в этом случае воспользоваться вирт таблицей оборотов из регистра с видом «Остатки» для получения поступивших и списанных значений?
Если надо получайте. Это вообще не связанные вещи.
Я пошел по такому варианту. Создал регистры ДолгПоОтгрузке и ДолгПоЗакупке. При формировании Заказа сразу приход на них оба на сумму и количество заказа, затем делаю расход приходной накладной по ДолгПоЗакупке и расходной накладной по ДолгПоОтгрузке и контролирую остатки по регистрам в обоих случаях. Как думаете, нормальный вариант? Ну для экзамена, по крайней мере.
Вполне.
Здравствуйте.
Будет ли верна такая реализация задачи:
Три регистра: регистр сведений Состояние Заказа(измерение Заказ, ресурс ДатаОтгрузки), регистры накопления Закупка(измерения Номенклатура, Заказ; ресурс Количество) и Отгрузка (измерения Номенклатура, Заказ; ресурс Количество, Себестоимость).
При проведении Заказа делаются движения в РС Состояние Заказа (Заказ = Заказ, ДатаОтгрузки = ПустаяДата) и в РН Закупка в плюс.
При проведении Приходной накладной делаются движения в РН Закупка в минус и в РН Отгрузка в плюс.
При проведении Расходной накладной делаются движения в РС Состояние Заказа, где проставляется дата отгрузки, если отгрузка прошла полностью и в РН Огрузка в минус.
Отчет строится следующим образом: из РС Состояние заказ выбираются все заказы у которых ДатаОтгрузки > Даты Отчета или ДатаОтгрузки = Пустая Дата. Для выбранных заказов подтягиваются обороты из РН Закупка и Отгрузка.
Хороший вариант. Если реализовали — пришлите мне базу для теста.
Выгрузку с базой отослала Вам на почту.
Здравствуйте! Возник вопрос по поводу проведения в расходной накладной Там используются два запроса первый использует новую методику проведения. Делает движения по заказам, после смотрит отрицательные остатки, второй рассчитывает себестоимость уже по регистру «ОстаткиТоваров». Вопрос использовать два запроса при проведение можно это не снимет балы ?
Если одним запросом не обойтись, то нужно писать 2. Это нормально.
Здравствуйте! Возник вопрос по поводу проведения в расходной накладной Там используются два запроса первый использует новую методику проведения. Делает движения по заказам, после смотрит отрицательные остатки, второй рассчитывает себестоимость уже по регистру «ОстаткиТоваров». Вопрос использовать два запроса при проведение можно это не снимет балы ?
Если одним запросом не обойтись, нужно писать 2. Это нормально.
Здравствуйте!
Возник вопрос по задаче 1.32. Если реализовать задачу на 3-х регистрах вместо 2-х, будет ли это ошибкой на экзамене?
Когда решал ее самостоятельно, реализовал ее на 3-х регистрах:
1.Остатки в заказах (в разрезе заказов).
2.Реальные остатки (в разрезе заказов).
3.Себестоимость.
При проведения заказа товар как бы приходуется на регистр «Остатки в заказах». При проведении Приходной накладной товар списывается из регистра «Остатки в заказах» с контролем и приходуется на регистр «Реальные остатки». Здесь же происходит приход в регистр «Себестоимость». В расходной накладной товар списывается уже из регистра «Реальные остатки».
Регистров больше, но зато схема ближе к реальным условиям (отгружается реальный товар — то, что уже пришло на склад).
Пришлите мне свою базу, так сложно прокомментировать. Вроде и все правильно, но что-то меня смущает.
Добрый день. Базу удалил после проработки задачи — чуть позже восстановлю.
Здравствуйте!
1.Почему в документе расходная накладная при блокировке данных по регистру накопления «Заказы» используем «Движения.Заказы.БлокироватьДляИзменения = Истина», а при блокировке данных по регистру «Остатки товаров» используем «Блокировка = Новый БлокировкаДанных;»?
2.Почему при контроле отрицательных остатков по регистру «Остатки товаров» при установке параметра «МоментВремени» не учитываем оперативный или неоперативный режим проведения документа?
3.В документе «ПриходнаяНакладная» почему «Заказ» — реквизит документа, а не реквизит таб.части.В Задаче сказано «В документе «Приходная накладная» для каждой номенклатурной позиции указывается заказ
покупателя, для которого приобретено это оборудование.».Сейчас по логике реализации задачи получается, что нельзя закупить в 1 приходной накладной оборудование по нескольким заказам. Тоже самое и с расходной накладной.
Ответы на все вопросы есть в этой статье: http://курсы-по-1с.рф/articles/статьи-по-платформе-контроль-остатка/
Здравствуйте!
А можно в регистре накопления «заказы» производить списание не расходной накладной, а приходной накладной? Ведь указано, что покупается только то, что заказывается. Затем приходная накладная добавляет приход в регистр «остатки товаров», а расходная — списывает оттуда. Лишнего расходная накладная в таком случае не спишет.
Я, видимо, Ваш замысел не понимаю. Пришлите готовую конфигурацию — я прокомментирую.
Здравствуйте!
Не могу понять почему Вы получаете из РегистраНакопления.Остатки обороты, ведь это считается ошибкой.
«В задачах получения итоговой информации по остаткам использование информации по оборотам или наоборот»
Из регистра остатков получаем остатки,
Из регистра оборотов получаем обороты.
Так?
Или эта трактовка про виртуальные таблицы?
Здравствуйте.
Несколько раз перечитывал вопрос, так и не понял о чем Вы.
В регистре остатков хранятся и показатели остатков и оборотов. Вот из оборотов остатки вытащить невозможно. Вот если Вы для получения оборотов (и только) создаете регистор остатков — это ошибка, или считаете остаток как «приход минус расход» — это ошибка. А тут в чем дело, я пока не понял.
Спасибо, я понял. Вы ответили на мой вопрос.
Здравствуйте Павел!!!
Вообщем по задаче все предельно ясно изложено, как и во всех. У меня вопрос (возможно уже замучивший Вас) по моменту итогов в запросе. При списании Регистра ОстаткиТоваров в РасходнаяНакладная Вы устанавлиеваете условие Если Режим проведения Оперативный, тогда Движения Очистить() и Записать(). Можно ли просто в модуле ОбработкаПроведения(,) кроме того что мы ставим метку Истина на запись, очищаем движения, следующей строкой Движения.Рег.Записать() и в дальнейшем уже не задумываться какой режим проведения и моментом итогов устанавливать МоментВремени() без каких либо условий??? Я имею ввиду не конкретно решение этой задачи, а любой задачи оперативного учета где используется старый метод проведения.
Можно
Добрый день. Чем отличаются ведущие виды расчетов от вытесняющих видов расчета ?
Вытесняющие — вытесняют, ведущие — отвечают за перерасчеты. Подобные вопросы разбираются в базовом и продвинутом курсе по программированию.
Добрый день. в задаче 1.32 есть такой момент: «В документе «Приходная накладная» для каждой номенклатурной позиции указывается заказ покупателя, для которого приобретено это оборудование.» Это значит что для каждого товара заказ на этот товар нужно указывать в табличной части или нет ? В решении заказ указывается для документа почему так ?
Здравствуйте.
А нигде не сказано, что в приходной вообще должна быть табличная часть. Я не вижу проблем с добавлением в ТЧ заказа. Что конкретно вызывает у Вас сложности в решении, когда заказ в ТЧ?
Здравствуйте!
Не могу понять, когда в решении НЕОБХОДИМО использовать последовательность документов? Как это определить по условию задачи? Можно ли считать так: если в условии сказано: «… документы могут перепроводиться/вводиться задним числом …», то делаем последовательность. Если нет, то не делаем.
С уважением,
Антон
В общих требованиях к экзамену есть условие «система должна корректно работать как при вводе данных вперед так и назад». Везде где есть обусловленное проведение необходима последовательность. Но как правило на оценку наличие последовательности мало сказывается.
Добрый день!
В отчете все три показателя мы получаем из виртуальных таблиц в явном виде:
— ПоЗаказу как КоличествоПриход из ЗаказыОбороты;
— Отгружено как КоличествоРасход из ЗаказыОбороты;
— Закуплено как КоличествоПриход из ТоварыОбороты.
Перед этим также получаем остатки по заказам, помещая их в ТЗ, т.к. отчет должен быть по недоотгруженным заказам.
Вопрос: будет ли считаться ошибкой, если показатель ПоЗаказу получать как сумму остатка по заказу и уже отгруженного товара? В этом случае обходимся без ВТ и условия в запросе проще.
Это будет ошибкой.
1. Почему при отгрузке товаров проверяется остаток по счету, а не остаток по складу? Так конечно можно реализовать новое проведение, но при таком условии мы сначала безусловно записываем остатки по заказам. Если всего хватает, то потом делаем еще один запрос и, более того, полученный результат еще надо проверить на остатки на складе.
Я изменил подобную схему на старый метод. Т.е. получаем остатки по складу, одновременно рассчитывая в запросе разницу в списываемом количестве и себестоимость. Сортируем результат по возрастанию разницы в количествах. Соотв. если у нас будет минус, мы отловим его в первых рядах в выборке, и никаких лишних действий не будет.
Если же таковых нет, то движения по отгрузке можно записать безо всяких проверок исходя из условия задачи (минус блокировка), что товар на складе может появиться только на основании счета. А списать мы можем не больше, чем есть на складе. Или я чего-то недопонял?
2. Почему в запросе нет параметра для таблиц оборотов? Ведь в зависимости от конкретной даты может быть разный оборот. Получается, что берем остатки на одно число, а результат по оборотам может быть на другое.
2а. В случае необходимости установки параметра одновременно для таблицы и остатков и оборотов, каким образом это лучше обрабатывать?
Вариант 1: Для таблицы оборотов просто конец дня от введенной пользователем даты. Для остатков — выражение в параметрах вида: ВЫБОР КОГДА &Период = ДАТАВРЕМЯ(1,1,1) Тогда ДАТАВРЕМЯ(1,1,1) ИНАЧЕ КонецПериода(ДобавитьКДате(&Период, «СЕКУНДА»,1), «ДЕНЬ») КОНЕЦ.
Вариант 2: В модуле объекта отчета в процедуре «ПриКомпоновкеРезультата». Где необходимо проверить пользовательские настройки на предмет наличия в них периода, его использования и конкретной даты в периоде. Установить параметры данных соотв. образом.
3. Данную задачу можно решить с помощью одного регистра. При этом итог будет гарантированно сведен к 0 через какое-то время (т.е. не будет никаких вечно висящих остатков). Но это приведет к общему увеличению записей в регистре, т.к. какие-то из них будут уменьшать только первый ресурс, какие-то только второй и т.д.
Может ли такое решение быть оправданным в какой-то ситуации? Ведь можно считать, что показатель один — состояние счета, но несколько ресурсов.
Получение оборотов из регистра остатков менее эффективно, чем из регистров оборотов. Помнится читал статью, что при получении оборотов из регистра остатков SQL вообще всегда будет собирать обороты только лишь из движений. В то время как получение из оборотов приведет к тому, что будут получены итоги и досчитаны движения, если надо.
Есть ли смысл разделить регистры на отдельно остатки и отдельно обороты?
Собственно большую часть времени решения задачи я трачу на проработку стратегии «сколько и каких регистров нужно». А учитывая, что решений всегда несколько, то не всегда оптимальное решение лежит на поверхности. Быть может есть какой-то совет из Вашего личного опыта, на чем основывается окончательное решение в применении того или иного вида регистра. Ведь можно решить проблему одним регистром остатков, а можно разбить проблему на две подзадачи: остатки и обороты. Как выбрать?
1. «причем можно приобрести только то оборудование, которое заказано покупателем»
2. Заказ всегда конечен. и от дат не зависит. Обороты по заказу гарантированно рассчитались в основной таблице итогов.
3. Есть правило: 1 регистр = 1 показатель.
1. С цитатой из задания согласен, но мы же не можем отгрузить больше, чем есть на складе на момент проведения?
А если проверки наличия на складе все равно не избежать, то для чего делать проверки на кол-во в заказе? Ради демонстрации оперативного проведения?
2. Если представить след. ситуацию: 10го числа мы отгрузили 5 штук, 26го числа мы отгрузили 10 штук. Если не устанавливать никаких параметров, то мы получим остаток на текущую дату и обороты в размере 15 штук. А если мы хотим получить данные на десятое число? Выходит остатки будут на десятое, а обороты не 5 штук, а 15.
1. Есть условие в задаче. «причем можно приобрести только то оборудование, которое заказано покупателем» Давайте постараемся подобные вопросы не поднимать в следующих комментариях.
2. Я не против установки конечной границы расчета на момент проведения документа. Но в условии, что документ проводится не оперативно.
Павел, здравствуйте!
Традиционно 2 вопроса.
Вопрос №1 Объясните, пожалуйста, разницу в след.конструкциях:
//тут запрос
Если Режим=Оперативный Тогда
Движения.РегистрНакопления.Очистить();
Движения.РегистрНакопления.Записать()
КонецЕсли;
Запрос.УстановитьПараметр(«МоментИтогов», МоментВремени() );
и второй вариант
Движения.РегистрНакопления.Очистить()
//тут запрос
Если РежимПроведения = РежимПроведенияДокумента.Оперативный Тогда
МоментИтогов = ‘00010101’;
Иначе
МоментИтогов = Новый Граница(МоментВремени(), ВидГраницы.Включая);
КонецЕсли;
В чём разница?
Вопрос №2. Почему контроль связи остатков по заказам Вы делали по оборотам в запросах и отчетах?
1. В одном случае движения документа будут включены в расчет итогов, в другом — нет.
2. Не понял вопроса. В отчете указаны показатели оборотов. Берем недоотгруженные товары и читаем из таблицы основных итогов общий оборот.
1. Это понятно)) Я имел виду — в каких случаях применяется первый вариант, а в каких второй?
2. Я хотел сказать, что частенько вы используете таблицу оборотов, хотя можно заюзать таблицу остатков. Почему?
1. Не могу ничего нового добавить :) Когда надо включать движение — нужно их включать в расчета, когда нет, тогда нет. Извините, возможно я просто не понял о чем Вы меня спрашиваете.
2. Там неоткуда остатки брать. Там классические обороты. Сколько отгрузили и пр.
1. Нет, все верно — это я просто допетрить никак не могу)))
Можете привести пример, когда движения документа нужно включать в расчет итогов, а когда — нет?
P.S. извините за глупые вопросы, просто никак не могу въехать, а оставлять на авось такие моменты не хочется
Вот тут есть пример: http://xn—-1-bedvffifm4g.xn--p1ai/post-2014-03/%D1%81%D1%82%D0%B0%D1%82%D1%8C%D1%8F-%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0-%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B8/
Если можно, добавлю по первому вопросу. Тут статья Павла, мне кажется, будет к месту http://1c.chistov.pro/2013/07/blog-post_25.html
Во втором запросе (который в реальной задаче идет перед первым) речь идет о контроле остатков «по новой методике». Соответственно важно, на какой момент рассчитывать таблицу итогов.
В первом запросе (которые в реальной задаче идет вторым) остатки получаются для списания, делается расчет себестоимости.
Ещё в первой задаче стартового пакета более подробно рассматривается похожая ситуация.
Несколько вопросов:
В тексте задания указано — «В документе ПриходнаяНакладная для каждой номенклатурной позиции указывается заказ покупателя». У вас реквизит Заказ покупателя находится в шапке документа. Если так сделать на экзамене — это будет нарушением?
Еще вопрос — все-таки фразу «можно приобрести только то оборудование, которое заказано покупателем», надо трактовать как необходимость делать проверку?
Ну и последний вопрос — я сделал для каждого показателя регистр оборотов, куда записываю данные при проведении документа, т.е. у меня три регистра оборотов — Закупка, Отгрузка и Заказ. У вас регистров меньше. Смотрят ли вообще на экзамене на это? Или если решение работает, то все равно как оно внутри реализовано.
1. Если требование четко описано в задаче, то его свободная трактовка может снизить балл, следовательно, если нужно делать в ТЧ, то реквизит шапки будет воспринят как ошибка.
2. В задаче показатель то один: состояние заказа. На экзамене на это смотрят. Но если все работает и по тестовым данным расхождений с эталоном нет — то докапываться к мелочам не будут.
Вопрос по документу «Приходная накладная»:
В обработке проведения мы сначала делаем движения по остаткам товаров (приход), а потом проверяем, не купили ли больше чем в заказе таким запросом:
Запрос.Текст = «ВЫБРАТЬ
| ОстаткиТоваровОбороты.КоличествоПриход КАК Закуплено,
| ЗаказыОбороты.КоличествоПриход КАК Заказано,
| ОстаткиТоваровОбороты.Номенклатура
|ИЗ
| РегистрНакопления.ОстаткиТоваров.Обороты(, , , Заказ = &Заказ) КАК ОстаткиТоваровОбороты
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Заказы.Обороты(, , , Заказ = &Заказ) КАК ЗаказыОбороты
| ПО ОстаткиТоваровОбороты.Номенклатура = ЗаказыОбороты.Номенклатура
|ГДЕ
| ОстаткиТоваровОбороты.КоличествоПриход > ЕСТЬNULL(ЗаказыОбороты.КоличествоПриход, 0)»;
Вопрос в следующем: не проще ли сделать сначала движения (расход) по регистру Заказы, а после этого проверить, не ушли ли мы в минус только по остаткам регистра заказов?
Или надо делать регистр заказов оборотным и тогда так проверять. Но в этом случае регистр заказов будет двигать только документ «Заказ покупателя», а остатки товаров документами Приходная и Расходная накладные
У любой задачи может быть несколько решений. Так как курс записывался более 2х лет назад, я сейчас не могу вспомнить почему я решал задачу именно так. Попробуйте сделать свое решение, сравните с этим решением.
Здравствуйте! Ответте кто-нибудь плз на вопросы в предыдущем посте.
Характер задачи не ПОДРАЗУМЕВАЕТ для «приходной» и «расходной» реализации команд для автоматического заполнения табличных частей:
1) номенклатурными позициями (и количествами, конечно), которые уже заказаны, но еще не закуплены;
2) уже закуплены, но еще не отгружены?
Поясните вопрос. Автозаполнение не требуется по условию задачи.
Ну вот представьте себе, что некий менеджер в реальной практике пользуется нашим решением. Предположим, ему уже сделали заказов 50. Пусть в каждом из этих заказов в среднем по 150 номенклатурных позиций. Какие-то из этих позиций уже закуплены, а какие-то из закупленных уже даже поставлены заказчику. Вы же понимаете, что в какой-то момент этому менеджеру заполнить очередную приходную или расходную по какому-то из этих 50 заказов без листка бумаги и карандаша в руке будет не так просто?
В требованиях к экзамену пишут, что могут снимать баллы в том числе за:
1) за неэффективное решение;
2) за упрощение задачи
Поэтому, если бы Вас попытались обвинить в неэффективности решения или упрощении задачи, как бы Вы защищались?
В тексте задачи нет явного требования использовать механизм ввода на основании. Ни в тексте, ни в общих требованиях. Не стоит усложнять себе и так не очень простые задачи.
ОК. С этим вопросом все ясно. Спасибо.
Я бы лишь хотел уточнить Вашу позицию в более общем смысле.
Для целей экзамена решение задачи может быть неэффективным только в том случае, когда мы неграмотно используем механизмы, заложенные в платформу. Например:
1) у нас в цикле крутятся 2 запроса (этот пример любят приводить на курсах по 1С);
2) если при использовании объектной техники мы не укладываемся в одно обращение к базе данных, мы не эффективны (здесь надо пользоваться табличной моделью).
Ну и т.д.
При этом эффективность решения не оценивается ни с точки зрения программиста (то есть насколько легко придуманное решение реализовать в виде кода, а потом этот код сопровождать), ни с позиции конечного пользователя (я Вас уверяю, большинство пользователей найдут более эффективным то решение, где табличная часть заполняется автоматом, а не вручную).
Я здесь правильно все понимаю?
Если у Вас решение функционирует как того ожидает экзаменатор, то есть подозрение, что даже конфигуратор он открывать не будет.
Однако, если есть описание типовых ошибок (на сайте 1С) и с ним нужно ознакомиться для понимания того за что снимают оценки.
Запрос в цикле — плохо.
Обращение через точку к нетипизированным полям — плохо.
Обращение к базе объектной моделью — плохо.
И пр.
Эффективность оценивается именно с методической точки зрения, с точки зрения понимания функционирования системы.
А вот заниматься рисованием форма, «ублажением» пользователей, если об этом явно не указано в тексте задания, не надо. В РР задачах не нужно оклад рассчитывать автоматом если он в середине месяца поменялся, пусть пользователь две строки введет.
Цитата из задачи:
…На основании заказов покупателей
производится закупка оборудования у поставщика (документ «Приходная накладная»),…
Вопрос:
Мы не обязаны здесь реализовать МЕХАНИЗМ ввода на основании?
В тексте задачи нет этого требования.
Здравствуйте! Такой вопрос:
В документе Реализации, мы использовали новую методику проведения когда списывали с регистра Заказы остатки по отгрузке. А почему не воспользовались тем же методом и для списания остатков?
И еще: в той же обработке проведения, в запросе по остаткам в параметре ВТ:
(Заказ, Номенклатура) В
| (ВЫБРАТЬ
| &Заказ,
| ДокТЧ.Номенклатура
| ИЗ
| ДокТЧ КАК ДокТЧ)
Равносильно ли было бы Заказ = &Заказ И Номенклатура В (Выбрать …)
?
Два условия вместо одного составного. Думаю — это менее эффективно, хотя результат одинаков.
Понял. А первый вопрос?)
Не помню, Если Вы считаете что можно, давайте Ваше решение обсудим.
ПС: до нормально компьютера доберусь послезавтра, посмотрю базу.
Добрый день!
Не до конца понимаю ситуацию, сложившуюся в результате первоначально неправильно спроектированного
регистра накопления с одним из ресурсов «Стоимость». Приняла решение, что достаточно описать его «оборотный».
Конечно , подвел шаблон-«один ресурс — один регистр». Сейчас понимаю , что количество с суммой могут «соседствовать» в одном регистре. Были проведения документов в варианте регистра «оборотный».
Далее регистр описан как «остатки», модули проведения всех документов откорректированы, в исполняемом режиме отменено проведение всех документов и все снова проведены.
При проведении расходного документа во всех датах октября(документы все из октября) запрос по остаткам был пустым.
Интуиция подсказывала,что нет итогов на конец октября(есть запрос на текущий момент с использованием текущих итогов).
В режиме управления итогами увидела,что все итоги регистров накопления — на конец сентября 30,09,13.
Перенесла период рассчитанных итогов на конец октября 31.10.2013 и все заработало, как надо!
Не понимаю, почему текущие итоги в этом случае так себя вели, ведь они не связаны с итогами октября?
1. Один показатель = один регистр, у показателя может быть много ресурсов.
2. На какой вопрос отвечать тут не понятно.
Возник еще вопрос по блокировкам, правда , не из этой задачи
По условиям задачи 1.36 надо сделать документ «Сторно», который для выбранного документа будет формировать все те же движения по всем тем же регистрам, но с отрицательным знаком.
Надо ли накладывать блокировки на считываемые движения выбранного документа и если да, то как ?
А зачем? Мое мнение: не надо.
Добрый день.
В модуле объекта ПриходнаяНакладная в видеорешнении была наложена управляемая блокировка на РегистрНакопления Заказы. Режим блокировки — Исключительный.
В дальнейшем мы только читаем данные по этому регистру в запросе.
Но такой режим применяется,если происходит чтение данных с последующим изменением.
В нашем случае изменений нет.
Возможно ли в этом случае ограничиться режимом блокировки — Разделяемый ? Или принципиальной разницы нет и ,в общем случае, можно всегда накладывать только режим Исключительный?
Да, тут можно разделяемый режим использовать. Спасибо.
Павел, в условии задачи сказано, что «В документе «Приходная накладная» для каждой номенклатурной позиции указывается заказ покупателя». Не означает ли это что необходимо заказ указывать в ТЧ?
Это не принципиально на мой взгляд. Нужно в запросе условие по заказу перенести в условие соединения и все.
1. Интересно, период отчета — это период таблицы остатков Заказы. В тоже время мы не ограничиваем две таблицы оборотов по дате конца. Таким образом мы вполне корректно получаем список недоотгруженных заказов на конкретную прошлую дату, но данные по оборотам — отгружено, закуплено, всегда будут актуальные. Так и должно быть? Или может все таки таблицы оборотов также следует ограничить по дате конца минус одна секунда?
2. Похожий вопрос с документом приходная накладная. В тексте этого запроса мы также не ограничиваем таблицы оборотов по дате конца, т.е. берем актуальные обороты. Возможно я не очень понимаю, но может по дате конца обороты следует ограничить моментом времени документа с режимом — «включая»?
«ВЫБРАТЬ
| ОстаткиТоваровОбороты.КоличествоПриход КАК Закуплено,
| ЗаказыОбороты.КоличествоПриход КАК Заказано,
| ОстаткиТоваровОбороты.Номенклатура
|ИЗ
| РегистрНакопления.ОстаткиТоваров.Обороты(, , , Заказ = &Заказ) КАК ОстаткиТоваровОбороты
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Заказы.Обороты(, , , Заказ = &Заказ) КАК ЗаказыОбороты
| ПО ОстаткиТоваровОбороты.Номенклатура = ЗаказыОбороты.Номенклатура
|ГДЕ
| ОстаткиТоваровОбороты.КоличествоПриход > ЕСТЬNULL(ЗаказыОбороты.КоличествоПриход, 0)»
А зачем нам ограничивать обороты? По логике, работа будущим числом не предусматривается.
Павел вопрос по блокировкам, там где используется конструкция БлокироватьДляИзменения = Истина.
Очередность насколько я понял такова:
1. Ставим у движений по регистру БлокироватьДляИзменения = Истина.
2. Получаем данные запросом по этому регистру.
3. Формируем движения.
4. Записываем их и в этот момент система устанавливает блокировку на регистр по полям движений.
А не изменит ли кто-нибудь данные в регистре, пока мы не записали движения на шаге 4 и блокировка не налодилась еще на регистр?
Нет, очередность такова:
1. Устанавливаем БлокироватьДляИзменения = Истина и формируем движения. Последовательность тут не важна.
2. Записываем движения, в этот момент устанавливается блокировка.
3. Читаем остстки и отменяем транзакцию проведения если ушли в минус.
Ага понял, спасибо))
Интересно, это только у меня вместо видео черный экран и тишина (прежние видео воспроизводятся нормально)?
Видео стало воспроизводиться…
Только звука нет.
Обратитесь к саппорту по почте