Как для ГК операции в LedgerTrans найти соответствующую операцию в VendTrans?

[romulis]

Здравствуйте,
Хотим просматривать ГК операции (LedgerTrans) и для них находить соответствующие операции в таблицах VendTrans, CustTrans, ProjTransPosting. К сожалению, никак не можем найти однозначной связи LedgerTrans<->VendTrans. Для одной операции LedgerTrans иногда существуют много операций в VendTrans, с таким же ваучером, датой, а даже с такой же суммой.
Подскажите пожалуйста, где искать однозначную связь между LedgerTrans и VendTrans.

Спасибо за любые советы.
Роман

[petr]

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

Вам это необходимо для того чтобы построить отчет по счету ГК в разрезе поставщиков (и, возможно, накладных) или нет?

[slava09]

Цитата:

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

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

Вам это необходимо для того чтобы построить отчет по счету ГК в разрезе поставщиков (и, возможно, накладных) или нет?

Хотел бы подключиться: такая задача стоит при построении журнала-ордера по поставщику\клиенту\банку\кассе\подотчету и т.д.

[ppson]

Цитата:

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

такая задача стоит при построении журнала-ордера по поставщику\клиенту\банку\кассе\подотчету и т.д.

это отдельная история ...
у каждого клиента свои "журналы-ордера, соответствующие "стандартам"
поэтому приходилось выкручиваться индивидуально

[slava09]

Цитата:

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

это отдельная история ...
у каждого клиента свои "журналы-ордера, соответствующие "стандартам"
поэтому приходилось выкручиваться индивидуально

Как это "у каждого клиента"? Может у каждого функционального участка (клиент, поставщик, касса, подотчет)? Ошиблись или я не понял?

Пытались решать задачу универсально?

[TasmanianDevil]

Цитата:

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

Пытались решать задачу универсально?

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

Сам с подобным вопросом сталкивался, только по RAssetTrans - было и есть несколько ОС , у которых амортизация начисляется на 2 разных счета по долям (собственное и сданное в аренду) и (как реализовали внедренцы) под одним и тем же док-том ГК лепились 2 записи в RAssetTrans - что по одной , что по другой при просмотре проводок наблюдается набор из всех проводок ГК с данным док-том ГК.
Но особенно было забавно наблюдать подобное при просмотре проводок по операции выбытия/продажи ОС , когда разом штук N-цать картчек продавали как положено через модуль "Расчеты с клиентами" - в RAssetTrans были как и положено все N-дцать записей по карточкам, а вот в проводках ГК - только прописанный профилем разноски набор проводок в единичном экземпляре на сумму всех карточек (смотрим проводки по операции продажи кресла с остаточной стоимостью 10 тыс. - а там проводки тыщ на 500)

[kosenkov]

Цитата:

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

Здравствуйте,
Хотим просматривать ГК операции (LedgerTrans) и для них находить соответствующие операции в таблицах VendTrans, CustTrans, ProjTransPosting. К сожалению, никак не можем найти однозначной связи LedgerTrans<->VendTrans. Для одной операции LedgerTrans иногда существуют много операций в VendTrans, с таким же ваучером, датой, а даже с такой же суммой.
Подскажите пожалуйста, где искать однозначную связь между LedgerTrans и VendTrans.

Спасибо за любые советы.
Роман

Что стоит в Главная книга - Параметры - Контроль номеров документов? Если есть и было "Запрещать дубликаты", то все должно быть ОК.
Конечно, и в этом случае соотвествия "один-в-один" или "много проводок ГК с одним номером ГК - одна проводка поставщика" не будет (разнесите закупку с указанием подотчетника - будут две проводки по поставщику, и несколько по ГК).
Но по крайней мере проводки по ГК и поставщикам с одним номером ГК и одной датой будут гарантировано принадлежать одной "разноске".
Это конечно если у вас нет модификаций на эту тему.

[ppson]

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

[poul]

установить связь один к одному между проводками по модулям(CustTrans, VendTrans, RassetTrans и тд) и проводками ГК(LedgerTrans) не удастся, т.к. например иногда одной строке "CustTrans" может соответствует несколько строк "LedgerTrans"...

[poul]

однако своими глазами видел модификации которые устанавливали и поддерживали подобную связь, которые например помогали определить например по какому бух.счету(в LedgerTrans) прошла проводка по клиенту(CustTrans)... и модификации эти очень сильно помогали в подавляющем большинстве случаев

[MironovI]

Для этих целей в системе есть вспомогательные таблицы типа InventTransPosting, MarkupTrans, TaxTrans и пр.. и в большинстве-то случаев нужную инфу можно вытащить оттуда, а LedgerTrans пусть сворачивается себе по счетам и аналитикам..

