И какая логика ведения РСБУ и НУ в Аксапте?!

[mazzy]

Цитата:

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

Ваучер+Дата - есть, но ее недостаточно для задачи.

Правильно. Потому что вы не полностью используете возможности Аксапты.
На самом деле Ваучер+Дата+Счет+Фин.аналитика

Цитата:

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

Связи, достаточной для задачи сверки до элеменарного, т.е. неделимого , уровня детализации - нет.

Вы неправильно формулируете задачу - отсюда и проблема.

Произвольной сверки - нет. Но ее и не нужно.
Есть сверка до уровня, который изначально заложен в план счетов.

Единица учета в ГК - субсчет+фин.аналитика. Все.

Поэтому:

• Хотите сверку до каждой номенклатуры/клиента/поставщика - сделайте отдельные субсчета для каждой номенклатуры/клиента/поставщика
• Хотите сверку до уровня групп - сделайте отдельные субсчета для каждой группы
• Не хотите сверку - сделайте один субсчет (помойку)
• Хотите сверку для особо важных номенклатур - сделайте для них отдельные субсчета, а для остальных сделайте субсчета по группам или субсчет-помойку
• хотите контролировать не остатки, а дебетовые/кредитовые обороты - создайте отдельные субсчета для прихода и для расхода (аксапта сама будет делать между этими субсчетами проводки в момент сопоставления/закрытия)

Вам пытаются это втолковать.
Вы сами определяете что и до какого уровня сможете сверять в ГК.
Вы сами определяете объем информации, которая попадает в ГК.
В определяете это на этапе формирования плана счетов.

Следовательно задача не в том, чтобы получить произвольную связь для произвольной сверки.
Задача в том, как сделать план счетов таким, чтобы его было достаточно для задач 1),2),3),4) ... N-1), N).
Обратите внимание, что задачи вам должны быть известны заранее.
В этом и есть проблема: Многие заказчики очемнь смутно представляют какие цели они хотят достичь, завершив внедрение.

[mazzy]

Цитата:

Сообщение от Raven Melancholic

(достаточно посмотреть на судоржные попытки определения исходного документа на российском слое)

Дык, среди локализаторов сидят наши же люди.
Многие из них тоже 1Совскими терминами думают

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

А ведь это врожденное свойство международного функционала Аксапты...

[glibs]

Цитата:

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

...
Ваучер+Дата - есть, но ее недостаточно для задачи.
...

Еще есть:
LedgerTrans.TransType
LedgerTrans.Posting

Стандартный отчет по выверке работает по ним.

Еще важно правильно генерить номера ваучеров ГК. Тут неоднократно спрашивали что такого случится, если сделать проводку между двумя клиентами, например. Это как раз к этой теме относится.

Итак, мы пришли к следующему, получается:
- Связь есть.
- Она реализована до определенного уровня (группа проводок в синтетическом учете с группой операций в аналитическом модуле).
- Она не очень удобна для глобальной выверки, но вполне приемлема для расковыривания основания конкретной операции.
- Российские бухгалтеры такой механизм наверняка будут считать неудобным или и того хуже.
- В теории бухучета и в законодательстве требований по наличию глобальной выверки нет.
Так?

[TasmanianDevil]

Цитата:

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

Правильно. Потому что вы не полностью используете возможности Аксапты.
На самом деле Ваучер+Дата+Счет+Фин.аналитика

Счет не всегда помощник, один счет может быть назначен какой-то группе учетных сущностей и будет един для какого-то множества физических и финансовых движений, хотя экземпляров этой сущности в рамках этого физ. движения пройдет совсем не одна. Фин. аналитика ? Как ? Неужто дублировать справочник каких-то учетных сущностей в справочник фин.аналитик ? Вы же противником этого были ? В противном случае мы мало чего достигнем этим .

Цитата:

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

Есть сверка до уровня, который изначально заложен в план счетов.

mazzy, я в курсе и понимаю к чему Вы клоните - но не дело это, в один физический уровень аналитического измерения, коим является счет ГК, пихать потребные несколько логических аналитических измерений. Максимум два уровня - счет и субсчет. В противном случае это повлечет и раздутие самого справочника счетов ГК за счет перемножения всех тех справочников, что мы захотим запихать в него, и колоссальную трудность разделения и манипуляций данными при анализе по элементам этих справочников.

