Александр ПузаковGaryaА вот Вы, Александр, как полагаете, что быстрее работало бы - то, что использует унифицированный интерфейс для 10 субконто, единообразную структуру данных, или то, что на "на ходу" пытается "склеивать" данные с первых трех аналитических уровней, расположенных в одних структурах, с тем, что расположено в других структурах, при том, что структуры эти, ко всему прочему, не унифицированы?
Всё зависит от многиф факторов. Как то: оптимальность структуры хранения, производительность железа, пряморукость администрирующих СУБД и много другогоЯ как раз про оптимальность структуры хранения. В 1С она значительно менее оптимальна, нежели в ИНФИНе. Все эти "счета" и "регистры", по своей сути, OLAP-кубики для предоставления сводной информации в тех или иных аналитических разрезах. Когда и если ты можешь смотреть только на некоторую часть данных через один частично-унифицированный интерфейс (например, ОСВ, карточки счета и т.д.), на другие только через другой интерфейс (формы исключительно для регистров), то в конечном итоге оказывается, что ты не можешь ни в каком интерфейсе увидеть единообразно данные как в том, так и в этом разрезах.
Когда ПО накладывает непонятно кому и по какой причине пришедшие в голову ограничения, то мы получаем именно ограничения, а не возможности.
В ИНФИНе, например, справочник контрагентов можно сделать аналитическим разрезом (субконто) для нескольких разных уровней одного и того же счета. И тогда ты можешь просматривать взаиморасчеты в разрезе комиссионеров, "проваливаясь" на нижние уровни - в разрезе покупателей, которым ушел товар по договорам комиссии. А можно наоборот, просматривать взаиморасчеты в разрезе покупателей, "проваливаться" в данные покупателей и смотреть, через каких комиссионеров (возможно, нескольких разных) они приобретали наш товар. Интерфейс просматривания подобных вещей никак не подстраивается именно под эту данную задачу - он УНИВЕРСАЛЕН ! Если ты настроил счет, указал какие у него аналитические разрезы, то ты можешь уже делать по нему проводки, просматривать оборотки так и сяк, с остатками или без, в количестве или в сумме, или и в том и в другом, или в двух суммах (рублевой и валютной) - это всё настраивается "налету" тем кто что-либо хочет просмотреть. И никакие дурацкие ограничения в стиле "кто-то болван, что справочник контрагентов в качестве аналитического разреза можно использовать только один раз" ему не мешают. Если он настроит счета, необходимые для учета ценных бумаг, то сможет смотреть их как в разрезе трассатов (должников), либо в разрезе эмитентов, либо в разрезе видов ценных бумаг (вексель простой, вексель переводной, акция, облигация и т.д.), в разрезе их доходностей, сроков погашения, и еще в куче других разрезов... И при этом ты просто "крутишь OLAP-кубик" в единообразном унифицированном интерфейсе, убираешь, что не хочешь видеть, добавляешь, что хочешь. И тебе не нужно заглядывать в разные формы и отчеты, чтобы соотнести информацию на нескольких счетах, связанных с учетом ценных бумаг, друг с другом - они все вот они, в единообразном унифицированной "смотрелке", которая может выглядеть как ОСВ, а может выглядеть как "реестр учета ценных бумаг", или как "книга складского учета", или как "учетная карточка" - в зависимости от того, что тебе нужно и в каком виде, сам пользователь может настроить. Может кто-нибудь объяснить, почему пользователь 1С не может просматривать платежные поручения или банковскую выписку в таком виде, чтобы списком документов итог этих документов? Это нормально, что имея "продвинутейшее" средство автоматизации, пользователи постоянно хватаются то за калькулятор, то за электронные таблицы? В ИНФИНе всё, что хотя бы отдаленно похоже на таблицу, автоматом получает возможности подсчитывать итоги, выводить дополнительную информацию в шапках или в подвалах (которых тоже несколько), и даже производить некоторые юзер-дефайнд расчеты "на лету", если пользователь введет формулы, по которым они должны производиться. Можно, например, просматривать ОСВ по продажам через комиссионеров так, чтобы процент комиссии выводился в ней, рассчитываясь "на лету" исходя из значений добавленного в справочник "договоры комиссии" поля "процент комиссии". Для этого не нужно звать никаких кастомизаторов, программистов или прочих "продвинутых айтишников", это может сделать сам пользователь . И сам пользователь может сделать так, чтобы автоматически формировались проводки на одних счетах по им же добавленным атрубутам договора комиссии и им же добавленным формулам расчета сумм проводок, их аналитики (многие из которых могут подставляться на автомате) и корреспондирующим счетам.
Бухгалтер может смотреть ОСВ по основным средствам в разрезе их мест нахождения (например, в Москве у нас было несколько разных офисов)... В разрезе направлений их использования... В разрезе источников их приобретения... В разрезе амортизационных групп... В разрезе степени износа по БУ или степени износа по НУ... И да, если он не согласен с "типовым функционалом" расчета амортизации, он может просто ввести формулу, по которой амортизация рассчитается так, как ему нужно, а не так, как "кто-то где-то почему-то решил, что ОС в БУ и амортизируемое имущество в НУ обязано быть одним и тем же и учитываться исключительно на счете 01 БУ/НУ".

