Немного об архитектуре разноски в ГК и проблеме корреспонденции счетов

[mazzy]

Автор статьи: Денис Федотенко (fed)
Спасибо ему сказать можно по этой ссылке http://axforum.info/forums/reputation.php?p=147198

Добавить комментарий
Disclaimer

В качестве некоторой преамбулы: В этой статье я время от времени буду рассказывать о некоторых чисто финансовых концепциях. Тем не менее, хочу заранее уточнить что я никогда не получал формального образования в области финансов, а самостоятельно учился финансам по переводным книжкам из ООНовсковской серии по финансовому учету и рассказам своих коллег-консультантов с финансовым бэкграундом. Поэтому, вполне вероятно, что часть используемой мною терминологии будет не привычна для людей с классическим российским финансово/бухгалтерским образованием. Тем не менее – я надеюсь , что по сути я не написал ничего принципиально неправильного. Cтатья рассчитана на архитекторов решения, которым важно понимать, как в Dynamics AX сделана работа с ГК, а не вообще как устроен российский и западный учет в абстрактной бухгалтерии.
Зачем вообще нужна разноска в ГК?

Сразу хочу сказать, что разноска в ГК с точки зрения DAX, является некоторым финальным результатом проведения операции. Данные из ГК почти нигде (за исключением собственно финансовой отчетности типа баланса /”отчета о прибылях и убытках” или распределения затрат) не используются системой как некоторые входные данные, на основании которых выполняются дальнейшие операции. Пишу об этом потому, что я регулярно сталкивался с ситуацией, когда не очень опытные консультанты (особенно – пришедшие с 1c 7ой версии) писали в ТЗ что-то типа “Для расчета суммы проводимой системой со счета НДС входящего на счет НДС оплаченного, надо сосчитать обороты по счету 19.xx по документу ГК, связанному с данной накладной и умножить его на процент сопоставления”. Так вот, идеология Dynamics AX предполагает, что все суммы, необходимые для операций системы, должны хранится не в таблице проводок в ГК, а в каких-то других таблицах - таблице регистров (типа проводок по поставщику, клиенту, налоговых или складских проводок), или в таблицах результирующих документов (накладных, отборочных накладных, письмах-напоминаниях и т.п.). В нашем примере – данные можно взять из таблицы налоговых проводок. Если вы пользуетесь стандартной функциональностью, то с большой вероятностью любую сумму, нужную вам для дальнейших операций с документом вы сможете найти среди полей тех таблиц, о которых я написал чуть выше. Даже если вы каким-то образом дорабатываете функциональность, то в той ситуации, при которой вам не хватило данных для дальнейшего расчета в этих таблицах, следует попытаться дополнить эти таблицы новыми полями и написать алгоритм их заполнения, а не пытаться собрать данные по ГК. Допустим,...

Подробнее...
http://www.ms-dynamics.ru/blog/2007/...encii-schetov/

[mazzy]

Вах!

Нахожусь в процессе чтения, но уже абсолютно убежден, что это Шедевр!
Денис, появись в этой ветке. Дай тебе спасибо сказать и респект поставить.

[oip]

Спасибо огромное! Читаю не отрываясь!

[mazzy]

Цитата:

В 3ей версии эта таблица называлась в российской локализации “Бухгалтерские проводки”, что с точки зрения российского бухгалтера не очень корректно. В 4ой версии, ее переименовали в “Операции ГК”, что в целом гораздо корректней, но чересчур громоздко. Я буду эту таблицу и вообще эти половинки проводок называть “постингами”

Это движения. Движения! ДВИЖЕНИЯ!
Английский термин movements.
Есть финансовые движения (Leger Movements), есть складские движения (InventMovements).

В свое время несколько дней было потрачено только на этот термин.
Переводчики категорически упирались и не хотели переводить Movements как движения, поскольку термин "движение" уже используется для Transfer. А изменить transfer... В общем, это была локальная Бородинская битва, в которой мы не смогли победить.

Денис, не "постинги", не "полупроводки", не еще как-то...
Это движения по счетам.
Из нескольких движений с одинаковым кодом ваучера состоит ПРОВОДКА.
Из нескольких проводок состоят Операции.
Движения по регистрам - операции, движения по главной книге - проводки.

