Расчет итогов в журналах ГК

[KiselevSA]

Только сейчас обратил внимание, что в строках журналов ГК итоги по дебету и кредиту для "русской" функциональности одинаковы. Неужели никто не задумывался, что при включенной корреспондеции счетов такой результат для коечного пользователя неудобен и странен?
(смотрел на DAX4.0 SP2)

[Logger]

Наверно я чего-то недопонимаю, но почему они должны отличаться ?

По идее всегда и должны совпадать. Валюта баланса чтобы не расходилась.
Иначе при разноске пошлет.

[ppson]

Цитата:

Сообщение от KiselevSA

Только сейчас обратил внимание, что в строках журналов ГК итоги по дебету и кредиту для "русской" функциональности одинаковы. Неужели никто не задумывался, что при включенной корреспондеции счетов такой результат для коечного пользователя неудобен и странен?
(смотрел на DAX4.0 SP2)

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

[KiselevSA]

Т.е. спокойно реагируем на то, что в колонке "Дебет" строки журнала указано значение, в кредите пусто, а в итогах одинаковые значения? Ну хотя бы тогда метки надо другие использовать. А разве в западной функциональности не может быть варианта, когда дебетовую часть вводит один сотрудник в одном журнале, а кредитовую другой в другом журале?

[Михаил Андреев]

Дебет или кредит относится к тому счёту, который слева. А корсчёта, что справа, может и не быть.

[MironovI]

Цитата:

Сообщение от KiselevSA

дебетовую часть вводит один сотрудник в одном журнале, а кредитовую другой в другом журале?

Вот это уже интересно, как вы себе это представляете?

[mazzy]

Цитата:

Сообщение от KiselevSA

А разве в западной функциональности не может быть варианта, когда дебетовую часть вводит один сотрудник в одном журнале, а кредитовую другой в другом журале?

Нет, не может быть.

[KiselevSA]

Цитата:

Сообщение от mazzy

Нет, не может быть.

А перевод из банка в кассу? Или тоже через транзитный счет прогоняют?

[Михаил Андреев]

Цитата:

Сообщение от KiselevSA

А перевод из банка в кассу? Или тоже через транзитный счет прогоняют?

В международной версии АХ вообще нет кассы. А перевод из банка в кассу можно просто в кассе и оформить, или через транзитный счёт. Не проблема

[mazzy]

Цитата:

Сообщение от KiselevSA

А перевод из банка в кассу? Или тоже через транзитный счет прогоняют?

ЕСЛИ за каждый расчетный счет отвечают разные люди
ИЛИ используется функционал выписки по счету
ТО через транзитный счет
ИНАЧЕ делают одну проводку Банк/Банк

Цитата:

Сообщение от Михаил Андреев

В международной версии АХ вообще нет кассы.

Ну, началось...
Есть там касса.
Ведется в модуле Bank, который должен переводится как Денежные средства, а не Банк.
просто создается запись, которая отвечает за наличные деньги.
И делается проводка Банк-Банк.

[KiselevSA]

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

А вот по "человечески" (интерфейс для конечного пользователя) расчет реализован в журнале ордеров (смотрим на ПКО и РКО)

Почему нельзя было сделать по-уму в остальных журналах )))

[ppson]

Простите KiselevSA, поясните что "нечеловеческого" в общем журнале ГК?

[KiselevSA]

Цитата:

Сообщение от ppson

Простите KiselevSA, поясните что "нечеловеческого" в общем журнале ГК?

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

[ppson]

Цитата:

Сообщение от KiselevSA

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

По моему вы немного перепутали теплое и мягкое
Попробую пояснить.
Бухгалтерские проводки в Аксапте вводяться по прицнипу двойной записи.
Как работает "аксаптовская двойная запись" можно посмотреть здесь
Корреспонденция счетов
или здесь
Что такое корреспонденция?

Общий журнал ГК, как и все прочие журналы, построенные на основе этого журнала, представляют собой всего лишь экранную форму для ввода операций (проводок) по прицнипу двойной записи.
Поэтому итоги по колонкам "дебет" и "кредит" сами по себе ничего не значат, важнее итог операций по журналу и итог сумм по дебетовым и кредитовым оборотам по всем счетам в журнале.
если итоги по дебетовым и кредитовым оборотам расходяться, значит нарушен прицнип двойной записи и журнал не будет разнесен.
Тот же ваше пояснение на примере кассового журнала можно "развалить", указав в строках журнала разные кассы.

Цитата:

Сообщение от KiselevSA

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

если я вас правильно понял то под словами "расходы и приходы по одному счету" вы подразумеваете "обороты по дебету и по кредиту одного счета".
Кнопка "Печать/Журнал", устанавите галку "итоги".

[KiselevSA]

Цитата:

Сообщение от ppson