Цитата:

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

Единица учета в ГК - субсчет+фин.аналитика. Все.

Поэтому:

• Хотите сверку до каждой номенклатуры/клиента/поставщика - сделайте отдельные субсчета для каждой номенклатуры/клиента/поставщика

Отдельный счет в плане счетов по учетной сущности - спасибо, конечно, но оно и даром не нужно, ибо проходили уже - дикие количества профилей разноски, необходимость точно их соблюдать и не дай бог перепутать. Номенклатур, для примера, у нас более 30 тысяч, важных тысяч 5. Заводить для каждой из них около 40 (точно не помню кол-во настроек по всем действиям по номенклатуре по заказам,закупкам, складам и производству) записей в профилях разноски номенклатуры - не самый лучший вариант, да и план счетов в таком случае превращается в уродливое нетехнологичное дерево с длиннющими корнями (помнится, проскакивала тема, где у одного джентльмена, пошедшего по такому пути SQL просто отказался сгенерированный запрос исполнять по одному итоговому счету)

Цитата:

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

Вы сами определяете что и до какого уровня сможете сверять в ГК.

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

Цитата:

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

Вы сами определяете объем информации, которая попадает в ГК.

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

Цитата:

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

Обратите внимание, что задачи вам должны быть известны заранее.
В этом и есть проблема: Многие заказчики очемнь смутно представляют какие цели они хотят достичь, завершив внедрение.

Задачи известны, другое дело , что адекватных людей, способных трезво в общих чертах сопоставить потребности от системы с ее возможностями на основе анализа архитектуры хранения и связи данных, бывает раз-два и обчелся, и никто из них не входит в узкий круг ограниченных лиц, реально решающих вопрос о выборе и внедрении. У меня, к сожалению, именно такой случай - и система внедрена, несмотря на все предостережения, и от требований никто отказываться не собирается.

[mazzy]

Цитата:

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

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

Ну, дык не делайте так.
А если делаете, то отчего ж удивляетесь, что нельзя сделать выверку?

Цитата:

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

Неужто дублировать справочник каких-то учетных сущностей в справочник фин.аналитик ?

Правильно. ДУБЛИРОВАТЬ - не надо.
Выделять главные направления, определять требуемый уровень сверки, продумать производительность. И в конце концов принять ОСОЗНАННОЕ решение - надо.

Цитата:

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

но не дело это, в один физический уровень аналитического измерения, коим является счет ГК, пихать потребные несколько логических аналитических измерений.

Не пихайте несколько.
Кажый субсчет для своей цели. Каждый субсчет должен иметь отдельный смысл, требуемый для получения финансовой отчетности и решения задач 1), 2), 3), ... N-1), N)

Цитата:

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

Максимум два уровня - счет и субсчет.

С какой это стати?
Слушайте, выкиньте из головы 1С и ее жесткую гнездовую структуру, христа ради!

Cчетов может быть сколько угодно.
Итоговые счета могут суммировать счета в произвольном виде.
В настройках итогового счета можно указать несколько диапазонов счетов, можно указать хоть по одному счету из разных диапазонов.
Каждый счет может входить в несколько итоговых.
В отчет могут входить разные счета. Причем, не обязательно подряд.

Снимите шоры с глаз.

Пример:
90.1. Реализация (итог по диапазону 90.1-90.1.9999, как привыкли русские бухи)
90.1.11. Реализация лампочек
90.1.12. Себестоимость лампочек
90.1.13. НДС лампочек
90.1.21. Реализация розеток
90.1.22. Себестоимость розеток
90.1.23. НДС розеток

а теперь итоговые счета, как может Аксапта, но не умеют русские бухи
90.9.1. Реализация (суммирует 90.1.11 и 90.1.21)
90.9.2. Себестоимость (суммирует 90.1.12 и 90.1.22)
90.9.3. НДС (суммирует 90.1.13 и 90.1.23)
90.9.6. Реализация без НДС (суммирует 90.1.11, 90.1.21 и 90.1.13, 90.1.23. НДС можно с обратным знаком. Да, Аксапта это умеет)
90.9.7. Валовая прибыль (суммирует 90.1.11, 90.1.21 и 90.1.12, 90.1.22)
и т.п.

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