Обрати внимание, не "номер ваучера", а "код ваучера". Так и короче, и привычней.

История появления термина "Операция ГК" - отдельная песня.
Дело в том, что в Аксапте Voucher используется как для обозначения КОДА операции, так и для самой операции. Эх...

С твоими оценками перевода - полностью согласен. Согласен с тем, что лучше. Согласен и с тем, что еще далеко не идеал.
Полностью сделать так, как хотелось - не удалось в этот раз. К сожалению.

[fed]

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

[glibs]

Цитата:

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

...
это Шедевр
...

Однозначно!

Аж слов нет. Хоть я и понял, что про классы LedgerViucher я не так уж мало и знаю, все равно было интересно прочитать систематизированное их описание. Про корреспонденцию прочитал с удовольствием, хотя тоже пришлось поиметь ... с ее багами. Но чтобы вот так вот правду взять написать про большую часть армии консультантов по Аксапте (что можно наблюдать в начале статьи)... да еще и так абсолютно точно... очень понравилось.

Небольшие дополнения.

Дата подтверждения (AcknowledgementDate) — я не смотрел в Аксапту по этому поводу, но похоже на дату валютирования. Такой термин существует у нас, но только в банковском бухгалтерском учете.

Когда речь идет о российском понимании чего-либо в бухгалтерском учете, то речь идет преимущественно о бухучете на предприятиях торговли, производства, сферы услуг, сельского хозяйства, бюджетных организаций, и, наверняка некоторых других. В финансово-кредитных учреждениях (банках), например, бухучет уже гораздо меньше подвергся стереотипам, которые навязаны работающими с 1С бухгалтерами. Насколько я помню, я сталкивался с системами отечественного производства, в которых поддерживались многострочные проводки.

Так что не стоит так абсолютизировать и обосабливать "наш" подход к учету. В нем есть доля засилия стереотипов.

[fed]

to mazzy: В принципе - термин постинг мне тоже не нравится. Я его использовал как чисто технический и локальный для данной статьи. Он кривенький, но по крайней мере никаких лишних ассоциаций для русскоязычной аудитории не несет.
to glibs: Ну я скорее не столько армию консультантов имел в виду, сколько общий уровень управленческих технологий в отечественном бизнесе. Как раз среди внедренцев Аксапты я видел немало людей с хорошим бухгалтерским бэкграундом, которые бы вполне могли учетную политику приличную выработать для клиента. Просто зачастую проблема в том, что у клиента просто нету людей, которым можно бы было продать идею разработки учетной политики. Бухгалтерам для налоговой сложная учетная политика не нужна; А финансисты после выпуска из института немедленно забыли все чему их учили и начали свой собственный учет изобретать - какой-то вариант учета темных веков - еще до изобретения двойной записи.

[blokva]

Цитата:

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

Это движения. Движения! ДВИЖЕНИЯ!
Английский термин movements.
Есть финансовые движения (Leger Movements), есть складские движения (InventMovements).

В свое время несколько дней было потрачено только на этот термин.
Переводчики категорически упирались и не хотели переводить Movements как движения, поскольку термин "движение" уже используется для Transfer. А изменить transfer... В общем, это была локальная Бородинская битва, в которой мы не смогли победить.
...

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

[mazzy]

Цитата:

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

Он кривенький, но по крайней мере никаких лишних ассоциаций для русскоязычной аудитории не несет.

Это точно. Я понимаю.

Цитата:

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

Мне больше нравиЦЦа термин "поток" "финансовый поток" и "материальный поток" и одна строка - "элемнт потока", например. А если понять что эти 2 потока всегда = но противополжны по направлению, то возникает достаточно глубогое понимание происходящих реальных процессов.

Их может быть больше, чем 2
Термин "поток" - хороший термин.
Есть только одно "но" - есть складские movements. Лично для меня термин "складскиой поток" звучит слишком авангардно.

[Raven Melancholic]

Отличная статья. Оказалось, что я не так уж мало знаю о разноске
Отдельное спасибо за экскурсы, объясняющие откуда пошли те или иные механизмы (сам работаю начиная с 3.0 SP2).
Небольшое замечание: все таки функционал открывающего и закрывающего периодов используются и в российской функциональности. Мы проводим в этих периодах "безвременья" реформацию баланса, когда нужно, например, схлопнуть 90 счет или остатки в разрезе аналитик и т.п.).

