Александр ПузаковGaryaВозможно, избавившись в 1С от поддержки (а без снятия типовой конфигурации с поддержки предложенное "настроить элементарно" не получится) и превратив тиражную систему в той или иной степени в самописку, в 1С можно решить любую задачу.
Вот только зачем покупать тиражную систему (в частности, 1С), если у предприятия есть кого занять написанием кода?
В 1с версии 8.3 появился механизм расширений конфигурации , и теперь снимать конфигурацию с поддержки не обязательно. Причем и раньше снимать конфигурацию с поддержки не нужно было, достаточно было включить возможность редактирования нужных объектов. Да, дальнейшее обновление конфигурации это осложняло, но если изменения вносить грамотно, то ничего страшного в этом нет.Интересно. Это очень серьезный шаг вперед. Спасибо за информацию.

Александр ПузаковGaryaЗачем вообще покупать то, что наверняка потребует переписывания исходного кода? Как бы Вы отнеслись к разработчику операционной системы, который предлагал бы переписать исходный код проданной им операционной системы, если бы в ней какое-либо приложение невозможно было бы запустить или если бы копирование основной массы файлов работало бы нормально, за исключением файлов PDF?
Некорректно сравнивать операционную систему и программу для автоматизации учета и управления. В случае с операционной системой используются низкоуровневые технологии, и тут пользователь использует то, что ему предлагает разработчик, другое пользователю и незачем, да он другого и не знает. В случае с УПРАВЛЕНЧЕСКОЙ (!) программой всё совершенно иначе - тут уже у каждого предприятия свои стандарты ведения учета и свои подходы к бизнесу, единственно правильного решения нет и быть не может, поэтому нужна кастомизация...Это распространенное мнение, но моё от него отличается... :)
Есть масса весьма продвинутых RAD и языков программирования, которые позволяют очень быстро и удобно сделать какие-то прикладные приложения, в которых заполняются некие формы исходными данными, производятся некие расчеты, результат которых выводится на экран в том или ином виде... Однако, не настолько быстро и удобно, как в электронных таблицах. Поэтому не смотря на "великую мощь" алгоритмических RAD, для решения текущих задач ни одна из систем не может сравниться по популярности с MS Excel. Концепция электронных таблиц такова, что позволяет минимальными усилиями получить максимальный результат в очень широком диапазоне задач и без использования алгоритмического программирования (не смотря на то, что VBA там тоже есть, пользуются им минимум миниморум всех пользователей).
Да, электронные таблицы не дотягивают до того, чтобы быть средством разработки достаточно сложных учетных задач с одновременным доступом многих пользователей к различным группам данных. Но тут важно понимать, что смена концепции, новый взгляд под совершенно новым ракурсом в принципе способен дать такой профит в удобстве пользования и кастомизации, который не может дать никакая система с упором на встроенное алгоритмическое программирование.
Мне довелось поработать с учетными системами и с кнопочно-флажочной кастомизацией, которую сколько сложной и запутанной ни делай, всегда не хватает (не дай бог, не подумайте, что я их сторонник), и с учетными системами, в которых кастомизация производится посредством переписывания исходного кода, вроде 1С, который предлагается, по сути, "присоединиться к разработчику", то есть, бьет из пушки по воробьям. С моей точки зрения, оптимальные возможности кастомизации - это золотая середина, excel-подобная концепция. И мне довелось с такой поработать - это ИНФИН. Там нет никакого "языка программирования", но это нисколько не мешает реализовать "всё что сердцу может быть мило". Конечно же, тут огромное значение имеет, насколько разработчик заранее всё продумал и систематизировал.

Это очень важно, чтобы у поставщика кастомизируемой системы не было каши в голове, а у разработчиков 1С это уже не каша - это каша из множества каш. Не нужно придумывать "правила" и "ограничения", зациклившись на своей концепции, чтобы потом постоянно в них упираться, нужно от них избавляться. Нашел правило или ограничения - ок, давайте подумаем, что сделать, чтобы его не было. Просто - чтобы его не было !

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

Чем, в принципе, отличается 1С от, например, того же MS Access? И там, и там есть возможность переписать исходный код приложения, некая среда разработки... Говорят, среда более ориентирована на учетные задачи - да ничего подобного, если вот так вот размножены сущности без необходимости, и каждая сущность слегка недосущность...
...
В общем, к хорошему привыкаешь быстро. А отвыкнуть - сложно. Подобные "пустяки" (каковыми их, судя по всему, полагают в 1С), и каковых на многие порядки больше, нежели тут озвучено, в 1С вызывают изрядное раздражение. Извините за излишнюю эмоциональность...