Ну с какой стати "два уровня"?!!! О чем вы говорите?!!!

Цитата:

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

В противном случае это повлечет и раздутие самого справочника счетов ГК за счет перемножения всех тех справочников, что мы захотим запихать в него, и колоссальную трудность разделения и манипуляций данными при анализе по элементам этих справочников.

Вот что меня безмерно удивляет... Так это вот такое бездумное беспокойство о "производительности".
А вы думаете как 1С получает итоги по субконто?!!!
1С не делает промеэжуточных итогов и не раздувает?
Ну, почитайте http://1c.mazzy.ru/articles/generation1c/
Вот здесь как решили http://1c.mazzy.ru/articles/mymistake/

Смотрите еще раз:

Цитата:

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

ВЫ САМИ определяете что и до какого уровня сможете сверять в ГК.
ВЫ САМИ определяете объем информации, которая попадает в ГК.
В определяете это на этапе формирования плана счетов.

Нужна детализация - сделайте (но будет больше данных и надо будет продумывать вопросы производительности)
Нужна производительность - уменьшите детализацию.
Все в ваших руках.

Цитата:

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

Отдельный счет в плане счетов по учетной сущности - спасибо, конечно, но оно и даром не нужно, ибо проходили уже - дикие количества профилей разноски, необходимость точно их соблюдать и не дай бог перепутать.

Точно-точно. Фигня то какая - сначала подумать, потом еще настроить, а потом (ужас то какой) еще и соблюдать придется!

Цитата:

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

Номенклатур, для примера, у нас более 30 тысяч, важных тысяч 5. Заводить для каждой из них около 40 (точно не помню кол-во настроек по всем действиям по номенклатуре по заказам,закупкам, складам и производству) записей в профилях разноски номенклатуры - не самый лучший вариант, да и план счетов в таком случае превращается в уродливое нетехнологичное дерево с длиннющими корнями

Угу. Гораздо лучше иметь неуправляемые промежуточные итоги по всем 40 тысячам номенклатур...

Итак, у вас важных всего 5 из 30 тыс (16%).
Эти важные наверняка группируются каким-то обозримым образом.
Наверняка имеется несколько десятков групп и один-два ответственных за эти группы.

Что предлагает Аксапта:
1. ни в коем случае не делать универсальные промежуточные итоги для произвольной сверки (на всякий случай)
2. думать
3. опять же подумать
4. еще раз подумать
5. настроить
6. потом система будет контролировать исполнение задуманного.

Цитата:

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

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

Вот именно.

Цитата:

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

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

Ну, дык, не ВПИХИВАЙТЕ. Думайте.

Цитата:

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

Задачи известны, другое дело , что адекватных людей, способных трезво в общих чертах сопоставить потребности от системы с ее возможностями на основе анализа архитектуры хранения и связи данных, бывает раз-два и обчелся, и никто из них не входит в узкий круг ограниченных лиц, реально решающих вопрос о выборе и внедрении. У меня, к сожалению, именно такой случай - и система внедрена, несмотря на все предостережения, и от требований никто отказываться не собирается.

Здесь вы конечно же не правы.
Ведь эти люди со стороны заказчика как то работали и разбирались с 40тыс. позиций и без системы учета.
Просто скорее всего пришли аналитики/консультанты/программисты и не разбираясь в сути задачи наваяли что-то "универсальное". А выяснилось, что это универсальное нафиг никому не нужно, поскольку не решает вполне конкретных задач вполне конкретных людей.

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

Цитата:

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

А что делать, коли такая архитектура и "брат Митька помирает, ухи просит"

Исправлять дешевле причину, а не бороться со следствием.

Цитата:

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

В первом приближении - не вопрос. Во втором - засада, мы уж как-нибудь по старинке, синхронизацией в финаналитику перезимуем. Поясню, почему именно так - на каждый уровень у EDT можно завязать только всего один справочник. Памятуя об ограничении в 16 на кол-во сегментов в индексе для статистики и наличии DataareaID в индексах - максимум 15 справочников можем поиметь(а в реальности чуть более 10). Их потребно больше, по крайней мере у нас - на физическом уровне уживаются 2-3 справочника, разделенные доп. признаком. А зачем все это ? Да хотя бы чтобы не напрягаясь по времени и затраченным усилиям , строить модульные и ГКшные ОСВ в детальных разрезах единых аналитик, позволяющие нам досконально отверять физический модульный и финансовый учеты, оперативно и наглядно, вплоть до пооперационной детализации, доказывать его достоверность и находить между ними несоответствия и ошибки.

