Автоматизация учета | Обмен данными с удаленными подразделениями

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

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

Итак, какие же существуют средства для обмена данными между удаленными подразделениями. Перечислим их для начала.

Непосредственный удаленный доступ к единой базе данных.

Штатные средства 1С для синхронизации данных в удаленно расположенных базах данных.

Не штатные средства, разрабатываемые сторонними производителями, для синхронизации данных в удаленно расположенных базах данных.

Индивидуальные механизмы выгрузки-загрузки данных из одной базы в другую.

Опишем недостатки и достоинства этих методов.

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

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

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

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

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

Данное решение превосходит предыдущее в вопросах зависимости от канала связи. Синхронизировать данные можно раз в день, в неделю, или несколько раз в день, в зависимости от того, какая оперативность вам требуется. А вот кратковременное отсутствие связи в данном случае не парализует работу удаленных подразделений. Оперативность при этом, безусловно, снижается, но мы уже упомянули о том, что требуемую оперативность определяете именно вы. Режим On-line в вашем конкретном случае может вовсе и не требоваться. Так, кстати, чаще всего и бывает. Предположим, есть у вас удаленный магазин. Обмениваться с ним данными целесообразно раз в день, чтобы подводить общие итоги, плюс в те моменты, когда вы осуществляете перемещение товаров между магазинами. Что касается вопросов громоздкости базы данных и ее безопасности, то они при таком подходе, оказываются еще более уязвимыми, чем при непосредственном удаленном доступе. Действительно, ведь на деле мы теперь имеем не одну общую базу данных, где есть абсолютно все о нашей компании, а сразу несколько ее клонов с минимальными расхождениями (от одной синхронизации до другой). Таким образом, злоумышленник может получить доступ к интересующей его информации уже не только в главном офисе, но и в любом удаленном подразделении. А следовательно, расходы на обеспечение безопасности при данном подходе растут тем больше, чем больше у вас удаленных подразделений.

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

3. Не штатные средства, разрабатываемые сторонними производителями для синхронизации данных в удаленно расположенных базах данных. По существу функционирования данный метод ничем не отличается от предыдущего. К нему справедливы все те же достоинства и недостатки. Отличие заключается лишь в инструменте реализации обмена данными. Вместо компоненты 1С:Управление распределенными базами данных можно использовать аналогичные программы, разрабатываемые сторонними производителями. Обычно такие средства дешевле, чем штатные средства 1С, иногда даже лишены некоторых их недостатков (например, требования к абсолютной идентичности конфигураций). Но! Если вы решите воспользоваться такими средствами, вам следует знать о том, что такие средства работают напрямую с ядром системы 1С:Предприятие, а следовательно подобные действия нарушают права разработчика (имеется в виду фирма 1С) и лицензионное соглашение. Сама фирма 1С, естественно, не одобряет подобных действий, через свою сеть альтернативных средств обмена данными не продает, и получить какую-либо поддержку в случае нештатных ситуаций от нее будет невозможно.

4. Индивидуальные механизмы выгрузки-загрузки данных из одной базы в другую. В своей повседневной практике подобные решения наша компания использует чаще всего. Сущность данного подхода заключается в том, что в каждом удаленном подразделении функционируют свои независимые друг от друга учетные программы. Каждое ведет учет в соответствии с теми требованиями и задачами, которые перед ним стоят. Соответствующим образом происходит и индивидуальная настройка и доработка тех или иных конфигураций в удаленных подразделениях. Обмен данных между конфигурациями осуществляется с помощью специально индивидуально создаваемых под конкретные задачи механизмов выгрузки-загруки данных. То есть из одной базы нужные данные выгружаются, а из другой - загружаются. Физический обмен может осуществляться разными способами: через текстовые файлы, через xml, через dbf, и т.п. Передача самих файлов может осуществляться тоже по-разному: через ftp-сервер, по электронной почте, и т.д. К передаче файлов могут быть также применены различные средства обеспечения безопасности. Но! Главным отличием от предыдущих подходов является тот факт, что сами данные, которые передаются от одного подразделения к другому, содержат только очень ограниченную информацию, описывающую, во-первых, текущий момент времени (например, выгрузка итогов дня), а во-вторых, только те объекты учета, которые нам необходимы. Например, если во всех удаленных подразделениях мы используем единый справочник товаров и однозначно идентифицируем товары по коду (или штрих-коду), то в передаваемых файлах наименований товаров может не быть вообще, там может присутствовать только код. Другой пример из жизни - удаленный склад в портовом терминале. Предположим офис у вас в Москве. В порту Новороссийска у вас есть удаленное подразделение, которое занимается приемкой товара. Причем это подразделение не имеет (и не должно иметь!) представления о стоимости этого товара вообще. Оно оперирует только с количеством. В его задачу входит только отслеживание правильности объема получаемого товара, списания или возврата негодного, и сообщение о своих действиях в центральный офис с тем, чтобы при продаже менеджеры имели реальную картину по наличию товара. Организовав такой обмен подобным способом, вы с одной стороны исключаете из процесса обмена информацию о деньгах вообще, а с другой - обеспечиваете бесперебойную работу разных по сложности и объему конфигураций, не перегружая их избыточной информацией.

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

А выбирать, прежде всего, конечно же Вам!