Я вот недавно начал играться с тонким клиентом 1С v. 8.3.3 и SQL Server 2012. Интересная, надо сказать, штука. Но поскольку задача внедрения типовых конфигураций для меня не очень актуальна, так как все проблемы вполне решаются уже задействованными средствами, то решил запрограммировать тонкую конфигурацию, для восьмерки, с нуля. Ну, чтобы разобраться лишний раз, что к чему.

Одновременно с этим возник вопрос, а почему бы не написать тонкую конфигурацию для «семерки», для последних версий MS SQL Server? Ведь для этого на уровне платформы ничего делать не надо. Достаточно просто не задействовать объекты 1С77, без которых, в принципе, можно обойтись, даже если для этого нужно написать «лишний» код. Тогда уже не придется кивать на фирму «1С», мол, плохо чего-то там реализовала или вообще не сделала. Типа, тормоза при проведении, медленная скорость работы и т.п.

Здесь попутно возникает другая идея. Если, в принципе, можно обойтись 1С77 с очень ограниченным функционалом, то тогда можно попытаться написать свою облегченную версию «семерки», либо воспользоваться существующими бесплатными опенсорсными реализациями. Например, «Ананас», «1L», «2С» и т.п. К тому же, в соседнем топике речь идет еще об одной версии а ля «1С» - «Сибирском ананасе». Вот я и предлагаю ее автору, реализовать сначала сверхтонкого клиента на стандартной «семерке» в купе с SQL сервером, а потом уже реализовать этот самый минимальный функционал в собственной программе. Тогда и систему отчетов нет необходимости делать, а просто задействовать ее серверный вариант.

Теперь, о собственно «сверхтонком» клиенте 1С77.

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

Поскольку клиент «семерки» мы собираемся реализовывать сверхтонким, то подход наш будет очень революционным. Мы просто отказываемся от использования всех объектов 1С, кроме справочников, ну может быть еще, констант и обработок. Всё! Все остальные объекты мы моделируем на базе таблиц справочников.

Подобный успешный опыт работы у меня уже есть. Мои две основные конфигурации «Учет ресурсов» и «Учет начислений» реализованы только на справочниках (без периодических реквизитов), константах, обработках, перечислениях и отчетах (которые ничем не отличаются от обработок). Причем без последних двух вполне можно обойтись. Только все это реализовано в dbf-версии, а теперь абсолютно весь функционал будем писать на сервере. При расчете зарплаты я использовал внешнее приложение, написанное на визуал ФоксПро, которое «общается» с «семеркой» как с DDE-сервером.

На «семерке» мы пишем только вызов скриптов и хранимых процедур из SQL сервера. И ничего более! Мы даже не собираемся возвращать табличные данные сервера клиенту. Зачем? Пусть серверный скрипт делает проведение сам, на стороне сервера, а клиенту только передают статус завершения транзакции. Клиенту, максимум, нужно обновить формы с данными на своей стороне.

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

Попытка модификаций данных таблиц 1С на стороне сервера вызывает некоторые сложности, но, тем не менее, вполне решаемые.

Вот такой план моих действий. Вы можете высказать свои критические замечания по этому поводу, типа, «многа буккафф» : ) .

Программист 1сВ чем разница в производительности между справочником и регистром?
Если сам все контролируешь, то никаких затыков. Мой учет ресурсов, без регистров, работает уже несколько лет и все проблемы, если они возникают, оперативно решаются.

Программист 1сЧто будете делать если в справочнике "остатков" обнаружен сбой (задвой или не хватает записей)? Будете ПОЛНОСТЬЮ пересчитывать данный справочник?
У меня нет независимого справочника остатков, я процедуру проведения делаю через подчиненные справочники Ресурсы–8Периоды–8ДебетовыеОперации–8КредитовыеОперации. Если учет не партионный, то вместо кредитовых операций используются отрицательные дебетовые. В ресурсах мы имеем общие остатки, в справочнике периодов – движения по периодам и т.д.

Если возникает сбой, что иногда случается, то все решается просто – вызовом обработки пакетной отмены проведения, корректировкой и затем обработкой пакетного проведения. Делать это приходится нечасто и практически никого не напрягает.

Однако речь не об этом, этот dbf-вариант конфигурации работает много лет и с ним никаких проблем нет. Мы сейчас говорим о другом, о полном написании кода конфигурации на стороне сервера. Надеюсь, что к серверу мы не будем предъявлять никаких претензий.

