Счет и корр. счет не могут быть одинаковыми?

[Flomik]

В MSBS Axapta 4.0 из 1С: Бухгалтерия транслируем проводки в строки журнала ГК (Дт Подотчетное лицо Кт Подотчетное лицо). Причем, при программном создании строк журнала, Система не выдает предупреждение – «Счет и корр. счет не могут быть одинаковыми», и разносит сроки журнала.

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

• Чем обусловлен данный блок (запрет на одинаковый счет и корр. счет в одной строке)?
• Чем грозит игнор данного блока?

Спасибо!

[sukhanchik]

Цитата:

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

• Чем обусловлен данный блок (запрет на одинаковый счет и корр. счет в одной строке)?
• Чем грозит игнор данного блока?

1. Такая проводка не имеет под собой никакого экономического смысла. Если в 1С такая проводка существует - то, видимо, счет и корр. счет все-таки чем-то отличаются (например значениями субконто - переброска денег между людьми).
В АХ предполагается, что учет ведется не по бух счетам, а по сущностям - клиент, поставщик, сотрудник. Поэтому проводка Д71К71 абсурдна, а ДПупкин-КИванов вполне обоснованна.
2. Ничем. Просто если счет и корсчет ПОЛНОСТЬЮ одинаковы - то и результата не будет.
А если они хотя бы чем-то будут отличаться и Вы сможете эти отличия собрать в отчет (например, добавив финаналитику при корсчете и делать проводки между финаналитиками).

[Flomik]

Счет и Корр. счет отличаются, например, договорами, или профилями разноски, аналитиками.

[sukhanchik]

Цитата:

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

Счет и Корр. счет отличаются, например, договорами, или профилями разноски, аналитиками.

Вооот... Тогда нужно влезать в код и разрешать делать переброски по договорам, профилям разноски или аналитикам.
И можно не бояться.

Запрет же обусловлен следующими факторами:
1. Договора - российская функциональность и при локализации не возникло потребности разрешать переброску между договорами. А у буржуев этой проблемы изначально нет.
2. Аналитик в корсчете штатно нет, а значит и нет проверки на то, что они различаются при разноске.
3. При переброске по профилям разноски получается "нулевая" проводка по сущности - возможно поэтому буржуи запретили ее. Но ничего не мешает снять это ограничение.

[Raven Melancholic]

Транслируйте такие проводки не одной строкой (счет и коррсчет), а двумя без указания корсчета. Если номера операций ГК формируете сами, то дайте этим двум операциям один и тот же номер.

[BOAL]

Уже давно и регулярно (в каждой версии АХ) делаем тюнинг, разрешающий нужные проводки по утвержденным типовым проводкам учета.

Запрет в системе "разрешается" и все нормально работает, без связывания рук и лишней кучи операций.
Например, переброска между договорами клиента или аналитиками учета и т.п.
Можно делать и в две строки, через промежуточный счет.

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

[mazzy]

Цитата:

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

Счет и Корр. счет отличаются, например, договорами, или профилями разноски, аналитиками.

Цитата:

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

Вооот... Тогда нужно влезать в код и разрешать делать переброски по договорам, профилям разноски или аналитикам.

Не нужно влезать в код.

Цитата:

Сообщение от Raven Melancholic

Транслируйте такие проводки не одной строкой (счет и коррсчет), а двумя без указания корсчета.

Именно так - делайте многострочную проводку.
Читайте ФАК. читайте форум. Неоднократно задавался вопрос и давались ответы.

Заодно почитайте плюсы и минусы многострочных и однострочных проводок.

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

Цитата:

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

Уже давно и регулярно (в каждой версии АХ) делаем тюнинг, разрешающий нужные проводки по утвержденным типовым проводкам учета.

Блин....

[mazzy]

Цитата:

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

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

Просто локализаторы уроды. И делали "как в 1С".
Вместо того, чтобы делать "как в Аксапте".
В Аксапте родной формой записи является "многострочная проводка".

У буржуев проблем нет, поскольку они всегда могут воспользоваться этой формой записи. Нет профиля у кор.счета? делаем многострочную проводку и указываем разные профили. Нет аналитик у кор.счета? Делаем многострочную проводку и указываем.... Нет * у кор.счета? Делаем многострочную проводку и...

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

