Билеты на экзамен 1С (билет 3)

Оперативный учет

       Компания занимается оптовой торговлей. Поступление товаров отражается документом «Приходная накладная», продажа - «Расходная накладная». Помимо продажи товара, могут оказываться дополнительные услуги, например по доставке. И услуги и товары указываются в одной табличной части.

       Складской учет товаров не ведется.

       Списание себестоимости должно быть в зависимости от принятого на момент проведения документа значения учетной политики. Метод списания себестоимости либо по FIFO, либо по средней. Учетная политика может меняться каждый месяц, её изменение фиксируется соответствующим документом. Например:

       01.01.2012 Учетная политика № 1 Списание по FIFO

       05.01.2012 Прих. накладная № 1 Куртка 1 шт. 1800р. (стоимость закупки)

10.01.2012 Прих. накладная № 2 Куртка 1 шт. 1000р. (стоимость закупки)

15.01.2012 Прих Накладная № 3 Куртка 1 шт. 2000р. (стоимость закупки)

25.01.2012 Расх. накладная № 1 Куртка 1 шт. 1800р. (себестоимость)

       01.02.2012 Учетная политика № 2 списание по средней

       07.02.2012 Расх. накладная № 2 Куртка 1 шт. 1500р. (себестоимость)

Считается, что документы задним числом не вводятся, но старые документы могут неоперативно перепроводиться.

       Необходимо построить отчет по движениям товаров за период.

Движения товаров за период с 15.01.2012 по 25.01.2012

Бухгалтерский учет

Необходимо создать документ «Операция», с помощью которого пользователь должен иметь возможность ввести проводки с произвольной корреспонденцией счетов. При решении задач следует учитывать возможность наличия проводок, сформированных с помощью данного документа.

       Требуется организовать возможность ведения взаиморасчетов (счет «Покупатели») в разрезе контрагентов и договоров в валюте взаиморасчетов. С каждым контрагентом может быть заключено любое количество договоров (у каждого может быть своя валюта взаиморасчетов). Все взаиморасчеты по договору ведутся только в валюте, указанной в этом договоре, и рублевом эквиваленте.

       Задолженность покупателей возникает при проведении документа «Расходная накладная». В этом документе пользователем указывается сам покупатель («Контрагент») и договор. Все суммы в документе указываются в валюте выбранного договора.

       Документ «Расходная накладная» формирует следующую проводку:

Дт «Покупатели» - Кт «Прибыли и убытки»

на сумму продажи в валюте взаиморасчетов и в рублях по курсу на дату документа

Оплата задолженности по отгрузке происходит документом «Приход денег», где указывается контрагент и сумма оплаты в рублях. Сумма должна автоматически распределяться на договоры в соответствии с максимальной рублевой задолженностью по договору (чем больше задолженность, тем скорее она должна быть оплачена). Следует считать, что авансов и переплат быть не может.

       Документ «Приход денег» должен формировать следующие проводки:

Дт «Касса» - Кт «Покупатели»

на расчетную сумму оплаты в валюте взаиморасчетов и в рублях по курсу на дату документа.

Необходимо реализовать документ «Корректировка задолженности», который был в соответствии с изменившимся курсом валюты взаиморасчетов корректировал рублевую задолженность покупателя. Т.е. предположим, что при курсе валюты «Валютная» в 10 рублей покупателем был получен товар на 10 единиц «Валютная» (получается, по курсу это 100 рублей). Курс вырос до 12 рублей за единицу валюты. В соответствии с этим рублевая сумма задолженности покупателя должная возрасти на 20 рублей.

       Документ «Корректировка задолженности» делает следующие проводки:

В случае увеличения рублевого долга покупателя:

Дт «Покупатели» - Кт «Прибыли и убытки» на сумму разницы

В случае уменьшения рублевого долга покупателя:

Дт «Прибыли и убытки» - Кт «Покупатели» на сумму разницы

Документ «Корректировка задолженности» вводится как регламентный (один экземпляр корректирует все существующие задолженности).

Необходимо создать отчет о взаиморасчетах с покупателями по выбранной валюте за период с детализацией до документа.

