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

[romulis]

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

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

[petr]

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

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

[kosenkov]

Цитата:

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

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

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

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

[ppson]

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

[slava09]

Цитата:

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

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

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

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

[ppson]

Цитата:

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

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

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

[slava09]

Цитата:

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

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

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

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

[TasmanianDevil]

Цитата:

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

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

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

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

[Михаил Андреев]

Цитата:

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

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

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

Цитата:

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

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

Хм. С любым журналом ГК будет то же самое, если поле "Уровень детализации" установить в значение "Сводка".

[TasmanianDevil]

Цитата:

Сообщение от Михаил Андреев

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

И от этого грустно ...

[Михаил Андреев]

Цитата:

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

И от этого грустно ...

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

[ppson]

Цитата:

Сообщение от Михаил Андреев

А мне грустно оттого, что вместо обучения наших бухгалтеров и финансистов из стройной логики системы делают непонятно что.

Запустите выверку модуля налогов с главной книгой.
Вот там и увидите стройную логику системы.

[Gustav]

Цитата:

Сообщение от Михаил Андреев

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

Ох, +1 !

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

В группе нас было человек 20: мужиков - 2, остальные - девушки разных возрастов. Учила нас достаточно взрослая тетенька, заточенная, естественно, на ручные технологии времен Луки Пачоли. И рисовали мы эти "шахматки" и "самолетики"... И всякие другие таблицы вида перекрестного... В общем, к середине курса от моей стройности не осталось и следа - в голове была полная каша...

Усилием воли и от нежелания выброса на ветер кровных собственных активов я эти курсы-таки закончил. А сам утвердился в мысли, что бухгалтеров в ВУЗе нужно начинать учить не с заучивания плана счетов, а с глубокого погружения в мир реляционных БД и только на старших курсах говорить: "Так вот, у птичек то же самое!".

Мораль: "Не дадим бухгалтерам нас оседлать! Оседлаем их сами!" (ну, или постараемся...)

[kosenkov]

Цитата:

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

А сам утвердился в мысли, что бухгалтеров в ВУЗе нужно начинать учить не с заучивания плана счетов, а с глубокого погружения в мир реляционных БД и только на старших курсах говорить: "Так вот, у птичек то же самое!".

Мораль: "Не дадим бухгалтерам нас оседлать! Оседлаем их сами!" (ну, или постараемся...)

Как и везде, среди бухов есть как пустоголовые курицы, для которых за шахматкой и планом счетов - пустота и мрак, так и вполне профессиональные тетеньки, которые рубят фишку как капусту и для которых что шахматка, что 1С, что Аксапта - только инструмент.
А начинать учить нужно бухов не реляционным БД, а экономике. Правда, реальное понимание ИМХО все равно приходит только с опытом.

[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. Купили ли бы Вы такую систему?

[MironovI]

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

[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 (заказ,закупка, складской журнал) создавать бухгалтерские проводки" в Аксапте реализована приемлемо. Приемлемо настолько, что любой партнер в силах ее "долизать" до конкретных требований. Вот вторая часть задачи может быть вынесена в отдельное приложение, что в принципе уже и так всеми сделано. Я хочу сказать, что отчеты гораздо удобнее и приятнее строить сторонними средствами, но данные всетаки получать из первоисточника.
Считаю, что указанные проблемы полность перекрывают преимущества.