sp5. Возможность получить Корр.счет ГК попроводкам клиента/поставщика без извращений

[studentLPC]

sp5.
Правильно ли я понимаю:
Нельзя получить стандартными способами список проводок по клиенту. А именно вытащить счет ГК , корр счет ГК в разрезе клиента, причем, чтобы счет ГК был именно счет клиента. Стандартая ОСВ по клиентам формируется по данным из CustTrans, где естественно ничего не сказано о счетах ГК. Да в отчете можно выбрать счет ГК, но это счет из настроек разноски, и если его поменять в настройках, то формирование отчета уже будет не корректым, как впрочем и если был бы аванс. Можно увидеть проводки, собранные по клиентам в разнообразных отчетах, но эта информация не так уж и полезна, так как туда входят проводки по НДС, не имеющие отношения к клиенту, а так же без анализа нельзя сказать, где счет клиента, а где Корр. счет.
Посавщики симметрично.

[mazzy]

стандартными - нельзя.

Ибо счет ГК - это финансы, а клиенты - расчеты с клиентами.
Предполагается что работают с этой информацией разные люди в разных разрезах.

Если программированием, то надо сделать запрос по двум таблицам LedgerTrans и CustTrans связав их через ваучер. В LedgerTrans надо дополнительно сделать фильтр по типу разноски.

Насчет "не так уж и полезных" отчетов с проводками по НДС.
Можно подробнее? Не очень понял.

[studentLPC]

Все дело в том, что просто по ваучеру нельзя связать LedgerTrans и CustTrans. Если так сделать, то в выборку будут попадать проводки с данным ваучером и никак не связанные с клиентом (разноска заказа с налогами. Возникают проводки по НДС, а они с клиентом не связаны), а так же проводки (клиент - клиент), в которых вообще не понятно кому в кредит, а кому в дебет. Я вижу один выход: анализировать знак суммы в CustTrans и тогда уже определять, что в кредит, а что в дебет. Но еще одна прблемма в том, что в CustTrans храняться сводные проводки, так что в LedgerTrans придется еще и суммировать. Типа разноски в LedgerTrans я что-то не заметил.

[studentLPC]

Цитата:

Изначально опубликовано mazzy

Насчет "не так уж и полезных" отчетов с проводками по НДС.
Можно подробнее? Не очень понял.

Не так уж полезных при анализе проводок по клиенту.

[mazzy]

Цитата:

Изначально опубликовано studentLPC
Все дело в том, что просто по ваучеру нельзя связать LedgerTrans и CustTrans. Если так сделать, то в выборку будут попадать проводки с данным ваучером и никак не связанные с клиентом ...

Погоди, не кипятись.

В проводках по главной книге есть поле "Тип разноски"
В проводках по клиенту есть поле "Тип операции"
Почему тебе этих полей недостаточно, чтобы однозначно определить что это за проводка?

Кроме того, в клиентах есть поле Разноска. Разноска вообще очень информативное поле должно быть. И информация в нем должна быть не бухгалтерская, а смысловая.

[Елена Сысовская]

Какой отчет вы хотите получить?
Вообще мы опирались на таблицы накладных и проводок главной книги - они связываются по лоту.
Может быть, в ОСВ, если включить разделение по счетам, полуиться необходимый отчет.
Я могу выслать класс, который позволяет для проводки выдернуть информацию их источника.
В главной книге есть отчет "происхождение проводок", который показывает тоже информацию по источникам в разрезе проводок.
И главное, зачем его получать?
Если это надо управленцам, то привязка к главной книге не нужна.
Если для выгрузки данных в бухгалетрию - все равно писать программу.
На наших предприятия часто бухгалтерия выполняет роль менеджеров по работе с клиентами, сверяя расчеты, опирается на 60, 62, 76. Но это - дисфункция учетного отдела.
В Аксапта, вроде, все логично. Просто она расчитана на то, что главная книга - регистратор проводок, а не аналитический инструмент.
Выверку главной книги с источниками можно сделать специальным отчетом "выверка..."

