Поля CreatedTransactionID, BondBatch в таблице LedgerTrans

[mazzy]

Цитата:

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

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

НЕ НАДО.
Если сделать связь по фин.аналтике, аксапта сдохнет на таблице промежуточных итогов LedgerBalancesDimTrans.
Очень осторожно относитесь к числу комбинаций финансовых аналитик.

По-другому получится, если запретить свертку.

Обратите внимание на поле LedgerTrans.TaxRefId и TaxTrans.TaxRefId
Разработчики международного функционала этим полем пытались добиться однозначного соответствия между налоговыми и бух.проводками (в некоторых сервис-паках российской локализации связь была запорота и не работала).

Лучше уж так, чем через финансовую аналитику.

Но перед тем как программировать, подумайте:
1. А как эти проклятые буржуи живут без однозначного соответствия между складскими и бухгалтерскими проводками
2. Какая сволочь и зачем добавила параметр "Уровень детализации"? И почему эта сволочь принудительно в коде постановила суммировать бух.проводки для операций, связанных со складом?

[TasmanianDevil]

Цитата:

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

НЕ НАДО.
Если сделать связь по фин.аналтике, аксапта сдохнет на таблице промежуточных итогов LedgerBalancesDimTrans.
Очень осторожно относитесь к числу комбинаций финансовых аналитик.

По-другому получится, если запретить свертку.

Обратите внимание на поле LedgerTrans.TaxRefId и TaxTrans.TaxRefId
Разработчики международного функционала этим полем пытались добиться однозначного соответствия между налоговыми и бух.проводками (в некоторых сервис-паках российской локализации связь была запорота и не работала).

Лучше уж так, чем через финансовую аналитику.

Но перед тем как программировать, подумайте:
1. А как эти проклятые буржуи живут без однозначного соответствия между складскими и бухгалтерскими проводками
2. Какая сволочь и зачем добавила параметр "Уровень детализации"? И почему эта сволочь принудительно в коде постановила суммировать бух.проводки для операций, связанных со складом?

Вспоминая о назначении данной таблицы и глядя на реализацию этого назначения, невольно задаешься вопросом - зачем так ? Есть отличный пример - управление запасами с закрытием модуля по периодам и дальнейшими танцами с InventSum и InventTrans при построении отчетов. Кто здесь мешал ? Контроль даты при разноске по статусу периода есть, проводки редактировать/удалять пользователь не может. Закрываем период, рассчитываем/фиксируем остатки на конец периода - и в путь !
Но нет, легких путей в MBS не ищут, очередной лисапед изобрести - это хлебом не корми

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

Разве что по InventTransPosting попытаться построить подобное , но в любом случае - перебор от начала времен придется делать

[mazzy]

Цитата:

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

Вспоминая о назначении данной таблицы и глядя на реализацию этого назначения, невольно задаешься вопросом - зачем так ? Есть отличный пример - управление запасами с закрытием модуля по периодам и дальнейшими танцами с InventSum и InventTrans при построении отчетов. Кто здесь мешал ? Контроль даты при разноске по статусу периода есть, проводки редактировать/удалять пользователь не может. Закрываем период, рассчитываем/фиксируем остатки на конец периода - и в путь !
Но нет, легких путей в MBS не ищут, очередной лисапед изобрести - это хлебом не корми

Не понял.

Цитата:

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

А насчет буржуев - не могу знать. Кто этих басурман поймет - мож втайне и мечтают об этом

Но обходятся как-то на протяжении XAL, AX2.1, Ax2.5, AX3.0, AX4.0...
Вот мазохисты то... А программисты бессильные тряпки, если не могут такую штуку прикрутить... Не так ли?

Цитата:

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

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

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

Их бухгалтеру принцип работы вбит еще крепче.
Но их бухгалтер не заменяет собой все предприятие и не становится бутылочным горлышком.
Их бухгалтер использует то, что ввели другие люди на предприятии.
Почему?

Цитата:

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

Как проверить достоверность отражения этих фактов (значимыми являются например разрезы склдаской аналитики, участвующие в финансовом склад) , за которые ему деньги платят - получается никак

А чем не подходит?
Главная книга \ Отчеты \ Выверка \ Склад \ Разноска номенклатур по счетам

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

Цитата:

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

Есть задача, есть система, за которую деньги немалые заплачены - решайте , господа программисты. Вот и приходится маяться.

Если есть желание, то почему бы не помаяться... Как хотите.

[TasmanianDevil]

Цитата:

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

Не понял.

Поясняю - не лезть в LedgerBalancesDimTrans со вставкой/корректировкой при каждом проведении чего-либо в ГК, а только при закрытии периода : рассчитали при закрытии, вставили . Потом при построении отчетов, аналогично идеологии расчета складских остатков, взяли оттуда - добили LedgerTrans'ом. Проблем с блокировкой этой таблицы при увеличении комбинаций финансовой аналитики должно быть меньше и реже , нежели теперь.

Цитата:

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

А чем не подходит?
Главная книга \ Отчеты \ Выверка \ Склад \ Разноска номенклатур по счетам

Ничем, абсолютно бесполезен в моем случае для сверки финансовых показателей в складском учете и отражения их в ГК по требующимся учетным разрезам.

[Raven Melancholic]

Цитата:

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

1. А как эти проклятые буржуи живут без однозначного соответствия между складскими и бухгалтерскими проводками

Они не проклятые, они несчастные - у них нет такого "прогрессивного" документа, как российский закон о бухгалтерском учете, в котором на законодательном уровне устанавливает технику ведения учета. И многими бухгалтерами положение о том, что записи в аналитических регистрах должны соответствовать записям на синтетических счетах считается именно как требование иметь подобные ведомости.
Вообще, в таких требованиях, как сделать какую-то ведомость по номенклатуре и счетам одновременно у меня всегда возникает несколько вопросов:
1) А почему нужно четкое соответствие только движению номенклатуры с финансовой проводкой, а почему не интересует такая же информация, но по накладным расходам, по корректировкам себестоимости, по НДС, связанном с номенклатурой?
2) А как работали бухгалтеры в СССР, когда в главную книгу записи вообще делались одной суммой за месяц?
PS: кстати, второй вопрос бухгалтеров со стажем (которые еще застали безмашинный бухучет) всегда убеждает, что их просьба не очень-то разумная.
PSS: а для выверки, о которой говорил TasmanianDevil, то для неё совершенно не нужно иметь точное соответствие между складским движением и финансовой проводкой.