Взаиморасчеты за период с 01.01.2012 по 31.01.2012

Валюта: USD

Периодические расчеты

       Начисление зарплаты сотрудникам предприятия осуществляется ежемесячно с использованием метода отклонений. Каждый сотрудник может работать одновременно в нескольких подразделениях компании, то есть совместительство допускается.

       Все сотрудники работают по пятидневному графику работы, однако в решении необходимо предусмотреть возможность работы по нескольким различным графикам.

       Сотрудники предприятия получают оплату по окладу пропорционально отработанному времени в часах. Часовая ставка рассчитывается как начальное значение оклада, деленное на количество рабочих часов в том же периоде, что и фактически отработанные часы. Первоначальное значение оклада может изменяться не чаще, чем один раз в день, но берется на начало расчетного периода. В информационной базе необходимо хранить историю его изменения.

       По мере необходимости любой сотрудник может быть отправлен в командировку.

В этом случае начисление по окладу не происходит. Часы, проведенные в командировке, определяются по пятидневному графику работы. Часовая ставка для расчета командировки определяется как сумма всех начислений за два предыдущих месяца, деленная на количество отработанных часов в двух предыдущих месяцах. Следует учесть, что данные о командировке могут вводиться в систему задним числом.

По понедельникам, средам и пятницам по 2 часа времени уходит на вечерние часы. Часовая ставка за каждый вечерний час на 50% больше часовой ставки оклада.

Вечерние часы (командировка) рассчитываются также, как и для оклада (возможно не требуется).

Механизм перерасчетов в рамках данной задачи использовать не надо.

Ввод всех начислений происходит документом «Начисление зарплаты». Документ в расчетном периоде может быть один (сразу для всех видов расчета), а может быть несколько (по одному для каждого отдельного вида расчета). Считать, что все данные вводятся только в пределах одного месяца, например, можно указать начисление оклада с 10.01 по 31.01, а запись оклад: с 10.01 по 03.02 вводить нельзя. В одном документе могу быть данные за разные расчетные периоды.

       Для анализа сделанных сотрудникам предприятия начислений в конфигурации необходимо предусмотреть отчет следующего вида:

Отчет может быть построен за любой расчетный период.

Управляемые формы

В справочнике «Контрагенты» необходимо создать управляемую основную форму элемента, в которой пользователь сможет увидеть все движения с участием этого контрагента по регистру бухгалтерии. Доступ к этой информации должен осуществляться из панели навигации.

В форме документа «Приходная накладная» необходимо предоставить пользователю возможность вводить произвольный текстовый комментарий. Текст комментария может содержать навигационную ссылку (не более одной) на документ оплаты. Переход по навигационной ссылке должен осуществляться при нажатии кнопки открытия, созданной у данного элемента управления формы. Примерный вид пояснения приведен на следующем рисунке.

       При проведении документа «Расходная накладная» в случае нехватки товара должно появляться сообщение с указанием реального количества. Данное сообщение должно быть привязано к полю «Количество» соответствующей строки табличной части документа (см. рисунок). В случае наличия дублей строк сообщение должно быть связано с первой строкой, содержащей проблемную номенклатуру.

Комментарии при сдаче

ОУ: Сделал как здесь http://www.ax-online.ru/Exams/AttPlatf/Task-1.5.aspx, в итоге получил -1 балл. Вывод: не стоит так делать. Я понадеялся на этот сайт, думал там круто решено, оказалось не совсем. Препод сказал, что так, конечно, можно делать, но лучше не нужно. Сказал (цитирую): идеальное решение этой задачи на двух регистрах, один с количеством, другой с суммой.

БУ: В бух части билета необходимо обратить внимание на то, что документ Приход денег должен погашать именно валютные суммы, несмотря на то, что оплата всегда в рублях. Еще измерение валюта не надо создавать, она указывается в договоре.

УФ: в открытии комментария надо искать не e1cib, а e1cib/data/Документ, поскольку может быть ссылка не только на документ.

Спросила про блокировки, нужно ли ставить две блокировки БлокироватьДляИзменения и БлокировкаДанных. Оказывается, вопрос спорный, зависит от ситуации и в 5 минутах не рассказать. В задачах на экзамене  Д. Гончаров ответил, что он бы не стал, поскольку вообще это может привести к взаимных блокировкам. А на экзамене за двойную блокировку не снижают.

