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

[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 сделали реверсирование для ОСов (правда буржуйских). Значит все-таки могут постепенно делать.

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

[Flomik]

Цитата:

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

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

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

Будут делать и многострочные, если надо! Но вот, как быть с многострочной проводкой по Клиенту, ведь она недопустима в Системе (см. LedgerJournalTransUpdateCust\checkVoucher)?

[mazzy]

Цитата:

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

Но вот, как быть с многострочной проводкой по Клиенту, ведь она недопустима в Системе (см. LedgerJournalTransUpdateCust\checkVoucher)?

Допустима. В общем журнале.
Повторюсь:

Цитата:

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

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

Добавлю только, что журналы платежей и журналы перенесенных оплат (правильнее было бы сказать: журналы перенесенных в клиент-банк оплат)...
...Так вот, эти журналы очень, очень сильно адаптированы под работу с клиент-банком.

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

...В ходе локализации эти журналы стали образцом для подражания (к сожалению).

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

[glibs]

Цитата:

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

...
Допустима. В общем журнале.
...

Да, но только в версии 2.5 и 3.0. С 4.0 запретили. Не локализаторы.

Проблему можно пытаться решить через транзитный счет ГК.

[mazzy]

Цитата:

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

Да, но только в версии 2.5 и 3.0. С 4.0 запретили. Не локализаторы.

Можешь подробнее?

привел два скриншота, на которых видно, что можно (ничего не запретили).
первый из русской аксапты 2009, второй - из буржуйской.

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




еще один со скриншотом многострочной проводки - два клиента, один банк (приняты платежи от клиентов).

[_scorp_]

2 glibs: Может быть я что-то не так понимаю, но вроде ничего не запретили


upd: опередили ))

[Raven Melancholic]

Цитата:

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

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

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

[BOAL]

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

[pitersky]

Цитата:

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

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

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

[Raven Melancholic]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

Я тоже раньше так думал, что бухов не перевоспитать.
....
Опять же, не скажу, что это было просто - сил потратили что мы, что руководство немерено. Но результата добились.

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

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

[Raven Melancholic]

Цитата:

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

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

Не спорю, хотя это уже выходит за рамки вопроса автора топика.
Вообще, взаимоотношения внедренцев и пользователей это очень большая тема, которая не раз обсуждалась, но к единому мнению ни разу не пришли. Живем с надеждой на лучшее, а в чем это лучшее можем узнать только на собственной шкуре.