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

[mazzy]

Цитата:

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

CreatedTransactionID

Номер записи в аудиторском следе.

Аудиторский след: Главное меню \ Главная книга \ ЗАпросы \ Аудит
Поле "Идентификатор источника создания" это и есть CreatedTransactionID
Поле служит для нахождения записей, связанных с записью в аудиторском следе.

См. перекрестные ссылки по методу таблицы TransactionLog::create()

Цитата:

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

BondBatch

Это уникальный идентификатор, испольуземый при корреспонденции.
Он должен быть уникален для каждой пары записей в LedgerTrans.
(но бывает, что один номер связывает больше записей)

см. Job'ы: tutorial_BondDateTestJob_RU(Args _args), tutorial_BondTestJob_RU(Args _args)
а также документ с методологией создания бух.проводок (где-то на этом форуме)

[kashperuk]

Цитата:

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

документ с методологией создания бух.проводок (где-то на этом форуме)

Если кто найдет, киньте ссылку сюда. Тоже хочется почитать.
Спасибо

[Raven Melancholic]

Цитата:

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

см. Job'ы: tutorial_BondDateTestJob_RU(Args _args), tutorial_BondTestJob_RU(Args _args)

Чуть чуть дополню. Данные джобы нужно смотреть, учитывая пару вещей:
1) корреспонденция может быть отключена, поэтому требуется дополнительная проверка ledgerBondClient;
3) не забывать писать в TransactionLog

[TasmanianDevil]

Цитата:

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

Это уникальный идентификатор, испольуземый при корреспонденции.
Он должен быть уникален для каждой пары записей в LedgerTrans.

Немного не так, Сергей ...
Это уникальный идентификатор для пакета проводок, генерируется по номерной серии, настраиваемой в параметрах ГК. Уникальное сочетание для пары проводок в корреспонденции - это упомянутый идентификатор пакета проводок(BondBatch_RU) + идентификатор пары строк проводок внутри пакета(BondBatchTrans_RU) + признак крЕдита(Crediting).

tolstjak, по этому вопросу гляньте метод accountNumCorr_RU у таблицы LedgerTrans - там оно видно сразу.

[mazzy]

Цитата:

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

Уникальное сочетание для пары проводок в корреспонденции - это упомянутый идентификатор пакета проводок(BondBatch_RU) + идентификатор пары строк проводок внутри пакета(BondBatchTrans_RU) + признак крЕдита(Crediting).

Да! Спасибо.

[tolstjak]

Всем большое спасибо.
Все понятно.
думал, что может быть по этим полям можно выцарапать номенклатурный номер из InventTrans (или какая-нибудь идентичная табличка).
Увы.
Еще раз спасибо.

[mazzy]

Цитата:

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

Всем большое спасибо.
Все понятно.
думал, что может быть по этим полям можно выцарапать номенклатурный номер из InventTrans (или какая-нибудь идентичная табличка).
Увы.
Еще раз спасибо.

Нет. По-умолчанию, нельзя.

В бухгалтерских проводках специально делается свертка записей.
Обратите внимание на параметр "Уровень детализации" в журналах.

Этот параметр действует следующим образом:
1. Уровень детализации = дополнительно (detail)
каждая строчка отражается отдельной записью в LedgerTrans (или двумя, если указан коррсчет)

2. Уровень детализации = сводка (summory)
В пределах одного ваучера строчки с одинаковым счетом/валютой/фин.аналитикой суммируются. В результате получается меньше проводок в LedgerTrans. Но соответствия между исходными записями и записями в LedgerTrans сделать уже нельзя.

Что происходит при создании проводок в заказах/закупках/производстве.
По сути дела там тоже создается журнал. И в большинстве случаев в этих автоматических журналах в коде принудительно установлен "Уровень детализации" = сводка.

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

Аксапта получает скорость за счет потери детализации.
Предполагается, что в LedgerTrans вы смотрите общую финансовую информацию. А детальную информацию о каждой номенклатуре в InventTrans|InventTransPosting.


ЕСЛИ у вас стоит задача "сделать оборотно сальдовую ведомость по номенклатуре как в 1С"
ТО у вас два выхода:
1. изменить уровень детализации журналов на Detail. Тогда вы получите:
1.1. однозначное соответствие между бухпроводками и строчками в заказе
1.2. но кроме этого получите и производительность как в 1С

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

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

[tolstjak]

Цитата:

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

Нет. По-умолчанию, нельзя.

В бухгалтерских проводках специально делается свертка записей.
Обратите внимание на параметр "Уровень детализации" в журналах.

Этот параметр действует следующим образом:
1. Уровень детализации = дополнительно (detail)
каждая строчка отражается отдельной записью в LedgerTrans (или двумя, если указан коррсчет)

У нас "Дополнительно". Но все равно проблем не рашает.

Имеем 50 строк в LedgerTrans и 50 строк InventTrans. При этом поля Voucher,TransDate, Dimension4_, Счета (тот и другой) - одинаковые. Как выцепить ItemId? Думал прицеплю еще сумму и будет мне счастье. Куда там. Даже суммы и те одинаковые. Вот блин.
Хотя мне надо выцепить 50 номенклатурных номеров, а к какой сумме (если они одинаковые) будет привязан этот номенклатурный номер не суть важно.

Я прав?

[mazzy]

Цитата:

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

Как выцепить ItemId?

Цитирую себя:

Цитата:

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

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

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

[TasmanianDevil]

Цитата:

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

Всем большое спасибо.
Все понятно.
думал, что может быть по этим полям можно выцарапать номенклатурный номер из InventTrans (или какая-нибудь идентичная табличка).
Увы.
Еще раз спасибо.

Да всегда пожалуйста ...
А вот с выцарапыванием номенклатуры - если только номенклатура синхронизируется в один из уровней финансовой аналитики(есть у такого подхода и плюсы и минусы), иначе вряд ли что-то получится. Ибо единственная связь м-ду проводками ГК(LedgerTrans) и проводками по номенклатуре(InventTrans) по Voucher+TransDate кроме вариантов отношений 1:1 и 1:N, позволяющих идентифицировать номенклатуру по проводке, может иметь еще и вариант N:N (в накладных клиента/поставщика такое имеет место быть, 2-3 проводки ГК, относящихся к операции движения номенклатуры и штук N-дцать соответствующих им проводок по номенклатуре) - тут уж простой выборкой за один проход ничего не сопоставишь.

[mazzy]

Цитата:

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

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

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

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

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

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

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

[TasmanianDevil]

Цитата:

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

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

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

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

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

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

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

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

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

[Raven Melancholic]

Цитата:

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

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

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