|  02.04.2007, 12:44 | #1 | 
| Участник | Поля CreatedTransactionID, BondBatch в таблице LedgerTrans 
			
			Здравствуйте уважаемые знатоки. Подскажите пожалуйста для какой цели предназначены поля CreatedTransactionID, BondBatch в таблице LedgerTrans и как ими можно воспользоваться? С уважением. 
				__________________ Александр | 
|  | 
|  02.04.2007, 12:57 | #2 | 
| Участник | 
			
			Номер записи в аудиторском следе. Аудиторский след: Главное меню \ Главная книга \ ЗАпросы \ Аудит Поле "Идентификатор источника создания" это и есть CreatedTransactionID Поле служит для нахождения записей, связанных с записью в аудиторском следе. См. перекрестные ссылки по методу таблицы TransactionLog::create() Это уникальный идентификатор, испольуземый при корреспонденции. Он должен быть уникален для каждой пары записей в LedgerTrans. (но бывает, что один номер связывает больше записей) см. Job'ы: tutorial_BondDateTestJob_RU(Args _args), tutorial_BondTestJob_RU(Args _args) а также документ с методологией создания бух.проводок (где-то на этом форуме) | 
|  | 
|  02.04.2007, 13:03 | #3 | 
| Участник | 
			
			Если кто найдет, киньте ссылку сюда. Тоже хочется почитать. Спасибо | 
|  | 
|  02.04.2007, 13:08 | #4 | 
| Участник | 
			
			Создание проводок ГК (программно) Исследование возможности удаления проводок А также: Изменение идентификаторов(id) полей и ссылка из нижнего раздела "Похожие темы" Поля LedgerTrans | 
|  | |
| За это сообщение автора поблагодарили: kashperuk (5). | |
|  02.04.2007, 13:33 | #5 | 
| Участник | Цитата: 1) корреспонденция может быть отключена, поэтому требуется дополнительная проверка ledgerBondClient; 3) не забывать писать в TransactionLog | 
|  | 
|  02.04.2007, 14:03 | #6 | 
| Мрачный тип | Цитата: Это уникальный идентификатор для пакета проводок, генерируется по номерной серии, настраиваемой в параметрах ГК. Уникальное сочетание для пары проводок в корреспонденции - это упомянутый идентификатор пакета проводок(BondBatch_RU) + идентификатор пары строк проводок внутри пакета(BondBatchTrans_RU) + признак крЕдита(Crediting). tolstjak, по этому вопросу гляньте метод accountNumCorr_RU у таблицы LedgerTrans - там оно видно сразу. | 
|  | |
| За это сообщение автора поблагодарили: mazzy (5). | |
|  02.04.2007, 14:08 | #7 | 
| Участник | 
			
			Да! Спасибо.
		 | 
|  | 
|  02.04.2007, 14:31 | #8 | 
| Участник | 
			
			Всем большое спасибо. Все понятно. думал, что может быть по этим полям можно выцарапать номенклатурный номер из InventTrans (или какая-нибудь идентичная табличка). Увы. Еще раз спасибо. 
				__________________ Александр | 