А локализаторы во многих местах запретили использование многострочных проводок. Зла не хватает...

[ikopyl]

Пока у нас будут стандарты учета РСБУ, а не МСФО, пока форма превалирует над содержанием - бухгалтеров и палкой не заставишь делать такую запись. имхо. Только когда совсем не вмоготу станет - запишут, плюясь, что заставили делать две записи, а не одну.
"Разруха - она в головах". (Собачье сердце)

[mazzy]

Цитата:

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

бухгалтеров и палкой не заставишь делать такую запись.

Скажите, что "это как сложные проводки в 1С". Только больше. Там нельзя делать несколько дебетов и несколько кредитов. А здесь можно.

И будут делать

Цитата:

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

"Разруха - она в головах". (Собачье сердце)

Ап-солютно согласен.

[ikopyl]

Обычно получается убедить). Проблема не в этом. Зачастую проблема в самом подходе бухгалтеров к учету, в нежелании смотреть шире на свою работу.
Давно довелось принимать на работу бухгалтеров (обновлять коллектив). На собеседовании часто на вопрос: "Какой участок вели?" следовал ответ: "Веду 10-й (20-й, 70-й, 71-й и т.п.) счет". Уточняю: "Ведёте учет ТМЦ?" - "Нет, 10-й счет!" Ей всё равно, какой поставщик, какой договор, какой субсчет расчетов с поставщиком, не говоря уже о какой-то дополнительной аналитике, хотя накладные в системе регистрирует она, а, следовательно, и кредитовую часть проводки - тоже она.
Дальше: "А как же потом расчеты с поставщиками ведёте?" - "60-й? Это не я. Это Марь Иванна, она потом, когда платит через банк, если надо договор менять, то накладую перепроводит".
Занавес. Новые действующие лица. В пьесе 10 актов, 9 из них - это вот такие одинаковые диалоги.

А в итоге получается, что если "не 1С", то приходится потом делать проводку между одним и тем же счетом ГК с разными аналитиками (потому что перепровести исходный документ нельзя). Кто-то убеждает разработчика сделать "для Марь Иванны" чтобы было удобно, а то как же, человек так каждый день мучается, меняя договора или подразделения в проводках...
Если такие ситуации возникают настолько часто, что необходимо привлекать разработчика для исправления ситуации, то, мне кажется, нужно посмотреть, что же там делает человек, который регистрирует эти операции в системе. И если всё делает правильно, в соответствии с учетной политикой (или в соответствии с утверждённым процессом), значит, где-то что-то не правильно в самих процессах, есть какой-то разрыв, позволяющий допустить такую ошибку.

[Rezervforall]

Просто в ситуации, при которой данная модификация присутствует в более чем 50% процентах решений, надо просто определиться в чьих головах разруха.
Можно долго объяснять и перетирать (про двойные проводки и промежуточные счета), а можно накатить модифу и внедрить, запустить, продать и т.п. Кому как нравится.

Как показывает практика первый вариант живет не долго.
А раз это так - то он и неверен.
Все остальное - лирика.

[mazzy]

Цитата:

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

Просто в ситуации, при которой данная модификация присутствует в более чем 50% процентах решений, надо просто определиться в чьих головах разруха.

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

Прежде всего локализаторам нужно победить разруху в своих головах: либо везде однострочные, либо везде можно использовать многострочные.

Цитата:

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

Можно долго объяснять и перетирать (про двойные проводки и промежуточные счета), а можно накатить модифу и внедрить, запустить, продать и т.п. Кому как нравится.

Угу. Только модифа не работает со всеми случаями (как и модифа удаления проведенных операций).
Наверняка договоры и аналитику сделали в вашей модифе
Наверняка не сделали разные профили разноски в однострочных проводках.
Наверняка не сделали разные ОС и их параметры...
Наверняка не сделали разные параметры проектов...
Наверняка не сделали разные параметры интеркампани...
Наверняка не сделали ...

Я еще ни разу не видел нормальной модификации, которая бы нормально дублировала любые параметры проводки.

Повторюсь: изначально однострочные проводки предназначались для очень ограниченного числа случаев, как инструмент оптимизации.
Вы предлагаете (вместе с локализаторами) этот ограниченный инструмент сделать основным в системе. Только вы осознайте сколько надо добавлять, чтобы частный инструмент стал основным.