А бухгалтер самой простейшей маленькой фирмочки на УСН 15% доходы-расходы может сам настроить субсчет счета 68, указав его атрибутом КБК так, чтобы в одну кучу не сваливалась задолженность по налогу УСН и по "минимальному налогу", имеющим разные КБК и сроки уплаты. Но бухгалтер, пользующий 1С, даже такого пустяка сделать не может... И когда он налетает на штраф из-за задолженности по "минимальному налогу" при переплате по налогу УСН, он просто берет Эксель, и начинает вести учет в нем отдельно этих двух налогов "сбоку от 1С" - потому что в 1С они свалены в одну бесформенную кучу. Да, даже для киосков 1С оказывается способен вот таким образом создавать проблемы...

svcoderGarya, Я не слышал о таком требовании РСБУ, чтобы по активно/пассивному счету была необходимость учета развернутого сальдоЕсть понятие "просроченная задолженность", которая формируется в разрезе документов, ее образовавших. Резервы по сомнительным долгам в РСБУ, в НУ, и в МСФО формируются по разным правилам. Но для начала нужно видеть саму "просроченную задолженность" не в виде одной бесформенной кучи, а в разрезе документов. Сальдо взаиморасчетов по просроченной и непросроченной задолженности должно соотноситься с показателями бухгалтерской отчетности , то есть, с бухгалтерским балансом, с тем, что наблюдается глазами в оборотно-сальдовом балансе (ОСВ по всем счетам), в ОСВ по тем или иным счетам взаиморасчетов... По-человечески сделанные средства автоматизации должны позволять увидеть на счетах сальдо, которое используется и в балансе, и в расчете резервов. ОНО ДОЛЖНО БЫТЬ ОДИНАКОВЫМ! Но оно не может быть одинаковым, если аналитический разрез "документы, образующие задолженность", упрятан в регистры и никак не может быть выведен в ОСВ в виде субконто.
Еще раз, чтобы было понятно... Если цифры, которые формируются на 7-м аналитическом уровне учетного "OLAP-куба" (счета, регистра, или блаблаблистра, не важно), должны единообразно и унифицировано попадать ВСЮДУ, потому что именно на 7-м уровне находится то сальдо, которое необходимо для всех учетов и расчетов. Если учетная система имеет ограничение "максимум 3 субконто на счетах", да, его можно в какой-то степени обойти, продолжив вести аналитические разрезы за пределами счетов... Но ведь вы не получите в бухгалтерских формах, которые унифицировано берут данные именно со счетов, ту информацию, которая находится за пределами счета в каких-то костыле-дополнениях к счетам.

svcoderОднако платформа позволяет показать информационно развернутое сальдо исходя из остатков выбранных субконтоОк, создайте сбусчет 76-го счета, добавьте на него 7 аналитических разрезов и продемонстрируйте, что в ОСВ по этом счету можно видеть развернутое сальдо до любого из семи уровней. И что в ОСВ по всей совокупности счетов может попадать сальдо с 7-го уровня, а не только с 3-го. И что в бухгалтерский баланс оно попадет на автомате, даже если вы не будете курочить форму бухгалтерского баланса, именно с 7-го уровня.

svcoderУ каждого менеджера могут быть свои правила, какую задолженность считать просроченной, по разным товарам она может быть разная. Вы всего этого на счетах БУ никогда не увидете.Я говорю не про менеджеров, а про НК РФ, ПБУ 4/99 и ПБУ 21/2008 - они регламентируют расчет резервов по РСБУ и по НУ, а не "менеджеры". Если фирма вышла на IPO, то для МСФО, то еще по стандартам IFRS 9. Бухгалтер должен иметь возможность контролировать, сверять, проверять, а не только бубнить "ничего не знаю, почему там ничего между собой не сходится, программа так посчитала". Если это действительно бухгалтер, а не просто жмакатель по клавишам.

svcoderGarya1С проигрывает ИНФИНу во многом - в технических возможностях, продуманности архитектуры, скорости кастомизации, но выигрывает в более грамотном маркетинге. Вот и всё объяснение.
Да ладно, и где об этих преимуществах можно почитать? Само приложение выглядит как 1С 7.7. Как эту поделку можно это сравнивать с 1С 8.3?Я работал с ИНФИНом более 10 лет. Почитать можно в руководстве пользователя. Подавать они себя не умеют. Приложили все усилия, чтобы маркетингово угробить великолепное архитеркурное начинание. Хотя, если интересно, на этом самом форуме запустите поиск по слову "ИНФИН" и почитайте мои посты еще многолетней давности. В них довольно много конкретики.