|  | 
|  02.04.2007, 14:46 | #9 | 
| Участник | Цитата: В бухгалтерских проводках специально делается свертка записей. Обратите внимание на параметр "Уровень детализации" в журналах. Этот параметр действует следующим образом: 1. Уровень детализации = дополнительно (detail) каждая строчка отражается отдельной записью в LedgerTrans (или двумя, если указан коррсчет) 2. Уровень детализации = сводка (summory) В пределах одного ваучера строчки с одинаковым счетом/валютой/фин.аналитикой суммируются. В результате получается меньше проводок в LedgerTrans. Но соответствия между исходными записями и записями в LedgerTrans сделать уже нельзя. Что происходит при создании проводок в заказах/закупках/производстве. По сути дела там тоже создается журнал. И в большинстве случаев в этих автоматических журналах в коде принудительно установлен "Уровень детализации" = сводка. При обработке каждой строчки в заказе/закупке/производстве Аксапта добавляет много-много строк в журналы (для каждой номенклатуры). Но перед разноской из-за установленного уровня детализации проводки с одинаковыми счетами/валютами/складскими аналитиками суммируются (сворачиваются) Аксапта получает скорость за счет потери детализации. Предполагается, что в LedgerTrans вы смотрите общую финансовую информацию. А детальную информацию о каждой номенклатуре в InventTrans|InventTransPosting. ЕСЛИ у вас стоит задача "сделать оборотно сальдовую ведомость по номенклатуре как в 1С"  ТО у вас два выхода: 1. изменить уровень детализации журналов на Detail. Тогда вы получите: 1.1. однозначное соответствие между бухпроводками и строчками в заказе 1.2. но кроме этого получите и производительность как в 1С  2. собирать оборотно-сальдовую ведомость по складским проводкам. Но в этом случе вы столкнетесь с тем, что в Аксапте хранится гораздо больше чем в 1С. Первый вопрос: а какие движения включать в оборотно-сальдовую ведомость. Аксапта четко подразделяет финансовые, физические, комплектацию, регистрацию и т.п. (посмотрите как решили этот вопрос российские локализаторы в оборотно-сальдовой ведомости по складу и НЕ делайте так) Второй вопрос: у номенклатуры могут быть разные счета прихода и расхода. Вообще с соотвествиями номенклатуры и счета вам придется очень плотно разобраться. | 
|  | 
|  02.04.2007, 15:04 | #10 | 
| Мрачный тип | Цитата: А вот с выцарапыванием номенклатуры - если только номенклатура синхронизируется в один из уровней финансовой аналитики(есть у такого подхода и плюсы и минусы), иначе вряд ли что-то получится. Ибо единственная связь м-ду проводками ГК(LedgerTrans) и проводками по номенклатуре(InventTrans) по Voucher+TransDate кроме вариантов отношений 1:1 и 1:N, позволяющих идентифицировать номенклатуру по проводке, может иметь еще и вариант N:N (в накладных клиента/поставщика такое имеет место быть, 2-3 проводки ГК, относящихся к операции движения номенклатуры и штук N-дцать соответствующих им проводок по номенклатуре) - тут уж простой выборкой за один проход ничего не сопоставишь. | 
|  | 
|  02.04.2007, 15:12 | #11 | 
| Участник | Цитата: Если сделать связь по фин.аналтике, аксапта сдохнет на таблице промежуточных итогов LedgerBalancesDimTrans. Очень осторожно относитесь к числу комбинаций финансовых аналитик. По-другому получится, если запретить свертку. Обратите внимание на поле LedgerTrans.TaxRefId и TaxTrans.TaxRefId Разработчики международного функционала этим полем пытались добиться однозначного соответствия между налоговыми и бух.проводками (в некоторых сервис-паках российской локализации связь была запорота и не работала). Лучше уж так, чем через финансовую аналитику. Но перед тем как программировать, подумайте: 1. А как эти проклятые буржуи живут без однозначного соответствия между складскими и бухгалтерскими проводками 2. Какая сволочь и зачем добавила параметр "Уровень детализации"? И почему эта сволочь принудительно в коде постановила суммировать бух.проводки для операций, связанных со складом? | 
|  | 
|  02.04.2007, 15:27 | #12 | 
| Участник | Цитата: 
		
			Сообщение от mazzy
			   Нет. По-умолчанию, нельзя. В бухгалтерских проводках специально делается свертка записей. Обратите внимание на параметр "Уровень детализации" в журналах. Этот параметр действует следующим образом: 1. Уровень детализации = дополнительно (detail) каждая строчка отражается отдельной записью в LedgerTrans (или двумя, если указан коррсчет) Имеем 50 строк в LedgerTrans и 50 строк InventTrans. При этом поля Voucher,TransDate, Dimension4_, Счета (тот и другой) - одинаковые. Как выцепить ItemId? Думал прицеплю еще сумму и будет мне счастье. Куда там. Даже суммы и те одинаковые. Вот блин.   Хотя мне надо выцепить 50 номенклатурных номеров, а к какой сумме (если они одинаковые) будет привязан этот номенклатурный номер не суть важно. Я прав? 
				__________________ Александр | 
|  | 
|  02.04.2007, 16:54 | #13 | 
| Участник | 
			
			Цитирую себя: Цитата: 
		
			Сообщение от mazzy
			   Обратите внимание на поле LedgerTrans.TaxRefId и TaxTrans.TaxRefId Разработчики международного функционала этим полем пытались добиться однозначного соответствия между налоговыми и бух.проводками (в некоторых сервис-паках российской локализации связь была запорота и не работала). Лучше уж так, чем через финансовую аналитику. | 
