|
![]() |
#1 |
Administrator
|
Не претендую на красивость решения и уж тем более на его повторение. Однако опишу идею, которая была реализована на одном из проектов.
Для начала было принято упрощение, что все платежи будут вводиться через журнал ГК. (На самом деле - это не очень обязательное упрощение, тем не менее - оно упрощает жизнь при программировании). Далее - в журнал ГК для корсчета была добавлена также финаналитика (ибо чей-то там ее нет?). Конечно, по умолчанию она копировалась из финаналитики при счете, однако была возможность ее менять. Тут конечно надо понимать - что у всех пользователей системы - разное количество финаналитик и разное предназначение каждой из аналитики - поэтому какие-то аналитики должны обязательно копироваться, какие-то пользователь может менять, а какие-то должны обязательно отличаться и это должно быть прошито в коде. Поэтому в рамках поставленного вопроса я опущу тематику состава финаналитик. Дальше - была сделана "врезка" в разноску журнала ГК, которая "складировала" в отдельную таблицу строки журнала, в которых при счете или корсчете присутствовали бы денежные счета (Банк/Касса). Для инкассации / обналички естественно создавалось 2 записи. Новоявленная табличка таким образом являлась фактически готовым отчетом ДДС. При этом, т.к. она получалась из ЖГК - у нее всегда были счет и корсчет (дебет/кредит). По ней можно было фильтроваться, сортироваться, переходить к исходному документу, строить различные выборки и автоотчеты. С одной стороны - заполнение лишней таблички - конечно не уменьшает время разноски. С другой стороны - заказчику, для которого делался данная модификация было очень важно иметь мгновенный отчет ДДС, обновляющийся фактически онлайн. Собственно - говоря - описанное представляет собой просто еще один взгляд на ДДС, очевидно, при этом не лишенный ряда недостатков. Еще момент. Отмечу - что в данном подходе никак не описывается сопоставление именно накладных с оплатами. Т.е. тут описано простое копирование (=простая выжимка) того, чего навводили в ЖГК по денежным счетам. С другой стороны - для анализа данных именно по денежным счетам по финаналитикам - это самое то. Если конечно хочется получить информацию независимо от сопоставления.
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 28.08.2011 в 23:20. |
|
![]() |
#2 |
Участник
|
To: sukhanchik
1) Идея с "врезкой" фин. аналитик в ЖГК, это в общем-то стандартный функционал журнала платежей, который по умолчанию и содержит фин. аналитики. 2) Доработать доп. таблицу, к платежу, в которой бы содержались строки по разбитым фин. аналитикам - это интересная идея. У меня была мысль переносить в журнал платежей накладную не одной итоговой строкой, а разбивать строки накладной по строкам платежа, только в этом случае мы получим довольно много проводок по гк, чего в общем-то наверное делать не хочется т.к. это приведет к проблемам в их дальнейшем анализе. Кроме того, в этом случае, мы потеряем стд. функционал по сборам и т.д. 3) А чем мысль с отчетом по разбивке сопоставленных накладных так плоха, если мы примем за аксиому, что платежи создаются только на основании сопоставления накладных. А предоплаты имеют заданные фин. аналитики? To: mnt_dx 1) Фин. аналитики - подразделение/центр затрат 2) Платеж создает не бухгалтер, а человек инициирующий данный платеж, например менеджер отдела снабжения, который выполняет оплату поставленных накладных. Бухгалтер-же, лишь выполняет проверку и разносит журнал после успешной оплаты с р/с. Кроме того, в рамках журнала платежей используется б/п утверждения, он выглядит так - Инициатор->Рук.проекта->Фин. директор->Бухгалтер 3) Основная цель - получить ответ на вопрос: сколько денег мы реально заплатили поставщикам в разрезе фин. аналитик, фактически в он-лайн. (Фин. аналитики здесь используются по той причине, что заказчик имеет проектно-ориентированную структуру, и для него крайне важно отслеживать как ДДС, так и ДДР по проектно) |
|