понедельник, 14 октября 2013 г.

Выгружаем из 1С в EXCEL с помощью ADO. Решаем проблему с кавычками.

Многие читатели предыдущих статей, посвященных выгрузке из 1С в EXCEL с помощью технологии ADO, столкнулись с проблемой, которая возникает когда в значении поля, которое подставляется в запрос к базе данных, встречается апостроф(одинарная кавычка). В данной статье будет приведено простое и элегантное решение данной проблемы, которое сообщил один из посетителей сайта.

Рассмотрим фрагмент кода из первой статьи «Выгружаем из 1С в EXCEL с помощью ADO. Часть I»
// Заполняем таблицу данными выборки
Пока Выборка.Следующий() Цикл
Command.CommandText = "
|INSERT INTO [Table] VALUES ('"+Выборка.Код+"','"
+Выборка.Наименование+"')";
Command.Execute();
КонецЦикла;

Ошибка возникает если Выборка.Код или Выборка.Наименование содержат апостроф. Чтобы избежать этого я предлагал либо экранировать, либо заменять этот символ другим. Но более правильное решение этой проблемы заключается в использовании параметров:
Command.CommandText = "INSERT INTO [Table] VALUES (@Код, @Наименование)";
Пока Выборка.Следующий() Цикл
Command.Parameters("@Код").Value = Выборка.Код;
Command.Parameters("@Наименование").Value = Выборка.Наименование;
Command.Execute();
КонецЦикла;


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

Маленькие хитрости

Введение

Очень часто в различных электронных конференциях по программам семейства "1С:Предприятие" попадаются вопросы, связанные с администрированием баз данных. Желание поделиться опытом, накопленным почти за три года работы и обкатанными приемами в данной области с одной стороны и природная лень - с другой (в смысле надоело раз от разу отвечать на одни и те же вопросы) и вызвало желание как-то систематизировать все это в одном - общедоступном месте. Все нижеизложенное касается программ сетевой файл-серверной версии 7.5 (на 7.7 и SQL я только вот-вот перейду), т.ч. в случае использования более старших версий (как и SQL версий) возможно потребуется некая адаптация кода : Кроме этого подразумевается, что читатель хотя бы поверхностно знаком с компьютерной техникой, сетями, c основами MS Windows и основами работы с программой "1С:Предприятие". Приводимый в прилагаемых конфигурациях код не "привязан" к какой-то отдельной компоненте программы (Оперативный учет, Бухгалтерия, Расчет), а потому может быть использован в любых конфигурациях.

Общие сведения (v.7.5)

Итак, вы распаковали увесистую желто-красную коробочку с логотипом 1С :, что же дальше? Как и какую вязать сеть, что для этого нужно и прочие технические вопросы мы здесь рассматривать не будем - это отдельная тема - предположим, что сеть уже есть : Также не будем останавливаться на процедуре инсталляции программы 1С, как правило здесь вопросов не возникает. Единственное, что хочется отметить - я бы не советовал производить "административную" установку программы (сугубо личное мнение, наверняка у меня тут же найдутся оппоненты). Проще установить программу локально каждому клиенту - мне кажется, что такой режим более "человечен" по отношению к сетевому трафику. Хочу сразу же предостеречь - для работы в сети каталог базы данных лучше разместить на специально отведенном для этих целей компьютере - сервере. По возможности не следует нагружать его еще чем-либо (типа MS Office), т.е. сделать "выделенным", также следует помнить, что тактико-технические характеристики данного аппарата напрямую влияют на комфортность вашей работы, поэтому жаться здесь не стоит. Что выбрать в качестве операционной системы для вашего сетевого файл-сервера базы данных? Однозначный ответ - ни в коем случае не Microsoft Windows 9X ! Дело в том, что у этих операционных систем существует ограничение на число одновременно открываемых файлов (1К: 1024) - в результате с таким "сервером" в сети смогут работать лишь несколько пользователей (конкретное количество зависит от числа файлов в конфигурации вашей базы). Лично я предпочитаю пользоваться системой Microsoft NT 4.0. Если вы уверены, что число клиентов вашей сети не превысит 10, то можно установить на сервер NT Workstation (большее число соединений ей просто не поддерживается), в противном случае не обойтись без NT Server. В качестве альтернативы для серверной системы можно использовать и Nowell Netware, но я с ней к сожалению (или быть может к счастью) не знаком, поэтому ничего посоветовать не могу : Также уже начали появляться первые восторженные отзывы об использовании долгожданной Windows 2000 (NT 5) в связке с 1С, но мне кажется не стоит торопить события, 17 февраля уже не за горами, поживем - увидим.

Для начала приведу ключи запуска программы из командной строки (как не странно, много раз с удивлением убеждался, что не всем они известны) :

1cv7.exe MODE [ /M | /D<Path> | /U<Path> | /N<Name> | /P<Pass> ],

где MODE - режим запуска, может принимать только одно из трех значений :

config - режим конфигуратора;

debug - режим отладчика;

enterprise - нормальный (рабочий) режим.

следующие ключи опциональны :

/M - запуск программы в монопольном режиме;

/D - каталог базы данных;

/U - рабочий каталог пользователя (каталог из списка пользователей игнорируется);

/N - имя пользователя;

/P - пароль пользователя;

Например при выполнении такой команды : 1cv7 enterprise /DD:\Dbase /NИванов /P123,

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

Также хочу здесь остановиться еще на одном нюансе. В режиме кофигуратора в пункте меню "Файл" есть две команды : "Выгрузить данные" и "Загрузить данные" (не путать с командами "Сохранить/Восстановить" - это просто архивирование). Исходно они предназначены для переноса информационных баз между файл-серверной и клиент-серверной (SQL) версиями. Но у них есть одна приятная особеннось - в процессе выгрузки - загрузки производится верификация корректности исходных данных на уровне информационных объектов (т.е. констант, справочников, документов и пр.). Поэтому если в базе содержатся ошибки, появившиеся в процессе работы из-за сбоев оборудования или программы, при выполнении данной процедуры база с большой долей вероятности будет корректно восстановлена. Так что в процессе работы полезно периодически производить сие действие для уверенности в корректности данных (хотя данная процедура занимает порядка нескольких десятков минут - в зависимости от железа и объемов базы) - я обязательно выполняю ее раз в месяц. Кроме этого желательно почаще переиндексировать базу (особенно если есть документы, проведенные "задним числом") - напрочь сносим *.CDX и открываем базу в монопольном режиме, у меня это делается автоматически каждую ночь.


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


@ECHO OFF

NET TIME \\Server /SET /Y


(здесь Server - сетевое имя сервера базы)

Подальше положишь - поближе возьмешь :

Регулярно выполнять резервное архивирование нужно обязательно, чтобы не было потом обидно за безвозвратно утерянные данные. Чем это делать - это вопрос скорее вкуса. Существует например специально "заточенная" под 1С программа "Хранитель" от ростовской фирмы "Гендальф" http://www.gendalf.ru/, которая умеет делать массу полезных вещей, но мне она кажется слишком перегруженной для таких простых целей, я пользуюсь старым добрым RAR'ом. Архивировать следует только файлы базы *.dbf и сами метаданные (1cv7.dd/md), ну еще LOG-файл и ваши оригинальные файлы (если они есть). Сначала приведу содержимое нескольких командных файлов (расширение *.cmd работает только под Win NT, если используется Win'9X, то расширение должно быть *.bat):


ARCH.CMD

REM используемые каталоги (должны существовать)

REM D:\1C\DB - рабочая база

REM C:\Temp\DB - временная копия базы

REM C:\BACKUP - архив базы

REM \\Adm\Storage - резервный архив базы (на другом компьютере сети)


@echo off

; чистим временный каталог

Del С:\Temp\DB\*.*

; копируем в него архивируемые файлы рабочей базы (*.md,*.dd,*.log,*dbf)

Copy D:\1С\DB\1cv7* С:\Temp\DB

Copy D:\1C\DB\*.dbf C:\Temp\DB

; сохраняем предыдущую версию архива под новым именем

copy C:\BACKUP\db.rar C:\BACKUP\db0.rar

; создаем новый архив

rar.exe u -r -m1 -dh -std C:\BACKUP\db.rar С:\Temp\DB\*.*

if errorlevel 0 goto rpl

echo P_A_C_K_I_N_G___E_R_R_O_R__!

goto end

:rpl

; сохраняем копию архива в надежном месте

net use Z: \\Adm\Storage

copy C:\BACKUP\*.rar Z:

net use Z: /delete

:end


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

На этом все, осталось всего навсего запустить системную службу Sсhedule: Explorer-ControlPanel-Services-Schedule-Startup-Automatic (поддерживается только под Win NT, для Win'9X нужны специальные внешние утилиты) и набрать из командной строки что-нибудь аналогичное :


At 13:00 /Every:M,T,W,Th,F C:\COMMAND\arch.cmd

At 18:00 /Every:M,T,W,Th,F C:\COMMAND\arch.cmd

At 07:00 /Every:M,T,W,Th,F C:\COMMAND\shutdown /l /r /y /c


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

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

REINDEX.CMD

@echo off

; каталог базы

set db=D:\1С\DB

; каталог программы

set pr="C:\Program Files\1cv75\bin\1cv7"

; принудительно сносим индексы

del %db%\*.cdx /Q

; запускаем программу монопольно под "фиктивным" пользователем

%pr% enterprise /D%db% /M /NЧистяков /Pstart


Этот командный файл вставляется в папку автозагрузки на сервере, утилита SHUTDOWN.EXE (из Windows NT Resource Kit - это набор дополнительных сервисных утилит) производит перезагрузку сервера, для того чтобы по загрузке не нажимать магическую комбинацию из трех пальцев (Ctrl-Alt-Del) и не вводить пароль, а загрузить сервер автоматически, нужно подправить системный реестр NT (запустить из командной строки regedit.exe) :


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

"DefaultUserName"="YourProfileName"

"DefaultDomainName"="Comp"

"AutoAdminLogon"="1"

"DefaultPassword"="YourPass"

где YourProfileName - имя профиля администратора на сервере (по умолчанию Administrator), Comp - сетевое имя сервера, YourPass - пароль аминистратора на сервере (обязательно должен быть не пустым).


Итак подъитожим - в заданное нами время происходит автоматическая перезагрузка сервера с переиндексацией базы, для того чтобы программа по окончании переиндексации сама завершилась необходимо в глобальном модуле конфигурации предусмотреть некие нестандартные действия по обработке входа в программу исскуственного "фиктивного" пользователя (Чистяков - без пароля) - они приведены в демонстрационной конфигурации (архив Adm.rar).

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

Уборка мусора в DBF-файлах

Идеология использования DBF/CDX-файлов построена таким образом, что при удалении объекта базы производится только пометка объекта как удаленного, физически же запись об этом объекте остается в базе в качестве "мусора". Если не предпринимать никаких специальных мер, то этот мусор копится, база пухнет, драгоценный сетевой трафик забивается зря. В принципе "уборку мусора" можно производить в конфигураторе через выгрузку-загрузку данных, но это не очень удобно, поскольку, как я уже упоминал выше, выполнение данной процедуры может требовать значительных временных затрат: Альтернативный путь - использовать для этих целей внешние утилиты, предназначенные для работы с DBF/CDX-файлами (например утилитка DBU.EXE из Clipper'а) тоже не очень хорош, т.к. обычно они не умеют работать с маской файлов (*.dbf), а "подсовывать" им по одному файлу из сотни - удовольствие ниже среднего.

В тоже время встроенный язык программ "1С:Предприятия" поддерживает соответствующий DBF-примитив (метод объекта Xbase Сжать()), поэтому я в свое время и написал на 1С небольшую конфигурацию, предназначенную исключительно для этих целей и пользуюсь ей регулярно до сих пор (раз в неделю). Кроме "чистки" базы в ней также попутно предусмотрена возможность использования стандартного внешнего архиватора WinZip/WinRAR для архивирования базы, собственно сама конфигурация в архиве Cleaner.rar, небольшое описание приведено в этом же архиве в файле Read.me.

Есть кто живой ?

Как известно, в состав сетевых версий программы 1С:Предприятие входит встроенная утилитка - монитор пользователей (пункт главного меню программы "Помощь", далее пункт меню "О программе" и кнопка "Монитор"), назначение ее очевидно - отображать кто в данный момент находится в системе, причем реализована она как внешнее приложение (..\1cv75\bin\usrmon.exe). В свое время, на ранних релизах версии 7.5 я столкнулся с крайне неудовлетворительной работой данной утилиты - либо безумно долго запускалась, либо вообще убивала систему. Но ведь вещь то нужная и я решил построить что-то аналогичное средствами 1С.

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

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

Опять же, при таком подходе можно пойти дальше - добавить дополнительные поля в данный справочник и хранить в них все что заблагорассудится. К примеру, год назад у меня были проблемы с сетью, почти ежедневно кто-то из пользователей аварийно отваливался, нужно было как-то автоматически отслеживать кто именно. Я добавил к данному справочнику поле, в которое один раз в 15 минут для каждого пользователя записывалось текущее время (делалось это в глобальном модуле через процедуру ОбработкаОжидания(), т.е. если пользователь умирал, то запись соответственно не производилась). Перед каждой записью из элемента справочника считывалось предыдущее значение времени и если разница между ним и текущим значением времени превышала 18 минут (15 мин. + некий запас), то констатировался факт "смерти" пользователя с сохранением некролога в LOG файл. Это в свое время помогло съэкономить мне массу сил и нервов - не пришлось допрашивать с пристрастием бедных пользователей "А корректно ли вы сегодня закончили работу ?" и сверять результаты допроса с содержимым LOG-файла - подсчитывать для каждого пользователя число входов/выходов в/из систему/системы:

Как поняли, прием :

Часто бывает крайне полезно иметь под рукой средства интерактивного общения по сети, например, попросить всех "выйти вон" на 5 мин. для переиндексации базы, или пользователь просит меня открыть ему доступ для авансового резервирования товара (выписать счет на товар, который уже пришел, но еще не оприходован), в конце концов просто послать кого-нибудь куда подальше : Штатные средства, предназначенные для этих целей (WinPopUp и пр.) не всегда удобны - они должны быть установлены и запущены у всех клиентов - в общем морока.

Общеизвестно, что в типовых конфигурациях Торговли, по-моему начиная с Редакции 6, появился справочник "Блокнот", предназначенный именно для этих целей. Но моя реализация мне нравится больше, к тому же на момент ее написания - не только 6, но и Редакции 5 еще в помине не было. Ну а насколько я объективен - судить вам. Суть в следующем - есть справочник "Сообщения" со следующими полями : "Наименование" - адресат сообщения, "Запись" - собственно текст сообщения, "Прочитано" - флаг 1/0 (дошло до адресата или нет), "Кто" - отправитель сообщения и "ДВ" - дата и время отправки. Для каждого активного пользователя системы (опять же нам здесь пригодился справочник "Сеансы") каждые 30 секунд перебираются элементы справочника "Сообщения", в случае совпадения имени пользователя и значения поля "Адресат" и нулевого значения флага "Прочитано", выводится сообщение "Вам письмо!" и открывается соответствующая форма с текстом сообщения. По закрытии данной формы, что предполагает прочтение адресатом сообщения, флаг "Прочитано" автоматически устанавливается в 1. При выходе пользователя из системы все прочитанные им сообщения автоматически удаляются. Каждый "обычный" пользователь может послать сообщение только одному из пользователей, активных в данный момент. И только администратор (для себя любимого возможность) может послать сообщение для всех пользователей сразу. Такая организация кажется мне наиболее оптимальной исходя из соотношения сервисные возможности / загрузка трафика. Реализация приведена все в той же конфигурации - adm.rar.

Кому-то можно, кому-то нет :

Достаточно часто встречаются вопросы, а как производить авторизацию пользователей с одинаковым набором прав - скажем есть 5 менеджеров и желательно сделать так, чтобы доступ у каждого из них был только к своим документам. Это делается достаточно просто - при помощи предопределенных процедур глобального модуля ПриУдалении() и ПриОтменеПроведения(), все это совершенно очивидно из кода демонстрационной конфигурации adm.rar, поэтому задерживаться на этом не буду. Еще один момент - мне кажется довольно удобным, когда каждому пользователю соответствует свой цифровой префикс (точнее его часть) в нумерации документов (конечно же при условии, что пользователей не очень много). Механизм реализации этого можно посмотреть там же :

Ссылки на полезный софт (всякие всякости)

Поскольку все наши данные хранятся в формате DBF/CDX, очень часто бывает полезно, а порой и просто необходимо средство для просмотра / редактирования данных на уровне файлов. Таких утилит существует множество, единственный недостаток - не все из них умеют сами разбираться с перекодировкой ANSI-OEM (да еще и с кириллицей), в этом смысле самая на мой взгляд удобная - это DBFView от фирмы "Гендальф", скачать ее можно совершенно бесплатно здесь: http://www.gendalf.ru/DOWNLOAD/wDBFview.zip

Теперь остановимся подробнее на собственно средствах системного сетевого администрирования. Их сейчас появилось очень много, поэтому здесь я упомяну только те, с которыми я сам постоянно работаю и которые мне нравятся. Начну пожалуй со своей любимой программы Hyena от фирмы "Adkins Resource Inc." http://www.asdkins-resource.com/. Пожалуй проще перечислить чего она не умеет, чем наоборот : С ее помощью вы сможете получить полный доступ к локальным дискам клиентов, просматривать журналы событий на компьютерах сети, запускать и останавливать service'ы на клиентах, изменять их права, ну в общем почти все что может придти в голову. В общем настоятельно ее рекомендую. Да, стоит упомянуть, что как и положено, работает она только с Windows NT 4 / 2000, т.ч. любителям Windows 9X можно не беспокоиться. Достойны также пристального внимания продукты, предназначенные для целей сетевого администрирования фирмы "Aelita Software" http://aelita.net/. Их целый ряд, на мой взгляд наиболее полезны MultiReg - средство для удаленного редактирования системного реестра клиента, EventAdmin и Journal - база данных для накопления и последующего анализа системных журналов событий на клиентских машинах, ну и пожалуй еще ERDisk - утилита для создания копий загрузчиков и системных файлов сетевых клиентов (в случае "Blue Screen of Death" - это первое и, пожалуй единственное средство). Все эти продукты также поддерживают только Windows NT.

В последнее время появился целый ряд программ для полного удаленного доступа к сетевым компьютерам. Собственно Norton pcAnywere создан давно и достаточно хорошо известен, но он не является лучшим продуктом этого класса. Я экспериментировал с двумя аналогичными программами - это WinOp (отдельное большое спасибо BigHarry) фирмы "Danware A/S" http://www.danware.com/ и Remoute Administrator нашего соотечественника Дмитрия Зноско http://www.famatech.com/, функциональные возможности у них примерно одинаковые, но первая мне нравится больше, мне показалась, что она более разумно обходится с сетевым трафиком, т.ч. я работаю с ней. Что же она умеет, а почти все - поддерживает все сетевые протоколы от Microsoft, включая MSDN и модемный Dial-Up (чуствуете какие перспективы открываются для ленивых админов!). Программа состоит из двух компонент - host (устанавливается на клиентов) и guest (ставится на компьютер администратора). Причем клиентская часть под WinNT может устанавливаться как service в stealth-режиме, абсолютно прозрачно для клиента. При запуске guest'а и подключении к клиенту вы видите на своем мониторе его экран, ваши клава и мышь работают как клиентские, т.е. доступ действительно полный ! Более того, вы можете погасить экран клиента, заблокировать его клаву и мышь и даже удаленно перезагрузить его компьютер : Есть еще такие вещи как chat, файловый обмен и пр. В общем штука чрезвычайно полезная. Работает быстро и надежно (и кстати поддерживает Windows 9X/3.1). Единственное хочу предостеречь от злоупотреблений - трафик то не резиновый, т.е. пользоваться ей нужно только тогда, когда это действительно необходимо.

Итак подытожим - используя все эти средства у сисадмина появляются реальные возможности для проведения своего рабочего времени целиком у родного компьютера, беготня по клиентам канула в лету :

суббота, 5 октября 2013 г.

Сетевые "глюки" 1С

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

1. Общие положения.

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

1. Инициализация сервера защиты.

Это пожалуй один из самых "глюконосных" моментов в программах 1С. Начать вероятно следует с самого страшного и необъяснимого.

Если при установке ключа защиты на сервер Windows NT Вы последуете рекомендациям, приведенным в документации по установке, и установите сервер защиты (NetHasp server) в качестве NT-шного сервиса, то может случиться так, что Вы будете сильно удивлены: при перезагрузке NT сервер стабильно переходит в режим "синей смерти", т.е. загрузка не завершается, а на экране монитора на синем фоне возникает какое-то жуткое невразумительное диагностическое сообщение с указанием каких-то адресов. В этой ситуации можно только выразить Вам соболезнование и посоветовать быстренько переустановить NT Server. Нам так и не удалось определить зависимость возникновения такой ситуации от релиза NetHasp server-а - такая штука кажется может происходить с любыми релизами, кроме 13, но прямой связи версии NetHasp Server с релизом нет - в одном и том же релизе, но в разных коробках может попасться NetHasp Server разных версий. Зато нам удалось найти то, с чем не желает спокойно жить NetHaspServer, вызывая этим нежеланием "синюю смерть" - это установленный SAP support. Достаточно убрать из сетевых протоколов SAP support и никакой "синей смерти" больше не возникает. Можно конечно не устанавливать NetHasp Server как NT-шный сервис и запускать его при старте NT любым доступным способом - хоть вручную. Но даже при ручном запуске наличие SAP support продолжает конфликтовать с NetHasp Server-ом - в некоторых случаях NetHasp Server не видит нормально установленный и "живой" протокол NetBios (имеется в виду конечно его эмуляция на IPX), иногда при выключении и последующем включении (без перезагрузки) NetHasp Server вдруг вообще перестает "видеть" установленные сетевые протоколы. В итоге конечно можно подобрать такую комбинацию версии NetHasp Server, способа его запуска и установленных и задействованных на сервере NT сетевых протоколов, что все будет нормально, но как мне кажется, даже в этой ситуации сбои при опознавании ключа возникают чаще. В качестве хохмы могу привести пример, когда нам пришлось написать небольшой BAT-файл, который перезапускался каждые пять минут и вырубал, а затем снова запускал NetHasp Server. Это из-за того, что после каждых 5-7 запусков программы 1С:Торговля на рабочих станциях ключ вдруг переставал опознаваться, а NetHasp Server начинал показываать, что он не видит ни одного из установленных сетевых протоколов. В итоге после сноса SAP support-а все нормализовалось.

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

Наверное любой из специалистов, поимевших дело с сетевыми версиями программ 1С обратил внимание на возникающую иногда ситуацию, когда после старта NetHasp Server-а первая попытка запуска программы 1С с рабочей станции заканчивается неудачей с сообщением о том, что "…ключ не найден". Однако следующий запуск проходит нормально и все последующие тоже. Хотя иногда вдруг опять программа берет и не запускается. В чем тут дело? По всей вероятности причина заключается в следующем. Ключ защиты - это активное устройство, имеющее в своем составе микрочип. Этот микрочип питается микротоком, который возникает в тот момент, когда в порт LPT (т.е. на ключ) записывают какие-либо данные. До момента первой записи ключ остается не запитанным и соответственно не инициализированным. Вероятно, для инициализации ключа NetHasp Server должен либо бросить туда пустую посылку, а затем уже начать давать "рабочие" посылки, которые требуют ответа ключа, либо после первой посылки сделать паузу перед вычитыванием данных. Мне представляется более вероятным первый вариант. Налицо факт недоработки программного обеспечения NetHasp Server. При встрече с подобным дефектом Вы можете уточнить его характер просто напечатав что-либо на принтере, подключенном к тому же LPT-порту сразу после запуска NetHasp Server-а. Если после этого первый запуск программы 1С с рабочей станции проходит успешно - можете быть уверены - Вы столкнулись именно с вышеописанным дефектом. Если он начинает досаждать Вам, можно попытаться вылечить его заменой LPT-порта - просто подобрать порт, обеспечивающий большую величину микротока (конечно, если LPT-порт интегрирован на материнской плате, то придется поставить дополнительный порт). Программным путем этот дефект можно излечить написанием программки, периодически обращающейся к LPT-порту, однако здесь есть свои трудности - есть вероятность влезть в процесс обмена между NetHasp Server-ом и ключем, так что аппаратный способ мне кажется более приемлемым.

С "левыми" материнскими платами (типа китайских Lucky Star) часто связана неработоспособность нескольких ключей, подключенных к встроенному (на маме) LPT-порту: порт просто не дает необходимой мощности микротока для питания более, чем одного ключа.

2. Принтеры.

Если уж речь зашла об LPT-портах, то невозможно не упомянуть о лазерных принтерах, особенно о принтере HP LaserJet 6L, которые напрочь "сажают" напряжение на ключе и делают его полностью неработоспособным. Выход один - установка дополнительного LPT-порта - больше здесь ничего не поможет. В некоторых случаях принтер просто "подсаживает" LPT-порт и работать на таком порту может только один ключ. На два и более ключа просто не хватает мощности. Есть также некоторые модели принтеров, которые "убивают" ключ, если питание принтера выключить после того, как выключается питание компьютера. Это в первую очередь относится к комбинированным монстрам, объединяющим в себе факс, ксерокс, принтер и т.д. Конечно, не все модели таких устройств столь злобно настроены по отношению к Алладдиновским ключам, но я бы рисковать не стал.

Отдельный разговор о принтерах Lexmark, а вернее о программном обеспечении для них. Речь идет о драйверах этих принтеров. Эти драйвера написаны не программистами, а какими-то абсолютно враждебными существами, категорически недружелюбно настроенными к сетевым принтерам других производителей. Если на компьютере, подключенном к сети болтается такой драйвер (от принтера Lexmark) и в свое время Вы имели неосторожность установить этот принтер, как доступный другим пользователям сети, а потом принтер отключили, но драйвер не снесли, то сколько бы Вы не пытались организовать сетевую печать на принтер другой фирмы, подключенный туда, где раньше жил Lexmark, ничего у Вас не получится - никто из других пользователей сети не сможет напечатать на этом принтере ни слова. Даже снос драйвера Lexmark не всегда помогает: он оставляет какие-то DLL включенными в систему и их приходится либо удалять хирургически, путем долгих и нудных поисков в Registory, либо просто переставлять с нуля Windows. Сами можете представить себе, что будет выделывать ключ NetHasp, включенный в порт компьютера, изгаженного драйверами Lexmark. Выводы: может быть где-то и существуют нормальные драйвера для лазерных принтеров Lexmark, но я таких не встречал. С того момента, как Lexmarkи появились на нашем рынке (3-4 года назад) нам неоднократно приходилось с ними бороться.

Еще о принтерах. Это уже не относится к поиску ключа, а относится к нормальному режиму работы. Однажды мы наткнулись на следующую загадочную ситуацию. Вдруг, ни с того, ни с сего у одного из наших клиентов стали чрезвычайно медленно работать два компьютера из пяти, подключенных к одному хабу (сеть - витая пара пятой категории, 10 Мбит, сервер Novell NetWare 4.11, протокол IPX/SPX). Больно было смотреть, как компьютеры "засыпали" на несколько секунд при листании справочника. Клиент клялся и божился, что с этими компьютерами ничего не делал. После целого дня бесплодных попыток что-то сделать (переустановка и настройка протоколов, драйверов сетевых карт, замена сетевых карт, замена хаба и т.д.) мы обратили внимание на один из оставшихся трех "нормальных" компьютеров этой группы, а вернее на странный лазерный принтер, подключенный к одному из них. Спросили и выяснили, что клиент где-то (ГДЕ???) добыл по случаю лазерный принтер (кажется фирмы NEC), абсолютно новый, но 4-х или 5-ти летней давности выпуска. А с этим принтером на дискете был драйвер только для Windows 3.11. Вот этот драйвер клиент и влепил в Win95. Мы тут же снесли драйвер и к неописуемой радости (своей и клиента) обнаружили, что те два "больные" компьютера заработали как надо - с нормальной скоростью. Драйвер для Win95 мы потом скачали с Интернет, но почему драйвер принтера под 3.11, установленный на одном из компьютеров тормозил два других компьютера (и только их!) я так до сих пор понять не могу.

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

3. Протокол TCP/IP

Я не хочу говорить никаких плохих слов о протоколе TCP/IP. Я просто считаю его не нужным для систем, использующих программы 1С. Поскольку в системе спокойно уживаются несколько протоколов, то в случае необходимости для сугубо определенных целей TCP/IP имеет право на существование. Ну и пусть он живет на тех рабочих станциях или серверах, где он нужен (например для удаленного доступа), а 1С чудесно будет работать на IPX/SPX или на NetBIOS. 1C-овские программы, работающие на протоколе TCP/IP вполне работоспособны, однако не являются идеалом быстродействия. Тем более, что существуют какие-то заморочки с работой NetHasp Server на TCP/IP. По идее TCP/IP - это протокол, который в первую очередь обязан обеспечить маршрутизацию в сложных сетях. Однако, на обычной локальной сети, но с несколькими сегментами, NetHasp Server часто бывает невозможно заставить дать доступ к ключу программам, запущенным на другом сегменте сети. Скорее всего это ошибка самого NetHasp Server-а, но нам от этого не легче. Систематизировать неполадки данного вида нам не удалось (да честно говоря мы особо и не старались), как не удались и попытки смоделировать подобные ситуации на своей сети (2 сегмента). Но факт есть факт - иногда не работает и не лечится, а иногда работает. Я лично предпочитаю с головной болью не связываться.

TCP/IP способен преподнести еще некоторые сюрпризы. Наличие установленного, но ненастроенного (по IP-адресам) протокола TCP/IP на паре компьютеров в сети способно заставить программы 1С искать ключ по 3-5 минут, а затем "тормозить" при работе так, что создается впечатление, что перед Вами не 100 мегабитная сеть Ethernet, а просто компьютеры, связанные через COM-порты. При этом тормозит ВСЯ сеть, а не только те машины, где установлен TCP/IP. Лечится просто - сносом протокола TCP/IP на одной из машин (т.е. следует устранить наличие TCP/IP-шной "двухточки"). Естественно ситуация такая наступает не всегда, но при определенных условиях (каких???). Исследования на эту тему нам проводить было лень, достаточно того, что найден метод лечения.

4. NetBIOS, IPX/SPX и NetHASP.

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

· Для одноранговых сетей Win95 оптимальным вариантом является протокол NetBIOS (родной NetBEUI, а не эмуляция его на IPX/SPX). Сама сеть работает очень быстро и протокол устанавливается легко. Единственным недостатком является то, что NetBIOS не маршрутизируется по многосегментной сети, хотя недостатком это назвать сложно: я с трудом могу представить себе одноранговую сеть без выделенного сервера, но с несколькими сегментами. По-моему это будет просто извращение какое-то. Единственным препятствием для использования NetBIOS в такой сети может служить наличие сетевого принтера вроде Jet Direct, который, как правило, требует для своей работы протокола IPX/SPX.

· Если в одноранговой сети используется более 6-7 компьютеров и все они должны иметь доступ к одному из компьютеров, играющему роль сервера, то здесь начинаются неприятности. Ресурсы Win95 в случае, когда компьютер играет роль сервера, не позволяют ему обслужить более 5-6 экземпляров 1С:Торговли или 1С:Бухгалтерии, запущенных на других компьютерах (каждый экземпляр программы открывает более 200 файлов на дисках псевдо-сервера). В итоге запуск 6-го или 7-го экземпляра программы 1С заканчивается неудачей. Конечно, наилучшим решением является установка выделенного сервера, но клиенты/заказчики прижимисты и часто приходится устанавливать NT Workstation на компьютер, выполняющий роль сервера (NT Wks имеет значительно большие ресурсы по открытию разделяемых файлов). В такой ситуации наилучшим вариантом будет протокол IPX/SPX (без поддержки SAP). Работает практически так же быстро, как и NetBIOS (надо только сделать скидку на "естественное" торможение NT Wks по сравнению с Win95). Варианта с установкой эмуляции NetBIOS на IPX следует избегать - хотя работа программы будет так же быстра, как и на чистом IPX/SPX, при запуске программы и поиске ключа будет происходить сильное "торможение".

· Такой же вариант следует предпочесть и для системы с выделенным сервером Windows NT Server.

· Для систем с выделенным сервером Novell NetWare 3.12 или 4.11 протокол IPX/SPX является практически единственным. Его использование дает прекрасные результаты, как по надежности поиска ключа, так и по скорости. А если еще применить двухпроцессорную конфигурацию (с NetWare 4.11) то система просто будет летать. Только ни в коем случае не надо ставить на рабочие станции родного Novell-овского клиента. Глючит по-черному. Несмотря на мое теплое отношение к продуктам Novell и резко отрицательное к продуктам от Била Гейтса, вынужден признать, что Microsoft-овский клиент NetWare для Win95 вполне прилично выполняет свои функции.

Все вышеописанные варианты проверялись на наиболее капризной комбинации: 1C:Бухгалтерии 7.5, поставленной поверх 1С:Торговли 7.5 в один и тот же каталог. При этом тестировались NetHasp Server-ы от релизов с 8-го по 15-й. Наилучшие (по безотказности и надежности) результаты показал NetHasp Server от 13-го релиза, вне зависимости от какого продукта он был взят (проверяли в том числе NetHasp Server от SQL-версий). Не забыли мы и про проблемы с ключами от Бухгалтерии 6.0 о которых часто пишут в конференции 1сsoft. Как ни странно, никаких проблем у нас с ними не было - все прекрасно функционировало "в одном флаконе" в вышеописанных конфигурациях. Во всяком случае, посоветовать кое-что могу: надо внимательно читать не только печатную документацию, но и файлики "Readme" на установочных дискетах. Ну а пользователям пиратской продукции могу только посочувствовать.

Здесь следует добавить еще несколько слов вот о чем: если на Вашей сети установлено несколько протоколов, то запись в AUTOEXEC.BAT "set nethaspprotocol=…" определяет только протокол, который будет использоваться для поиска ключа на сети. А вот с помощью какого протокола будут выполняться файловые операции программой 1С? Нами замечено, что многие сетевые глюки появляются, когда на разных компьютерах сети установлен разный набор протоколов и каждая станция (т.е. каждый экземпляр программы 1С) выбирает тот протокол, который ей больше по душе из того набора, который предлагается на данном компьютере. Поэтому настоятельно рекомендую унифицировать все рабочие станции сети по набору протоколов и их настройкам.

5. NE2000-совместимые драйверы.

Очень часто в процессе установки сетевой карты в компьютер Win95 сама определяет свежеустановленную сетевую карту как NE2000-совместимую и устанавливает соответствующий драйвер. Многие "специалисты" этим и удовлетворяются. А иногда просто для карты нет дискеты с драйвером и искать его лень - ведь установился же NE2000-совместимый и вроде бы даже все работает. Вот это самое "вроде все работает" может жестоко Вас подставить.

Действительно, если на сетевую карту установился NE2000-совместимый драйвер, то сеть внешне может быть вполне (и даже очень хорошо) работоспособна. Однако, установка такого драйвера на современную сетевую карту подобна установке драйвера VGA на хорошую видео карту с ускорителем. Вы не в состоянии использовать всю ее функциональность. Дело в том, что сетевая карта имеет много аппаратных функций, которые используются сетевым ядром системы Windows95 через драйвер карты. Если установлен "родной" драйвер, то все эти функции полноценно используются. Если же установлен NE2000-совместимый драйвер, то во время установки он проводит тесты, чтобы определить, какие функции имеются у карты. Как правило, аппаратное исполнение любой сетевой карты хоть немного, да отличается от стандарта совместимости, по которому действует драйвер NE2000. Поэтому, некоторые из имеющихся в наличии функций, остаются для NE2000-совместимого драйвера невидимыми и при последующем обращении ядра Windows к этой функции, драйвер даже не пытается что-то сделать с картой, а просто возвращает ядру код успешного завершения. Для обычной работы сети большинство таких "продвинутых" функций не нужны, поэтому все выглядит пристойно - сеть работает, файлы качаются и т.д. и т.п. Однако, программа 1С для поиска ключа видимо использует какую-то из этих функций, скорее всего что-то связанное с широковещательными посылками. Если NE2000-совместимый драйвер способен реально заставить карту выполнить эту функцию, то все будет хорошо: ключ будет найден. Если же выполнение функции просто имитируется, то программа 1С ключ не найдет.

По опыту работы могу сказать следующее: в 60-70% случаев неработоспособности программ 1С на сети (не находится ключ) виноваты те, кто залепил NE2000-совместимый драйвер вместо "родного", поставляемого на дискете или CD вместе с картой. Особенно это касается случаев установки такого драйвера на компьютер, на котором установлены ключи NetHASP.

Метод лечения очевиден: установить "родной" драйвер. А вывод прост: всегда, когда на сети с программами 1С имеют место "глюки", и на одном или нескольких компьютерах обнаруживается NE2000-совместимый драйвер - это первое, что следует поправить.

Примечание: желающим удостовериться в разнице между родными и NE2000-совместимыми драйверами могу посоветовать следующий метод: установите свою карточку в сервер Novell NetWare и установите сначала родной, а потом NE2000-совместимый драйвера (имеются в виду конечно драйвера для сервера с расширением "lan"). И в том, и в другом случае посмотрите в программе MONITOR набор возможностей и функций, выполняемых картой.

6. "Левые" драйвера сетевых карт.

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

Имелась работоспособная сеть: 15-20 компьютеров на витой паре и сервер Novell NetWare 3.12. Происходило расширение сети - добавляли 3 или 4 компьютера (точно не помню сколько). В компьютеры установили свежезакупленные сетевые карты на чипе AMD и драйвера с дискеток, поставленных вместе с картами. Все шло нормально, пока дело не дошло до последнего компьютера из новой партии. Когда стали устанавливать драйвера, обнаружили, что на дискетке помимо обычного драйвера живет еще один драйвер - т.н. "турбо"-драйвер. В прилагаемом файлике "Readme" утверждалось, что при применении этого драйвера производительность сети увеличится на 10-15%. Ну что ж, увеличение производительности - это хорошо. Поставили этот "турбо" драйвер. Проверили. Да, действительно, скорость передачи данных несколько возросла. По несчастной случайности "одевание" последнего компьютера происходило поздно вечером, когда на сети никто уже не работал, поэтому проверяемый компьютер был на сети один одинешенек. Опять же, поскольку было уже поздно, другие компьютеры из новой партии "переодевать" в турбо-драйвера мы не стали и разошлись по домам весьма довольные. И естественно, про турбо-драйвера моментально забыли. Но, начиная с утра следующего дня нас начал доставать персонал предприятия: система работала очень медленно. При ближайшем рассмотрении обнаружилось огромное количество коллизий на довольно слабо загруженной сети - светодиод коллизий на хабе светился практически постоянно. Начали разбираться. И опять нам не повезло: тот самый компьютер, где был установлен турбо-драйвер, был загружен практически постоянно и до него мы добрались в последнюю очередь. В итоге, когда наконец до этого компьютера добрались и он был выключен - тут же восстановилась нормальная работоспособность сети. Поскольку было абсолютно непонятно, почему совершенно исправный компьютер с совершенно исправной картой (а это было проверено в первую очередь) ведет себя таким образом, мы занялись исследованиями, использовав все имевшееся в наличии программное и аппаратное обеспечение, позволявшее анализировать функционирование сети. Не буду пересказывать здесь подробности наших изысканий, которые заняли у нас 2-3 дня. Вот что нам удалось выяснить. Турбо-драйвер прекрасно работает и действительно увеличивает производительность сети на 10-15%, но… только в том случае, если ВСЕ компьютеры в сети (в т.ч. и сервер) укомплектованы одинаковыми картами и НА ВСЕХ них установлены эти самые турбо-драйвера. Как только в сети появляется "чужая" карта или "чужой" драйвер, так сразу же все карты, снабженные турбо-драйверами, начинают бомбардировать сеть широковещательными посылками, ожидая, что вновь появившаяся "чужая" карта получит эти посылки и ответит на них. Соответственно, если она ответит так как нужно, т.е. в случае установленного турбо-драйвера, в сети устанавливается симбиоз: турбо-драйвера образуют сообщество, которое использует дополнительную функциональность карт для ускорения работы сети. Если же ответ неправильный или ответа вообще не получено (т.е. драйвер действительно "чужой"), то турбо-драйвер не желая смириться с этим продолжает бомбардировать сеть широковещательными посылками, вероятно в надежде на то, что в один прекрасный момент "чужая" карта с "чужим" драйвером вдруг заработают так как надо. В нашем случае, поскольку на сети существовала всего одна карта с турбо-драйвером, она непрерывно бомбардировала сеть этими широковещательными посылками, причем делала это тем интенсивнее, чем больше машин было активно на сети. Налицо явный просчет разработчика программного обеспечения для сетевой карты. Если эти турбо-драйвера поставлялись в качестве рекламы, то конечно в файле "Readme" следовало написать об особенностях их применения. Вот такая история, стоившая нам нескольких дней сильной головной боли и ругани с заказчиком.

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

7. 100 мегабитная сеть.

100 мегабитная сеть дарит нам удивительный глюк, метода борьбы с которым (кроме переконфигурирования сети) я пока не нашел. Непосредственного отношения к программам 1С этот глюк не имеет, но поскольку он сильно снижает быстродействие сети, его следует здесь упомянуть. Глюк возникает, если имеется "умный" хаб 10/100 (который сам разбирается, какой из каналов с какой скоростью может работать) и с этого хаба каскадируется хотя бы один обычный 10 мегабитный хаб. Кроме этого, к хабу 10/100 подключены не только 100 мегабитные станции, но и парочка 10 мегабитных. Так вот этот "умный" хаб в некоторые моменты становится слишком умным: он начинает путать 10 мегабитные линии со 100 мегабитными. Вернее он начинает считать некоторые 100 мегабитные линии 10 мегабитными. А компьютеры со 100 мегабитными карточками продолжают работать в режиме 100 мегабит. В результате резко подскакивает уровень коллизий и катастрофически падает производительность сети. Лечение "на лету" проводится кратковременным (на 2-4 сек.) выключением питания "умного" хаба. Иногда кроме этого приходится перегружать сервер. Такие глюки происходят не часто, но если происходят, то весь персонал, работающий на сети встает на уши. Что здесь можно придумать? Или полностью разделить 10 и 100 мегабитные сегменты, или не использовать "умный" хаб, а использовать комбинированный хаб с фиксированным числом 10 и 100 мегабитных линий. Решение не самое лучшее, но иного я пока не придумал.

8. SQL-версии.

Все сказанное выше относительно неполадок, связанных с поисками ключа относится и к SQL-версиям программ 1С. Что же до всего остального, то в связи с отсутствием опыта (SQL-версии выпущены недавно), нами пока замечены только разные мелочи. Могу только напомнить, что не следует забывать устанавливать протокол Named Pipes при установке MS SQL Server. Отсутствие этого протокола существенно снижает производительность системы.

9. Некоторые общие рекомендации для больших сетей

Если Вы имеете дело с большой сетью (а большой сетью я считаю сеть с числом компьютеров более 20 и конечно, с выделенным сервером), то экономически и технически вполне оправдано завести отдельный компьютер для установки на нем ключей NetHASP. Избавьте сервер от этой нагрузки: ведь у него и так хватает дел, которыми следует заняться. Поверьте, такой подход облегчит жизнь и серверу и Вам, если Вы занимаетесь администрированием этой сети. "Ключевой" компьютер не обязательно одевать "по полной программе" - это может быть вполне посредственная по характеристикам машина, например какой-нибудь 486DX2-66. Кроме задачи по обслуживанию ключей этот компьютер можно загрузить работой по приему и отправке почты и факсов, обслуживанию линии удаленного доступа (в режиме Dial Up), а также другими вспомогательными задачами, например программированием офисной ATC и протоколированием ее работы с помощью программы типа WinTarif. Ну и конечно, как и сервер, этот компьютер должен быть запитан через UPS.

Далее: не вешайте на один сетевой сегмент более 20 компьютеров, даже если на них только вбивают накладные. Трафик по сегменту будет слишком интенсивным и сеть будет тормозить.

При возможности используйте "европейский" метод разводки сети, т.е. все кабели от всех рабочих мест сводятся в одну комнату. Конечно, кабеля может потребоваться значительно больше и за прокладку придется платить больше, но поверьте, при последующей эксплуатации это окупится сторицей.

среда, 2 октября 2013 г.

Плюсы и минусы работы с частным программистом 1С

Многие работодатели, заказчики задаются вопросом: «С кем работать? Частным лицом или компанией? Или нанять на работу своего программиста 1С?». Давайте это и обсудим со всех сторон.

Допустим, есть некая задача, которую необходимо выполнить. Для любого заказчика существует, по сути, только два критерия: сроки и стоимость решения.

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

Рассмотрим три варианта решения:

1. Прием на работу штатного программиста 1С.

Приемлемый вариант, сам долго и много работал программистом 1С в крупных компаниях. В том, то и дело КРУПНЫХ компаниях, в которых существует постоянный поток различных задач, проблем и т.д. с 1С:Предприятием. Но стоимость такого подхода высока. Зарплата хороших специалистов по 1С начинается от 60 000 рублей. Что касается сроков то они зачастую, формально, назначаются самим программистом 1С, т.е. программист 1С является и заказчиком и исполнителем. Что не всегда эффективно. Цифры: 12 месяцев Х 60000 рублей (например) = 720 000 рублей в год. + налоги.

2. Работать с компанией, занимающейся доработкой 1С.

В фирмах занимающихся внедрением, настройкой 1С мне также приходилось работать. Как правило, они требуют от заказчика детальное техническое задание на внедрение, настройку 1С. Затем происходит оценка работ исходя из временных затрат (часов). Потом эти часы умножаются на ставку за час, она как правило колеблется от 1500 до 3000 рублей, что выходит не в маленькую сумму по затратам на внедрение, доработку 1С. Но если у Вас 1С:Предприятие нелицензионная, то Вы сначала вынуждены будете ее купить, иначе даже разговаривать не будут, т.е. по большому счету, ставка больше идет на продажу 1С:Предприятие и ее поддержку (диски ИТС). Когда работа сдана, Вы подписываете «Акт сдачи работ» и все! Шаг влево, шаг вправо – опять оплата. Преимущества конечно также есть, это взаимозаменяемость специалистов по 1С, правовые аспекты и т.д. Кстати, про программистов 1С, они имеют от 15 до 30% от заказа в лучшем случае. Поэтому их заинтересованность низка, отсюда, со временем очень сильно падает мотивация.

3. Работать с частным программистом 1С (который тоже занимается доработкой 1С).

Конечно же, работа с частным программистом 1С учитывает все те недостатки описанные выше. Минус один, если вдруг человек заболел, или не успевает что-либо, то нет взаимозаменяемости, но 1С:Предприятие платформа открытая, можно найти и другого частного специалиста.

Частный программист 1С (фрилансер) не спросит у Вас про то, где Вы взяли 1С:Предприятие, ему главное выполнить ту работу, которую Вы ему заказали, т.е. все поставлено именно на результат. Как правило, речь не идет о почасовой оплате. Например, я работаю так, Заказчик ставит задачу, я сразу озвучиваю, сколько это будет стоить и не важно сделаю я это за день или за месяц. Мне, как специалисту, выгодно сделать это быстрее, отсюда у частного программиста 1С более большая мотивация. Ну и конечно цены ниже… Т.е. у частного специалиста по 1С работа идет больше на результат! За меньшие деньги!

Выбор за Вами!