|  | 
|  02.04.2007, 17:00 | #14 | 
| Мрачный тип | Цитата: 
		
			Сообщение от mazzy
			   НЕ НАДО. Если сделать связь по фин.аналтике, аксапта сдохнет на таблице промежуточных итогов LedgerBalancesDimTrans. Очень осторожно относитесь к числу комбинаций финансовых аналитик. По-другому получится, если запретить свертку. Обратите внимание на поле LedgerTrans.TaxRefId и TaxTrans.TaxRefId Разработчики международного функционала этим полем пытались добиться однозначного соответствия между налоговыми и бух.проводками (в некоторых сервис-паках российской локализации связь была запорота и не работала). Лучше уж так, чем через финансовую аналитику. Но перед тем как программировать, подумайте: 1. А как эти проклятые буржуи живут без однозначного соответствия между складскими и бухгалтерскими проводками 2. Какая сволочь и зачем добавила параметр "Уровень детализации"? И почему эта сволочь принудительно в коде постановила суммировать бух.проводки для операций, связанных со складом? Но нет, легких путей в MBS не ищут, очередной лисапед изобрести - это хлебом не корми   А насчет буржуев - не могу знать. Кто этих басурман поймет - мож втайне и мечтают об этом   Нашему бухгалтеру твердо вбит принцип его работы - своевременное и достоверное отражения фактов хозяйственной деятельности на счетах бухгалтерского учета согласно требований законодательства и учетной политики. Принесли ему ворох бумаг, обработал их человек - движение есть, остатки есть. Как проверить достоверность отражения этих фактов (значимыми являются например разрезы склдаской аналитики, участвующие в финансовом склад) , за что ему собственно деньги и платят - получается никак, большая куча в виде остатка по счету и ничего более. И никакие ссылки на запад, всякие разные словеса и аббревиатуры нерусские его не волнуют. Есть задача, есть система, за которую деньги немалые заплачены - решайте , господа программисты. Вот и приходится маяться.  Разве что по InventTransPosting попытаться построить подобное , но в любом случае - перебор от начала времен придется делать Последний раз редактировалось TasmanianDevil; 02.04.2007 в 17:09. | 
|  | 
|  02.04.2007, 17:13 | #15 | 
| Участник | Цитата: 
		
			Сообщение от TasmanianDevil
			   Вспоминая о назначении данной таблицы и глядя на реализацию этого назначения, невольно задаешься вопросом - зачем так ? Есть отличный пример - управление запасами с закрытием модуля по периодам и дальнейшими танцами с InventSum и InventTrans при построении отчетов. Кто здесь мешал ? Контроль даты при разноске по статусу периода есть, проводки редактировать/удалять пользователь не может. Закрываем период, рассчитываем/фиксируем остатки на конец периода - и в путь !   Но нет, легких путей в MBS не ищут, очередной лисапед изобрести - это хлебом не корми Цитата: Вот мазохисты то... А программисты бессильные тряпки, если не могут такую штуку прикрутить... Не так ли?  Цитата: 
		
			Сообщение от TasmanianDevil
			   Нашему бухгалтеру твердо вбит принцип его работы - своевременное и достоверное отражения фактов хозяйственной деятельности  на счетах бухгалтерского учета согласно требований законодательства и учетной политики. Принесли ему ворох бумаг, обработал их человек  - движение есть, остатки есть. Не бухгалтеру принесли ворох бумаг, а ответственному человеку на складе или в закупках или в продажах... При чем здесь бухгалтер? Их бухгалтеру принцип работы вбит еще крепче. Но их бухгалтер не заменяет собой все предприятие и не становится бутылочным горлышком. Их бухгалтер использует то, что ввели другие люди на предприятии. Почему?  Цитата: Главная книга \ Отчеты \ Выверка \ Склад \ Разноска номенклатур по счетам В этом то и разница. Их бухгалтер работает с цифрами которые получил от других подразделений. Наш бухгалтер пытается подменить собой все остальные подразделения. Если есть желание, то почему бы не помаяться... Как хотите. | 