svcoderЯ застал эпоху Гаранта. Она всегда была второсортным решением, которое предлагали распространять любому желающему. Консультант-Плюс при этом имел всего пару-тройку партнеров на миллионный город. Никаких преимуществ по сравнению с Консультант-Плюс я там не увидел, поэтому кончина была предопределена.То что Вы ее застали, это еще не значит, что во всем разобрались. В нашем холдинге использовался и Гарант, и Консультант Плюс с 1995 года. И юристы, и бухгалтера в конечном итоге стали пользоваться только Гарантом. Вот Вы говорите, Консультант Плюс был лучше. А можете привести хотя бы один пример, в чем это выражалось? Я, например, могу подтвердить свою позицию конкретными аргументами, вот пожалуйста (навскидку):
1. В Гаранте раньше, чем в Консультанте было произведено объединение информационных блоков в единую базу. В Консультанте Плюс же длительное время приходилось запускать поиск документов отдельно в разных базах и получать сообщение "документ находится в другой базе". Со временем они устранили эту проблему, но примерно на 2 года позже, чем Гарант.
2. Поиск и в Гаранте, и в Консультанте Плюс для его ускорения использовал методы фильтрации информации по ключевым словам. В некоторых видах поиска такая фильтрация включалась неявно, в частности, в контекстном. В Гаранте пользователь, который не помнил точно, как называется нормативный документ, регламентирующий правила расчета среднего заработка, не помнил, какой орган этот документ выпустил, но помнил, что понятие "*** среднего заработка" (то ли "методика", толи "правила", толи еще что-то такое по смыслу) упоминается именно в заголовке нормативного документа, мог ввести поисковый запрос, указав что фраза "средн его зараб отка " (именно в этом падеже!) должна встречаться именно в заголовке документа, получал только три документа, удовлетворяющих результатам поиска. В Консультанте Плюс ввести поисковую фразу со словами в каком-то конкретном падеже именно для заголовка документа было невозможно. Более того, кто-то из разработчиков решил, что составлять булевы выражения в построителе булевых выражений по совокупностям ключевых слов будет весьма увлекательно бухгалтерам, которые и терминов таких "коньюнкция" и "дизъюнция" не слышали. В итоге к Консультант Плюс аналогичный запрос можно было построить только в виде ("Заголовок документа" содержит "средн*") И ("Заголовок документа" содрежит "заработк*"). Результатом выполнения такого поискового запроса было несколько сот разных документов, в которых слово "заработок", в частности, встречался ранее слова "средний", и упоминались они во всех шести падежах. Далее бухгалтер должен был просмотреть порядка двухсот документов ГЛАЗАМИ, чтобы "методом тупого перебора", наконец, найти именно то, что ему нужно. Ну так вот, форма для поисковых запросов в Гарате была существенно проще и понятней юристам и бухгалтерам, не продвинутым в булевой алгебре. Они имели возможность ограничить количество возвращаемой информации так, чтобы не приходилось перечитывать глазами сотни и тысячи документов. В Консультанте Плюс такая возможность тоже появилась. Но примерно через полтора года после того как она была реализована в Гаранте.
3. В Гаранте каждый документ, помещаемый в базу СПС, проходил специальный анализ внутренней службой специалистов Гаранта, которые, добавляли свои комментарии к некоторым абзацам. Например, рядом с некоторым абзацем текста мог появиться выделенный цветом комментарий Гаранта "А еще на эту тему мы рекомендуем ознакомиться с документами тынц1, тынц2 и тынц3". В документах Консультанта Плюс таких комментариев изначально не было, были только исключительно гиперссылки на другие документы только в том случае, если сам пероисточник содержит ссылки на эти документы. В результате, если несколько разных нормативных документов не ссылались друг на друга, но регулировали некий правовой вопрос совместно, то найти всю совокупность таких документов в Консультанте Плюс было гораздо сложнее. Требовалось, во-первых, как-то догадаться, что помимо уже найденных документов имеются еще и другие примерно на эту же тему. Во-вторых, нужно было как-то догадаться, как нужно построить поисковый запрос, чтобы тебя не завалило тоннами лишней информации и при этом оказалась найдена та информация, которая тебя интересует. В Гаранте же достаточно было найти хотя бы один документ, затрагивающий некую область. Можно было быть уверенным, что если существуют еще какие-то документы, касающиеся затронутой темы, то Гарант вставит на такие документы гиперссылки в своих комментариях. Между тем, распространители Консультанта Плюс около года ходили и убеждали, что Гарант вводит пользователей в заблуждение подобными гиперссылками, что пользователи-дальтоники, не отличающие голубой от черного, могут решить, что выделенный цветом текст является частью текста самого первоисточника и т.д. и т.п.... До тех пор, пока в Консультанте Плюс не сообразили, что для пользователей такие комментарии на самом деле очень и очень полезны и не стали тоже добавлять их в документы.

Я мог бы и продолжить перечисление, но, полагаю, это и так уже достаточно объемный оффтоп.

Суть же в том, что всё, что ни делал Консультант Плюс в совершенствовании своего продукта, он, как правило, делал это с опозданием - в Гаранте новый удобный функционал появлялся существенно раньше. И делал он это, срисовывая новые идеи у Гаранта.

Справедливости ради следует сказать, что со временем оба продукта по возможностям, производительности и удобству пользования сравнялись, и сейчас ни один из них не имеет существенных преимуществ перед другим. Но примерно с 1995 года по 2005 год Гарант стабильно находился в авангарде инновационных решений.

svcoderЯ уже писал, что это вопрос веры в то, что система работает правильно. При запрете на ручные операции по счетам, по которым есть детальная аналитика в регистрах никаких расхождений не будет.А почему Вы считаете, что такой запрет - это благо? Потому что он устраняет почти гарантированные проблемы в конкретно в 1С?

В ИНФИНе в подобных запретах просто нет необходимости. Можно работать "от документа", можно "от проводки". Если пользователю потребовалось отразить редкую и особую операцию, под которую не настроен "типовой функционал", он мог сам добавить необходимые для подобных операций субсчета в систему, настроить аналитические разрезы, добавить справочники, которых в системе нет, но которые нужны. Добавить в существующие справочники атрибуты, в которых возникла необходимость для выполнения особых операций. Выполнить проводки просто на счетах, не терзая кастомизаторов "мне нужен такой-то функционал". Самостоятельно проверить, что настроенный счет попадает в нужные разделы баланса и... всё.

