Автор Тема: Билет 6. Спец по платформе V8  (Прочитано 146782 раз)

0 Пользователей и 1 Гость просматривают эту тему.

alex1248

  • Призрак форума
  • *****
  • Сообщений: 714
Re: Билет 6. Спец по платформе V8
« Ответ #270 : Декабрь 17, 2016, 01:37:27 pm »
Тут вот чел отписался по поводу БУ:
А что тут нового/странного/важного? Задача решена с очевидной грубой ошибкой.

dgchar

  • Пользователь
  • **
  • Сообщений: 30
Re: Билет 6. Спец по платформе V8
« Ответ #271 : Декабрь 17, 2016, 02:34:57 pm »
А что можешь посоветовать по поводу СПР, что данные оплаты берутся из БУ. На Сч Касса если повесить аналитику по Сотруднику?


alex1248

  • Призрак форума
  • *****
  • Сообщений: 714
Re: Билет 6. Спец по платформе V8
« Ответ #272 : Декабрь 17, 2016, 02:52:58 pm »
А что можешь посоветовать по поводу СПР, что данные оплаты берутся из БУ. На Сч Касса если повесить аналитику по Сотруднику?
Не вижу такой формулировки в 6-СПР. Где такое условие?

dgchar

  • Пользователь
  • **
  • Сообщений: 30
Re: Билет 6. Спец по платформе V8
« Ответ #273 : Декабрь 17, 2016, 03:45:03 pm »
ВОТ:
Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц, полученная сотрудником, умноженная на определенный процент. Значение процента для надбавки может изменяться не чаще, чем один раз в месяц. В информационной базе необходимо хранить историю его изменения. Сумма оплат должна быть получена по данным бух учета пользователем следующей проводкой:
ДТ «Касса» - Кт «Покупатели» на сумму оплат
Считать что после расчета сумма оплат корректировке не подлежит.
Один календарный месяц в году сотрудникам предоставляется оплачиваемый отпуск, размер которого определяется как количество дней отпуска, умноженное на среднюю дневную ставку.
Дни отпуска рассчитываются по пятидневному графику. Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во рабочих дней за пред. 3 месяца. Следует учесть, что данные об отпуске не могут вводиться в систему задним числом.

alex1248

  • Призрак форума
  • *****
  • Сообщений: 714
Re: Билет 6. Спец по платформе V8
« Ответ #274 : Декабрь 17, 2016, 03:56:30 pm »
Сумма оплат должна быть получена по данным бух учета пользователем следующей проводкой:
ДТ «Касса» - Кт «Покупатели» на сумму оплат
В актуальных этого нет.
Даже если добавить, то в задаче 6-БУ нет кассы.

dgchar

  • Пользователь
  • **
  • Сообщений: 30
Re: Билет 6. Спец по платформе V8
« Ответ #275 : Декабрь 17, 2016, 04:06:39 pm »
где здесь читал что комуто попадалось данное условие. Вот собственно текст того, кому попался: Попался билет 6. СПР задача изменена. Нужно было делать перерасчет для начисления,которое рассчитывается по бухгалтерским регистрам. Не сделал.И перерасчет нужно было сделать еще один(плохо помню,по какому начислению) В итоге троечка. из ошибок :

"СПР: Неверно организованны графики, для одного автомобиля не должно быть несколько разных графиков; перерасчет не реализован
« Последнее редактирование: Декабрь 17, 2016, 04:26:52 pm от dgchar »

alex1248

  • Призрак форума
  • *****
  • Сообщений: 714
Re: Билет 6. Спец по платформе V8
« Ответ #276 : Декабрь 17, 2016, 04:32:38 pm »
где здесь читал что комуто попадалось данное условие
Так надо видеть точное условие, чтобы понимать, как получать данные по сотрудникам.
Но на мой взгляд, с/к Сотрудники на счете Касса - не оптимальный вариант. Хотя, если оборотное, может быть.

