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

[glibs]

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

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

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

Цитата:

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

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

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

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

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

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

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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

[TasmanianDevil]

Цитата:

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

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

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