Ну и глупость это. Представляете себе количество клиентов сотовой связи? И что, по ним оператор ОСВ формирует? Наверное, нет. Логично?

Цитата:

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

Мы являемся открытым акционерным обществом, у нас ведутся операции с паями и акциями, мы являемся эмитентами векселей и используем их и сторонние векселя в расчетах как с внешними, так и с внутригрупповыми структурами на протяжении десятка лет - мы можем считаться профессиональными участниками рынка ЦБ ?

Навскидку не скажу. А вот как вы учитываете ценные бумаги, было бы интересно знать.

Цитата:

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

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

Ничего не понял, честно. Термин "аналитические счета" что означает в данном контексте?

Цитата:

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

Будьте добры, конкретизируйте в таблицах Axapta, где хранятся движения по аналитическим счетам - очень любопытен сей момент и почему они могут совпадать и не совпадать . Уж не модульные ли ~Trans'ы Вы имеете ввиду под движением по аналитическим счетам ?
Если это так, то очень интересно получается. Синтетический счет является обобщенным разрезом финансового учета по какому-то направлению деятельности, аналитические счета предназначены для детализации синтетических счетов по более предметным и конкретным секторам финансового учета в рамках этого синтетического счета. Как может физическое движение (модульные ~Trans'ы) быть элементом финансового движения ? Или рассказы про разделение физического и финансового движения в Axapta не соответсвуют истине ? Или я чего-то фундаментально не понимаю ?

Масло масляное. Движение в модулях может быть финансовым, а может и не быть. Я это своим слушателям на каждом своём тренинге разъясняю

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

Цитата:

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

Задачи известны, другое дело , что адекватных людей, способных трезво в общих чертах сопоставить потребности от системы с ее возможностями на основе анализа архитектуры хранения и связи данных, бывает раз-два и обчелся, и никто из них не входит в узкий круг ограниченных лиц, реально решающих вопрос о выборе и внедрении. У меня, к сожалению, именно такой случай - и система внедрена, несмотря на все предостережения, и от требований никто отказываться не собирается.

Это очень частое явление Я бы сказал, повсеместное. Сочувствую, но вариантов реально мало. А если не удастся убедить руководство переделать "по-уму", насколько получится (а, может, и переделывать бесполезно - стоимость "переделки" выше потенциальных убытков от ручного труда и потерь производительности, у нас такие случаи были), то вы обречены вечно делать это "хотелки"

[gl00mie]

Очень занимательное обсуждение

Цитата:

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

Отдельный счет в плане счетов по учетной сущности - спасибо, конечно, но оно и даром не нужно, ибо проходили уже - дикие количества профилей разноски, необходимость точно их соблюдать и не дай бог перепутать.

Я, может, чего-то не догоняю, но зачем заводить «дикие количества профилей разноски»? Там же есть штатные варианты связи: таблица/группа/все. Можно в рамках одного-единственного профиля разноски настроить отдельные счета для тех же номенклатур-исключений (или какой-то их группы, или нескольких их групп) и отдельные - для всех остальных. В результате пользователи будут везде видеть один и тот же профиль разноски, а счета будут использоваться при разноске разные в зависимости от кода или группы той же номенклатуры.

Цитата:

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

Номенклатур, для примера, у нас более 30 тысяч, важных тысяч 5. Заводить для каждой из них около 40 (точно не помню кол-во настроек по всем действиям по номенклатуре по заказам,закупкам, складам и производству) записей в профилях разноски номенклатуры - не самый лучший вариант

«Человек должен думать, а компьютер - работать» © кто-то из IBM. Для чего, спрашивается, придуманы те же job'ы - чтобы все действия, в т.ч. по настройке, делать вручную?..

Цитата:

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

да и план счетов в таком случае превращается в уродливое нетехнологичное дерево с длиннющими корнями

Вам шашечки или ехать?..