ОУ. Два метода - по средней и фифо. Отсебятину не добавлял, под два метода затачивал решение. Документ Изменение учетной политики, в случае, когда с фифо менялось на среднюю, списывал все остатки партий и тут же делал приход с незаполненной партией. В расходной вообще разделил проведение в условии Если ИначеЕсли КонецЕсли. В зависимости от текущего метода списания. Данные для списания получал одним запросом. Один регистр накопления, измерения: Номенклатура, Партия, ресуры: Количество, Стоимость. Отчет стандартная ведомость по таблице остатков и оборотов. Красивости не наводил, все ресурсы в отдельных колонках smile

БУ. Тут тоже вроде ничего не изобретал. Договоры как справочник, подчиненный справочнику Контрагенты. Валюта - реквизит договора. Признак учета Валютный для счета Покупатели и Касса,  на счете Покупатели два субконто Контрагент и Договор. В регистре бухгалтерии измерение Валюта (небаланс, связь с ПУ), ресурсы Сумма и ВалСумма (небаланс, связь с ПУ). В документах все стандартно, в расходной просто движения с БлокироватьДляИзменения = Истина, в Приходе денег классическое списание партий по "старой" методике, только в качестве партий договора. Трудности с документом Корректировка задолженности, но я его для себя почти выучил, делал регламентным его, без реквизитов, т.е. отрабатывал для всех контрагентов и их договоров.

Отчет делал также по таблице Остатки и обороты. Без "красивостей", как в тексте билета. Столкнулся с интересным косяком, добавил признак учета и когда хотел связать его с измерением регистра бухгалтерии и ресурсом, то ПУ в окне выбора не появлялся! Пусто там было. Раньше почему то с таким не сталкивался. Сохранял конфу, конфу базы данных обновлял, бесполезно. Минут 10 был в шоке smile Потом пришла мысль перезапустить конфигуратор целиком. ПУ стал доступен для выбора. Вот такие чудеса smile

Расчетная часть. Тут вообще как по маслу, с нее и начал решать. Оклад и командировка, все по часам, все в одном ПВР, один РР, Отработано дней накапливал в ресурсе РР, измерения Подразделение (т.к. есть совместительство), Сотрудник, ресурс Сумма и ОтработаноДней, параметр График (связь с графиком). Командировка вытесняет Оклад, ПВР ОсновныеНачисления - с периодом действия, зависит по периоду действия от Осн начислений. РР с периодом действия, связь с графиком, с базовым периодом. В качестве базы для командировки поставил оклад и саму командировку. Сторно должны быть получены и учтены. В общем модуле делал расчет отдельно для оклада, записывал, потом делал отдельным запросом для командировки, записывал. Отчет классический в виде таблицы по периодам. На фразу в билете "В одном документе могу быть данные за разные расчетныепериоды" покосился и забыл. В качестве периода регистрации использовал дату документа smile

В силу моих особенностей не очень торопиться с мыслями, раздел на управляемые формы не успел сделать, кроме вывода сообщения в расходной, который сделал по ходу оперативной части.  

Вот как то так. В сообщении о результатах экзамена написали "Оценка 3. Результат: Сдан. Не реализован раздел по управляемым формам". Получается, что все остальное проверяющих устроило smile Ну я и рад безмерно smile Все свои сомнительные умозаключения описывал в файле-пояснении к решению, рекомендую это делать всем. Например, я туда написал, что специально не делал красивости в отчетах, т.к. они и так выводят правильные данные smile ну и другие мысли туда понаписал, когда решал СПР и ОУ.

ОУ: Во-первых, при сортировки по партиям указал дату документа, а нужно было использовать момент времени.

Во-вторых, сам метод решения был неправильным. Для экзамена пойдет, но для жизни - нет. Многое сделано неоптимально. Сомневался я над решением этой задачи, оказалось не зря.