erdem.badluev

  • Проверенный
  • ***
  • Сообщений: 139
Re: Билет 6. Спец по платформе V8
« Ответ #277 : Январь 18, 2017, 05:43:39 am »
Мой вариант решения, с дополнительным условием в СПР - реализация процедуры перерасчета.
Буду рад критике.
 :)

Pathfi

  • Новичок
  • *
  • Сообщений: 9
  • ФИО: Евгений
Re: Билет 6. Спец по платформе V8
« Ответ #278 : Январь 22, 2017, 06:54:58 pm »
где здесь читал что комуто попадалось данное условие
Так надо видеть точное условие, чтобы понимать, как получать данные по сотрудникам.
Но на мой взгляд, с/к Сотрудники на счете Касса - не оптимальный вариант. Хотя, если оборотное, может быть.

Прикладываю точное новое условие по СПР. Такое условие попадается при дистанционной сдаче...
http://forum.chistov.pro/index.php?topic=3670.msg48191#msg48191

alex1248

  • Призрак форума
  • *****
  • Сообщений: 714
Re: Билет 6. Спец по платформе V8
« Ответ #279 : Январь 22, 2017, 07:38:37 pm »
где здесь читал что комуто попадалось данное условие
Так надо видеть точное условие, чтобы понимать, как получать данные по сотрудникам.
Но на мой взгляд, с/к Сотрудники на счете Касса - не оптимальный вариант. Хотя, если оборотное, может быть.

Прикладываю точное новое условие по СПР. Такое условие попадается при дистанционной сдаче...
http://forum.chistov.pro/index.php?topic=3670.msg48191#msg48191
При таком условии я сделал бы субконто "Сотрудники" на счете "Покупатели" (а в реальной задаче предварительно на счете "Покупатели" создал бы субсчет "Пассажиры", и уже на нем данное субконто).

flex

  • Пользователь
  • **
  • Сообщений: 27
Re: Билет 6. Спец по платформе V8
« Ответ #280 : Январь 23, 2017, 07:37:46 pm »
Не очень понятно, как реализовать перерасчет при таких условиях. Есть ли идеи?

Pathfi

  • Новичок
  • *
  • Сообщений: 9
  • ФИО: Евгений
Re: Билет 6. Спец по платформе V8
« Ответ #281 : Январь 28, 2017, 06:43:02 pm »
Не очень понятно, как реализовать перерасчет при таких условиях. Есть ли идеи?

Мой вариант решения 6 СПР с новым условием. Реализацию перерасчета свистнул у Гакусея (нашел в соседних темах).

CeHbKA

  • Пользователь
  • **
  • Сообщений: 88
Re: Билет 6. Спец по платформе V8
« Ответ #282 : Февраль 03, 2017, 12:31:36 pm »
Наконец-то осилил 6 билет по СПР. Программный перерасчёт не делал, т.к. ещё не въезжаю что это и зачем.