По моему вы немного перепутали теплое и мягкое
Попробую пояснить.
Бухгалтерские проводки в Аксапте вводяться по прицнипу двойной записи.
Как работает "аксаптовская двойная запись" можно посмотреть здесь
Корреспонденция счетов
или здесь
Что такое корреспонденция?


если я вас правильно понял то под словами "расходы и приходы по одному счету" вы подразумеваете "обороты по дебету и по кредиту одного счета".
Кнопка "Печать/Журнал", устанавите галку "итоги".

Что такое корреспонденция - я знаю. И не на словах знаю, чем отличается подход аналитика на клиенте, от консультанта внешнего, который вместо того, чтобы сделать удобно, говорит: "Это сделано так потому-то, к этому надо привыкнуть". Это не камень в Ваш огород , это просто констатация факта. А в журнале ордеров подсчет работает независимо от счета кассы, просто по дебетовой и кредитовой части.

[mazzy]

Цитата:

Сообщение от KiselevSA

итерфейс с человеческим лицом должен рассчитывать итоги по колонкам дебита и кредита отдельно.

Вы ошибаетесь и даете ошибочное ТЗ.

Если указать корр.счет И не указывать счет, то итоги все равно будут рассчитаны правильно. Они будут рассчитаны не по колонкам!

Итак, поймите, что в конечном итоге
ПРОВОДКА - это набор ДВИЖЕНИЙ по счетам с одним номером ВАУЧЕРА.
ВАУЧЕР - это код проводки, код набора движений.
КАЖДОЕ движение - это запись в LedgerTrans.

Дебетовое или кредитовое движение определяется двумя признаками:
1. знаком суммы
2. признаком коррекция.

ЕСЛИ сумма > 0 И коррекция = Нет, ТО дебет
ЕСЛИ сумма < 0 И коррекция = Да, ТО дебет (сторно дебета)
ЕСЛИ сумма < 0 И коррекция = Нет, ТО кредит
ЕСЛИ сумма > 0 И коррекция = Да, ТО кредит (сторно кредита)

Так получается в конечном итоге.

Но журнал дает дополнительный сервис.
Во-первых, если проводка состоит только из двух движений И у движений одинаковая аналитика И у движений одинаковая валюта И у движений разные счета И движения не являются одновременно накладными, то такую проводку можно записать в одной строке в журнале (указав корр.счет)

Во-вторых, в журнале можно указать минус дебет или минус кредит. Так вводится сторно в Аксапте.

Который раз повторяю:
корр.счет - это не основной инструмент.
Корр.счет - это всего лишь дополнительный инструмент для удоства в некоторых случаях.

Основной способ ввода данных - многострочная проводка, которая состоит из нескольких движений.

Итоги так и работают. Итоги в основном нужны для основного многострочных проводок.


=================
Дополнительно: здесь прозвучал термин "Сложная проводка". Этот термин пришел из 1С. Сложная проводка по терминологии 1С - это либо (один дебет и много кредитов), либо (один кредит и много дебетов).

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

[KiselevSA]

Закрываем тему - это спор глухого со слепым. Прежде чем описывать мне идеологию системы, которую подробно до вас описал в своей статье, по-моему, Денис, вы поитересуйтесь у конечных пользователей в России, еще не знакомых с Аксаптой: "Как вы думаете, что выводится в полях итогов? Что бы вы хотели бы видеть в данных полях?"

[mazzy]

Спасибо Денису.
Как плохо, что я повторился

Цитата:

Сообщение от KiselevSA

вы поитересуйтесь у конечных пользователей в России, еще не знакомых с Аксаптой:

Конечные пользователи, не знакомые с Аксаптой?
А где вы таких видели?

Конечные пользователи хотят в основном то, что пообещают им консультанты.
Если консультанты обещали какую-то фигню, которой никогда там не было...
Что вам обещали консультанты в этих итогах?

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

[mazzy]

Цитата:

Сообщение от KiselevSA

Закрываем тему - это спор глухого со слепым

еду. думаю...
может быть вам еще не рассказали про автоотчет? попробуйте.

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

[mazzy]

теперь отвечу на первоначальный вопрос

Цитата:

Сообщение от KiselevSA

Только сейчас обратил внимание, что в строках журналов ГК итоги по дебету и кредиту для "русской" функциональности одинаковы. Неужели никто не задумывался, что при включенной корреспондеции счетов такой результат для коечного пользователя неудобен и странен?
(смотрел на DAX4.0 SP2)

задумывались конечно.
нет, не странен и удобен, если:
1. консультант объяснит что это функционал для многострочных проводок и корреспонденция тут ни при чем
2. если непутевый "консультант" таки заставил программиста "победить" функциональность многострочных проводок и пользователи вынуждены рабоать только с однострочными, то консультант ДОЛЖЕН спрятать итоги.
3. если пользователь хочет простого суммирования строк в форме, то консультант ДОЛЖЕН расск
зать об автоотчетах вместо того, чтобы звать программиста

тогда пользователю будет и понятно, и удобно.