Перемещение ОС!!

[MEGA]

Всем добрый день (вечер)!

Подскажите, как в системе отразить перемещение ОС так, чтобы это отразилось на счетах 01 сч. в разрезе аналитики Отдел (пермещение между отделами) ?

Заранее спасибо

[glibs]

Поменять фин. аналитику в карточке, и сделать в журнале ГК проводку на величину остаточной стоимости?

[MEGA]

Спасибо.

А других вариантов нет? На самом деле перемещая ОС между Отделами, необходимо еще и акты на перемещение иметь возможность формировать....

Это что такой бедный функционал модуля?

[glibs]

В первом посте вы спрашивали про бух. проводки и (?) фин. аналитики.

Посмотрите документацию по ОС по операции перемещения. Унифицированная форма № ОС-2 вас устроит?

[TasmanianDevil]

Цитата:

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

Спасибо.

А других вариантов нет? На самом деле перемещая ОС между Отделами, необходимо еще и акты на перемещение иметь возможность формировать....

Это что такой бедный функционал модуля?

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

Функционал не бедный, это просто типичный самопал (жаль, неизвестно имя героя из нашего MBS, родившего это чудо). При разборе многих частей этого модуля говорить будете много всякого и долго. Не Вы первый, не Вы последний... И не только в модуле ОС с этим столкнетесь, но и в любом другом самопальном от местного MBS. Системного подхода ноль, ошибки имеют место быть, про какие-то оптимизации и речи нет.

P.S. Верно mazzy подметил - "относитесь с большим подозрением ко всему в Аксапте с префиксом 'R' и суффиксом '_RU'"
P.P.S. Прошу простить за некую излишнюю резкость, крови этот модуль попил немеряно ...

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

Поддерживаю TasmanianDevil.
Внедрял данное чудо.
Что касается разработки новой операции, то не факт, что её необходимо делать. Для чего нужно при перемещении изменять аналитику на 01 счету по ОС? Для отчётов? Каких? Не проще воспользоваться отчётами на базе модуля ОС, а не пытаться править финансовые аналитики?

[glibs]

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

Насчет отчетов в модуле... тоже дело вкуса. Я предпочитаю фин. отчетность строить по проводкам ГК и аналитикам.

[СибирскийКлещ]

Цитата:

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

Операцию я бы писать не стал, тем более что она уже есть в модуле.

Есть, но без проводок в ГК.
Можно ее доработать, привязав формирование записей в ней к общему журналу и генерации строк в нем , в принципе. Объем модификации будет примерно одинаковым как и разработка новой операции. Только вот общей проблемы не решит это.

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

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

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

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

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

Цитата:

Сообщение от СибирскийКлещ

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

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

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

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

Цитата:

Сообщение от СибирскийКлещ

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

Не совсем так. Есть устоявшаяся практика ведения учёта, принятая во многих странах, в основном, западных. Эту практику и стараются поддерживать в той или иной мере. Другое дело, что у нас эта практика... мягко говоря, не совсем приветствуется.
На моей практике легко было внедрять бухучёт только там, где руководитель (главбух или финдир) были неплохо знакомы с "тамошними" правилами ведения учёта. В остальных случаях биться приходилось "за каждый дом, за каждый угол"...

[MEGA]

Всем спасибо огромное за ответы!

Цитата:

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

В первом посте вы спрашивали про бух. проводки и (?) фин. аналитики.

Посмотрите документацию по ОС по операции перемещения. Унифицированная форма № ОС-2 вас устроит?

Унифицировання форма меня устраивает и журнал перемещения вприницпе тоже. Но!
Даже если в справочнике я залью нашу аналиику Отдел (чтобы добиться перемещения между отделами) и в настройках справочника Местоположений укажу по каждому Отделу счет 01 - то журнал перемещений не отразит движений по 01сч. в разрезе Отделов и в карточке ОС не изменит аналитику Отдел...

[СибирскийКлещ]

Цитата:

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

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

А можно ведь и без "пилы" обойтись. Чуть-чуть больше системного подхода к архитектуре средств отражения хоздокументов в бухгалтерских проводках, чуть меньше фундаментальных блоков в функционале, исполняемых безусловно, чуть больше параметров настроек, влияющих на исполнение этих блоков. Галочка там, галочка сям ... Для примера вспомните настройку складской модели - есть чудесная галочка "Разносить финансовые операции", управляющая формированием проводок ГК по журналам номеклатуры. Как бы подобное в обсуждаемом варианте пригодилось, будь перемещение ОС стандартной операцией модуля, отражаемой в RAssetTrans, а не "бедной родственницей" где-то на задворках .

Цитата:

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

Не совсем так. Есть устоявшаяся практика ведения учёта, принятая во многих странах, в основном, западных. Эту практику и стараются поддерживать в той или иной мере. Другое дело, что у нас эта практика... мягко говоря, не совсем приветствуется.
На моей практике легко было внедрять бухучёт только там, где руководитель (главбух или финдир) были неплохо знакомы с "тамошними" правилами ведения учёта. В остальных случаях биться приходилось "за каждый дом, за каждый угол"...

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

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

Цитата:

Сообщение от СибирскийКлещ

А можно ведь и без "пилы" обойтись. Чуть-чуть больше системного подхода к архитектуре средств отражения хоздокументов в бухгалтерских проводках, чуть меньше фундаментальных блоков в функционале, исполняемых безусловно, чуть больше параметров настроек, влияющих на исполнение этих блоков. Галочка там, галочка сям ... Для примера вспомните настройку складской модели - есть чудесная галочка "Разносить финансовые операции", управляющая формированием проводок ГК по журналам номеклатуры. Как бы подобное в обсуждаемом варианте пригодилось, будь перемещение ОС стандартной операцией модуля, отражаемой в RAssetTrans, а не "бедной родственницей" где-то на задворках

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

[TasmanianDevil]

Цитата:

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

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

Михаил, а Вы представьте себе утопию с точки зрения Аксапты как системы(в ней уже такое не сделаешь - успели уже в ней дел наделать), но вполне реализуемую на ее платформе :
есть модуля системы , есть в каждом модуле набор каких-то типов документов (для каждого типа документов в каждом модуле существует отслеживаемая хронологически настройка о необходимости проведения данных документов по используемым методикам учета, одновременном/неодновременном физическом и финансовом разнесении документа и пр.), при создании данного документа на него попадает ссылка в единый журнал разноски (делящийся по модулям, типам документов) , в спецификации которого по методикам учета (бухгалтерский, МСФО -что Вашей душе угодно) в дальнейшем указывается профиль разноски по соответствующей методике учета. Единое хранилище профилей разноски опять таки с разбиением по модулям, типам документов. Профиль разноски многострочный, с указанием в каждой строке типа обрабатываемого параметра из документа/его спецификации/атрибута для получения суммы, с указанием для каждого уровня аналитики способа его получения, кучей разных других признаков для формирования в финансовых проводках.
Документы в системе можете строить с любой структурой, как в голову взбредет - только для каждого реализовать потомка базового класа финансовой разноски который по настройкам этого документа будет обрабатывать его и разносить или не разносить).
Не надо подобную систему пилить, настраивайте ее параметрически. Не возникнет в подобной архитектуре вопроса как в данной теме. Есть пользователи со своими документами, отличающимися своей спецификой своего направления деятельности - пусть, это их работа и их головная боль. Финансовая разноска - единообразна, концепция финансовой разноски (документ -> журнал разноски -> профиля по методикам учета -> проводки) - единообразно. Физический внутримодульный учет гибко настраиваем для отражения в финансовом.
Вот оно, счастие конечного пользователя !