Решение ДЗ №11 базового курса
09.08.2010
комментарий 31
Решение второго задания по бухгалтерскому учету.
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь. Если Вы оплачивали курс, у Вас активирован токен доступа, Вы залогинены, но Вы видите эту запись — напишите нам на e-mail поддержки.
Выполнил
Пожалуйста, оставьте более детальный отчет.
Задание выполнено
ДЗ №11 сделал…
Зачем такой геморой с заменой запятых на предыдущих строках?!..
Ведь можно эти поля перенести немного выше – чтоб они были НЕ послдними..
Реч идет о заменах в запросе в 4 уроке..
Сделано.
Евгений, с Вашего позволения ещё несколько “рацпредложений”:
1. Модуль объекта РеализацияТоваров, процедура СформироватьДвиженияБУ(). В запросе следует указать:
ISNULL (ХозрасчетныйОстатки.СуммаОстатокДт,0) КАК СумОст,
ISNULL(ХозрасчетныйОстатки.КоличествоОстатокДт,0) КАК КолОст
Если не было движений по БУ, то без ISNULL будет ошибка, т.к. присоединяем таблицу.
2. Модуль объекта Выписка, процедура ОбработкаЗаполнения(). Думаю, что использование отбора только по субконто “Контрагенты” явно недостаточно. Мало ли где у нас ещё это субконто будет… Не далее как в ДЗ12 появляется забалансовый счет с таким субконто. Думаю лучше наложить условие на сами счета, тем более, что в ДЗ11 они указаны явно: 62 и 60. Иначе потом концов не найти. Мой вариант запроса:
ВЫБРАТЬ
ХозрасчетныйОстатки.Счет,
ХозрасчетныйОстатки.Субконто1 КАК Контрагент,
ХозрасчетныйОстатки.СуммаОстатокДт КАК Приход,
ХозрасчетныйОстатки.СуммаОстатокКт КАК Расход
ИЗ
РегистрБухгалтерии.Хозрасчетный.Остатки(,
Счет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.Поставщики) ИЛИ Счет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.Покупатели), ,
Субконто1 = &Контрагент) КАК ХозрасчетныйОстатки
3. Модуль менеджера АктСверки, процедура Печать(). Ну не мог я оставить на одну простую форму три запроса:
ВЫБРАТЬ
АктСверки.Дата,
АктСверки.ДатаНачала,
АктСверки.ДатаОкончания,
АктСверки.Контрагент,
АктСверки.Номер,
ISNULL(ОстаткиНаНачало.СуммаОстаток,0) ДолгНачало,
ISNULL(ОстаткиНаКонец.СуммаОстаток,0) ДолгКонец,
АктСверки.Сверка.(
НомерСтроки,
Документ,
СуммаУменьшения,
СуммаУвеличения)
ИЗ
Документ.АктСверки КАК АктСверки
ЛЕВОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(&ДатаНачала, Счет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.Поставщики) ИЛИ Счет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.Покупатели), , Субконто1 = &Контрагент) КАК ОстаткиНаНачало
ПО АктСверки.Контрагент = ВЫРАЗИТЬ(ОстаткиНаНачало.Субконто1 КАК Справочник.Контрагенты)
ЛЕВОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(&ДатаОкончания, Счет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.Поставщики) ИЛИ Счет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.Покупатели), , Субконто1 = &Контрагент) КАК ОстаткиНаКонец
ПО АктСверки.Контрагент = ВЫРАЗИТЬ(ОстаткиНаКонец.Субконто1 КАК Справочник.Контрагенты)
ГДЕ
АктСверки.Ссылка = &Ссылка
Остальные параметры можно взять из Ссылки, для команды Печать поставить Режим использования параметра: Одиночный.
Евгений, если я перебираю со своей дотошностью, можете не модерировать мой комментарий – у меня никаких претензий. “Не корысти ради, а пользы для”.
1, 2. Принято.
3. А вот тут спорный вопрос.
Что лучше сложный запрос (который мог бы быть и больше, при дополнительных условиях) или ряд простых запросов.
Пожалуй, если это не операция, выполняющаяся в транзакции, то лучше второй вариант.
По п.3. Думаю понятия “простой” и “сложный” запрос – достаточно субъективные. Наверное я “испорчен” типовыми конфигурациями 1С. После УПП для меня любой запрос простой, если его можно распечатать менее, чем на 5 страницах :) Например, Функция ПолучитьТаблицуДействийСУправленческимиНачислениями(). Там в запросе навскидку порядка 1000 строк.
Да, запросы по ЗУП вообще сказка. Иногда рука устает давить PgDown пока дойдешь по секции итогов ))
Евгений, не совсем согласна с решением 11 задания.
Проведение документов поступления: Изначально, еще в 10 задании, данные для проведения БУ нужно было брать из другого запроса, который для регистра продажи. Если нет проведения по УУ, то совершенно не нужны наборы, развернутые по составу. Получается, что мы запрашиваем избыточные данные. Кроме того, тогда не придется делать отдельный запрос для проведения услуг по БУ
Реализация: Некорректно при недостатке товара проводить документ, т.к. в себестоимости будет полная ерунда, которая потом никак не откорректируется. Поэтому нужно проверять остатки и при нехватке выдавать отказ.
Я при решении организовала запрос так, что его сразу можно загрузить в набор записей, правда потратила значительно больше времени. Вопрос, с точки зрения сдачи экзамена, насколько важно этого добиваться, ведь время очень ограничено?
И не только для экзамена,но и на практике. Какие критерии есть, чтобы определить когда можно закончить с оптимизацией, а то это процесс почти бесконечный, а когда все же оптимизировать нужно.
Заполнение документа выписка – не все так однозначно. Если от покупателя получен аванс, то в Вашем случае выписка формирует движение расход. Мне кажется, нужно контролировать по какому счету остаток и формировать проводки не по всем остаткам. Правда тогда теряется универсальность ведь Вы сознательно не задаете счет. Как правильнее поступить в данной ситуации?
По поводу акта сверки, на мой взгляд, долги на начало и конец периода, нужно выбирать тем же запросом, что и движения и потом записывать в реквизиты документа. Т.к. нехорошо при печати лишний раз выполнять запрос. И уж совсем нехорошо выполнять запрос для долгов два раза.
Соглашусь с отдельным запросом для получения данных БУ в поступлении товаров.
Но, не проводить реализацию при нехватке ТМЦ на счете БУ, считаю не правильным. Ведь отгрузка это оперативная деятельность предприятия, именно она приносит прибыль. Тем более мы сделали контроль по регистру накопления. Поэтому проводить документ надо. Но можно выдать диагностику, о том что идет списание в минус.
А что касается неверных данных (отрицательных остатков), то их можно выявить отчетом на конец месяца. Чтобы видеть реальную себестоимость по БУ нужно будет сделать регламентный документ, который доведет себестоимость до среднего.
По поводу оптимизации, процесс действительно можно проводить очень долго. Главное чтобы система удовлетворяла бизнес-требованиям. Например, время проведения документа должно удовлетворять неравенству
РабочийДень<=(Время на заполнение документа + Время проведения) * Количество документов в день.
Также нужно анализировать субъективное мнение пользователей. Если выполняются бизнес-требования и от пользователей нет жалоб можно остановиться на оптимизации.
Кроме этого, списание в минус (вначале продажа, потом поступление) является нормальной ситуацией для таких конфигураций как УПП и КА.
По поводу заполнения выписки, конечно могут быть нюансы, но мы рассматриваем простой случай. Даже в приведенном вами примере, когда был аванс от покупателя, то вводом на основании мы возвращаем назад аванс. Такая ситуация возможна.
По акту сверки можно записывать остатки в реквизиты документа. Но все-таки нужно отдельно получать данные об оборотах и остатках. Если вы будете использовать ВТ ОстаткиИОбороты, система будет считать остатки долга по каждому документу. Что, во первых, не нужно, а во вторых представляет серьезную нагрузку для сервера..
Конечно в акте сверки я использовала три запроса 2 к регистру остатки и один к оборотам. Вы же хороший преподаватель, и таких “ляпов” ваши слушатели не делают.
Отлично )
Оптимальнее в одном запросе объединить два запроса к остаткам, чтоб 2 раза не обращаться к серверу..
А еще луче Полным соединением !..
Насчет решений ДЗ от Мастера: их же не в обяз поверх своего кода набивать. Но вот ознакомиться с ними очень интересно.
Я уже раньше отмечал, что обучение задаёт направление, а не жёсткий шаблон действий.
Заради эксперимента никто не запрещает реализовывать различные варианты.
Главное – правильный результат и оптимальная производительность.
Все верно, Сергей )
Сдавал экзамен , с его точки зрения всёравно как заполнять движения, загрузкой или по одной … главное чтобы правильно. И чтобы в запросах небыло лишних таблиц.
Да, на экзамене главное правильно работающее решение.
Но за грубые ошибки голову снимают, типа запрос в цикле.
Не соглашусь по поводу записи остатков в реквизиты – на момент печати могут произойти изменения задним числом, которые соответсвенно не отразятся в отчете..
Пара вопросов.
В Печатной форме Акта Сверки ДатаНачала
Мы получаем остаток на конец дня даты Начала что наверное всётаки неправильно …
Второе вообще по решениям БлокироватьДляИзменения не надо выставлять Движениям?
1. Хорошее замечание.
В своей базе сделал переделал определение долга: в функцию сразу передается та дата, на которую нужно получить долг.
2. В нашей базе блокировка требуется только для реализации товаров. Но свойство БлокироватьДляИзменения будет полезным только для регистра ОстаткиНоменклатуры, для регистра бухгалтерии нужно будет накладывать блокировку вручную.
Подробно о механизме блокировок мы будем говорить в продвинутом курсе..
Есть несколько мелких замечаний.
1. В модуле ПоступлениеТоваров в обработке проведения лучше указать:
Если УУ Тогда СформироватьДвиженияУУ(Взаиморасчеты); КонецЕсли;
Если БУ Тогда СформироватьДвиженияБУ(); КонецЕсли;
Иначе даже при обоих снятых флагах попадают движения во Взаиморасчеты и Хозрасчетный (см. документ от 01.08.2010).
2. В модуле АвансовыйОтчет в обработке проведения следует добавить:
Движения.ОстаткиНоменклатуры.Записывать = Истина;
Движения.Закупки.Записывать = Истина;
Движения.Хозрасчетный.Записывать = Истина;
Коллега xalker упомянул ранее, приоритет за ним :) Иначе снимаем УУ и БУ, перепроводим, а старые движения остаются.
3. Новый ресурс регистра бухгалтерии Количество лучше привязать к признаку учета Количественный. Иначе КоличествоДт, КоличествоКт можно указывать для любых счетов.
Замечания все верные.
Спасибо, Константин!
Ну… почти так… :)
Проверку на остатки при проведении по бух регистру все же делал (по наитию видео из курса)… Не использовал изменения текста запросов => все было несколько более громоздким – будем исправляться… Хотя читать потом эти кусочные тексты с несколькими заменами так или иначе неопытному довольно сложно.
А там нет ошибки: В процедуре ПриходНоменклатуры общего модуля, когда выдирали установку свойства Записывать в истину для наборов движений. Выдернули их и внесли в обработку проведения документа ПТУ, а про Авансовый отчет вроде как и забыли.
При формировании ТЧ акта сверки упорядочивал по дате регистратора.
Файлы 10-13 “Not found”
Через 17 минут ситуация исправиться.
с 10 по 13 видео не качается, хотя думаю это у вас под контролем =)
Сейчас все файлы должны качаться..