|  | 
|  02.04.2007, 21:15 | #16 | 
| Участник | 
			
			mazzy, будьте добры, поясните  пожалуйста одну вещь - каковы в общих чертах назначение и методика работы нашего бухгалтера в Axapta, при условии, что закупки/заказы/склад/бухгалтерия ведутся целиком в Axapta и согласно Вашей цитате.  Может быть я что-то фундаментальное упустил в своем познании системы? Цитата: 
		
			Сообщение от mazzy
			
			 Не бухгалтеру принесли ворох бумаг, а ответственному человеку на складе или в закупках или в продажах... При чем здесь бухгалтер? Их бухгалтеру принцип работы вбит еще крепче. Но их бухгалтер не заменяет собой все предприятие и не становится бутылочным горлышком. Их бухгалтер использует то, что ввели другие люди на предприятии. | 
|  | 
|  02.04.2007, 21:33 | #17 | 
| Участник | Цитата: 
		
			Сообщение от СибирскийКлещ
			   mazzy, будьте добры, поясните  пожалуйста одну вещь - каковы в общих чертах назначение и методика работы нашего бухгалтера в Axapta, при условии, что закупки/заказы/склад/бухгалтерия ведутся целиком в Axapta и согласно Вашей цитате.  Может быть я что-то фундаментальное упустил в своем познании системы? Как им избежать конфликта интересов, когда одному нужно оперативное отражения факта своей деятельности (остатки, движение номенклатуры в правильных количественно-суммовых показателях), второму нужно отобразить действия первого в ГК с корректной финансовой аналитикой по корректным бухгалтерским счетам корректной суммой в ситуации, когда выполнение этих разных по сути и, вполне вероятно, разнесенных во времени действий реализовано в системе в одном месте и одновременно (обработка накладной по заказу/закупке, проведение складского журнала) ?  Порядок нужно наводить ДО, а не ПОСЛЕ выбора и внедрения системы. А у нас привыкли делать, как недавно обсуждалось здесь же. Привезли товар клиенту, одновременно привезли накладную ТОРГ-12 и счёт-фактуру. Клиент часть не принял. Порвали документы, сделали новые. Это порядок? Это бардак. Если произошло физическое движение товара, то и нужно регистрировать физическое, а не финансовое. И какой такой "конфликт интересов"? Правильные настройки сделать и людей обучить. | 
|  | 
|  02.04.2007, 22:58 | #18 | 
| Участник | 
			
			2СибирскийКлещ, слушайте, что Михаил Андреев говорит. Он хорошему научит. Добавлю только Цитата: 2. представьте что у вас нет системы, только карандаш и бумага у каждого участника процесса. Объясните, как они могут в принципе удовлетворить вашим же требованиям. 3. в Аксапте четко разводится физическое и финансовое движение (да, эти движения можно выполнить одновременно, но нужно ли?). Пусть каждый вводит только то, что знает. Не больше. Но и не меньше. | 
|  | 
|  03.04.2007, 09:22 | #19 | 
| Участник | Цитата: Вообще, в таких требованиях, как сделать какую-то ведомость по номенклатуре и счетам одновременно у меня всегда возникает несколько вопросов: 1) А почему нужно четкое соответствие только движению номенклатуры с финансовой проводкой, а почему не интересует такая же информация, но по накладным расходам, по корректировкам себестоимости, по НДС, связанном с номенклатурой? 2) А как работали бухгалтеры в СССР, когда в главную книгу записи вообще делались одной суммой за месяц? PS: кстати, второй вопрос бухгалтеров со стажем (которые еще застали безмашинный бухучет) всегда убеждает, что их просьба не очень-то разумная. PSS: а для выверки, о которой говорил TasmanianDevil, то для неё совершенно не нужно иметь точное соответствие между складским движением и финансовой проводкой. | 
|  | 
|  03.04.2007, 12:35 | #20 | 
| Участник | К сожалению по этому полю ничего не выцепить. Там значения 0 или 1. Других нет. Еще раз всем большое спасибо. Очень помогли.   По поводу дискуссии: Мне кажется что проблемы не в бухучете как таковом, а в том, что рассматривая вопрос с двух сторон не получаешь одинакового результата. Если у бухгалтеров все крутится от баланса они и пытаются в складском учете выйти на те же результаты. А это не получается. В этом и проблемы. Остальное от лукавого. С уважением. 
				__________________ Александр | 
|  |