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

[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

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

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

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

[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: опередили ))