Программист 1сЗарплатные регистры, я так понимаю вы не смогли сделать через справочник...?
Зарплатных регистров, как таковых у меня тоже нет. Есть структурированный справочник первичных табелей (за последние 10 лет, число сотрудников – порядка тысячи). Необходимости сжатия базы пока еще не было. Из 1С вызываю внешнее приложение Visual FoxPro и оно в режиме реального времени обновляет данные во вторичных табелях. Которые также структурированы по годам и месяцам. Из вторичных табелей делаем все необходимые отчеты. Если что не так, осуществляем перерасчет в этот же самый каталог текущего периода. Последний рассчитанный вариант данных из вторичных табелей проводим в соответствующие подчиненные справочники сотрудников, по схеме: Сотрудники–8Табульки–8Табулька, которые используются для расчетов в будущих периодах. Если есть необходимость, делаем перепроведение, при которые данные просто перезаписываются и ничего более.

Полученный опыт позволяет существенно оптимизировать эту конфигурацию, например, отказаться от VFP, без потери производительности, однако более интересно реализовать весь учет начислений на стороне SQL сервера.

Программист 1сps Загоним гвоздик в крышку ... Где хранятся текущие остатки? (В курсе где они хранятся в регистре остатков? Даже пока не будем брать оборотные и промежуточные остатки....) Если запросом из справочника ... то НАСКОЛЬКО будет медленнее?
Остатки, точнее проводки с остатками, хранятся в подчиненных справочниках. Опыт показывает, что это очень удобно. Все остатки видны и для произвольного просмотра не требуют выполнения никакого кода. Где хранит их фирма 1С я знаю, но их парадигма учета, которую я называю «субконтный учет» (а они сами называют «аналитическим учетом») меня не устраивает совершенно. У меня же реализован «натуральный учет», которому подчинен бухгалтерский учет.

С третьей конфигурацией, бухгалтерским учетом, я поступаю так. Выгружаю операции из своих конфигураций в журнал операций, в чистой типовой конфигурации «Бухгалтерия для Украины». После этого мне становятся доступными все отчеты стандартной бухгалтерии, которые слишком сложны и громоздки для собственно программирования.

Проблем с производительностью, для нашего предприятия, нет никаких.

sikuda1. Лицензии никто не отменял. 1С77 не opensource.
Об этом речь не шла.

sikuda2. Официально 1С77 не работает Windows 7.
Работает. Может быть Вы имеете в виду в связке SQL Server 2005 и выше? Но и здесь особых проблем нет. Используется внешний прокси-сервер, код 1С не модифицируется. Однако я веду речь об общем (в принципе) коде на стороне сервера, как для «семерки», так и для официального тонкого клиента «восьмерки».

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

sikuda4. Никакое решение типа «Ананас», «1L», «2С» не популярно.
Я это знаю, но Вы меня не поняли. Я имел в виду другое. Ошибки всех «а ля 1С-ников» в том, что они идут по пути догоняющего. А фирму 1С они не догонят в принципе, просто сил не хватит. Я же предлагаю другое – 90% функционала перенести на сторону сервера (программирование которого, в принципе, не зависит от 1С), а оставшиеся 10% в виде тонкого клиента для работы с сервером. Трудоемкость подобного решения – порядка два человека года. Зато можно получить эффективное решение полностью независимое от 1С силами одного человека. А использовать ли для этого существующие наработки опенсорсных аналогов либо нет, это уже вопрос целесообразности.

DmitriyZEmery, я вот не пойму, если практически не использовать ничего кроме справочников, зачем все это делать на 1С? Почему не взять C#, например, или Яву и не сделать "сврехтонкий клиент"?
Вот! Вы правильно поставили вопрос. Об этом то и идет речь, найти эффективное 1С-независимое решение. Пока только проблема в тонком клиенте. Все существующие, на мой взгляд, сделаны не очень удачно, например, Акцесс. Опенсорсные аналоги страдают концептуальными дефектами. С# либо Ява это не очень серьезно, ибо получаются монстры, типа «Дебет-Кредит». Только С/С++. Пока лучшие, из имеющихся потенциальных тонких клиентов, которые я знаю, это «облегченный» 1С77 и тонкие клиенты (кстати, распространяемые фирмой 1С бесплатно) под 8х. Поэтому, чтобы не тратить зря время на создание очередной версии «голого» клиента, лучше сосредоточится на переносе общего функционала или лучше сказать, создании нового, из конфигураций 1С на сторону, скажем, SQL сервера. По-моему это будет оптимальным решением. Даже если не получится полностью перенести код на сервер, можно немного лучше разобраться с программированием собственно SQL сервера, что, думаю, лишним не будет.