Я делал способом описанным здесь на формуме. Для смены учетной политики я сделал месячный регистр сведений. Оказалось не совсем правильно, поскольку учетная политика меняется раз в месяц, но кто сказал, что она должна меняться именно первого числа в начале дня . Упрощение - раз. Далее - не факт, что именно в эту секунду не будет сделан приход или расход. В общем выход один - сделать так, чтобы учетная политика могла устанавливаться на определенный момент времени и меняться хоть сто раз в день. Условие, что учетная политика может меняться раз месяц - это ограничение пользователей. Дополнительных проверок не нужно делать. (Тоже самое касается и бухгалтерского учета, переплат и авансов нет, и проверять это не нужно в программе, это ограничение в самом вводе, контролировать не нужно.)

Краткое описание как я сделал - один регистр ОстаткиНоменклатуры - два измерения - Номенклатура, Партия - два ресурса - Количество, Сумма.

Я сделал так - приход в зависимости от метода списания - приход делается либо по пустой партии, либо в партию идет документ прихода. При списании я сделал два алгоритма - либо по среденей, либо по партиям. Получение метода, далее простое условие, если по средней, то один алгоритм и выборка, иначе - другой. Преподаватель сказал, что я сделал лишнюю работу, потерял время, так как можно было сделать одно партионное списание, но баллы не снял.

Нужно было делать так - списание чисто по партиям. Регистр учетная политика - подчинен регистратору документу СменаУчетной политики и определяется на каждый момент времени (а не даты). Далее основная идея - нет никаких пустых партий в регистре. При переходе на учетную политику по средней документ СменаУчетнойПолитики должен закрывать все партии, а делать приход на себя. То есть Партия - это документ оприходования или же документ смена учетной политики. Вот так. При проведении приходной накладной, она смотрит установленное значение метода списания, если по партиям- пишет в партию себя(ссылку), если же по средней - то из регистра получает, какой документ поставил эту учетную политику, и ставить его. Проведение - по партиям. Всё оказалось просто и легко, работает для любого момента времени, даже если документы были в одной секунде. Можно менять учетную политику много раз в любой интервал времени.

Всё остальное - более менее нормально и стандартно.

БУ: счет покупатели - Контрагенты, Договоры. Сумма - баланс, ВалСумма - небаланс, валютный учет. Валюта не является субконто, так как расчеты по одному договору только в этой валюте. Главное в курсах не запутаться. Приход денег без контроля авансов. Корректировка задолженности с проверкой, чтобы не писать пустые записи, если курс не изменился.

СПР: период регистрации в таблице. Один регистр с периодом действия и базой по периоду действия, виды начисления - командировки и оклад. График пятидневка, отдельный реквизит для хранения. Ресурсы - результат и отработано часов. Командировка вытесняет оклад. База для расчет командировки - оклад.

Есть одна сложность - получить в запросе для списка сотрудников на разные даты периода регистрации - оклад на первое число. Пришлось обращаться к записям регистра ОкладыСотрудников, искать сначала нужные мне периоды (меньше или равно началу менсяца периода регистрации, дальше брать максимум). Потом уже когда период известен, то по сотруднику, подразделению и периоду в регистре находить нужный мне оклад. Далее стандартно - при расчете, сделать запись результата оклада до расчета командировки. Так же не забыть про сторно записи.

Отчеты смотрелись только по внешнему виду, сами запросы не смотрелись. Шапки и заголовки не нужны. Однако важно наличие положения колонок - вертикально, горизонтально. Положение и заполнение группировок - отдельно и только в итогах.

Красоту делать не нужно. Внешний вид документов  по умолнчанию. Пересчета табличных частей нет (сумма, цена, количество). Последовательностей нет. В документе операция сделал только установку дату для всех проводок, при отмене проведения делал отмену активности записей. Претензий не было.

Принимал Белоусов. Было неудобно, торопился всё время. Сняли баллы за решение задач по управляемым формам, не успел всё доделать. По управляемым формам три задачки, я сделал только одну, вторую не до конца, третью не успел. Не хватило чуть-чуть, слишком много времени потратил на отладку ошибок, ввод данных, первоначальный разгон. Снял баллы за решение оперативной задачи. Смотрел код проведения всех документов, запросы, блокировки, запись, проблема копеек.