PS - Хотя самолично добавлял в VendTrans счет ГК - эт конечно жизнь упрощает

[Recoilme]

На основании "Складских операций" а Axapta (заказ,закупка, складской журнал)
создавать бухгалтерские проводки
по ним - оборотка, шахматка, журналы-ордера, ведомости и т.п.

Т.е.:

1 контур - Аксапта - оперативный учет

2 контур - система N (не 1С) - финансовый учет

Преимущества:
1. Алгоритмы формирования проводок (финансы) настраиваются в системе N
2. Изменение финансового контура не затрагивает оперативного контура
3. Прозрачная связь документ - проводки
4. Привычная модель бух. учета
5. Возможность независимого от основного контура пересчета себестоимости, например
6. Возможность анализа в независимой от основной, более оперативной и компактной СУБД
7. Высокое быстродействие

Проблемы:
1. Синхронизация в режиме "почти" реального времени - затруднена.. Сколько раз в день?
2. Обмен - через файлы (писать каждый раз выгрузку) или ADO?
3. Обработка удаления документов?
4. Кастомизации насколько сильно влияют?

Вопросы:
1. Как Вы думаете нужна ли такая система?
2. Сколько она может стоить?
3. Купили ли бы Вы такую систему?

[slava09]

Цитата:

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

На основании "Складских операций" а Axapta (заказ,закупка, складской журнал)
создавать бухгалтерские проводки
по ним - оборотка, шахматка, журналы-ордера, ведомости и т.п.

Т.е.:

1 контур - Аксапта - оперативный учет

2 контур - система N (не 1С) - финансовый учет

Преимущества:
1. Алгоритмы формирования проводок (финансы) настраиваются в системе N
2. Изменение финансового контура не затрагивает оперативного контура
3. Прозрачная связь документ - проводки
4. Привычная модель бух. учета
5. Возможность независимого от основного контура пересчета себестоимости, например
6. Возможность анализа в независимой от основной, более оперативной и компактной СУБД
7. Высокое быстродействие

Проблемы:
1. Синхронизация в режиме "почти" реального времени - затруднена.. Сколько раз в день?
2. Обмен - через файлы (писать каждый раз выгрузку) или ADO?
3. Обработка удаления документов?
4. Кастомизации насколько сильно влияют?

Вопросы:
1. Как Вы думаете нужна ли такая система?
2. Сколько она может стоить?
3. Купили ли бы Вы такую систему?

Мое мнение: такая связка в принципе не будет востребованна, независимо какая конкретно система N. Я считаю, что задача "На основании "Складских операций" а Axapta (заказ,закупка, складской журнал) создавать бухгалтерские проводки" в Аксапте реализована приемлемо. Приемлемо настолько, что любой партнер в силах ее "долизать" до конкретных требований. Вот вторая часть задачи может быть вынесена в отдельное приложение, что в принципе уже и так всеми сделано. Я хочу сказать, что отчеты гораздо удобнее и приятнее строить сторонними средствами, но данные всетаки получать из первоисточника.
Считаю, что указанные проблемы полность перекрывают преимущества.

[MironovI]

Для основной функци системы - принятия решений - данные должны лежать в могучей куче а иначе зачем ERP система вообще -так бы и жили себе на 20-ти базах 1С-а, это мелкие всякие специфичные вещи можно выносить - типа биллинга или POS-терминала..

[TasmanianDevil]

Recoilme, коллега, побойтесь бога такое создавать! Как человек, измученный нарзаном, (тьфу, то есть подобной конфигурацией связки двух систем и которого заставляют расширять ее до указанного Вами уровня - чем последние 4 месяца и занимаюсь) заявлю , что данное творение будет больше вреда приносить, а не пользы. Даже в конфигурации 2х Аксапт - ибо если там будет в реплицируемых данных хоть одна связка по RecId - пиши пропало либо сразу, либо в перспективе. Две же разные системы могут просто по структуре хранимых данных не срастись.

Ну а, так сказать, вдогонку про связь проводок модуля/документов/их строк с LedgerTrans добавлю, но только теперь про профили разноски и обработку ими различных документов (как раз на подходе разработка новой операции ОС, касаемо одного из видов выбытия - душа просто "поёт" от перспектив повкалывать на выходных, понастраивать профиля разноски чудные , так что промолчать сил просто нету и потому яду будет немеряно)

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

При реализации подобной концепции профилей разноски и разноски документов в ГК по ним, а так же вышеупомянутого мной по связям документов и операций с LedgerTrans - пункты 2,3 из преимуществ реализуются на все 200 % в одной системе.