angroА кто-то уже писал, что использует только справочники. Может это были вы. hogik свой механизм работы с сервером сделал. sadovnikov - тоже утверждал что 7.7 только для рисования интерфейсов использовал. Зачем 7.7 в таком случае, все таки у неё бедный интерфейс и лицензии нужны.
Да, я про свои конфигурации писал ранее. В семерке интерфейс отнюдь не бедный. Рюшечек и «бантиков» маловато, согласен, но вся необходимая функциональность там реализована с избытком. Только вот прикладная модель реализована не очень. Платформу 1С77 писали правильные хлопцы, а конфигурации делают по принципу, нам с ней не работать или, в принципе фурычит, чего вам еще надо? Скажем, мутатень с документами, журналами, регистрами. Все плоское, неудобное и некомфортное. Делаем структурированный справочник документов и душа радуется. Далее, оперативные проводки нужны только для получения актуальных (натуральных) остатков. Делать оперативно бухгалтерские проводки нет никакой необходимости. Это все можно сделать пакетно в конце периода или когда явно нужно. Натуральные характеристики – субконто, подчинены бухгалтеским счетам, что требует обязательных бухгалтерских проводок. По умолчанию субконто в плане счетов только три, хотя на уровне системы задействуются все имеющиеся в конфигураторе. Только вот ввести или вывести их напрямую Вы не можете, только программно. Подключение субсчетов уровня предприятия может вызвать проблемы при проведении, нужно модифицировать весь код в документах. Повышение количества субконто также приводит к необходимости существенной переработки конфигурации. В моем же случае проблем с субконто нет вообще. Теоретически доступна для использования любая имеющаяся информация. Бухгалтерские проводки я вообще не делаю, только выгружаю автоматом операции из своего учета ресурсов и начислений в журнал операций типовой бухгалтерии.

Справочники 1С77 очень удобны для использования в учете. Важнейшее их достоинство это группы, что позволяет структурировать справочники документов или там общий справочник ресурсов. Периодические реквизиты можно реализовывать через подчиненные справочники. Других доступных систем с удобством навигации по справочникам, как в 1С77 еще нужно поискать. Конкурент только 1С8х. Но там, в тонких клиентах, как я понял, заблокирована возможность редактирования реквизитов в списке справочника, только в его диалоге. Может быть, я чего не до конца понял, но в типовых тонких клиентах «восьмерки» этот так. Да, красота интерфейса «Такси» в «восьмерке» просто потрясающая. Делали явно специалисты. Вот если бы он и еще разрешили центрирование форм по умолчанию, так вообще было бы замечательно.

Вот у нас, в Украине, навязывают систему отчетности «Медок». Так там ни групп нет, ни навигации по справочникам кнопками PgUp / PgDown, ни быстрого поиска как в 1С. И так во всех подобных системах. Должен сказать, что справочники «семерки» хоть и недостаточно понтовые, но вполне функциональные, в отличие от других подобных систем. Так что на интерфейс «семерки» я не жалуюсь, особенно учитывая достаточное количество внешних компонент.

Стоимость же семерки достаточно дешевая. Наша фирма ее покупала даже дважды. Просто в знак, скажем так, моей благодарности за эту систему. Правда, в последнее время франчайзи испоганились. При второй покупке поддержка конфигураций должна быть полгода (тогда как при первой была неограниченной), а реально оказывалась не более 2-х месяцев. А сами бухгалтерские конфигурации меняются у нас с регулярностью раз в месяц. Так что третий раз уже покупать не будем :) . А ведь могли бы.

sikudaНе чуствуете разницу между запускается и официально поддерживается.
http://1c.ru/rus/products/1c/predpr/sysreq.htm
Не чувствую. По ссылке речь идет о минимальных или типичных требованиях. Если бы одна «семерка» просто бы не инсталлировалась на другой «семерке», то тогда бы проблем не было, типа не поддерживается и все тут. А если она прекрасно ставиться, то, какие вопросы? Обычно ограничения идут вниз, а не вверх. Типа, «This program cannot be run in DOS mode». Если же фирма 1С имеет ввиду, что ограничения существуют также и вверх, то пусть запрограммирует в своих инсталляциях ругань типа: «Эта версия программы 1С не может быть запущена на Windows версии более чем 5.2 и менее чем, скажем, 3.0». При этом она действительно не должна иметь возможности быть запущенной к исполнению. Все остальное это уже от лукавого.