То, что система позволяет в 90% случаев обходиться без кастомизаторов - это ее огромный плюс. То, что она остается устойчивой к изменениям - это результат хорошо продуманной идеологии ведения учета и ее архитектуры. Хорошо сделанный продукт, автоматизирующий некую предметную область (например, бухучет) не вынуждает пользователей изучать новые области (булеву алгебру, объектную модель и метаданные "регистров" и т.п.), а подстраивается под привычные специалистам в этой области понятия - "счет", "аналитический разрез", "первичный документ", "проводка", оборотно-сальдовая ведомость, оборотно-сальдовый баланс и т.п.

Пример хорошо кастомизируемого продукта, чтобы было понятно, о чем я - Excel. Для того, чтобы настроить электронные таблицы для решения каких-то задач, не требуется изучать язык программирования, объектные модели и т.п. Достаточно понимать тривиальный язык формул. ИНФИН в этом смысле подобен Excel. Он не требует программирования для кастомизации, достаточно понимания языка формул в учетной (бухгалтерской) терминологии. Ну, может быть, совсем немного специфических обозначений: А1... А10 - аналитические разрезы и т.п. Загляните сюда 4912987 , здесь есть примеры используемых ИНФИНом в формулах обозначений.

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

svcoderGaryaПо-человечески сделанные средства автоматизации должны позволять увидеть на счетах сальдо, которое используется и в балансе, и в расчете резервов. ОНО ДОЛЖНО БЫТЬ ОДИНАКОВЫМ! Но оно не может быть одинаковым, если аналитический разрез "документы, образующие задолженность", упрятан в регистры и никак не может быть выведен в ОСВ в виде субконто.
Еще раз, чтобы было понятно... Если цифры, которые формируются на 7-м аналитическом уровне учетного "OLAP-куба" (счета, регистра, или блаблаблистра, не важно), должны единообразно и унифицировано попадать ВСЮДУ, потому что именно на 7-м уровне находится то сальдо, которое необходимо для всех учетов и расчетов.
Я уже писал, что это вопрос веры в то, что система работает правильно. При запрете на ручные операции по счетам, по которым есть детальная аналитика в регистрах никаких расхождений не будет.
Уж запрещать, так уж запрещать! Давайте запретим пользователям работать с 1С! По-моему, это сразу снимет все возможные проблемы, которые могут возникать в 1С... :)

s_ustinovGaryaЕсть понятие "просроченная задолженность", которая формируется в разрезе документов, ее образовавших. Резервы по сомнительным долгам в РСБУ, в НУ, и в МСФО формируются по разным правилам. Но для начала нужно видеть саму "просроченную задолженность" не в виде одной бесформенной кучи, а в разрезе документов. Сальдо взаиморасчетов по просроченной и непросроченной задолженности должно соотноситься с показателями бухгалтерской отчетности , то есть, с бухгалтерским балансом, с тем, что наблюдается глазами в оборотно-сальдовом балансе (ОСВ по всем счетам), в ОСВ по тем или иным счетам взаиморасчетов... По-человечески сделанные средства автоматизации должны позволять увидеть на счетах сальдо, которое используется и в балансе, и в расчете резервов. ОНО ДОЛЖНО БЫТЬ ОДИНАКОВЫМ! Но оно не может быть одинаковым, если аналитический разрез "документы, образующие задолженность", упрятан в регистры и никак не может быть выведен в ОСВ в виде субконто.
Еще раз, чтобы было понятно... Если цифры, которые формируются на 7-м аналитическом уровне учетного "OLAP-куба" (счета, регистра, или блаблаблистра, не важно), должны единообразно и унифицировано попадать ВСЮДУ, потому что именно на 7-м уровне находится то сальдо, которое необходимо для всех учетов и расчетов. Если учетная система имеет ограничение "максимум 3 субконто на счетах", да, его можно в какой-то степени обойти, продолжив вести аналитические разрезы за пределами счетов... Но ведь вы не получите в бухгалтерских формах, которые унифицировано берут данные именно со счетов, ту информацию, которая находится за пределами счета в каких-то костыле-дополнениях к счетам.

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