Итак, 1 - в условии задачи сказано что возможен обмен автомобилями. По сути здесь у нас автомобили это подразделения. А слово обмен говорит нам, что совместительство невозможно. Т.е. не может человек одновременно ездить на 2 автомобилях, поэтому кидаем автомобиль в реквизит РР.
2 - все сотрудники работают по графику, индивидуальному для каждого автомобиля. Значит автомобили - это и есть графики. Добавляем соотв. измерение в РС графики работы
3 - Не зависимо от отработанного времени сотрудникам предприятия ежемесячно выплачивается фиксированная сумма денег. Размер суммы одинаков для всех сотрудников и не меняется в течение расчетного периода. Это значит что у нас есть произвольное начисление, которое вообще живёт само по себе. Поэтому кидаем это начисление в ДопНачисления, где у нас никакого периода действия нет. Насчёт фикс. суммы - можно добавить константу, туда пихать число и когда юзер будет набивать нашу фиксу, тупо подтягивать значение из константы. Но я не стал заморачиваться.
4 - Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц, полученная сотрудником, умноженная на определенный процент. Здесь очень хитрое условие. На мой взгляд задача по СПР должна и решаться механизмами СПР, особенно если в условии явно ничего не указано. Ну или как проще. Поэтому я замутил обычный вид расчета "Оплата пассажиров" и беру его как базу. Это очень удобно. Не нужно городить лишний регистр, можно связать сумму оплат пассажиров и автомобиль, на котором наш сотрудник рубил капусту. Одним словом БАЗА.
5 - Значение процента для надбавки может изменяться не чаще, чем один раз в месяц. В информационной базе необходимо хранить историю его изменения. Тоже всё понятно - делаем РС с периодичностью месяц и при расчёте базы, аккуратненько подтягиваем этот процент.
6 - Один календарный месяц в году сотрудникам предоставляется оплачиваемый отпуск, размер которого определяется как количество дней отпуска, умноженное на среднюю дневную ставку. Тут честно говоря, можно словить вакуум от слов "размер" и "определяется", поэтому я забил. Делаем вид расчета отпуск и пусть пользователь вручную его вбивает, с какого и по какое число. Причем какой автомобиль будет указан - неважно. Лишь бы под него была заполнена пятидневка.
7 - Дни отпуска рассчитываются по пятидневному графику. Тут у нас отвисает пачка, мы начинаем нервничать, но не стоит. Решение красивое и простое. Помните, что у нас графики по автомобилям делаются? Логично что никакой автомобиль "пятидневка" или доп.измерение нам городить не нужно и вот почему. Легким движением руки, добавляем второй ресурс пятидневка в наш РС графики работы. И заполняем его всегда программно! Т.е. сб и вс у нас выходные по пятидневке. Всегда. Для всех. Даже если у автомобиля какой-то свой непонятный график, по пятидневке у него своё значение
8 - Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во отработанных дней за пред. 3 месяца. Тут всё понятно - используем базу, считать её придётся из 2-х регистров расчета. Не забываем, что отпуск у нас рассчитывается по пятидневке, значит именно по ней мы должны подцепить данные об отработанном времени за пред. 3 месяца
9 - Следует учесть, что данные об отпуске не могут вводиться в систему задним числом. Отлично! Механизм сторнирования не нужно делать!

В принципе всё!
« Последнее редактирование: Февраль 03, 2017, 12:34:46 pm от CeHbKA »

CyberGirl

  • Пользователь
  • **
  • Сообщений: 13
Re: Билет 6. Спец по платформе V8
« Ответ #283 : Февраль 03, 2017, 01:33:52 pm »
Думаю, вид расчета "Оплата пассажиров" - это в корне неверное решение. Мы не начисляем сотруднику "Оплату от пассажиров", это не вид расчета. Тем более, в новом условии задачи данные по оплатам пассажиров берутся по данным бух. учета, так что хочешь-не хочешь, а нужно будет их взять из регистра бухгалтерии.

CeHbKA

  • Пользователь
  • **
  • Сообщений: 88
Re: Билет 6. Спец по платформе V8
« Ответ #284 : Февраль 03, 2017, 01:52:54 pm »
Думаю, вид расчета "Оплата пассажиров" - это в корне неверное решение. Мы не начисляем сотруднику "Оплату от пассажиров", это не вид расчета. Тем более, в новом условии задачи данные по оплатам пассажиров берутся по данным бух. учета, так что хочешь-не хочешь, а нужно будет их взять из регистра бухгалтерии.
Позволю себе заметить, что в регистре расчета нет никаких остатков и в ноль он не закрывается. Соответственно под "начислением сотруднику" можно понимать, что угодно. Я выбрал такое решение и оно работает, в оригинальном условии об этом ничего не сказано.
Что касается последней версии с данными из БУ, то это только облегчает жизнь, т.к. условную проводку можно сделать документом операция и она не затрагивает остальные области учёта в данной задаче.