[blokva]

Цитата:

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

Их может быть больше, чем 2
Термин "поток" - хороший термин.
Есть только одно "но" - есть складские movements. Лично для меня термин "складскиой поток" звучит слишком авангардно.

A "складскиой поток" = "материальный поток", если честно, то да их может быть больше, но в самам общем случае их только 3, все остальные, могут быть только производными или комбинациями, например "поток ресурсов".

[KiselevSA]

Автору спасибо за интересную статью. Для удобства последующего использования преобразовал ее в Word и убрал многочисленные тире (ну не любят у нас возиться со знаками препинания). В одном месте класс SalesFormLetter_Invoice обозначен как SalesForm_letterInvoice.

[Gustav]

Цитата:

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

Автору спасибо за интересную статью. Для удобства последующего использования преобразовал ее в Word...

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

А вот по поводу второго задумался: А почему, собственно, автору самому не положить сюда вордовый документ? Ведь получается нелепая цепочка. Статья наверняка изначально пишется в Ворде, потом она выкладывается "туда" (не "к нам") в формате, заведомо более бедном, нежели Ворд. Потом ее обнаруживает робот, тащит сюда два первых абзаца (еще более глумясь над форматом, но хоть ссылка "туда" появляется - и то хорошо). Далее mazzy издает указ: Читать всем! И мы ждём появления fed'а, чтобы отрепутировать его короткое сообщение типа "Ну в общем - комментарии принимаются." и сообщение с таким содержанием становится хитом месяца (и даже квартала - это к вопросу о репутации не людей, но сообщений )

По-моему, куда более "лепо" вложить в пост здесь вордовую доку и тогда именно она будет заслуженно и логично отрепутирована. И, кстати, попадет в офф-лайн версию! И Киселеву, и мне, и всем не придется заниматься самостоятельным вордовым он%*№змом. Ммм... а так получается, что репутируется нефорумный контент, что тоже своего рода нелепость (не хочу показаться язвой, но в этом случае, тогда уж стоит "обласкать", например, и mfp сотоварищи за "Inside DAX 4.0" - почему нет?)

Денис, что думаешь по этому поводу? Можно в будущем рассчитывать на твой вордовый документ, что называется, из первых рук?

P.S. Кстати, вопрос уже робко поднимался мною еще в первом хите Denis Fedotenko: Себестоимость и закрытие склада

[fed]

Статья конечно и в самом деле готовится в ворде, поэтому и форматирование странненькое получается. Просто после того как статья выкладывается, я перестаю вордовый документ обновлять и правлю только текст в блоге. Кстати уже сейчас есть проблема, связанная с тем что angl иногда из моего блога тексты выкладывает как отдельные статьи - в отрыве от блога. И после изменения текста в блоге - мне приходится ему письмо писать чтобы он не забыл правленный текст в статью переложить. Вряд ли я смогу обновлять еще и вордовый файл, приложеный к моему постингу здесь.

[Alex_K]

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

[fed]

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

[Alex_K]

Ну тогда вот...

[Maximin]

Полезное обновление описания по механизму ГК и корреспонденции со времен описания её камрадом Ivan Mischenko для 2.5. Несколько глубже и подробнее.
Впрочем, в 3.0 изменилось не так многое и это уже обсуждалось как-то....
Автору респект!

[Alex_R2]

Спасибо за материал. Давно интересовал вопрос, да не было повода его задать. Кто нибудь при внедрении Ах. занимался написанием учетной политики для клинета ?

[komar]

Заниматься написанием учетной политики лучше все-таки профессионалам в этой области. Хотя знание того, что такое ERP, и в частности Axapta, конечно, не помешает...

To fed: Что касается легенды о ваучерах - попробую выдвинуть более правдоподобную гипотезу. Давно замечал, что во многих системах английское название того, что на русский переводят как "журнал" - batch. Посему предполагаю, что принципы организации документов "пакет-документ" с уникальными номерами родилась в эпоху начала компьютерной обработки (а не докомпьютерной), а именно - пакетная обработка (в данном случае ввод) документов. Поясню на примере (компании, имеющие дело с большим количеством первички, например с квитанциями об оплате коммунальных платежей, иногда и по сей день пользуются таким способом ввода данных):

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