s_ustinovДостаточно сделать механизм “применений” (связывания разных операций между собой, чтобы, например, видеть - конкретно этот инвойс полностью оплачен или нет) - и сальдо взаиморасчетов можно строить исключительно в разрезе документов.Я с этим не спорю. Можно сделать очень много, пока ты сам ковыряешь код конфигурации. Да, в 1С можно взять данные хоть из документов, хоть из регистров, хоть еще откуда, лишь бы они хоть где-нибудь были. Проблема в том, что типовой функционал формирует сальдо в бухгалтерских формах исключительно в разрезе бухгалтерских счетов по младшему субконто. Для того, чтобы сальдо подставлялось в аналитические карточки, в оборотно-сальдовые ведомости, во все формы бухгалтерской, налоговой и статистической отчетности, однако, нужно переделывать невообразимую груду типового функционала.
Когда и если приходится перелопачивать существенную часть типового функционала, типовое решение очень быстро перестает быть типовым и стремительно превращается в "самописку" со всеми вытекающими из этого последствиями.
Существенное замечание .
Я в принципе не имею ничего против того, чтобы данные в учетной системой хранились в ненормализованном виде. И понимаю, что в ряде случаев денормализация вполне оправдана. Однако, когда и если используется денормализация, одновременно должны быть задействованы механизмы обеспечения целостности информации, ее непротиворечивости. Денормализация данных не должна приводить к неоправданным ограничениям, в частности, в унификации методов работы с информацией. Денормализация, ПМСМ, вполне оправдана, когда она происходит на нижних уровнях информационной обработки и не требует учета нюансов ее работы на уровне бизнес-логики. Ну ненормально, я полагаю, заставлять бухгалтера ломать свой мозг об 1С-овские "регистры". Нет в бухгалтерском учете такого понятия "регистр", до которого его трансформировал 1С. Вот что такое бухгалтерский регистр в изначально бухгалтерском понимании:
https://ru.wikipedia.org/wiki/Регистр_бухгалтерского_учёта Регистр бухгалтерского учёта — элемент организации бухгалтерского учёта на предприятии, предназначенный для систематизации и накопления информации, содержащейся в принятых к учёту первичных документах, для отражения на счетах бухгалтерского учёта и в бухгалтерской отчетности .
...
Учётные регистры различаются:
по внешнему оформлению: бухгалтерские книги, регистраторы, отдельные листы, карты, сведения.
по назначению: хронологические, систематические и комбинированные;
по содержанию: синтетические и аналитические;
по форме: односторонние, двусторонние, табличные и шахматные.
...
Федеральный Закон 402-ФЗ «О бухгалтерском учете» от 06.12.2011 установил с 1 января 2013 года дополнительные требования к ведению и оформлению регистров. Так, обязательными признаками этих документов стали:
наименование регистра;
наименование экономического субъекта, составившего регистр;
дата начала и окончания ведения регистра и (или) период, за который составлен регистр;
хронологическая и (или) систематическая группировка объектов бухгалтерского учёта;
величина денежного измерения объектов бухгалтерского учёта с указанием единицы измерения;
наименования должностей лиц, ответственных за ведение регистра;
подписи лиц, ответственных за ведение регистра, с указанием их фамилий и инициалов

[u]Формы регистров бухгалтерского учёта по новым правилам должен утверждать руководитель организации [/u]. ... а не разработчики 1С... :)


s_ustinovА сроки оплаты и прочую информацию, включая классификацию для целей МСФО можно хранить на уровне документов, а не плане счетов.В ИНФИНе можно иметь аналитическим разрезом документ. Я понимаю, что не во всех учетных системах такое возможно, но не вижу в принципе ничего плохого в подобной возможности. Одни только плюсы. Когда такая возможность ЕСТЬ, тогда вот такие предложения выглядят несколько странными и забавными. Возникает естественный вопрос "а зачем?". Зачем закладывать левую ногу за правое ухо, когда правое ухо, гораздо проще правой рукой, и на пути правой руки не выстроено никаких вычурных и необоснованных ограничений?

s_ustinovsvcoderИНФИН реализует некоторую концепцию построения учета, которая может быть реализована и на платформе 1С (отключив итоги можно сделать быстрым запись проводок с любым количеством субконто).
Может.
Но она - не реализована.Кстати, о птичках. Лет примерно 12 назад одна из 1С-франчей из города Иваново, ознакомившаяся с возможностями ИНФИНа, была настолько ими воодушевлена, что решила разработать собственную конфигурацию 1С а-ля-ИНФИН. К сожалению, довести свою разработку до ума так, чтобы ее возможности действительно оказались соизмеримы с ИНФИНом, они так и не смогли. Их "динамический разбор формул" тормозил так, что вместо увеличения быстродействия они получили "литку в замедленной съемке". Проект сдох до того как смог продемонстрировать какие-либо результаты.

Александр Пузаковя бы предложил спуститься с облаков к управленческому учету. Попробую на примерах описать тот управленческий учет, который я видел.Скажу больше. Можно иметь одновременно "управленческий учет", "бухгалтерский учет", "налоговый учет", "учет по требованиям IFRS", "операционный учет", "предварительный учет" и "аудированный учет", и еще десяток учетов для чего-нибудь еще. Для того, чтобы их вести, не требуется под каждый из них придумывать новый интерфейс и/или новые структуры данных. Достаточно предоставить возможности кастомизации, при которых можно создать произвольное количество планов счетов (или "регистров", если этот термин кому-то больше нравится), разработать УНИВЕРСАЛЬНЫЕ методы визуализации их содержимого для всех возможных целей и предоставить возможность делать проводки одним документом сразу по десятку планов счетов. Или сначала делать проводки на счетах (не обязательно бухгалтерских) через мощный универсальный на ходу настраиваемый пользовательский интерфейс, который можно отдать, в том числе, кладовщику, и он даже понятия иметь не будет о том, что он "формирует проводки" на каких-то там "промежуточных счетах"... А потом уже по этим проводкам генерить документы, по документам+проводки генерить новые документы и новые проводки... КОНТРОЛИРУЕМО! Например, бухгалтером. Так, чтобы по данным "промежуточных счетов" формировались уже реальные проводки на бухгалтерских счетах, а источник данных при этом блокировался бы от модификаций... И всё это БЕЗ АЛГОРИТМИЧЕСКОГО ПРОГРАММИРОВАНИЯ !!! Экселе-подобными настройками. Вот это, ПМСМ, высший пилотаж, который ИНФИН не смог должным образом на рынке преподать.