Последний выдох ГПЖGaryaСам подход "мы тут что-то натяпляпали, если вам вдруг что-то не понравится, перепишите", вызывает у меня отторжение. Зачем вообще покупать то, что наверняка потребует переписывания исходного кода?

переписывается не исходный код а бизнес-логика...

ЗЫ "подход не держите его так" вам ближе?А в MS Access при программировании на VBA тоже бизнес-логика переписывается? В чем принципиальная разница - я ее не вижу? Самописка на VBA или самописка на языке 1С - в чем отличие? В том, что во втором случае использованы страшные термины вроде "регистр"? А толку-то от этого использования, если потом "счета" и "регистры" требуется "склеивать в одну таблицу"? Еще не известно, что труднее - склеить непонятно по каким причинам разделенное, или сразу написать, оперируя "таблицами" без разделения сущностей, так что и склеивать будет не нужно.

Последний выдох ГПЖGaryaчтобы при попытке добавить новый документ поля сразу заполнялись бы наиболее часто используемыми значениями...

эмм... вообще то это реализовано давно...

на двух уровнях в типовых:

1. на уровне бизнес-логики

- из "типовых настроек" для пользователяМожет быть, я чего-то не знаю?
Типовая конфигурация 1С:Бухгалтерия 8.3.6.2152 - достаточно новая?
Захожу в "Администрирование" -> "Персональные настройки", вижу только "Основное подразделение" и "Основной склад". И это всё?
А как сделать, чтобы в документе "Поступление товаров (накладная)" (ПТиУ) автоматически предлагался одному пользователю тот поставщик, и тот договор, с которым как правило работает он, а другому пользователю другой поставщик и другой договор? Как указать, чтобы зачет аванса автоматически не производился, чтобы не делать это в каждом документе? И это только по одному виду документа...
Или для такого пустяка нужно конфигурацию с поддержки снимать?

Последний выдох ГПЖGaryaв бухгалтерских отчетах развернуть сальдо активно-пассивных счетов взаиморасчетов до уровня документов - невозможно

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

Последний выдох ГПЖGaryaЗачем, например, "регистры сведений" и отдельно "справочники" - разве у них не схожие возможности и предназначение?

разные сущности. и хранятся по разномуА эта "разность" она действительно необходима? Если, например, "Курсы валют" сделать подчиненным справочником (а не "регистром сведений") к справочнику "Валюты", и при этом в нем будет поле типа "дата", по которой можно будет найти курс по состоянию на любую дату посредством функции выбора записи по условию на такую-то дату, а в справочник "Валюты" добавить вычисляемое поле, которое бы отображало самый последний курс из подчиненного справочника, что принципиально изменится?

Последний выдох ГПЖGarya8.3.6.2152

это версия платформы, а не конфигурацииВерно. От усталости фигню-с спорол-с, извиняюсь. 3.0.42.37.

Последний выдох ГПЖза свежие типовые не скажу, в упп >> 20 значений для заполнения - примерно так выглядит:

В бухгалтерии картинка другая.

Последний выдох ГПЖGaryaЕсли, например, "Курсы валют" сделать подчиненным справочником (а не "регистром сведений") к справочнику "Валюты", и при этом в нем будет поле типа "дата", по которой можно будет найти курс по состоянию на любую дату посредством функции выбора записи по условию на такую-то дату, а в справочник "Валюты" добавить вычисляемое поле, которое бы отображало самый последний курс из подчиненного справочника, что принципиально изменится?

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

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

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

А в 1С сколько переделывать-переписывать, на сколько грабель попутно наступив?...

Про НДС, распределяемый по направлениям деятельности с разными ставками налога или расчет амортизации по модернизированным ОС я уже вообще не говорю... Как они там считаются, никто из пользователей никаким образом проверить не способен, не получив вывих мозга. И почему-то в ИНФИНе всю эту информацию можно было смотреть в разрезе бухгалтерских счетов, субсчетов и аналитических разрезов, и посмотреть на суммы проводок в любом их соотношении, и проверить правильность формул расчета - мог, не поверите, не программист, а бухгалтер! Бухгалтер, который познал базовые принципы работы с Excel и научился использовать в формулах функции...

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

Механизма наследования, однако, нет ни в 1С, ни в ИНФИН.