Бухи и пользователи шугаются вовсе не потому что они такие глупые (я совершенно не согласен с ikopyl).
Бухи и пользователи шугаются из-за различия в подходах. В общем журнале многострочные проводки идут хорошо, а в кассовых журналах и журналах АО многострочные запрещены. Оприходовать несколько русских ОС в журнале полученных накладных можно только через жопу.

Я, например, понимаю зачем буржуи запретили многострчные проводки в журналах платежей - чтобы облегчить интеграцию с клиент-банком. Но я в упор не понимаю зачем ввели запрет на многострочные проводки в кассовых журналах, в журналах ОС. И особенно в журнале АО. Что уж говорить о людях, которые только начали работать с Аксаптой. Шугаются из-за этой нелогичности.

[sukhanchik]

Цитата:

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

Угу. Только модифа не работает со всеми случаями (как и модифа удаления проведенных операций).
Наверняка договоры и аналитику сделали в вашей модифе
Наверняка не сделали разные профили разноски в однострочных проводках.
Наверняка не сделали разные ОС и их параметры...
Наверняка не сделали разные параметры проектов...
Наверняка не сделали разные параметры интеркампани...
Наверняка не сделали ...

Я еще ни разу не видел нормальной модификации, которая бы нормально дублировала любые параметры проводки.

Вот оно - главное противоречие жизни. С т.з. Микрософта, как разработчика - то если делать, то делать надо хорошо (т.е. учитывать все случаи).
А с т.з. внедрений данная модифа не учитывает проекты, интеркампани, .... Но зато используется в ХХ% внедрения. Значит востребована. И от этого надо отталкиваться.
Возникает бизнес-потребность рекомендовать Микрософту пойти по правилу 20/80. Т.е. перенести наиболее часто требуемые модифы в функционал (при условии непротиворечия глобальной логике - типа удаления проведенных операций) - но реализовать их не для всех случаев.

Пример - в АХ 4.0 сделали реверсирование операций. Но не всех. В АХ 2009 сделали реверсирование для ОСов (правда буржуйских). Значит все-таки могут постепенно делать.

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

[mazzy]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

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

В общем - вечная тема для обсуждения .... Пора завязывать

[Raven Melancholic]

Цитата:

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

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

Не думаю, что проблема в бухах. Проблема в консультантах. Например у нас удалось объяснить что записи в журналах ГК должны делаться зависимости от ситуации. В простых случаях - делаем двухстороннюю запись, в сложных - думаем что делать и, возможно, делаем несколько односторонних. Не скажу, что это было просто, но результата добились.

[BOAL]

Бухам в АХ думать вредно над чего чем и как делать, или это уже крутые бухи - фин аналитики.
У нас типовые проводки и инструкции, чего чем - если лезет новая операция, то спрашивают нас.
Иначе кончается самоуправством по пути наименьшего сопротивления, например, курсовые разницы начинают корректировать или делать в ЖГК ручками.

[pitersky]

Цитата:

Сообщение от Raven Melancholic

Не думаю, что проблема в бухах. Проблема в консультантах.

Я бы сказал, что проблема и в тех, и в других
Бухи, как правило, мыслят чётко в категориях 1С и за их пределы не хотят выходить принципиально (причём исключительно по привычке. без логических обоснований). А консультанты зачастую вместо разъяснительной работы идут по простому пути - требуют, чтобы разработчики взяли в руки напильник и сделали из Аксапты 1С

[Raven Melancholic]

Цитата:

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

Бухи, как правило, мыслят чётко в категориях 1С и за их пределы не хотят выходить принципиально

Я тоже раньше так думал, что бухов не перевоспитать. У нас раньше было четкое разделение: финотдел работал в Аксе, бухи в 1С. Сейчас идет процесс возложения работе по отражению текущей информации в Аксе бухами. Первое время были большие проблемы, связанны с привычкой работы в 1С и привычкой работы "исторически" (то есть, прошлым месяцем, а то и кварталом).
Ничего, бухи научились осознанию того, что от того, что они внесли, зависят решения топов, что информацию нужно вносить по мере поступления, а не в конце перида. Пока не получилось доказать, что факт операции выше, чем его документальное подтверждение, но надеемся, что дойдем и до этого.
Опять же, не скажу, что это было просто - сил потратили что мы, что руководство немерено. Но результата добились.