s_ustinov1С как раз попыталась "впихнуть" в фин проводки слишком много - и получила проблемы.
https://its.1c.ru/db/metod8dev/content/2732/hdoc
https://its.1c.ru/db/metod8dev/content/2752/hdoc
И регистр накопления, и регистр бухгалтерии решают одну и ту же задачу: накопление каких либо показателей в разрезе измерений. Различие заключается в том, что регистр накопления имеет жесткую структуру измерений и не поддерживает двойную запись, регистр бухгалтерии, наоборот, поддерживает двойную запись и возможность гибкой настройки измерений конечными пользователями .В ИНФИНЕ встроенными механизмами контролируется соблюдение метода двойной записи только для одного вида плана счетов - балансового. Все остальные виды планов счетов могут работать примерно как забалансовые (на которых метод двойной записи соблюдаться НЕ должен).
Очень верная цитата. Вот именно, что и регистр накопления, и бухгалтерский счет решают одну и ту же задачу. Если бы эта задача была качественно решена один раз, второго раза не потребовалось бы. А поскольку она была решена лишь частично и с огромным количеством искусственно созданных ограничений, потребовалось решать ее еще раз, уменьшив одни ограничения, но введя при этом другие.
В ИНФИН Управлении максимальное количество "субконто" на любых счетах - 10. Все настройки исключительно гибкие, которые могу выполняться НЕ программистами (в Excel-подобной концепции), в том числе, бухгалтерами. При этом достаточно эффективно решены проблемы быстродействия - 10 аналитических разрезов на порядок быстрее, чем 3 аналитических разреза в 1С.
Все экранные формы имеют очень гибкие настройки, которые можно сохранить таким образом, что их вид будет автоматически меняться в зависимости от того, кто просматривает и что просматривает. При этом имеются возможности, которых нет в 1С, например, при формировании ОСВ по счетам. В 1С можно вывести ОСВ по счету только в одном виде и один раз. Дальше, если ты "проваливаешься", например, в ОСВ по счету взаиморасчетов в обороты контрагента, открывается карточка - то есть, форма иного вида. В ИНФИНе можно настроить вывод ОСВ по счету таким образом, чтобы на верхнем уровне выводились обороты в разрезе контрагентов, а "проваливаясь" в обороты конкретного контрагента выводится опять же ОСВ, но в котором отфильтрован только один выбранный контрагент, в разрезе его договоров. "Проваливаясь" в договор, можно по такой же логике производить декомпозицию остальных 10 аналитических уровней. Причем, в любом порядке (если "субконто" не подчинены друг другу, как "Договоры" "Контрагентам"), и порядок декомпозиции - настраивается. Так называемая "аналитическая карточка" открывается на самом нижнем уровне декомпозиции, когда все аналитические уровни уже декомпозированы - выводится перечень проводок в исторической их последовательности по автоматически отфильтрованным аналитическим разрезам. Можно настроить несколько разных вариантов просмотра содержимого одного и того же счета, один будет предлагаться по умолчанию, остальные выбираются по ситуации. Можно настроить каждый уровень декомозиции - что должно выводиться именно на нем (например, на одних уровнях только рублевая сумма, на других рублевая и валютная, на третьих еще и количество, которое выбирается из корреспондирующих счетов. В 1С в ОСВ по счетам все выбранные для группировки аналитические уровни выводятся в отчет сразу-одновременно и в одном формат-варианте.

Любые таблицеобразные экранные формы в ИФИН Управлении (ОСВ, баланс, журнал документов, сам документ и т.д. и т.п.) имеют настраиваемые вычисляемые поля, шапки (их несколько) итоги (тоже несколько), которые можно размещать внизу, вверху, справа или слева... Поэтому когда и если пользователь видит, что в настроенной по умолчанию форме не предусмотрен автоматический подсчет сумм платежей из журнала банковских документов или из банковской выписки, он просто сам настраивает вывод в нужном месте нужного ему итога или подытога, а не трясет кастомизаторов, чтобы они его туда встроили.

Вывод ОСВ по счету 62, например, можно настроить таким образом, чтобы вместо фразы "Контрагент" на соответствующем аналитическом уровне выводилась фраза "Покупатель". Вместо фразы "Договор" - "Договор с покупателем". А на счете 60 выводилась бы фразы соответственно "Поставщик" и "Договор с поставщиком". Более того, уже на фазе настройки аналитических разрезов счета это можно настроить. И это не какой-то пустяк. Потому что ИНФИН позволяет ссылаться на один и тот же справочник (например, справочник контрагентов) разными аналитическими уровнями одного и того же счета. И тогда, для того, чтобы пользователь не запутался в смыслах разных аналитических уровней, уже на этапе настройки счета необходимо задать алиас, который будет выводиться по умолчанию во всех еще не настроенных формах - для учета взаиморасчетов через комиссионеров на одном уровне "Контрагент" - это "Покупатель", на другом уровне "Комиссионер". На другом счете "Контрагент - это "Поставщик", и "Контрагент" - это "Комитент".

И такая возможность декомпозиции - совсем не пустяк. Пользователь, которого интересует, например, обобщенное движение товара по всей совокупности складов, выводит "Номенклатурные группы" на самый верх, затем "Номенклатуру", затем "Склады", затем "Материально-ответственных лиц". И сначала бегло просматривает движение товара в разрезе номенклатурных групп, если какая-то номенклатурная группа привлекла чем-то внимание, то "проваливается" внутрь нее и смотрит уже движение в разрезе номенклатуры. Если данные по какой-то номенклатуре привлекли внимание, "проваливается" в нее и смотрит, на какие склады как она приходила и уходила. Далее он может "провалиться" уже в соответствующий склад", выяснить, какой кладовщик был ответственным за соответствующее движение, связаться с ним и уточнить какие-то детали. И для каждого элементарного движения достаточно нажатия одной кнопки - нет необходимости перенастраивать вывод формы. Если ответы на вопросы получены, можно "вернуться" на уровень выше и продолжить просмотр следующих позиций соответствующего аналитического разреза.
В другой ситуации, когда склады более приоритетны, он может "перевернуть" аналитические разрезы таким образом, чтобы сначала просматривалось обобщенное движение по складам, проваливаясь в склад уже бы открывалось движение в разрезе номенклатуры, которая на этом складе двигалась либо лежала без движения.

Я уже сказал о том, что ОСВ по счету в зависимости от того, кем она открывается, откуда и для чего, можно перенастроить так, чтобы ее вывод вообще не имел ничего общего с ОСВ, а был бы похож на отчет иного вида, на документ, на "Карточку складского учета" или на "Книгу складского учета". То же самое можно сделать с любой другой преднастроенной формой, имеющей вывод "по умолчанию" (в зависимости от настроек самого счета). Например, типовой функционал "аналитической карточки" подразумевает вывод в нее перечня проводок, но их можно вывести в таком виде, что на форме не будет бухгалтерских терминов "Дебет", "Кредит", "Сальдо" и т.п., а будут фигурировать более понятные для пользователя, который будет пользоваться этой настройкой "Приход", "Расход", "Остаток на начало", "Остаток на конец", также можно сделать, чтобы не выводился номер счета, а вместо него выводилась фраза "Движение товара по складам".

Таким образом, "счетами" ИНФИНа можно пользоваться хоть как "оборотными регистрами", хоть как "бухгалтерскими счетами", и даже можно пользоваться как "журналами документов". Когда и если функционал содержит ВОЗМОЖНОСТИ, а не ОГРАНИЧЕНИЯ, остается лишь воспользоваться гибкостью настроек, возможностей визуализации - и всё, уже работает хоть для оперативного учета, хоть для управленческого, хоть для бухгалтерского. Хоть на складе, хоть в плановом отделе, хоть в бухгалтерии, хоть еще где-то. Нет необходимости плодить сущности без необходимости. При этом вывод ОСВ по "управлеческому" 41-му счету кладовщик будет просматривать, даже не подозревая о том, что это ОСВ - он будет видеть исключительно складскую терминологию. А бухгалтер, если ему позволено просматривать тот же самый счет, может просматривать его так как более привычно бухгалтеру.

s_ustinovФин учет должен иметь возможность работать в асинхронном режиме.Само собой. Именно поэтому бухгалтер должен иметь возможность автоматизированно выполнить проводки на бухгалтерских счетах, опираясь на данные "вспомогательных операционных счетов", с заглядыванием в те или иные документы и уточнением той или иной информации. Именно поэтому 1С-овская возможность формирования проводок "от документа" - это от ограниченного понимания сути проблемы.

Когда и если учетная система требует обязательной предварительной настройки любого документа, который в ней должен быть учтен, она сама себя ограничивает. Каждая специфическая операция, которая требует отражения в системе, но по ней не оказалось предварительно настроенного документа, тут же создает серьезную проблему. Когда и если таких ситуаций лавина (а у нас было именно так), тогда и выясняется, насколько удачно был в свое время выбран именно ИНФИН, а не 1С. Ну вот, например, создан филиал или представительство за рубежом, по которому нужно считать зарплату в валюте иной страны и начислять налоги по правилам иной страны, с учетом при этом нюансов начисления амортизации по ОС, находящимся в этом самом представительстве, в валюте... В ИНФИНЕ - три дня (максимум - неделя) - и всё настроено. В 1С - это целый "проЭкт", продолжающийся годами, пока не будут выявлены все плюхи, добавленные в процессе куроченья типового функционала, ломающего этот самый типовой функционал в тех местах, где он прежде нормально работал.
Когда и если нужно настроить учет путевых листов, списание ГСМ по нормативам в БУ и в НУ, то в ИНФИН примерно за 4 часа делается нужная настройка - и вперед! В 1С это либо корежить типовой функционал, либо "рядом" внедрять специализированную конфигурацию для автотранспортных предприятий, которую "интегрировать" с основной конфигурацией.
Когда и если нужно настроить учет вспомогательного производства "Буфет" или "Заводская столовая", в ИНФИНе это настраивается за неделю - рецепетура, стандартные операции для учета прихода, списания, продажи по талонам и без... В 1С - это еще одна специализированная конфигурация для предприятий общепита, которую нужно устанавливать "рядом" с основной и опять настраивать интеграцию... А когда и если транспорт собственного транспортного подразделения задействуется для собственного буфета, а в буфете кормятся водители транспортного подразделения, то в 1С начинаются "проблемы зоопарка приложений". В ИНФИНе таких проблем нет, потому что он продолжает без напряга оставаться одним приложением.

Но самое главное не это, не "специализированные участки учета". Самое главное - это вообще "НЕ УЧАСТКИ", а просто относительно редкие, но при этом НЕ ТИПОВЫЕ операции. У нас это было сплошь и рядом. То груз прошел транзитом через несколько границ, то внезапно купили ценные бумаги нового вида, то "неамортизируеммое имущество" в НУ необходимо переквалифицировать в товар (поскольку задним числом принято решение о необходимости его перепродажи), оставив его в БУ на счете 01, то еще много чего подобного... Тогда бухгалтер НЕ бежит к кастомизаторам 1С-никам "внедрите мне такой-то новый функционал!" - ну невозможно, когда через 3 дня нужно закрывать месяц, в котором уже все эти операции должны быть отражены... Нужные счета с нужными аналитиками создаются "на ходу" самим бухгалтером. Если он считает, что ручных операций достаточно, он этим ограничивается - и тут же выполняет необходимые проводки, которые корректно отражаются и в БУ, и в НУ. А если он понимает, что необходимо автоматизировать расчет разниц по некоторым видам ценных бумаг, да еще и настроить "напоминалки", чтобы бухгалтер не забывал проконтролировать текущую стоимость таких-то ценных бумаг, публикуемых на таких-то ресурсах, то требуется еще немного шевелений - часа на два примерно. И хоп - всё работает! И на вопрос "откуда на этом счете взялась вот эта цифра" ни один бухгалтер, пользующийся ИНФИНом, никогда бы не ответил "программа так посчитала", потому что он сам настраивает программу так, чтобы иметь возможность отвечать на подобные вопросы .

"Стандартные операции" ИНФИН Управления позволяют автоматизировать формирование в учетной системе чего угодно - проводок по другим проводкам, документов по другим документам, проводок по документам, документов по проводкам, документов по проводкам и документам, проводок по документам и проводкам... И это гораздо-гораздо-гораздо более полезный и более универсальный функционал, нежели формирование проводок по документам одним-единственным способом, "зашитым" в 1С, или формирование одних документов "на основании" других.

Ну, простой пример для иллюстрации. Комиссионер продает товар нескольких разных комитентов по разным договорам. В одних договорах сумма комиссии фиксированная, в других в виде процента от суммы продажи, в третьих в виде процента от стоимости передачи между комитентом и комиссионером, в третьих совокупность фиксированной суммы и процента от того или этого. Одни договоры комиссии оговаривают цену продажи, которую комиссионер не имеет права изменять, другие предоставляют комиссионеру определенные рамки, в которых он может варьировать продажную цену, третьи предоставляют комиссионеру полную свободу управления продажной ценой. Необходимо автоматизировать формирование всех операций (и соответствующих документов, и проводок), в частности, акты приема-передачи товара от комитента комиссионером, возвраты непроданного товара от комиссионера комитенту, операции управления продажными ценами с контролем соблюдения правил соответствующих договоров, автоматизированное формирование отчета комиссионера с учетом параметров соответствующих договоров комиссии, автоматизированное формирование проводок, в том числе, по НДС... Для 1С такая задача - "мама-не-горюй-проЭкт"... Для ИНФИНа - вопрос примерно 3-5 часов настроек. На справочнике "Договоры с комитентами" настраиваются дополнительные поля, в которых в параметризованном виде вводятся все базовые параметры, необходимые для подобных расчетов. Настраиваются новые документы, их поля. В стандартных операциях настраивается, что откуда должно подставляться на полном автомате без возможности откорректировать содержимое этого поля, что с возможностью коррекции... Настраиваются счета, на которых формируются проводки либо по документам, либо по операциям на вспомогательных счетах, либо и по тому, и по другому. Отчет комиссионера может сформироваться по пулу документов, либо по пулу проводок, либо и по тому, и по другому, с автоматическим расчетом суммы комиссии, параметры которой указаны в соответствующих полях договора комиссии...

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

А еще стандартные операции использовались в ИНФИНе просто для того, чтобы сократить потребность в ручном вводе просто для формирования "значений по умолчанию". Они сами настраивали "стандартные операции" просто когда им лень было лишний раз шевельнуть клавишами, подставляя для себя наиболее часто используемые значения. Именно поэтому бухгалтеры оказались в глубоком шоке, когда переходили с ИНФИНа на 1С - когда выяснилось, что объем ручного ввода в 1С на порядок больше. Что невозможно в принципе, например, для операции "приход ТМЦ от поставщика" настроить ввод таким образом, чтобы поставщик предлагался по умолчанию такой-то, чтобы номенклатура по умолчанию предлагалась из пула номенклатуры, ранее поставлявшейся именно этим поставщиком, но с возможностью при необходимости расширить просматриваемый перечень или добавить новую запись. Что в 1С нужно многократно в разные места вводить одну и ту же информацию, что невозможно в самой системе посчитать сумму оплат, поступившим по формулировкам платежей, содержащих такую-то фразу (нужно хвататься за калькулятор). И т.д. и т.п. В итоге выход из ситуации, конечно же, нашли - расширили штат бухгалтерии примерно в 2 раза. И штат "сопровожденцев учетных систем" в 4 раза.