|
23.08.2006, 12:00 | #1 |
Участник
|
Как для ГК операции в LedgerTrans найти соответствующую операцию в VendTrans?
Здравствуйте,
Хотим просматривать ГК операции (LedgerTrans) и для них находить соответствующие операции в таблицах VendTrans, CustTrans, ProjTransPosting. К сожалению, никак не можем найти однозначной связи LedgerTrans<->VendTrans. Для одной операции LedgerTrans иногда существуют много операций в VendTrans, с таким же ваучером, датой, а даже с такой же суммой. Подскажите пожалуйста, где искать однозначную связь между LedgerTrans и VendTrans. Спасибо за любые советы. Роман |
|
23.08.2006, 12:14 | #2 |
Участник
|
Однозначного соответствия между LedgerTrans и VendTrans в системе нет. Его можно добиться (или постараться добиться) только при помощи модификаций, но я бы этого не советовал.
Вам это необходимо для того чтобы построить отчет по счету ГК в разрезе поставщиков (и, возможно, накладных) или нет? |
|
23.08.2006, 13:25 | #3 |
Участник
|
Цитата:
Сообщение от petr
Однозначного соответствия между LedgerTrans и VendTrans в системе нет. Его можно добиться (или постараться добиться) только при помощи модификаций, но я бы этого не советовал.
Вам это необходимо для того чтобы построить отчет по счету ГК в разрезе поставщиков (и, возможно, накладных) или нет? |
|
23.08.2006, 14:10 | #4 |
Участник
|
Цитата:
Сообщение от slava09
такая задача стоит при построении журнала-ордера по поставщику\клиенту\банку\кассе\подотчету и т.д.
у каждого клиента свои "журналы-ордера, соответствующие "стандартам" поэтому приходилось выкручиваться индивидуально
__________________
|
|
23.08.2006, 15:27 | #5 |
Участник
|
Цитата:
Сообщение от ppson
это отдельная история ...
у каждого клиента свои "журналы-ордера, соответствующие "стандартам" поэтому приходилось выкручиваться индивидуально Пытались решать задачу универсально? |
|
25.08.2006, 10:07 | #6 |
Мрачный тип
|
Цитата:
Сообщение от slava09
Пытались решать задачу универсально?
Пока не будет в истеме нормального уникального идентификатора записи в таблице, однозначно идентифицирующего запись, и в LedgerTrans не будет нормальной коммутируемой связи фин. проводок с проводками/документами модуля/их строками по многосегментной ссылке типа "Тип модуля/тип документа в модуле/идентификатор документа/идентификатор строки документа" вместо "Тип модуля/Док ГК/Дата"- попытки что-то универсализировать в рамках текущей структуры в большинстве своем выльются очередное строительство комплекса затычек. Сам с подобным вопросом сталкивался, только по RAssetTrans - было и есть несколько ОС , у которых амортизация начисляется на 2 разных счета по долям (собственное и сданное в аренду) и (как реализовали внедренцы) под одним и тем же док-том ГК лепились 2 записи в RAssetTrans - что по одной , что по другой при просмотре проводок наблюдается набор из всех проводок ГК с данным док-том ГК. Но особенно было забавно наблюдать подобное при просмотре проводок по операции выбытия/продажи ОС , когда разом штук N-цать картчек продавали как положено через модуль "Расчеты с клиентами" - в RAssetTrans были как и положено все N-дцать записей по карточкам, а вот в проводках ГК - только прописанный профилем разноски набор проводок в единичном экземпляре на сумму всех карточек (смотрим проводки по операции продажи кресла с остаточной стоимостью 10 тыс. - а там проводки тыщ на 500) |
|
23.08.2006, 12:29 | #7 |
Columbus IT
|
Цитата:
Сообщение от romulis
Здравствуйте,
Хотим просматривать ГК операции (LedgerTrans) и для них находить соответствующие операции в таблицах VendTrans, CustTrans, ProjTransPosting. К сожалению, никак не можем найти однозначной связи LedgerTrans<->VendTrans. Для одной операции LedgerTrans иногда существуют много операций в VendTrans, с таким же ваучером, датой, а даже с такой же суммой. Подскажите пожалуйста, где искать однозначную связь между LedgerTrans и VendTrans. Спасибо за любые советы. Роман Конечно, и в этом случае соотвествия "один-в-один" или "много проводок ГК с одним номером ГК - одна проводка поставщика" не будет (разнесите закупку с указанием подотчетника - будут две проводки по поставщику, и несколько по ГК). Но по крайней мере проводки по ГК и поставщикам с одним номером ГК и одной датой будут гарантировано принадлежать одной "разноске". Это конечно если у вас нет модификаций на эту тему. |
|
23.08.2006, 12:34 | #8 |
Участник
|
По одному ваучеру может быть несколько проводок в LT и VT по одному поставщику при сопоставлении/рассопоставлении открытых проводок с разными профилями разноски.
По одному ваучеру может быть несколько проводок в LT и VT по разным поставщикам одновременно - при расчете нереализованной курсовой разницы, при переброске задолженности с одного поставщика на другого.
__________________
Последний раз редактировалось ppson; 23.08.2006 в 12:38. |
|
28.08.2006, 16:54 | #9 |
Участник
|
установить связь один к одному между проводками по модулям(CustTrans, VendTrans, RassetTrans и тд) и проводками ГК(LedgerTrans) не удастся, т.к. например иногда одной строке "CustTrans" может соответствует несколько строк "LedgerTrans"...
|
|
28.08.2006, 16:57 | #10 |
Участник
|
однако своими глазами видел модификации которые устанавливали и поддерживали подобную связь, которые например помогали определить например по какому бух.счету(в LedgerTrans) прошла проводка по клиенту(CustTrans)... и модификации эти очень сильно помогали в подавляющем большинстве случаев
|
|
28.08.2006, 17:26 | #11 |
Участник
|
Для этих целей в системе есть вспомогательные таблицы типа InventTransPosting, MarkupTrans, TaxTrans и пр.. и в большинстве-то случаев нужную инфу можно вытащить оттуда, а LedgerTrans пусть сворачивается себе по счетам и аналитикам..
PS - Хотя самолично добавлял в VendTrans счет ГК - эт конечно жизнь упрощает Последний раз редактировалось MironovI; 28.08.2006 в 17:28. |
|
28.08.2006, 17:55 | #12 |
злыдень
|
Есть одна идея
На основании "Складских операций" а Axapta (заказ,закупка, складской журнал)
создавать бухгалтерские проводки по ним - оборотка, шахматка, журналы-ордера, ведомости и т.п. Т.е.: 1 контур - Аксапта - оперативный учет 2 контур - система N (не 1С) - финансовый учет Преимущества: 1. Алгоритмы формирования проводок (финансы) настраиваются в системе N 2. Изменение финансового контура не затрагивает оперативного контура 3. Прозрачная связь документ - проводки 4. Привычная модель бух. учета 5. Возможность независимого от основного контура пересчета себестоимости, например 6. Возможность анализа в независимой от основной, более оперативной и компактной СУБД 7. Высокое быстродействие Проблемы: 1. Синхронизация в режиме "почти" реального времени - затруднена.. Сколько раз в день? 2. Обмен - через файлы (писать каждый раз выгрузку) или ADO? 3. Обработка удаления документов? 4. Кастомизации насколько сильно влияют? Вопросы: 1. Как Вы думаете нужна ли такая система? 2. Сколько она может стоить? 3. Купили ли бы Вы такую систему?
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
29.08.2006, 10:30 | #13 |
Участник
|
Цитата:
Сообщение от Recoilme
На основании "Складских операций" а Axapta (заказ,закупка, складской журнал)
создавать бухгалтерские проводки по ним - оборотка, шахматка, журналы-ордера, ведомости и т.п. Т.е.: 1 контур - Аксапта - оперативный учет 2 контур - система N (не 1С) - финансовый учет Преимущества: 1. Алгоритмы формирования проводок (финансы) настраиваются в системе N 2. Изменение финансового контура не затрагивает оперативного контура 3. Прозрачная связь документ - проводки 4. Привычная модель бух. учета 5. Возможность независимого от основного контура пересчета себестоимости, например 6. Возможность анализа в независимой от основной, более оперативной и компактной СУБД 7. Высокое быстродействие Проблемы: 1. Синхронизация в режиме "почти" реального времени - затруднена.. Сколько раз в день? 2. Обмен - через файлы (писать каждый раз выгрузку) или ADO? 3. Обработка удаления документов? 4. Кастомизации насколько сильно влияют? Вопросы: 1. Как Вы думаете нужна ли такая система? 2. Сколько она может стоить? 3. Купили ли бы Вы такую систему? Считаю, что указанные проблемы полность перекрывают преимущества. |
|
28.08.2006, 18:18 | #14 |
Участник
|
Для основной функци системы - принятия решений - данные должны лежать в могучей куче а иначе зачем ERP система вообще -так бы и жили себе на 20-ти базах 1С-а, это мелкие всякие специфичные вещи можно выносить - типа биллинга или POS-терминала..
|
|
29.08.2006, 14:10 | #15 |
Мрачный тип
|
Recoilme, коллега, побойтесь бога такое создавать! Как человек, измученный нарзаном, (тьфу, то есть подобной конфигурацией связки двух систем и которого заставляют расширять ее до указанного Вами уровня - чем последние 4 месяца и занимаюсь) заявлю , что данное творение будет больше вреда приносить, а не пользы. Даже в конфигурации 2х Аксапт - ибо если там будет в реплицируемых данных хоть одна связка по RecId - пиши пропало либо сразу, либо в перспективе. Две же разные системы могут просто по структуре хранимых данных не срастись.
Ну а, так сказать, вдогонку про связь проводок модуля/документов/их строк с LedgerTrans добавлю, но только теперь про профили разноски и обработку ими различных документов (как раз на подходе разработка новой операции ОС, касаемо одного из видов выбытия - душа просто "поёт" от перспектив повкалывать на выходных, понастраивать профиля разноски чудные , так что промолчать сил просто нету и потому яду будет немеряно) Допустим , имеется единое хранилище многострочных профилей разноски (профиль может быть как нормальный, генерирующий проводки, так и виртуальный, без генерации проводок в ГК - в случае смены учетной политики и пропадания/появления необходимости проведения каких-то типов документов это просто спасет систему от программерской хирургии) с разделением идентификацией по модулю/типу документа(типу операции) и связью 1 ко многим для гибкой настройки разноски документа по ГК в зависимости от нюансов операции - в отличии от текущей убогой концепции многотабличного хранения единственно возможного профиля с крайне неявной политикой подстановки как счетов, так и аналитики по операции/документу/справочнику (примитивные расширения профилей по типам группировок обрабатываемых данных вида "Все/Группа/Таблица" как в ОС и Управлении запасами - не в счет, это суть есть попытка изобрести N-угольное колесо вместо старого (N-1)-угольного в то время, когда всем давно ясно о необходимости круглых колес ). Согласно профиля, указанного при обработке документа из набора возможных в данном модуле/для данного документа, по его строкам и настройками строк этого профиля, класс-обработчик абстрактного документа порождает нужного потомка для обрабатываемого документа и производит все необходимые манипуляции с разноской в ГК. При реализации подобной концепции профилей разноски и разноски документов в ГК по ним, а так же вышеупомянутого мной по связям документов и операций с LedgerTrans - пункты 2,3 из преимуществ реализуются на все 200 % в одной системе. Последний раз редактировалось TasmanianDevil; 29.08.2006 в 14:53. |
|
|
За это сообщение автора поблагодарили: Recoilme (4). |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|