Форум Чистова. Подготовка к экзаменам 1С
Аттестация "1С:Специалист" => Аттестация "1С:Специалист по платформе 1С:Предприятие 8.3 и 8.2" => Тема начата: Jones от Сентябрь 22, 2015, 02:45:50 pm
-
Сделал Билет 12. Есть пара вопросов.
ОУ
Т.к. новая методика применима лишь в небольшом проценте задач, то ее алгоритм до автоматизма я так и не довел. Каждый раз приходится его вспомирать. Поэтому, коллеги, прошу проверить, ничего ли я не забыл:
1) новая методика контроля остатков (как более эффективная) применена потому, что для формирования движений не нужно ничего получать из БД, все уже есть в ТЧ документа. Алгоритм следующий:
2) До записи движений включаю БлокироватьДляИзменения
2) Формирую движения по списанию
3) Записываю движения
5) Запросом получаю остатки на ГраницуВключая этот документ
6) Если есть отрицательные остатки, то Отказ
В РН применена старая методика, т.к. надо списывать остатки стоимости.
Характеристики сделал так:
1) Создал регсведЗначенияХарактеристик: измерение Объект (ЗаказПокупателя), измернениеВидХарактеристики (ПВХ), ресурс ЗначениеХарактеристики (Характеристика)
2) В предприятии создал Характеристики, Регион сделал просто текстовым, заполнил регистр сведений
3) В запросе отчета настроил, что характеристики выводить для объктов типа ЗаказПоставщику, вид харак-к брать из ПВХ, значения из регсвед.
4) В элементе пользовательских настроек включил вывод Группировок на форму отчета, в режиме предприятия добавил группировку по характеристике Регион.
В регистре ЗаказыПокупателей у меня только Количество, а Сумма появляется только в регистре Резервы.
Кто что думает? Здесь все логично?
БУ
В блокировке хотел разделить номенклатуру на Детали и Изделия (получить две ТЗ и блокировать каждый счет по их содержимому), но потому подумал, что на экзамене не до таких извращений. Короче, просто блокирую оба счета по Номенклатуре из ТЧ. Пойдет?
ПР
В сборнике есть похожая задача – это 3.35. В задании есть несколько моментов, которые привели к возникновению вопросов:
Коллеги, я так понимаю, что в РР не нужно изменение Автомобили (Подразделения) т.к. совместительство невозможно, т.е. обмен автомобилями невозможен. Верно мыслю?
В общем сделал вообще без автомобилей, в документе только сотрудники, в РР тоже.
1000 часов проверяю как завещал уважаемый sv_mikh (http://forum.chistov.pro/index.php?topic=993.msg24021#msg24021)
Прорешал эту задачу три раза и каждый раз при начале отладки механизмов Расчетов возникала проблема с ПВР Удержания.
При попытке обращения к ПВР предприятие падало с ошибкой
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка SDBL:
Тип поля #updatedRows.BaseCKBaseCK несовместим с типом поля BaseCKBaseCK
Платформа 8.3.5.1248, каркасная конфигурация.
Методом тыка нашел решение, может кому пригодится )):
для удержания Штраф отключить зависимость от Невыхода, применить, а затем вернуть зависимость от Невыхода.
-
В общем сделал вообще без автомобилей, в документе только сотрудники, в РР тоже.
В ПР задаче 13 билета тоже нет совместительства. Думаю надо все таки Бригаду в документе сделать, для приличия. Т.е. здесь надо было в документе оставить колонку Автомобиль.
-
Прорешал эту задачу три раза и каждый раз при начале отладки механизмов Расчетов возникала проблема с ПВР Удержания.
При попытке обращения к ПВР предприятие падало с ошибкой
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка SDBL:
Тип поля #updatedRows.BaseCKBaseCK несовместим с типом поля BaseCKBaseCK
Платформа 8.3.5.1248, каркасная конфигурация.
Методом тыка нашел решение, может кому пригодится )):
для удержания Штраф отключить зависимость от Невыхода, применить, а затем вернуть зависимость от Невыхода.
Еще выход, и более удобный в рамках экзамена - воспользоваться советом из п.8 вот отсюда:
http://forum.chistov.pro/index.php?topic=2005.msg22414#msg22414 :)
-
Коллеги, я так понимаю, что в РР не нужно изменение Автомобили (Подразделения) т.к. совместительство невозможно, т.е. обмен автомобилями невозможен. Верно мыслю?
Скажу больше - даже если обмен автомобилями возможен, всё равно это не аналог совместительства, и измерение Автомобиль не нужно (только реквизит) (Это на случай, если не читал мой отчет об экзамене :) ).
-
Задача по ПР интересна двумя моментами:
1) Удержание Штраф 5000 за каждый день Невыхода
2) Компенсацию начислять только если в этом месяце НаездЧасов водителя перевалил через 1000
Штраф считаю от ресурса ДниНевыходаБаза (базовый ВР – Невыход)
НаездЧасов накапливаю в оборотном регистре, получаю с НачалаВремен по НачМес и по КонМес, сравниваю с помощью Цел(ЧасыНач/1000) и если целые тысячи отличаются, значит в этом месяце водитель перевалил через 1000.
Невосстановимую ошибку (см.выше) на этот раз победил минуты за 2-3.
Отключил зависимость Штрафа от Невыхода, применил, вернул, применил, но все это не помогло.
Тогда удалил Штраф, применил, создал новый, применил, включил зависимость и все заработало.
-
НаездЧасов накапливаю в оборотном регистре, получаю с НачалаВремен по НачМес и по КонМес, сравниваю с помощью Цел(ЧасыНач/1000) и если целые тысячи отличаются, значит в этом месяце водитель перевалил через 1000.
Альтернатива - регистр остаточный. Если остаток на конец месяца > 1000, начисляем компенсацию и списываем 1000.
-
В задаче по ОУ сложность заключается в использовании механизма Характеристик для ЗаказовПокупателей.
Спр ЗначенияСвойств делаем подчиненным ПВХ СвойстваОбъектов.
В тип значения ПВХ включаем спр ЗначенияСвойств.
Создаем рег свед ЗначенияХарактеристик (изм Объект – док ЗаказПокупателя, изм ВидХарактеристики – ПВХ, рес ЗначениеХарактеристики – Характеристика)
Для ресурса ЗначениеХарактеристики в связях параметров выбора включаем что Владельцем является ВидХарактеристики (чтобы в списке значений показывались только те значения, владельцем которых является данный ВидХарактеристики).
В Предприятии созадем Заказы, Поступления, Реализации, заполняем рег свед Значения свойств (указываем для Заказов регионы).
В отчете настраиваем вывод характеристик для объектов типа Документ.ЗаказПокупателя. Формируем Отчет.
-
Поэтому, коллеги, прошу проверить, ничего ли я не забыл:
1) новая методика контроля остатков (как более эффективная) применена потому, что для формирования движений не нужно ничего получать из БД, все уже есть в ТЧ документа. Алгоритм следующий:
2) До записи движений включаю БлокироватьДляИзменения
3) Формирую движения по списанию
4) Записываю движения
...
В пункте где "БлокироватьДляИзменения" надо еще очищать движения (но не записывать для новой методики).
Привожу цитату из статью Чистова:
К примеру, в зависимости от этого свойства, движения документа будут прочитаны (если галка стоит) при открытии формы или нет. А если даже галка не установлена, и в форме отображаются движения, то движения будут прочитаны при открытии формы.
В обычных формах движения будут однозначно прочитаны при открытии формы.
А если движения прочитаны, то наборы записей в свойстве документа "Движения" не пустые, и добавление при проведении новых движений, как правило приводит к дублям движений.
Так вот, чтобы не зависеть от обстоятельств, мы на всякий случай удаляем то, что возможно может находиться в коллекции движений по регистру ОстаткиТоваров. Обращаю внимание, что запись данных в базу тут не производится, просто в памяти очищается набор записей.
Кстати, если свойство конфигурации "Основной режим запуска" будет установлено в значение "Обычное приложение", то такую строку "Движения.ИмяРегистра.Очистить()" будет писать и сам конструктор формирования движений.
Проверил. Если в форме напротив всей ветки Движения тип "Коллекция движений", поставить галку "Использовать всегда", то движения в форме действительно не очищены.
-
БУ
В блокировке хотел разделить номенклатуру на Детали и Изделия (получить две ТЗ и блокировать каждый счет по их содержимому), но потому подумал, что на экзамене не до таких извращений. Короче, просто блокирую оба счета по Номенклатуре из ТЧ. Пойдет?
По идее мы же блокируем не весь счет товары, а счет товары по конкретному списку номенклатуры на субконто "Номенклатура".
Если в нашей табличной части нет товаров (а одни материалы), то не найдя по субконто что блокировать система счет Товары не будет блокировать вообще.
Я правильно понимаю?
-
Всем привет!
Только начинаю готовиться, ребят не подскажите как понять когда использовать старую методику, а когда новую, или ссылочку :)
-
Всем привет!
Только начинаю готовиться, ребят не подскажите как понять когда использовать старую методику, а когда новую, или ссылочку :)
Когда перед проведением НЕ НАДО предварительно получать данные из того же регистра, в который записываем, чтобы проконтролировать остатки, обязательно используется новая.
Когда перед проведением НЕОБХОДИМО получить данные именно из того же регистра, в который записываем, чтобы проконтролировать остатки, обязательно старая.
Но чаще ситуация бывает неоднозначная - можно создать дополнительный РН для учета остатков (обычно с меньшим количеством измерений, чем в РН для учета себестоимости), в котором эти самые остатки и контролировать без предварительного получения данных из этого же регистра. И вот в этом случае кто-то создает дополнительный РН, и делает "по-новому", кто-то не создает, и делает "по-старому", обычно на экз вроде прокатывают оба варианта (судя по отзывам).
-
alex1248, спасибо !=)
-
В пункте где "БлокироватьДляИзменения" надо еще очищать движения (но не записывать для новой методики).
HRom, хочешь сказать, Очищать() надо всегда, даже при новой методике? Надо запомнить и применить.
-
Вот этот кусок мне абсолютно не понятен,то есть надо делать через регистр сведений или брать из документа" Процент компенсации общий для всех сотрудников и может изменяться не чаще, чем один раз в месяц. В информационной базе необходимо хранить историю изменения данного процента. В момент начисления компенсации значение процента определяется определяется пользователем самостоятельно и заносится в документ “Начисление зарплаты”. Компенсация начисляется только в случае отсутствия невыходов, однако контролировать программным образом данное обстоятельство не требуется." ?
-
И Jones у меня такой вопрос , я заметил ты всегда в период регстрации ставишь дату документа, я думал так можно делать только если есть такое условие" В одном документе могут быть данные только за текущий расчетный период." Если условие за разные расчетные периоды ,тогда период регистрации надо добавлять в ТЧ,или я ошибаюсь?)
-
Необходимо создать отчет по анализу недоотгруженных заказов покупателей на выбранную дату в разрезе выбранной характеристики.
JONES, Может я ошибаюсь, но по-моему не совсем правильно строить отчет отбирая только по региону?
-
НаездЧасов накапливаю в оборотном регистре, получаю с НачалаВремен по НачМес и по КонМес, сравниваю с помощью Цел(ЧасыНач/1000) и если целые тысячи отличаются, значит в этом месяце водитель перевалил через 1000.
Альтернатива - регистр остаточный. Если остаток на конец месяца > 1000, начисляем компенсацию и списываем 1000.
Тоже считаю Ваше решение правильным. Однако все комментарии убеждали на оборотный регистр... В общем, нашла такой топик - http://forum-1c.ru/index.php?topic=14856.10
Оставлю ссылку здесь, в защиту Вашего решения :)
-
Штраф за невыход, формирует сам невыход, 1000 беру на конец месяца, если часы превышают начисляю компенсацию. Вот только не понятно, после начисления компенсации, удалять 1000 из РН или в задаче имеется ввиду, что если сотрудник наездил 1000 значит если есть часы в этом месяце, то он само сабой получит свою компенсацию, типа за выслугу.
-
Штраф за невыход, формирует сам невыход, 1000 беру на конец месяца, если часы превышают начисляю компенсацию. Вот только не понятно, после начисления компенсации, удалять 1000 из РН или в задаче имеется ввиду, что если сотрудник наездил 1000 значит если есть часы в этом месяце, то он само сабой получит свою компенсацию, типа за выслугу.
не нашел у тебя списание 1000 часов, после выплаты компенсации. Да и похоже на упрощение задачи, часы берешь не из факта а вводишь отдельно. ПД в компенсации, имхо, лишний (ни план ни факт ты не считаешь).
Коллеги, не находите что отчет в СПР 12 билета - должен решаться на регистре оборотов? Не будет ли снижение балов за использование кучи джойнов и агрегатных функции по таблицам движений РР?
-
Штраф за невыход, формирует сам невыход, 1000 беру на конец месяца, если часы превышают начисляю компенсацию. Вот только не понятно, после начисления компенсации, удалять 1000 из РН или в задаче имеется ввиду, что если сотрудник наездил 1000 значит если есть часы в этом месяце, то он само сабой получит свою компенсацию, типа за выслугу.
не нашел у тебя списание 1000 часов, после выплаты компенсации. Да и похоже на упрощение задачи, часы берешь не из факта а вводишь отдельно. ПД в компенсации, имхо, лишний (ни план ни факт ты не считаешь).
Коллеги, не находите что отчет в СПР 12 билета - должен решаться на регистре оборотов? Не будет ли снижение балов за использование кучи джойнов и агрегатных функции по таблицам движений РР?
Я не нахожу. Регистр оборотов я использую, чтобы копить количество наезженных и компенсированных часов. Но, по идее, можно этим и не пользоваться, а обороты брать из регистров расчета. А в отчете ни одного джойна, зато два раза объединить все.
У venvlad решение, как мне показалось, не закончено, поэтому 1000 не списывается. Еще зачем-то какие-то путевые листы. Можно же вводить наезженные часы прямо в строку основных начислений в документе НачислениеЗарплаты.
P.S. Коллеги, не стесняйтесь, выкладывайте свои решения :)
-
Какой-то сложный билет получился
СПР Четыре вида расчета на трех ПВР. Наезд часов беру из фактически отработанных и накапливаю в РН.
Все расчеты начисляю по желанию пользователя.
БУ Посмотрел другие решения и не понял, почему нет доков комплектация и перемещение.
Сделал с ними.
ОУ простой, да если вклеивать в БУ то головоломный и 100 % завальный на экзамене. Во всех решениях проведение разделяют. Я решил разделить остатки. Т.к . проблема что не изчего комплектовать компы, раз все детали под заказ. Поэтому в приходной накладной указываю, что комплектующие для сборки и по ОУ этот док не провожу.
Отчет настроил из под пользователя и сохранил вариант по регионам.
На экзамене придется разделять проведение, иного варианта не нашел. Т.к. даже в моем решении остатки для сборки пользователь контролирует сам.
-
Какой-то сложный билет получился
СПР Четыре вида расчета на трех ПВР. Наезд часов беру из фактически отработанных и накапливаю в РН.
Все расчеты начисляю по желанию пользователя.
БУ Посмотрел другие решения и не понял, почему нет доков комплектация и перемещение.
Сделал с ними.
ОУ простой, да если вклеивать в БУ то головоломный и 100 % завальный на экзамене. Во всех решениях проведение разделяют. Я решил разделить остатки. Т.к . проблема что не изчего комплектовать компы, раз все детали под заказ. Поэтому в приходной накладной указываю, что комплектующие для сборки и по ОУ этот док не провожу.
Отчет настроил из под пользователя и сохранил вариант по регионам.
На экзамене придется разделять проведение, иного варианта не нашел. Т.к. даже в моем решении остатки для сборки пользователь контролирует сам.
А точно ли в СПР нужно использовать регистр накопления? Ведь он в итоге не "схлопывается", таблица итогов будет расти. Конечно, можно придумать документ Увольнение, где выводить регистр в ноль, но это может быть расценено как усложнение задачи. Мой вариант - оборотный регистр накопления, который в одном ресурсе копит отработанные часы, а в другом часы, с которых начислена компенсация. При расчете получаю таблицу оборотов без отбора по периоду, но с отбором по сотрудникам из строк документа. Тоже не идеально, но, по крайней мере, не попадет под ошибку из всеми любимого файла Построенная в решении учетная схема не обеспечивает правильного занесения данных в регистры. Например, необходимо списать 1000, а списывается 500 2,0
А есть еще такая ошибка В задачах получения итоговой информации по остаткам использование информации по оборотам или наоборот 2,0
На мой взгляд, отработанные часы это оборотные данные, и компенсированные часы - тоже. Кто что думает по этому поводу?
-
Пункт 8 отсюда http://forum.chistov.pro/index.php?topic=2005.msg22414#msg22414
8. СПР. Если Невыход вытесняет Оклад и при этом еще является штрафом - не нужно отдельно вводить ВР Штраф, Невыход должен вытеснять и сам производить удержание, ну а то что он находится не в ПВР Удержания, а в ПВР Основные начисления - это нормально.
Кто как считает? нужно ли под штраф ПВР Удержания задействовать?
Я делала, но после прочтения того поста - вызывает сомнения :-X
-
В условии написано "Если не вышел по неуважительной причине".
Т.е. сотрудник может прогулять и по уважительной причине, но оклад то мы платить не будем, и штраф начислять не будем. А вот если причина неуважительная, то нужно начислять штраф. Имхо, штраф должен пользователем инициироваться отдельно.
Другой вопрос, что эти домыслы возможно опустить на экзамене, а то больно емко получается.
-
В условии написано "Если не вышел по неуважительной причине".
Т.е. сотрудник может прогулять и по уважительной причине, но оклад то мы платить не будем, и штраф начислять не будем. А вот если причина неуважительная, то нужно начислять штраф. Имхо, штраф должен пользователем инициироваться отдельно.
Другой вопрос, что эти домыслы возможно опустить на экзамене, а то больно емко получается.
Да, тоже заметила эту фразу.. как мне объяснил начальник " если есть невыход, то он по любому неуважительный, для уважительного всегда есть другие виды расчета - больничные, отпуска и тд".
PS
а по поводу предложенного в том сообщении, результат надо с минусом писать -5000 или как обычно 5000?
-
А я все со своими характеристиками..
Пожалуйста, будьте так любезны, посмотрите кто-нибудь мой отчет по ОУ, не могу вывести характеристики в пользовательском режиме. Все заполнила, в запросе все настроила, в пользовательских настройках вывожу группировку, и в режиме пользователя видно группировки, но там не добавляются характеристики заказа, будто их нет. Я таки чего-то не понимаю.... Вроде бы вот ни у кого проблем с этим нет, одна я такая блин...
-
А я все со своими характеристиками..
Пожалуйста, будьте так любезны, посмотрите кто-нибудь мой отчет по ОУ, не могу вывести характеристики в пользовательском режиме. Все заполнила, в запросе все настроила, в пользовательских настройках вывожу группировку, и в режиме пользователя видно группировки, но там не добавляются характеристики заказа, будто их нет. Я таки чего-то не понимаю.... Вроде бы вот ни у кого проблем с этим нет, одна я такая блин...
ЗаказПокупателя - Данные - Характеристики не заполнено.
Еще по мелочи РС ДопХарактеристики ресурс Значение - установи связь по типу от свойства (и можешь смело пвх составной делать)
-
Ах, вооон оно где... данные блин! спасибо!!!!
так я же связь установила... на значение... или я не о том? где именно? Связи параметров выбора? это? или что?
Посмотрела у Джонса и еще одно решение - там тоже не заполнено. Только у тебя пожалуй и заполнено. Ну, мож еще у кого, но я не смотрела больше.
Щас у себя сделаю, отпишусь что получилось.
Так, ну я заполнила, но все равно в отчете эти поля не добавились. Сделала по твоей аналогии... У меня такое чувство что я делаю что-то не так в СКД. А что именно - не могу понять. Смотрела твой отчет - не поняла где ты настроил и как чтобы еще один вариант был по региону. В режиме пользователя я что-то не смогла какой-то еще вариант сделать.
Блин. вопрос остается открытым...
-
в отчете: характеристики к последнему запросу приделай, а не к тому что в ВТ помещаешь.
* связь по типу это мелочь. Это чтобы при выборе значения характеристики, не нужно было пользователю еще и тип значения выбирать (Если ПВХ составного типа).
-
ооо, алилуйя! Получилось
точно, слушай, а я ж ВТ позже сделала, сначала отчет сделала без ВТ, прицепила характеристики, потом увидела что не группируется, засунула в вт, сгруппировала, а характеристики остались на первом)))))
Спасибо)
-
БУ Посмотрел другие решения и не понял, почему нет доков комплектация и перемещение.
Сделал с ними.
Ага.
Я тоже так подумала сначала, а как же без перемещения и комплектации? Тоже с ними сделала. Но блин, как это оказалось долго! Коллеги, как думаете, если на экзамене эти операции (перемещение и комплектацию) оставить на откуп пользователю в документ Операция, будет ли ошибкой и упрощением задачи? Я прямо не знаю что тут делать, вроде и напрашиваются они, но в условиях про них ниче не сказано. Если делать с ними, то долго, если без них, то вдруг упрощением посчитают.....
-
Билет прорешан(Кроме БП).
Вот такая непонятная особенность у РМ к концу обучения выявилась. Кто сможет разобраться, прошу)))). Итог я знаю. Решил скинуть на форум для всеобщего обозрения.
Попробуйте провести документ "Начисления" от Февраля)).
до 12 го ещё не добрался. Сделал 10-ый ОУБУ. Но всё же интересно- что такое РМ ? ) Базу посмотрел..провёл док.от февраля...
-
zorky. Извиняюсь. Не тот скинул) РМ = Расчетные механизмы)
Билет прорешан(Кроме БП).
Вот такая непонятная особенность у РМ к концу обучения выявилась. Кто сможет разобраться, прошу)))). Итог я знаю. Решил скинуть на форум для всеобщего обозрения.
Попробуйте провести документ "Начисления" от Февраля)).
-
zorky. Извиняюсь. Не тот скинул) РМ = Расчетные механизмы)
Билет прорешан(Кроме БП).
Вот такая непонятная особенность у РМ к концу обучения выявилась. Кто сможет разобраться, прошу)))). Итог я знаю. Решил скинуть на форум для всеобщего обозрения.
Попробуйте провести документ "Начисления" от Февраля)).
Был глюк - не было факт Часов У Невыхода, и Факт-дней. Они почему то NULL были.
Глюк исправил - заменил в ОН ЗначениеЧасы на ЗначениеДни у Значения Графика, запустил - норма.
Потом поменял обратно - и всё появилось как нужно.
-
Ни Фига билетик не маленький! )))))))))) прорешал вроде!!!
БУ - без док-а "Комплектация" (а зачем "Перемещение" ??) .Это ужасно, но пусть Приходка принимает Готовые Компы или Комплектующие.(ВидНоменклатуры). Иначе на задачу уйдёт пусть даже 1,5 часа, минимум-не позволительно на экз) Да и в условиях нету...
И весьма объёмная задача СПР... много времени заняла, блин. Ставка в РС - стандартно. Один расчётный период, МесяцНачисления- в Шапку. 1000 часов - сделал накопления в РН(остатки). При начислении Компенсации смотрю, остаток >100 (для тестирования) и базу тут же... Если есть - начисляю. Вопрос ...тут такой же где то был..: а РН освобождать... когда и как. По логике можно сделать примочку, если чувак пересел на другую машину(новую) а та сломалась, тогда ВСЕ ЧАСЫ на старой МАШИНЕ - можно очистить))) Машину на свалку. Вечно на одной не поездишь))) как думаете??? А ещё: по условию Процент надо хранить, делаю в РС. Независимый, Период=Месяц по условию. Ещё там сказано, что в документе нужно указывать Процент...Прикинул так: Если нету в Доке - берём из РС, если есть в Доке - смотрим на месяц(период), если больше - пишем в РС(новый для всех)...вроде так по условию. Не знаю - кто на Экзамене эту задачу решил, 3 часа уходит блин запросто!)))) и Отчёт хитрый, часы из ДанныхГрафика, Был штраф-тут же можно взять по ВР. Сумму Компенсации присоединяю Джойном... Красиво вроде!)) ну и билет.
-
БУ - без док-а "Комплектация" (а зачем "Перемещение" ??) .Это ужасно, но пусть Приходка принимает Готовые Компы или Комплектующие.(ВидНоменклатуры). Иначе на задачу уйдёт пусть даже 1,5 часа, минимум-не позволительно на экз) Да и в условиях нету...
Что за "Перемещение"? А "Комплектацию" (или "Сборку") всё же надо. А так выходит существенное упрощение задачи.
Чего нет в условиях?
И весьма объёмная задача СПР... много времени заняла, блин. Ставка в РС - стандартно. Один расчётный период, МесяцНачисления- в Шапку. 1000 часов - сделал накопления в РН(остатки). При начислении Компенсации смотрю, остаток >100 (для тестирования) и базу тут же... Если есть - начисляю. Вопрос ...тут такой же где то был..: а РН освобождать... когда и как. По логике можно сделать примочку, если чувак пересел на другую машину(новую) а та сломалась, тогда ВСЕ ЧАСЫ на старой МАШИНЕ - можно очистить))) Машину на свалку. Вечно на одной не поездишь))) как думаете??? А ещё: по условию Процент надо хранить, делаю в РС. Независимый, Период=Месяц по условию. Ещё там сказано, что в документе нужно указывать Процент...Прикинул так: Если нету в Доке - берём из РС, если есть в Доке - смотрим на месяц(период), если больше - пишем в РС(новый для всех)...вроде так по условию. Не знаю - кто на Экзамене эту задачу решил, 3 часа уходит блин запросто!)))) и Отчёт хитрый, часы из ДанныхГрафика, Был штраф-тут же можно взять по ВР. Сумму Компенсации присоединяю Джойном...
Не надо усложнять - задача станет меньше. :)
"В одном документе могут быть данные только за текущий расчетный период" - следовательно, ни в каких дополнительных данных, типа месяца начисления, необходимости нет, можно считать, что все данные вводятся за месяц даты документа (так и вводить данные, без доп проверок).
"а РН освобождать... когда и как" - а есть варианты? Если оба допустимы, то выбрать для себя один, и при необходимости пояснить экзаменатору.
Никаких примочек на случай смены машины, естественно, не надо. Так вот, раз речь зашла про автомобиль, скажу больше, и спр Автомобиль не нужен, поскольку для решения задачи он не имеет никакого значения, Сотрудник = Автомобиль.
Процент - РС делаем, раз велят, а в док юзер вводит сам, следовательно, из РС выбирать не надо. Зачем лишние проверки в цейтноте?
Про отчет сказано "должен быть построен за текущий расчетный период", т.е. опять же за месяц. Только какой будет текущим? Думаю, достаточно указывать дату (одну) отчета, и за соответствующий месяц его формировать.
-
Ни Фига билетик не маленький! )))))))))) прорешал вроде!!!
БУ - без док-а "Комплектация" (а зачем "Перемещение" ??) .Это ужасно, но пусть Приходка принимает Готовые Компы или Комплектующие.(ВидНоменклатуры). Иначе на задачу уйдёт пусть даже 1,5 часа, минимум-не позволительно на экз) Да и в условиях нету...
И весьма объёмная задача СПР... много времени заняла, блин. Ставка в РС - стандартно. Один расчётный период, МесяцНачисления- в Шапку. 1000 часов - сделал накопления в РН(остатки). При начислении Компенсации смотрю, остаток >100 (для тестирования) и базу тут же... Если есть - начисляю. Вопрос ...тут такой же где то был..: а РН освобождать... когда и как. По логике можно сделать примочку, если чувак пересел на другую машину(новую) а та сломалась, тогда ВСЕ ЧАСЫ на старой МАШИНЕ - можно очистить))) Машину на свалку. Вечно на одной не поездишь))) как думаете??? А ещё: по условию Процент надо хранить, делаю в РС. Независимый, Период=Месяц по условию. Ещё там сказано, что в документе нужно указывать Процент...Прикинул так: Если нету в Доке - берём из РС, если есть в Доке - смотрим на месяц(период), если больше - пишем в РС(новый для всех)...вроде так по условию. Не знаю - кто на Экзамене эту задачу решил, 3 часа уходит блин запросто!)))) и Отчёт хитрый, часы из ДанныхГрафика, Был штраф-тут же можно взять по ВР. Сумму Компенсации присоединяю Джойном... Красиво вроде!)) ну и билет.
Отчет ОУ без характеристик. Ты их прицепил в запросе, но а в отчете нет. Почему?
-
Ни Фига билетик не маленький! )))))))))) прорешал вроде!!!
БУ - без док-а "Комплектация" (а зачем "Перемещение" ??) .Это ужасно, но пусть Приходка принимает Готовые Компы или Комплектующие.(ВидНоменклатуры). Иначе на задачу уйдёт пусть даже 1,5 часа, минимум-не позволительно на экз) Да и в условиях нету...
И весьма объёмная задача СПР... много времени заняла, блин. Ставка в РС - стандартно. Один расчётный период, МесяцНачисления- в Шапку. 1000 часов - сделал накопления в РН(остатки). При начислении Компенсации смотрю, остаток >100 (для тестирования) и базу тут же... Если есть - начисляю. Вопрос ...тут такой же где то был..: а РН освобождать... когда и как. По логике можно сделать примочку, если чувак пересел на другую машину(новую) а та сломалась, тогда ВСЕ ЧАСЫ на старой МАШИНЕ - можно очистить))) Машину на свалку. Вечно на одной не поездишь))) как думаете??? А ещё: по условию Процент надо хранить, делаю в РС. Независимый, Период=Месяц по условию. Ещё там сказано, что в документе нужно указывать Процент...Прикинул так: Если нету в Доке - берём из РС, если есть в Доке - смотрим на месяц(период), если больше - пишем в РС(новый для всех)...вроде так по условию. Не знаю - кто на Экзамене эту задачу решил, 3 часа уходит блин запросто!)))) и Отчёт хитрый, часы из ДанныхГрафика, Был штраф-тут же можно взять по ВР. Сумму Компенсации присоединяю Джойном... Красиво вроде!)) ну и билет.
Отчет ОУ без характеристик. Ты их прицепил в запросе, но а в отчете нет. Почему?
Не пойму...как это ? ...имеется в виду в пользовательском режиме, Изменить Вариант...или что то другое
-
Ни Фига билетик не маленький! )))))))))) прорешал вроде!!!
БУ - без док-а "Комплектация" (а зачем "Перемещение" ??) .Это ужасно, но пусть Приходка принимает Готовые Компы или Комплектующие.(ВидНоменклатуры). Иначе на задачу уйдёт пусть даже 1,5 часа, минимум-не позволительно на экз) Да и в условиях нету...
И весьма объёмная задача СПР... много времени заняла, блин. Ставка в РС - стандартно. Один расчётный период, МесяцНачисления- в Шапку. 1000 часов - сделал накопления в РН(остатки). При начислении Компенсации смотрю, остаток >100 (для тестирования) и базу тут же... Если есть - начисляю. Вопрос ...тут такой же где то был..: а РН освобождать... когда и как. По логике можно сделать примочку, если чувак пересел на другую машину(новую) а та сломалась, тогда ВСЕ ЧАСЫ на старой МАШИНЕ - можно очистить))) Машину на свалку. Вечно на одной не поездишь))) как думаете??? А ещё: по условию Процент надо хранить, делаю в РС. Независимый, Период=Месяц по условию. Ещё там сказано, что в документе нужно указывать Процент...Прикинул так: Если нету в Доке - берём из РС, если есть в Доке - смотрим на месяц(период), если больше - пишем в РС(новый для всех)...вроде так по условию. Не знаю - кто на Экзамене эту задачу решил, 3 часа уходит блин запросто!)))) и Отчёт хитрый, часы из ДанныхГрафика, Был штраф-тут же можно взять по ВР. Сумму Компенсации присоединяю Джойном... Красиво вроде!)) ну и билет.
Отчет ОУ без характеристик. Ты их прицепил в запросе, но а в отчете нет. Почему?
Не пойму...как это ? ...имеется в виду в пользовательском режиме, Изменить Вариант...или что то другое
Сравни отчеты. у тебя доделал. Там вычисляемое поле добавлено + в группировку включил поле Регион.
Но вот остаётся вопрос: "Необходимо создать отчет по анализу недоотгруженных заказов покупателей на
выбранную дату в разрезе выбранной характеристики."
В разрезе ВЫБРАННОЙ характеристики. Т.е. должно быть поле на форме отчета параметром. Как сделать не знаю.
-
Вопрос к задаче. БУ этого билета. А надо ли делать сборку, перемещение? Или мы уже как бы сделали это всё и просто приходной приходуем произведенный товар или материал на любой склад?
Ну т.е. я вижу в решениях что мы просто делаем приходную и в ней указаны товар это или комплектующая. А нам не нужно фиксировать что произведено было на главном из материалов, потом перемещено на другую точку с себестоимостью материалов?
-
Вопрос к задаче. БУ этого билета. А надо ли делать сборку, перемещение? Или мы уже как бы сделали это всё и просто приходной приходуем произведенный товар или материал на любой склад?
Ну т.е. я вижу в решениях что мы просто делаем приходную и в ней указаны товар это или комплектующая. А нам не нужно фиксировать что произведено было на главном из материалов, потом перемещено на другую точку с себестоимостью материалов?
Повторюсь, конечно, но думаю - Сборку надо. :)
Хм, отчет. Делается жеж.
Ладно, свой вариант прикрепляю. Хотя СПР там не работает, т.к. была вышеописанная ошибка с ПВР Удержания, и я ее не побеждал, поэтому СПР в целом не смотреть. И, наверное, в ОУ не совсем правильный расчет недоотгруженных товаров (я брал, сколько надо отгрузить по заказу всего, а не только из поступившего). Но основные моменты вроде бы вполне рабочие. :)
-
Сравни отчеты. у тебя доделал. Там вычисляемое поле добавлено + в группировку включил поле Регион.
Но вот остаётся вопрос: "Необходимо создать отчет по анализу недоотгруженных заказов покупателей на
выбранную дату в разрезе выбранной характеристики."
В разрезе ВЫБРАННОЙ характеристики. Т.е. должно быть поле на форме отчета параметром. Как сделать не знаю.
Мм, сравнил! ) А в чём мулька? Не найдено поле Регион! Ошибка. А чем не понравился мой вариант, когда Характеристики можно вытащить через "Изменить вариант" - добавить группировку по Полю (Регион,например) - и всё работает... Через вычисляемое поле кто-то тут СТРОГО не советовал делать... ! по моему.
Авот у Алекса посмотрел. Круто. В Запросе нет Характеристик. В Доке Заказ - тоже нету. Просто присоединяемся к Регистру с Характеристиками и вытаскиваем поле ЗначениеХарактеристики.
И вот вопрос, как всё таки предпочительнее с ними работать. Как у Романа? Алекса) Или как было: Ведь можно же в "Изменить Вариант" красиво вытащить поле, где выбирать Группировки по Характеристикам???
-
Выкладываю свой вариант. Считаю, что 1000 часов это опечатка, делала без накопления отработанных часов в регистре накопления, сумму штрафа сразу считаю по виду расчета Неявка.
-
Вопрос к задаче. БУ этого билета. А надо ли делать сборку, перемещение? Или мы уже как бы сделали это всё и просто приходной приходуем произведенный товар или материал на любой склад?
Ну т.е. я вижу в решениях что мы просто делаем приходную и в ней указаны товар это или комплектующая. А нам не нужно фиксировать что произведено было на главном из материалов, потом перемещено на другую точку с себестоимостью материалов?
По БУ я бы читал задание следующим образом:
1. Сказано что нужно собирать готовые компьютеры "Сборкой"/"Комплектацией"? Ответ - нет, не сказано. Это отбирает главный ресурс на экзамене - время.
2. Поскольку п.1 не обязателен ввиду отсутствия прямых инструкций в тексте, то сборку можно осуществить через универсальный документ "Операция" (который все равно будем делать). Забираем со счета "Материалы", приходуем на "Товары" на нужный склад.
Таким образом, не надо покупать готовые компьютеры у поставщика и не надо делать документ комплектации/сборки. Про прием товаров черех приходную... это вообще не согласуется с текстом "Сборка готовых компьютеров происходит из отдельных комплектующих...". Мы НЕ покупаем готовые компьютеры, а собираем их у себя из закупленных ранее комплектующих (материалов).
Прошу принять вышеописанное как чистое ИМХО.
-
Согласна, можно все сделать Операцией. Но Материалы оприходовать от поставщиков все равно нужно, не важно как Операцией или приходной накладной. Иначе контроль по остаткам у вас не пройдет в Расходной Накладной, да и себестоимость как-то считать нужно по материалам
-
Согласна, можно все сделать Операцией...
А как насчет расчета себестоимости собираемых компов, и особенно - контроля остатков (который "надо делать всегда, не зависимо от условия задачи" (с) Белоусов) материалов, используемых при сборке? Я думаю, ответ на обсуждаемый вопрос кроется именно вот в этой необходимости, неявно вытекающей из общих принципов решения экзаменационных задач.
-
Согласна, можно все сделать Операцией...
А как насчет расчета себестоимости собираемых компов, и особенно - контроля остатков (который "надо делать всегда, не зависимо от условия задачи" (с) Белоусов) материалов, используемых при сборке? Я думаю, ответ на обсуждаемый вопрос кроется именно вот в этой необходимости, неявно вытекающей из общих принципов решения экзаменационных задач.
Полагаю, все же задача допускает использовать некие допущения.
Как вариант, себес компа = сумма составляющих по закупочной цене.
Повторюсь, операция - только для готовых компьютеров, имитация "Сборки". Задача получается слишком емкой, если делать сборку + контроль материалов при сборке. Не думаю, что авторы задачи преследовали такую цель. Хотя, если есть лишних 20 минут на экзамене, можно и заморочиться.
-
Уважаемые специалисты, покритикуйте решение.
Спасибо
-
Уважаемые специалисты, покритикуйте решение.
Спасибо
посмотрел в части СПР
1. забыл галку "Базовое" в измерении Сотрудник ОН. По всем измерениям, которые дальше будут участовать в отборе по измерениям при получении базы
Измерения = Новый Массив;
Измерения.Добавить("Сотрудник");
Запрос.УстановитьПараметр("Измерение", Измерения);
надо ставить эту галку для индексации и ускорения.
2. Расчет после первичной записи надо выносить в общий модуль в экспортную процедуру.
3. Косяк в цикле при расчете ДН -два раза цикл по выборке, а про цикл по движениям забыл
Пока Выборка.Следующий() Цикл
СП.НомерСтроки = Запись.НомерСтроки;
Пока Выборка.Следующий() Цикл
4. В ПВР ДН зачем-то в качестве базового ПВР указаны ДН, хотя достаточно только ОН. И там зависимость скорее по периоду регситрации , а не действия, поскольку в условии сказано "процентом от начисленной в том же расчетном периоде", а не за тот же период.
5.Не совсем понял суть запроса по премии.Зачем-то посчитаны ЧасНачала и ЧасКонец, так и оставлены и больше нигде не использованы. Не вижу в запросе отбор по 1000 часов.
Ну еще есть момент, но он больше дискуссионный и ко всем участникам. Мне кажется, что автомобиль тут не нужен нигде от слова совсем. Ведь в отчете его нет, график тоже у всех фиксированный, совместительства нет. Имхо его нужно повыкидывать отовсюду да и все. И уж явно компенсация на ремонт не зависит от конкретного автомобиля, написано в условии. Так зачем его тащить в РН,РР и НЗ?
-
Мне кажется, что автомобиль тут не нужен
Факт, что не нужен. Без дискуссий. Хотя, при сдаче удаленно, наверное, есть смысл, пояснить, почему так сделано.
-
Уважаемые специалисты, покритикуйте решение.
Спасибо
посмотрел в части СПР
1. забыл галку "Базовое" в измерении Сотрудник ОН. По всем измерениям, которые дальше будут участовать в отборе по измерениям при получении базы
Измерения = Новый Массив;
Измерения.Добавить("Сотрудник");
Запрос.УстановитьПараметр("Измерение", Измерения);
надо ставить эту галку для индексации и ускорения.
2. Расчет после первичной записи надо выносить в общий модуль в экспортную процедуру.
3. Косяк в цикле при расчете ДН -два раза цикл по выборке, а про цикл по движениям забыл
Пока Выборка.Следующий() Цикл
СП.НомерСтроки = Запись.НомерСтроки;
Пока Выборка.Следующий() Цикл
4. В ПВР ДН зачем-то в качестве базового ПВР указаны ДН, хотя достаточно только ОН. И там зависимость скорее по периоду регситрации , а не действия, поскольку в условии сказано "процентом от начисленной в том же расчетном периоде", а не за тот же период.
5.Не совсем понял суть запроса по премии.Зачем-то посчитаны ЧасНачала и ЧасКонец, так и оставлены и больше нигде не использованы. Не вижу в запросе отбор по 1000 часов.
Ну еще есть момент, но он больше дискуссионный и ко всем участникам. Мне кажется, что автомобиль тут не нужен нигде от слова совсем. Ведь в отчете его нет, график тоже у всех фиксированный, совместительства нет. Имхо его нужно повыкидывать отовсюду да и все. И уж явно компенсация на ремонт не зависит от конкретного автомобиля, написано в условии. Так зачем его тащить в РН,РР и НЗ?
Спасибо за такой подробный разбор. Про автомобиль сам долго сомневался, но потом посмотрел разные решения и увидел, что он есть, ну и поставил.
-
2. Расчет после первичной записи надо выносить в общий модуль в экспортную процедуру.
А на сколько критично, если я не вынесу в общий модуль?
-
2. Расчет после первичной записи надо выносить в общий модуль в экспортную процедуру.
А на сколько критично, если я не вынесу в общий модуль?
Вроде такое решение считается каноничным. И якобы связано с перерасчетами, которые возможно придется делать программно.
Понятно, что 3 балла за это не снимут
-
2. Расчет после первичной записи надо выносить в общий модуль в экспортную процедуру.
А на сколько критично, если я не вынесу в общий модуль?
Вроде такое решение считается каноничным. И якобы связано с перерасчетами, которые возможно придется делать программно.
Понятно, что 3 балла за это не снимут
Понятно, сейчас вот 13ый билет прорешал с учетом Ваших замечаний.
-
2. Расчет после первичной записи надо выносить в общий модуль в экспортную процедуру.
А на сколько критично, если я не вынесу в общий модуль?
Вроде такое решение считается каноничным. И якобы связано с перерасчетами, которые возможно придется делать программно.
Понятно, что 3 балла за это не снимут
Понятно, сейчас вот 13ый билет прорешал с учетом Ваших замечаний.
да вижу, как ты понял, там работы на пару минут.Проще сделать, чем отмазываться потом перед преподом. Только сразу лучше не писать в ОМ, там контекстная подсказка теряется. Тупо перенести в конце.
-
2. Расчет после первичной записи надо выносить в общий модуль в экспортную процедуру.
А на сколько критично, если я не вынесу в общий модуль?
Вроде такое решение считается каноничным. И якобы связано с перерасчетами, которые возможно придется делать программно.
Понятно, что 3 балла за это не снимут
Понятно, сейчас вот 13ый билет прорешал с учетом Ваших замечаний.
да вижу, как ты понял, там работы на пару минут.Проще сделать, чем отмазываться потом перед преподом. Только сразу лучше не писать в ОМ, там контекстная подсказка теряется. Тупо перенести в конце.
ну я так и сделал, первичные проводки оставил, а остальную чепухню, после того ка дописал в документе, перенес в ОМ.
-
Доброго дня!
Плиз почекайте мое произведение. ОУ + БУ в этой задаче очень плохо совместимы - сделал галки ОУ и БУ , чтобы отлаживать можно было. Накладные вбиты по отдельности для разных задач.
Отличия:
ОУ - подглядел у Alex1248 - РН Заказы с 2-мя ресурсами. Вроде все красиво. Отчет получается по одной таблице остатков.
ПВХ не привязан в отчете, но так и должно быть, все работает.
БУ - как обычно. Отдельного дока для сборки нет, делал Операцией. Криминала не должно быть, так как про это ничего не сказано. Приходная ограничена только поступлением материалов, продукцию не закупает. У многих покупает. но это на мой взгляд неверно, ибо зачем тогда вся задача.
СПР - 1000 часов в месяце это да, 1С молодцы. Прочитал толкования, понял условие :) РН оборотный для хранения часов.
Прогул сам начисляет сумму, правда я не делал ее отрицательной, это ж не сторно. Автомобили нигде не фигурируют - так как равносильно сотруднику. Часы пишу также в реквизит РР для компенсации, чтобы в отчете без танцев с бубном.
ЗЫ: Условие про процент компенсации сделал так - подтягивается в реквизит ТЧ Размер при виде расчета = Компенсация.
Была мысль записывать при проведении НЗ в РС, но как это дико, не стал так делать.
-
Доброго времени суток!
Доделал 12-й билет, прошу критиковать.
ОУ: Вроде бы как у всех, 2 РН - Заказы и Остатки, ПВХ.
БУ. Вообще не вяжется с ОУ, пришлось делать реквизит в накладных - проведение по ОУ или по БУ. Сделал с документом Комплектация, надо попробовать эту задачу решить на время, реально ли успеть за 5 часов накодить и отладить.
СПР. Сначала решил "в лоб" с 1000 часов за месяц, потом почитал комментарии, исправил, только использую не оборотный регистр, а остатки. Не знаю насколько это правильно.
-
Где-то читал по поводу документа Операция, что могут придраться по поводу того, что при его копировании не копируются движения. Лучше добавить на всякий случай код типа
Процедура ПриКопировании(ОбъектКопирования)
Набор = ОбъектКопирования.Движения.Основной;
Набор.Прочитать();
НаборТек = Движения.Основной;
НаборТек.Загрузить(Набор.Выгрузить());
КонецПроцедуры
А еще вопрос, насколько кошерно проставлять период Операции в ПриЗаписи МО? Есть еще интересная процедура модуля формы ПередЗаписьюНаСервере. Есть ли в этом принципиальная разница, не соображу.
-
Лучше добавить на всякий случай код типа
Процедура ПриКопировании(ОбъектКопирования)
Набор = ОбъектКопирования.Движения.Основной;
Набор.Прочитать();
НаборТек = Движения.Основной;
НаборТек.Загрузить(Набор.Выгрузить());
КонецПроцедуры
Спасибо за совет, буду использовать этот код, лишним не будет.
-
ОУ:
РН Заказы, изм. Номенклаутра, Партия, рес. Количество (рег. Заказ, ПТУ)
РН Остатки изм. Номенклаутра, Партия, рес. Количество, Сумма (рег. РТУ, ПТУ)
Заказ в ТЧ ПТУ и в шапке РТУ
БУ:
ПС Товары, колич., суб. Номенклатура, Склад. Сч. Материалы, колич., суб. Номенклатура. Сч. ПрибылиУбытки, колич., суб. Номенклатура, оборотное
У Номен. видНоменклатуры (изделие, комплектующая). ПТУ приходует только комплект. Операция собирает изделие через сч. ОсновноеПроизводство
СПР:
что-то со сторно никак не получается.
РС Графики, изм. Дата, рес. Часы, Дни
ПВР ОН использует период, не зависит от базы. Эл-ты: Оклад, Невыход
ПВР ДН зависит от базы по периоду рег-ции, База по ОН. Эл-т Компенсация, база по Окладу
РР ОН период действия, связь с графиком. Изм. Сотрудник, рес. Результат, РабочиеДни, рек. Размер
РР ДН базовый период, изм. Сотрудник, рес. Результат, рек. Размер
-
Доброго времени суток, может кто-нибудь объяснить почему задачу по ОУ многие делают на 2-х РН, когда спокойно можно сделать на одном? Был бы признателен за объяснение.
-
Доброго времени суток, может кто-нибудь объяснить почему задачу по ОУ многие делают на 2-х РН, когда спокойно можно сделать на одном? Был бы признателен за объяснение.
Конкретно в этой задаче по ОУ или вообще? В этой задаче ОУ по первому РН документы "Заказ покупателя" формируют движения типа приход, документы "Приходная накладная" формируют движения типа расход по одному набору измерений. Для проведения приходной накладной требуется выполнить только контроль отрицательных остатков. Поэтому на РН ведется только количественный учет.
Информация из второго РН (приход - "Приходная накладная", расход - "Расходная накладная) используется для контроля отрицательных остатков и для расчета себестоимости. Поэтому у него 2 ресурса.
А ты как хочешь сделать на одном регистре? опиши свое решение, чтоб регистр в ноль закрывался.
__________________________________________________________________________________
У меня тоже вопрос. Почему в некоторых решениях при использовании старой методики проведения блокировку ставят после очистки движений документа в регистре:
Движения.РН.Очистить();
Движения.РН.Записать();
Блокировка = Новый БлокировкаДанных;
Элемент = Блокировка.Добавить("РегистрНакопления.РН");
...
Блокировка.Заблокировать();
В этом случае получается, что другой пользователь гипотетически может не увидеть в РН движения документа. Скажем, во время перепроведения первым пользователем расходной накладной второй пользователь увидит, что, хотя товар и был списан ранее по расходной, на складе товар есть (т. к. запрет на чтение/запись ставится уже ПОСЛЕ записи пустого набора). Разве это правильно?
-
У меня тоже вопрос. Почему в некоторых решениях при использовании старой методики проведения блокировку ставят после очистки движений документа в регистре:
Движения.РН.Очистить();
Движения.РН.Записать();
Блокировка = Новый БлокировкаДанных;
Элемент = Блокировка.Добавить("РегистрНакопления.РН");
...
Блокировка.Заблокировать();
В этом случае получается, что другой пользователь гипотетически может не увидеть в РН движения документа. Скажем, во время перепроведения первым пользователем расходной накладной второй пользователь увидит, что, хотя товар и был списан ранее по расходной, на складе товар есть (т. к. запрет на чтение/запись ставится уже ПОСЛЕ записи пустого набора). Разве это правильно?
Если Вы имеете в виду, что другой документ может увидеть тот товар, который был в Расходной накладной ранее и соответственно попытаться списать его, то для реализации такой блокировки обычно используют следующую конструкцию:
Движения.РН.БлокироватьДляИзменения=Истина;
Движения.РН.Очистить();
Движения.РН.Записать();
Блокировка = Новый БлокировкаДанных;
Элемент = Блокировка.Добавить("РегистрНакопления.РН");
...
Блокировка.Заблокировать();В этом случае при записи пустого набора записей при установленном свойстве БлокироватьДляИзменения регистр будет заблокирован иммено по "старым" (очищаем) позициям документа. Другой вопрос, что такая конструкция не всегда однозначно принимается проверяющими на экзамене. И как лучше делать на экзамене, единого мнения нет.
-
Если Вы имеете в виду, что другой документ может увидеть тот товар, который был в Расходной накладной ранее и соответственно попытаться списать его, то для реализации такой блокировки обычно используют следующую конструкцию:
Движения.РН.БлокироватьДляИзменения=Истина;
Движения.РН.Очистить();
Движения.РН.Записать();
Блокировка = Новый БлокировкаДанных;
Элемент = Блокировка.Добавить("РегистрНакопления.РН");
...
Блокировка.Заблокировать();В этом случае при записи пустого набора записей при установленном свойстве БлокироватьДляИзменения регистр будет заблокирован иммено по "старым" (очищаем) позициям документа. Другой вопрос, что такая конструкция не всегда однозначно принимается проверяющими на экзамене. И как лучше делать на экзамене, единого мнения нет.
Я имел в виду, что блокировать регистр надо не после записи пустого набора, а перед этим, т. е. вместо
Движения.РН.Очистить();
Движения.РН.Записать();
Блокировка = Новый БлокировкаДанных;
Элемент = Блокировка.Добавить("РегистрНакопления.РН");
...
Блокировка.Заблокировать();
писать так
Блокировка = Новый БлокировкаДанных;
Элемент = Блокировка.Добавить("РегистрНакопления.РН");
...
Блокировка.Заблокировать();
Движения.РН.Очистить();
Движения.РН.Записать();
Upd
Движения.РН.БлокироватьДляИзменения=Истина;
Движения.РН.Очистить();
Движения.РН.Записать();
Блокировка = Новый БлокировкаДанных;
Элемент = Блокировка.Добавить("РегистрНакопления.РН");
...
Блокировка.Заблокировать();
А зачем блокировать в РН пустой набор измерений?
-
Мы блокируем не пустой набор записей! А по тем позициям, которые были в документе (старые движения) Очень советую почитать эту ветку: http://forum.chistov.pro/index.php?topic=1999.0
-
Мы блокируем не пустой набор записей! А по тем позициям, которые были в документе (старые движения) Очень советую почитать эту ветку: http://forum.chistov.pro/index.php?topic=1999.0
Большое спасибо за информацию!
-
При новой методике проведения, когда проверяем ушли в минус или нет: Для чего соединяемся с Доком, и так ведь из регистра получаем данные по измерениям только которые есть в Доке.
-
Скажите кто знает:
Для чего в регистре расчета ОснНач "Значение графика" выбираем? Что это дает? В этой задаче у нас два значения, но мы можем выбрать один. Второй я так понимаю все равно посчитается, хоть его и не выбирали?
-
мой вариант решения. :)
UPD: см. ниже
|
V
-
Мой обновленный вариант решения...
Буду рад критике
-
Ребят, привет!
Что-то немного плыву с условием про 1000 часов в СПР... или туплю.
Я понимаю это так: если на начало периода регистрации компенсации есть 1000+ часов, то начисляется компенсация.
Если заводить оборотный РН (у некоторых РН остатков, но это дискусионный вопрос):
я беру обороты виртуальной таблицы "ОтработанныеЧасыОборот" и ограничиваю в виртуальных параметрах дату конца параметром "КП" = Новый Граница(ПериодРегистрации, ВидГраницы.Исключая).
Правильно ли так будет?
Посмотрев решение SAE и чье-то еще в этой ветке, видел конструкцию вида:
Если (Окр((Выборка.ЧасыКонец/1000),2,1)-Окр((Выборка.ЧасыНачало/1000),2,1)) > 0 тогда
Запись.Результат = Выборка.База*Выборка.Процент/100;
КонецЕсли;
Собственно, в чужом решении берутся обороты до текущего месяца, и обороты текущего и проверяется это условие.
Как вы обходили это условие?
Спасибо.
-
если на начало периода регистрации компенсации есть 1000+ часов, то начисляется компенсация.
Если я правильно понял написанное, то это не правильно. Получается, что при достижении 1000 один раз, СО СЛЕДУЮЩЕГО МЕСЯЦА каждый месяц будет начисляться компенсация?
И почему начало периода регистрации (если не вникать в прочие нюансы я задачи, а я их уже подзабыл, то явно напрашивается период действия, и никак не регистрации), если начислить эту 1000 надо именно в том месяца, когда она наезжена, а не в следующем?
В общем, я бы так сформулировал. Вариант для оборотного РН. Если ОКР(Наезжено часов на КП / 1000, 0) > ОКР(Наезжено часов на НП / 1000, 0), тогда начисляем компенсацию.
Для остаточного. Если Незачтенный остаток часов для компенсации на КП >= 1000, то начисляем компенсацию и остаток уменьшаем на 1000.
ПС. Формула для оборотного регистра НЕ КОРРЕКТНА. Рекомендую использовать остаточный РН.
-
alex1248, спасибо за ответ!
1. По поводу каждый раз начислять компенсацию или нет: я исхожу из здравого смысла - человек на своей машине наездил в данной компании больше 1000км. По логике ему надо компенсировать часть издержек на ремонт и поддержание состояния автомобиля (чтобы она и дальше ездила нормально), ведь это естественный износ. Исходя из такой трактовки я бы начислял компенсацию каждый период, начиная с превышения в 1000часов. Тут, наверное, стоило бы уточнить у экзаменатора.
Я так понимаю, если бы компенсация была единоразовой, то делали бы РН остатков: в плюс делали пробег при проведении "Начисления", в минус на 1000 при расчете записей РР (при превышении, конечно).
2. По условию "В одном документе могут быть данные только за текущий расчетный период". У компенсации нет периода действия => ПериодДействия=ПериодРегистрации при условии что у РР период "месяц" (так в этой задаче и есть). Другими словами, если в документе период регистрации 01.08.16, то период регистрации (и период действия) у компенсации будет точно 01.08.16.
3. Но у меня тоже, как я понимаю, ошибка. Я не учитываю движения текущего документа, т.е. хорошо бы было взять период оборотов РН на КонецМесяца(ПериодРегистрации).
К примеру:
- Пробег на начало 01.08.16 был 900часов
- Мы сделали начисление 01.08.16, и часы стали = 900 + 176 = 1076 (т.е. превышение!)
- Мы взяли обороты на конец месяца (31.08.16 23:59:59) и они оказались 1076
- т.к. 1076>1000, начислили компенсацию в ПР 01.08.16
Все-таки пока нет полного понимания как точно правильно.
В любом случае, еще раз спасибо.
Может кто-то еще прокомментирует?
-
По поводу каждый раз начислять компенсацию или нет
Трактовка экзаменаторов именно такая - каждая очередная наезженная 1000 км влечет начисление компенсации именно в том месяце, в котором эта 1000 была достигнута. Пока нет следующей 1000, начисления нет. Где-то на этом форуме есть отзывы тех, кому на экз попадалась эта задача, так что это не моё ИМХО, а достаточно надежная информация.
Да, пусть будет ПР, который всё равно совпадает с ПД.
-
alex1248, теперь понятно почему именно такая формула
Спасибо огромное!
-
Мой обновленный вариант решения...
Буду рад критике
Я думаю что, на счете ПрибылиУбытки количественный учет не обязателен. Количество проданного для отчета можно со счетов Товары и Материалы получить.
-
Мой вариант решения. Буду рад любой критике. На автозаполнение табличных частей Документов прошу не обращать внимания. Это сделано для контроля наличия
-
Коллеги, снова подниму вопрос про 1000 часов в СПР.
Знаю, что уже неоднократно обсуждалось, и, вроде как, за эталон было принято решение уважаемого SAE с вот такой вот конструкцией для расчета премии:
Если (Окр((Выборка.ЧасыКонец/1000),2,1)-Окр((Выборка.ЧасыНачало/1000),2,1)) > 0 тогда
Запись.Результат = Выборка.База*Выборка.Процент/100;
КонецЕсли;
Предположим, что сейчас я ввожу первое начисление ЗП сотруднику. Указываю, что он отработал 120 часов, и тут же начисляю премию, в этом же документе.
По предложенной формуле получается, что премия ему будет начислена, хотя никаких 1000 часов он не наездил. Так как 120/1000 больше, чем 0/1000.
Подскажите пожалуйста, я чего-то не понимаю, или предложенное решение не совсем корректно себя ведет?
-
...вроде как, за эталон было принято решение уважаемого SAE с вот такой вот конструкцией для расчета премии:
Если (Окр((Выборка.ЧасыКонец/1000),2,1)-Окр((Выборка.ЧасыНачало/1000),2,1)) > 0 тогда
Запись.Результат = Выборка.База*Выборка.Процент/100;
КонецЕсли;
Про эталоны не слышал (надеюсь, SAE не обидится). Формула не похожа на корректную для данной ситуации.
-
Про эталоны не слышал (надеюсь, SAE не обидится). Формула не похожа на корректную для данной ситуации.
Согласен, что не похожа. Я с этой задачей второй день сижу, всё пытался найти идеальное решение через оборотный регистр накопления с факт часами.
К сожалению, получается, что ни представленная формула, ни её вариации, типа округления в меньшую сторону без знаков после запятой и пр. - не удовлетворяют условию задачи в полной мере, если мы трактуем её таким образом (об этом Вы написали на предыдущей странице):
Трактовка экзаменаторов именно такая - каждая очередная наезженная 1000 км влечет начисление компенсации именно в том месяце, в котором эта 1000 была достигнута. Пока нет следующей 1000, начисления нет. Где-то на этом форуме есть отзывы тех, кому на экз попадалась эта задача, так что это не моё ИМХО, а достаточно надежная информация.
Не говоря о том, что при использовании оборотного регистра, он будет неоправданно раздут (нам никто не говорит, что нужно накапливать отработанные часы), а как я понял - с очисткой оборотного регистра никто не заморачивался.
В общем, решить удалось только через регистр остатков - каждый раз увеличиваем ФактЧасы, и тут же проверяем, не превысили ли они 1000. Если да - делаем расход на 1000.
Вроде бы, всё правильно. Решение всего билета прикрепляю, вдруг кому понадобится.
Если заметите какие-либо недочёты - буду очень признателен!
-
... решить удалось только через регистр остатков - каждый раз увеличиваем ФактЧасы, и тут же проверяем, не превысили ли они 1000. Если да - делаем расход на 1000.
Я именно так и решал при подготовке. Считаю, что это оптимальный вариант.
Подкорректировал старое сообщение, где под напором коллег соглашался с использованием оборотного РН. :)
ПС. Часы надо проверять не на превышение 1000, а на больше или равно.
-
В задаче СПР в для начисления компенсации за ремонт нет условия, что компенсация должна быть начислена за каждые 1000 часов наезда. Вероятно, что факт наезда 1000 часов дает сотруднику право на получение компенсации, т.е. с того месяца как пошло превышение ему может быть начислена эта компенсация. А начислять её или нет решает пользователь когда в документе Начисление ЗП заводит соответствующий вид расчета. Также возможно, во всех периодах в течение которых он наезжал свои 1000 часов у него были прогулы, тогда по условию задачи ему компенсация не положена и право на эту компенсацию может возникнуть только на 5000 часов.
Также в задаче сказано "наездил", а не отработал, потому копить часы по данным рабочего времени не правильно, просится отдельный документ, который будет делать движения только в регистр накопления.
-
Мой вариант решения. 1000 часов сделал на регистре расчета отдельным видом расчета.
Но если начислять за каждые 1000, то решение не верное.
Ориентировался по условию: "Если водитель в расчетном периоде наездил больше 1000 часов, то ему должна быть начислена компенсация" - то есть данные должны браться за начисляемый период (месяц), значит регистр оборотный должен быть, а не остатки (которые использовались бы для каждых 1000), и компенсация должна быть вроде как одна...
Использовал механизм базы и в ресурс для базы записывал то самое значение выработки, и в базу для компенсации указывал эту выработку за текущий период расчета, также базой для компенсации сделал штраф - для галки был штраф или нет. при расчете базу по виду расчета разрезаю и проверяю выработка или штраф (по тексту запроса станет более понятно).
Буду рад критике
:)
-
... то есть данные должны браться за начисляемый период (месяц) ...
Т.е вы имеете ввиду, что начисляете тогда, когда 1000 часов наезжено именно в течение расчетного месяца - с 1-го по последнее число этого месяца? :)
-
erdem.badluev, а зачем условие по периоду регистрации?
|ИЗ
| РегистрРасчета.Начисления.ДанныеГрафика(
| Регистратор = &Регистратор
| И ПериодРегистрации = &ПериодРегистрации) КАК НачисленияДанныеГрафика
Запрос.УстановитьПараметр("ПериодРегистрации", НачалоМесяца(Ссылка.Дата));
Запрос.УстановитьПараметр("Регистратор", Ссылка);
-
Зачем в компенсации со штрафом извращаться, ведь в условии задачи сказано
Компенсация начисляется только в случае отсутствия невыходов, однако контролировать программным образом данное обстоятельство не требуется.
Вид расчета "Выработка", для хранения времени это совсем уже извращение, так делать нельзя.
Штраф в допначислениях, по-моему, тоже ни туда ни сюда, лучше в основных сделать, там данные графика получать нужно, а в допначислениях данные о количестве дней не получить и настроена зависимость от базы, которая не нужна штрафу
-
... то есть данные должны браться за начисляемый период (месяц) ...
Т.е вы имеете ввиду, что начисляете тогда, когда 1000 часов наезжено именно в течение расчетного месяца - с 1-го по последнее число этого месяца? :)
Да. По условию задачи так понимаю.
-
erdem.badluev, а зачем условие по периоду регистрации?
|ИЗ
| РегистрРасчета.Начисления.ДанныеГрафика(
| Регистратор = &Регистратор
| И ПериодРегистрации = &ПериодРегистрации) КАК НачисленияДанныеГрафика
Запрос.УстановитьПараметр("ПериодРегистрации", НачалоМесяца(Ссылка.Дата));
Запрос.УстановитьПараметр("Регистратор", Ссылка);
Индекс у регистров расчета построен по регистратору и периоду регистрации, так быстрее сработает.
-
Зачем в компенсации со штрафом извращаться, ведь в условии задачи сказано Компенсация начисляется только в случае отсутствия невыходов, однако контролировать программным образом данное обстоятельство не требуется.
Вид расчета "Выработка", для хранения времени это совсем уже извращение, так делать нельзя.
Штраф в допначислениях, по-моему, тоже ни туда ни сюда, лучше в основных сделать, там данные графика получать нужно, а в допначислениях данные о количестве дней не получить и настроена зависимость от базы, которая не нужна штрафу
Я сделал зависимость по базе у компенсации от штрафа для определения был штраф или нет, чтобы потом его в отчет вытащить. Штраф зависит от НеВыхода, который в результат записывает количество дней, а штраф умножает это количество дней не выхода на 5000.
В отчете галку БылШтраф правильней было бы устанавливать в запросе по наличию начисления Штраф.
Вид расчет Выработка сделан для ввода тех самых 1000 часов.
Логика была такая: если мы проверяем наездил ли сотрудник в текущем месяце начисления более 1000 часов без учета ранее наезженного (без накопления остатков), тогда нужен оборотный регистр для учета тех самых часов. Но, зачем это делать на оборотном регистре, если регистр расчета прекрасно с этой задачей справится: вводим Выработку, обороты по ней по текущему месяцу начисления получим через базу для компенсации, что и требовалось нам для вывода сколько было наезжено в отчете.
Это решение с оговоркой: мы проверяем количество наезженных часов за текущий месяц начисления без накопления часов за предыдущие периоды.
Вопрос у меня такой: моя реализация с этой оговоркой на регистрах расчета правильна ли, или всё же нужно использовать оборотный регистр? И в требованиях одна из ошибок: "Решение задач накопления на регистре расчета" - но в этом решении выработка не накапливается, а проверяются обороты за конкретный период расчета.
Сейчас думаю, что всё же решение не верное :( у SAE на оборотном регистре сделано.
-
... то есть данные должны браться за начисляемый период (месяц) ...
Т.е вы имеете ввиду, что начисляете тогда, когда 1000 часов наезжено именно в течение расчетного месяца - с 1-го по последнее число этого месяца? :)
Да. По условию задачи так понимаю.
Посчитайте, сколько часов в месяце, даже если водитель будет работать круглосуточно и без выходных. :D
Экзаменаторы считают, что в данной задаче необходимо накапливать часы, и выплачивать компенсацию в каждом месяце, в котором общий пробег становится больше очередной (накопленной) тысячи.
-
Зачем в компенсации со штрафом извращаться, ведь в условии задачи сказано Компенсация начисляется только в случае отсутствия невыходов, однако контролировать программным образом данное обстоятельство не требуется.
Вид расчета "Выработка", для хранения времени это совсем уже извращение, так делать нельзя.
Штраф в допначислениях, по-моему, тоже ни туда ни сюда, лучше в основных сделать, там данные графика получать нужно, а в допначислениях данные о количестве дней не получить и настроена зависимость от базы, которая не нужна штрафу
... Штраф зависит от НеВыхода, который в результат записывает количество дней, а штраф умножает это количество дней не выхода на 5000 ...
Кстати, вот, напомнили, что там еще фигурирует.
Где-то писали конкретно, что экзаменаторы рекомендуют не создавать разные ВР для невыхода и штрафа, использовать один.
-
Спасибо!
Значит документ НачислениеЗарплаты должен делать приход на ФактЧасов (регистр накопления остатки) на количество фактически отработанных часов взятых из данных графика, затем проверять остаток этих ФактЧасов на конец начисляемого периода если больше 1000, то компенсация..., и расход ФактЧасов 1000. Так получается?
-
Спасибо!
Значит документ НачислениеЗарплаты должен делать приход на ФактЧасов (регистр накопления остатки) на количество фактически отработанных часов взятых из данных графика, затем проверять остаток этих ФактЧасов на конец начисляемого периода если больше 1000, то компенсация..., и расход ФактЧасов 1000. Так получается?
Да.
Я бы еще запретил ввод отрицательных часов, чтобы не контролировать возможную корректировку введенных ранее часов.
-
Покритикуйте, пожалуйста, задачку по СПР
-
И ОУ
-
Осилил наконец-то СПР
2 суток рвало башку с этими часами. У SAE наткнулся на ошибку, как тут и писали - всё время компенсацию считает.
Задача - бред, отчёт - бред. Решение - такой же бред (на мой взгляд)
-
Вопрос по отчету БУ. На каком счете делать оборотное субконто "Номенклатура". "Прибыли и убытки" или "Покупатели". По мне, так логичнее делать на "Покупатели". Кто как думает?
-
на "Покупатели"
Почти недопустимый вариант.
Или у вас пономенклатурный учет расчетов?
-
Просмотрела сейчас все билеты, пытаясь найти ПР с перерасчетом и не нашла... Пара задач с отчетом по перерасчету и все.... Нету что ли? :-\
-
Сделал оперчасть на одном регистре накопления:
измерения - заказ, номенклатура
ресурсы - Закуплено, Отгружено, Себестоимость (отгрузок)
Документ.Заказ делает приход, заполняет ресурс Закуплено
Документ.ПриходнаяНакладная делает расход по всем трем ресурсам, Закуплено = Отгружено
Документ.РасходнаяНакладная делает приход в Отгружено и себестоимость.
Единственное что надо брать потом остатки по "отгружено" с минусом и всё.
есть критики данного подхода?
может кто делал подобное на экзамене, что сказал проверяющий?
-
Сдал спеца 09.06.17. Хочу поделиться своими решениями билетов. Спасибо всем участникам за обсуждение и выкладываемые решения. Это серьезная помощь в подготовке к экзамену.
-
"Компенсация начисляется только в случае отсутствия невыходов, однако контролировать программным образом данное обстоятельство не требуется."
Если не требуется контролировать, то зачем вообще упоминается условие по невыходам?
-
Сдал спеца 09.06.17. Хочу поделиться своими решениями билетов. Спасибо всем участникам за обсуждение и выкладываемые решения. Это серьезная помощь в подготовке к экзамену.
Понравилось Ваше решение СПР.
Проверка на 1000р., я так понимаю, немного не доделана.
В этой ветке писалось о том, что для штрафа и невыхода можно (или даже нужно) использовать один ВР. Не представляю как это сделать корректно. С одной стороны этот ВР должен вытеснять Оклад, с другой стороны это удержание, которое не понятно как учитывать в РР.ОН. С минусом плохо, получится неразбериха, если будет добавлено сторно, с плюсом вообще бред, а не регистр получится. Логично удержание хранить в отдельном регистре, но тогда ничего не выйдет с вытеснением. С двумя ВР всё встает на свои места.
-
Просьба кому не лень посмотреть решение 12 билета
-
Мои решения после сдачи.
В ПР сложный отчет. Заморачиваться не стал.
Если Невыход, то просто списываю все наработанные часы.
Соответственно Компенсация за ремонт выплачивается если нет Невыхода по умолчанию.
-
Коллеги, доброго! Решенный билет ++ :) Буду рад обратной связи.
-
Решённый билет 12. Буду рада комментариям, особенно СПР. Наезженные часы заводила через регистр остатков.
-
А кто-нибудь сдавался по этому билету из присутствующих? Прокатывает ли вообще РН в расчетах и нужен ли он вообще? Отработанные часы у нас же хранятся в регистре расчета и можно получить количество отработанных часов из данных графика по условию ПериодРегистрации < &ПериодРегистрации - это до начисления, ПериодРегистрации <= &ПериодРегистрации - это после начисления. Соответственно свернув по сотруднику и суммированием часов. И уже анализировать перевал за тысячу в данном периоде.
Конечно это медленнее, но и задача же не оперативная, да и отработанные часы - показатель сугубо расчетного регистра. И где вы брали "ОтработаноЧасов" для отчета, если использовали РН и минусовали 1000 при начислении компенсации?
Никто не в курсе, что экзаменаторы вообще говорят по поводу использования в данной задачи РН?
-
А кто-нибудь сдавался по этому билету из присутствующих? Прокатывает ли вообще РН в расчетах и нужен ли он вообще?
А что еще за регистр накопления в расчетах, для чего он там нужен поясните ?
Я решил эту задачу за 1 час, ничем особенным от всех остальных не отличается вроде.
PS. 1000 часов как я понял это типа опечатки, в расчетном периоде (месяц) не может быть 1000 часов, поэтому я считаю их как 100 часов.
-
1000 — это не опечатка. Они накапливаются несколько месяцев. Потом обнуляются. Проще всего это сделать на регистре накопления.
-
1000 — это не опечатка. Они накапливаются несколько месяцев. Потом обнуляются. Проще всего это сделать на регистре накопления.
Т.е. "в расчетном периоде наездил больше 1000 часов" нужно читать как "в расчетном периоде нарастающий итог фактических часов превысил 1000" ?
Ну тогда добавляем еще один ресурс в регистр начисления "Факт нарастающим итогом", и считаем его по базе "Оклад" без указания начала базового периода.
Белоусов говорит "Если можно решить задачу на 1 регистре, значит это правильное решение. Добавление избыточных регистров - ошибка".
-
Человек отработал 40 лет. Если ты считаешь свой вариант более оптимальным, чем добавление регистра остатков, решай на ресурсе регистра расчетов.
-
Человек отработал 40 лет. Если ты считаешь свой вариант более оптимальным, чем добавление регистра остатков, решай на ресурсе регистра расчетов.
Остатков ? Там где-то в условии еще и сказано, что надо накапливать и списывать факт. часы ??
-
Мда, задача по СПР очень нестандартная. Внимательно изучил всю тему, ясного решения не нашел. Не претендую на правильность решения, но возможно, кто то найдет для себя что то нужное:
Оклад - стандартно (часы * ставка). Фактические часы каждый раз пишутся в регистр накопления (только обороты)
Невыход - в ПВР "Основные начисления", вводится пользователем, сумма по нему не рассчитывается - этот вид расчета является только базой для штрафа и вытесняет оклад.
Штраф - в ПВР "Удержания", создается автоматически при проведении, если требуется, рассчитывается по формуле: 5000*дни невыхода
Компенсация - в ПВР "Дополнительные начисления", создается автоматически при проведении, если сумма часов превысила 1000. В момент превышения 1000 часов добавляется запись -1000.
Не смог реализовать условие задачи "Компенсация начисляется только в случае отсутствия невыходов, однако контролировать программным образом данное обстоятельство не требуется". Тут логично, что у вида расчета "Компенсация" вытесняющим по периоду регистрации должны быть виды расчета "Невыход" или "Штраф". Но настроить это в ПВР мне не удалось. Надеюсь, кто-нибудь сможет это реализовать - в задаче это условие не просто так вставлено.
-
Не смог реализовать условие задачи "Компенсация начисляется только в случае отсутствия невыходов, однако контролировать программным образом данное обстоятельство не требуется". Тут логично, что у вида расчета "Компенсация" вытесняющим по периоду регистрации должны быть виды расчета "Невыход" или "Штраф".
Так проверь перед расчетом Компенсации размер результата по виду начисления Невыход. Если его нет, значит можно начислять.
-
Не смог реализовать условие задачи "Компенсация начисляется только в случае отсутствия невыходов, однако контролировать программным образом данное обстоятельство не требуется". Тут логично, что у вида расчета "Компенсация" вытесняющим по периоду регистрации должны быть виды расчета "Невыход" или "Штраф".
Так проверь перед расчетом Компенсации размер результата по виду начисления Невыход. Если его нет, значит можно начислять.
Сдается мне, что данное условие подразумевает контроль пользователем, поэтому лишние действия делать не нужно.
-
Сдается мне, что данное условие подразумевает контроль пользователем, поэтому лишние действия делать не нужно.
Полагаю, что данное условие означает, что не нужно программно запрещать пользователю добавлять начисление с видом Компенсация, если есть невыходы. Иначе для чего тогда вообще эта фраза в условии ?
-
Программный контроль исключается - 100%. Поэтому проверку в расчетах добавлять нельзя. То, что этот факт контролируется пользователем - вряд-ли, т.к. другие аналогичные ситуации в условиях задач не встречаются. Тут заковырка именно в конструкции метаданных... GROOVY бы сюда.
-
Программный контроль исключается - 100%. Поэтому проверку в расчетах добавлять нельзя. То, что этот факт контролируется пользователем - вряд-ли, т.к. другие аналогичные ситуации в условиях задач не встречаются. Тут заковырка именно в конструкции метаданных... GROOVY бы сюда.
ОК, для чего тогда вообще эта фраза в условии ?
-
Читая задачи из сборника, я понял систему. Составлялись задачи так - собиралась простенькая учетная система, затем по ней составлялось ТЗ (условие задачи). А чтобы не было альтернативных способов решения по условию, в условие добавлялись эти самые отпорки. Поэтому даже для себя, решая задачи, я вывел правило - если решение получается сложное, кривое, или просто в нем много кода - оно неверное. Нужно искать простое, верное решение задачи - конфигурацию, которая было составлена авторами сборника. А это самое предложение в условии, которое мы обсуждаем - та самая отпорка. Она имеет под собой основание.
-
Программный контроль исключается - 100%. Поэтому проверку в расчетах добавлять нельзя. То, что этот факт контролируется пользователем - вряд-ли, т.к. другие аналогичные ситуации в условиях задач не встречаются. Тут заковырка именно в конструкции метаданных... GROOVY бы сюда.
ОК, для чего тогда вообще эта фраза в условии ?
Контроль со стороны платформы не требуется. И все. Можно ее мимо пропустить, я думаю так. Здесь ключевой момент - проверку добавлять не надо. Значит пользователь должен все это нормально вводить.
-
1) Программно контролировать не надо (по условию)
2) Механизмов платформы для такого контроля — НЕТ.
3) Значит контролирует ПОЛЬЗОВАТЕЛЬ.
-
1) Программно контролировать не надо (по условию)
2) Механизмов платформы для такого контроля — НЕТ.
3) Значит контролирует ПОЛЬЗОВАТЕЛЬ.
Вот еще точнее пояснил. :)
-
До чего же е_нутая задача СПР в 12 билете. Прорешал на чистовую, на задачу ушло 1ч. 34м. Выполнены все условия задачи кроме "Компенсация начисляется только в случае отсутствия невыходов". У документа "Начисление зарплаты" в движениях аж 5 регистров. В задаче используются все три вида расчета. Штраф зависит от ОН "Невыход", который вытесняет оклад по периоду действия. Период действия штрафа выставляется пользователем, он может отличатся от периода невыхода, ибо "если сотрудник не вышел на работу по неуважительной причине". Процент компенсации вводится в шапке документа, пишется в регистр, но при расчете все равно используется реквизит шапки - т.е. регистр не нужен, но ведь"в информационной базе необходимо хранить историю изменения данного процента". Не нужнее в этой задаче разве что только справочник "Автомобили", который я сделал подчиненным справочнику "Физические лица", т.к. "Сотрудники работают на собственных автомобилях, поэтому обмен автомобилями между водителями не возможен". Не дай Бог вам попадется эта задача на экзамене.
-
Штраф = невыход
Подчинение автомобилей сотрудника не нужно. Автомобиль — реквизит регистра, т.о. выполняется условие, что совместительство (обмен автомобилями) невозможны.