Лучше сказать, не типичных, а рекомендуемых требованиях.

Сибирский ананас1. Мы в нашей программе старались делать простым и универсальными достук к метаданным и таблицам. Это дает возможность написания клиентов хоть на джаве, хоть на .net и других платформах. Поэтому я даже не вижу особого смысла привязваться к 1С. В нашей программе вы сами сможете написать клиент, т.к. выборка данных проста до безумия по сравнению с 1С, вы сможете сами писать и/или вызывать хранимые процедуры. Вы сможете использовать возможности SQL серверов на все 100%, а не так как это делается в 1С.
В этом я вижу соль проблемы. Клиента, по Вашему, нужно писать самому. А зачем мне тогда «доступ к метаданным и таблицам»? Чем Ваш доступ лучше SQL серверного варианта? У меня вообще никогда не было и надеюсь, не будет проблемы «простого и универсального доступа к метаданным и таблицам».

Идеальный клиент должен быть написан на С/С++, никаких там джав или .нет. Облегченный (только справочники) 1С77 это просто прототип для будущего 1С-независимого клиента. На программировании на стороне сервера нюансы клиента не должны сильно влиять. Именно поэтому я говорю об общем коде как для тонкого клиента 1С77, так и для тонкого клиента 1С8х.

В SQL Server «выборка данных» тоже «проста до безумия по сравнению с 1С». И я также «могу сам писать и/или вызывать хранимые процедуры» на сервере, в клиенте 1С. И уж тем более на сервере я «могу использовать возможности SQL серверов на все 100%, а не так как это делается в 1С». Какие конкретно преимущества перед существующими продуктами Вы можете дать, хотя бы в принципе?

Сибирский ананас2. Использование справочников имеет ряд минусов для организации регистров, т.к. справочник имеет автоинкрементный ID, а для регистра ID может быть не нужен. Автоинкрементный ID понижает быстродействие (блокировки при создании записи). Это вторая причина что нет смысла привязываться к 1С.
Я много лет имею дело с собственными конфигурациями 1С, которые работают, без каких либо проблем и даже позволяют проделать с ним еще большую оптимизацию. Но ее я уже хочу реализовать в серверном варианте.

А регистры в стиле 1С мне не нужны совершенно. Ибо предпочитаю иметь дело с явными объектами, которые я полностью контролирую.

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

P.S. Из Ваших слов я так понимаю, что Вы предлагаете собственный вариант SQL сервера?

Сибирский ананасХотя с другой стороны есть смысл делать на 7.7, чтобы развенчать миф о невиданных возможностях 8
Интерфейс «Такси» в управляемых приложениях мне очень нравиться, но не нравится отсутствие инлайн-редактирования в тонком клиенте «восьмерки», которое есть в семерке и невозможность штатно центрировать формы.

Если же не обращать внимание на рюшечки, то да все, что можно реализовать в тонком клиенте «восьмерки», можно реализовать и в искусственном тонком клиенте «семерки».

ZerroСмысла мало...понимаю предложить сделать облачную бух или торговлю альтернативную.. Многие переписывали конфы под себя вырезая все лишнее(для своей фирмы). но если фирма растет приходилось дописывать велосипеды.

Кто не видит смысла, тому и делать ничего не надо. Я вообще бессмысленные топики не читаю.

Последний выдох ГПЖпока вы будете думать о лапше которую вам на уши навешал очередной дядя из M$ и как вы будете реализовывать поддержку "облаков", html5, kinekt и dx11 для буха вместо думанья о простоте поддержке и реальном функционале (в котором вы судя по всему ничерта не смыслите)- ваш продукт будет в полной ж.пе...

Мой продукт уже давно работает и без проблем. Настало время для его оптимизации.

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

большинство убийцев 1С загибаются на этапе иерархических справочников...
Зато он дешевый и сердитый. А для SQL есть бесплатные версии. Если Вы не тролль, то последнюю фразу спишем на Вашу невнимательность, ибо я толкую о другом.