[studentLPC]

to mazzy:
Действительно, тип разноски в таблице Главной книги решает все проблемы. Странно, что я на него раньше не обращал должного внимания. Спасибо.

to Елена:
Необходим отчет для анализа движений по клиентам. В том числе и для сверки взаиморасчетов.
А бухгалтерия действительно выполняет роль менеджеров, потому что менеджеров нет. Согласен, что это дисфункция, но имзменить это, а еще и в лучшую сторону мне не представляется возможным.
Поэтому Главная книга в данном случае выполняет роль не только регистратора проводок, но и аналитического инструмента.
Спасибо за ответ.

[fed]

Имей в виду:
При выполнении сопоставления, у тебя может рождаться несколько (максимум 5 штук) проводок в CustTrans и соответственно до 4 проводок в LedgerTrans. При этом однозначно установить соответствие между custTrans и LedgerTrans тебе даже разноска в LedgerTrans не поможет, поскольку 5 записей в ledgerTrans будут иметь тип LedgerPostingType::custBalance.
Так что на мой взгляд - в общем случае эта задача не решаема.

[komar]

Если бухгалтерия выполняет функции менеджеров, то логично, что финансовая аналитика должна выполнять роль справочника контрагентов
Попробуй автоматически писать контрагентов в аналитику, и анализируй по счетам ГК и аналитическим измерениям.

[Елена Сысовская]

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

[komar]

Текст - это здорово, да только отчеты работают по счетам да аналитикам.

[mad_pilot]

Согласен, в раше почти всегда делают контрагента одной из аналитик.
Беда только, в Ax их всего 3 по умолчанию...........

Даже меню на батон повесили - "создание аналитики"

P.S
теперь я понял, почему в 1С им было так удобно.........

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

Вот почему у них функции фин. менеджера и бухгалтера разделены!

[studentLPC]

Цитата:

Изначально опубликовано komar
Если бухгалтерия выполняет функции менеджеров, то логично, что финансовая аналитика должна выполнять роль справочника контрагентов
Попробуй автоматически писать контрагентов в аналитику, и анализируй по счетам ГК и аналитическим измерениям.

Такими методами и 10 аналитик будет мало.

Цитата:

Изначально опубликовано fed
Имей в виду:
При выполнении сопоставления, у тебя может рождаться несколько (максимум 5 штук) проводок в CustTrans и соответственно до 4 проводок в LedgerTrans. При этом однозначно установить соответствие между custTrans и LedgerTrans тебе даже разноска в LedgerTrans не поможет, поскольку 5 записей в ledgerTrans будут иметь тип LedgerPostingType::custBalance.
Так что на мой взгляд - в общем случае эта задача не решаема.

Пока проблемы я не вижу. Просто надо грамотно обрабатывать каждый тип разноски в LedgerTrans.

[Елена Сысовская]

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

[studentLPC]

Очень интересный вариант. Вот только все аналитики уже распределены "на год вперед". Да и хочется использовать существующую функциональность Поставщики/клиенты.

[Елена Сысовская]

Извините за назойливость, но нельзя ли уточнить, какую именно аналитику вы используете на счетах расчетов с контрагентами и НДС (60, 62, 76) при выполнении операций закупок, продаж и оплат? Что-то не могу придумать ничего походящего, а так, чтобы целвх три аналитики... я же говорю - не заполняя справочник.

[studentLPC]

1. Вид деятельности
2. Налоговый период
3. подразделение

[Елена Сысовская]

Да, нормально! Спасибо за ответ.

[komar]

Цитата:

Изначально опубликовано studentLPC
1. Вид деятельности
2. Налоговый период
3. подразделение

Налоговый ПЕРИОД?

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

[mazzy]

Не.
не надо так делать.
Так теряется нормализация базы данных.
Что чревато кучей гемора при построении отчетов.

Конечно есть исключения.
Но в общем случае это слишком дорогой путь - дешевле просто купить новую аналитику.