Здравствуйте.

допустим есть договор.

есть у него план оплат. в разрезе источников оплат.
источники оплат - справочник. разделен по годам. те ПК там ИД источника оплаты и год.
Соответственно один и тот же источник в разные годы будет иметь разный ПК.

допустим имеем мы в договоре в 2016 году тип оплаты Х. В сумме миллион.
внутри года оплатили 900 тр. с указанием типа оплаты Х. записали в таблице оплат со ссылкой на год и на ИД типа оплаты Х.
Все красиво. баланс подбить не проблема.

образовалась у нас кредиторка.
наступил новый год. и решили оплатить. но в новом году у типа оплаты Х другой ПК. И в плане оплаты прошлого года его нет.
Да и быть не может. тк он из другого года. А может так случиться, что оплатить возможно будет только с типа Y нового года.

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


Спасибо

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

vmagsergqте ПК там ИД источника оплаты и год.

Мне вот интересно, тому кто этот костыль делал, не приходило в голову, что могут платить частями и даже не в этом году?
ПК в виде обычного счетчика в таблице оплат придумать - это наверное уже из области недосягаемого...

согласен. костыль.
Но. может случиться так, что в плане оплат в 2016 году будет стоять источник Х.
А в 2017 году такового источника может просто не оказаться. Будет источник Y. и тут уже без разницы какой ПК. ибо он в любом случае будет другой

vmag,

у источника Х в разные годы разные ПК.


собственно получится, что в плане оплат будет стоять ПК источника (например) равный 1.

а вот в факте оплат будет два факта. один факт за 2016 год с ПК источника равным 1.
и второй факт. за 2017 год с источником с ПК равным 2.

в итоге баланс получается такой.
по источнику с ПК 1 мы начислили миллион.

А оплатили по сути с двух разных источников.

В итоге надо получить стандартный отчет

ИД источникаПланФакт110000001000000

а раз разные источники погашения, то получается вроде как такой отчет

ИД источникаПланФакт1100000090000020100000

Кот Матроскин,

Те одина таблица справочника будет содержать просто список всех возможных типов оплат. Эдакий raw справочник. А вторая -только действующие в текущем году .
Кстати так и сделано со справочником )

В плане оплат на raw справочник , а в факте на действующие в текущем году?

Только вот в план должны попасть только те, что действуют в году договора. Сейчас реализовано на ФК. Как раз в ФК год и задействован .
И в фактах оплат тоже был год задействован в ФК

Тогда наверно наоборот . В план оплат - которые действуют в текущем году. Как раз по ФК можно будет отсеивать не действующие в тек году. А в факт -raw.

Проблема в том, что такие случаи очень единичны . И было удобно держать ФК на ид и год действия оплаты. Не добавишь по дурости лишку. А вот кредиторка как раз та лишка и есть

sergq,

А вообще как вариант сделать отдельную табличку.
'В 2017 году тип Х 2017 года считать как тип Х 2016 года '

в для "не пересекающихся " типов в неё писать такое.

В 2016 году тип Х 2016 года считать как тип Х 2016 года
Для "одногодок" заполнять её на триггере автоматом

И вот на эту табличку и делать ссылку и в плане и в факте.

Тогда вроде как все красиво получится. Ошибиться сможет только оператор в формировании этого справочника . Но это в редких случаях

Кот Матроскинsergqдействующие в текущем году?

Только вот в план должны попасть только те, что действуют в году договора. Сейчас реализовано на ФК. Как раз в ФК год и задействован .
И в фактах оплат тоже был год задействован в ФК

Ну и прекрасно - но группируйте их в этом Вашем отчете "план-факт" не до ссылок дочерних таблиц "тип+ год", а просто до "тип".
Т.е. у Вас 1 запись План ((XXX, 2016), 1000000), 2 записи "Факт" - ((XXX, 2016), 900 000 ) и ((ХХХ, 2017), 100 000), Вы группируете и план и факт по типу ХХХ, и Ваш отчет выглядит
Тип План Факт ХХХ 10000001000000
И то, что реально в "факте" 2 оплаты с разными ссылками на дочернюю таблицу - не видно.

чуть выше говорил. может быть запланирована оплата Х в 2016, а оплачена с оплаты Y 2017. те "пишем Y, Х в уме". вот в этом случае и расползется

те Y это именно наименование оплаты в 2017. а не ИД

vmag,

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

Выглядит это примерно так.
Таблица периодов оплат. С указанием года.
К ней дочерняя. С указанием типа оплаты и суммы. Плановой. Для одного периода может быть несколько типов и сумм.

И есть еще пара таблиц. Которые связывают факты оплаты с конкретным периодом.
В первой таблице ссылка на оплачиваемый период. Тут фк на шапку планов оплат с учетом года. И ссылка на шапку документа оплаты.

И вторая дочерняя — помимо всего прочего ссылка на тело документа оплаты. В нем фигурирует тип. И зачем то сделал ссылку на конкретную строку плана оплаты. Ну видно чтоб знать какая оплата к какому плану оплаты в конкретном периоде соответствует.

Можт конечно и перемудрил.

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

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

Согласен. Что то концептуально хромает

sergq,

Хотя. Раз можно связать план с любой оплатой любого года и любого типа, то можно сделать так.
Если связывается факт оплаты с оплатой не из того периода или не с тем типом оплаты, что указан в плане оплаты, то на уровне интерфейса ругнуться, переспросить связывать ли. И если связывать— взять тип оплаты из плана и записать его в спецполе.
Для пущей уверенности повесить констрейн что если связываемый факт оплаты не того года и—или не того типа, то в спецполе лолжен быть указан реальный тип из планового года. Маленькая, но гарантия защиты от лишних косяков

Тогда получится если года плана и факта не совпадают, то будет присутствовать значение типа оплаты из плана. Некое сопоставление—трансляция

И при запросе учитывать значение этого поля. Если есть— подменять и ид и текстовое представление типа оплаты из факта в выборке. И тогда будет все более менее красиво.
Хотя все равно кривовато)