Главная страница
Навигация по странице:

  • Подразделение Сотрудник Вид расчета

  • Расчетная часть

  • Билеты. Актуальные билеты на экзамене 1С_Специалист по платформе 1С_Пред. С 04. 2014 билеты компонуются случайным образом!


    Скачать 0.61 Mb.
    НазваниеС 04. 2014 билеты компонуются случайным образом!
    АнкорБилеты
    Дата14.03.2022
    Размер0.61 Mb.
    Формат файлаdocx
    Имя файлаАктуальные билеты на экзамене 1С_Специалист по платформе 1С_Пред.docx
    ТипДокументы
    #396536
    страница7 из 32
    1   2   3   4   5   6   7   8   9   10   ...   32

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


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

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

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

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

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

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

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

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

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

    Подразделение

    Сотрудник

    Вид расчета

    Период1

    Период2





















    Итого:
















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

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


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

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



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


    Комментарии при сдаче
    http://chistov.spb.ru/forum/16-993-27237-16-1357927083

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

    С другой стороны, есть комментарии, что так решать можно:

    1. Самое интересное что полтора года назад П.Белоусов говорил что решать надо как в http://www.ax-online.ru/Exams/AttPlatf/Task-1.5.aspx (http://chistov.spb.ru/forum/16-993-27300-16-1358298418)

    2. Человек решал этим же способом, получил “Отлично” (http://chistov.spb.ru/forum/16-993-142#27104)

    БУ: В бух части билета необходимо обратить внимание на то, что документ Приход денег должен погашать именно валютные суммы, несмотря на то, что оплата всегда в рублях. Еще измерение валюта не надо создавать, она указывается в договоре.
    http://chistov.spb.ru/forum/16-993-28684-16-1366686967

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

    Спросила про блокировки, нужно ли ставить две блокировки БлокироватьДляИзменения и БлокировкаДанных. Оказывается, вопрос спорный, зависит от ситуации и в 5 минутах не рассказать. В задачах на экзамене Д. Гончаров ответил, что он бы не стал, поскольку вообще это может привести к взаимных блокировкам. А на экзамене за двойную блокировку не снижают.
    http://chistov.spb.ru/forum/16-993-172#30563

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    1   2   3   4   5   6   7   8   9   10   ...   32


    написать администратору сайта