При внедрении 1С:ERP приходится делать множество программных доработок, большинство из которых носит частный характер. Они нужны конкретному заказчику или даже пользователю, на конкретном участке системы. Тем не менее, нередко вместо множества частных мелких доработок можно создать одно универсальное решение. И если такая возможность предоставляется, надо обязательно ей воспользоваться.
Вот несколько примеров таких ситуаций, возникших при выполнении моих проектов:
Заполнение реквизитов. На этапе опытной эксплуатации заказчик поставил задачу реализовать контроль заполнения некоторых реквизитов в документе «Заказ клиента». Вместо того, чтобы добавить эти проверки в модуль этого документа, я после согласования с клиентом поручил программисту разработать функцию, которая проверяла бы заполнение любого реквизита в любом объекте. Кроме того, функция должна была проверять соответствие значения, указанного пользователем, заданному списку, а также возможность выполнить произвольную проверку данных объекта при помощи запроса. То есть, мы решили задачу выполнения любой сколь угодно сложной проверки любого реквизита в любом объекте системы.
Зачем я это сделал? Я понимал, что заказчик начинает выстраивать в системе регламент работы сотрудников. Он устанавливает для них какие-то ограничения и хочет автоматически проверять корректность их действий в системе. Следовательно, скоро понадобятся проверки и ограничения в других справочниках и документах, и на других участках. Дальнейший ход опытной эксплуатации показал, что я прав – заказчик начал вводить новые проверки. При этом он уже не обращался к нам, а самостоятельно пользовался созданной нами функцией. Это сократило для нас количество мелких дешевых доработок и позволило не отвлекаться от решения более важных и дорогих задач.
Права на изменения статуса. При запуске подсистемы управления денежными средствами заказчик попросил ограничить права сотрудников на изменение статуса заявки на расход денежных средств. Следуя логике, описанной выше, я принял во внимание, что в 1С:ERP во многих важных документах есть статус, и что задачи по ограничению прав на изменение статуса других документов вскоре обязательно появятся. Поэтому я поручил разработчику создать небольшое дополнение к системе прав доступа – в карточке пользователя добавить возможность указать любой объект со статусом, и статусы, при которых пользователь может изменять объект. Действительно, через некоторое время возникла потребность ограничить права доступа для заказов, клиента, складских ордеров и других документов. При этом никаких доработок делать уже не было нужно, работа свелась к настройке карточек пользователей, которую выполнил сам заказчик.
Загрузка данных от разных контрагентов. При автоматизации компании, занимающейся интернет-торговлей, возникла задача загружать в систему данные от разных служб доставки. На основании этих данных нужно было формировать складские документы, документы реализации и возвратов, а также обновлять данные о состоянии заказов. Кроме того, требовалось сверять сведения об оплате товаров, переданные службами доставки с данными из банка. Компания работала с несколькими службами доставки, и все они предоставляли данные в разном формате. Поэтому задача была выполнена следующим образом: сначала мы разработали универсальные объекты для хранения всех данных, передаваемых перевозчиками. Данные перевозчиков сначала загружались в это единое хранилище отдельными обработками. А документы 1С:ERP формировались уже с использованием хранилища.
Почему был использовано такое решение? Формирование учетных документов 1С:ERP – сложная и дорогая задача. Мы решили ее один раз, разработав модуль, который использовал для этого данные универсального хранилища. А загрузка данных из службы доставки – задача простая. Службы доставки могут измениться, или они могут поменять формат своих файлов. С выбранным нами решением в этом случае нужно только написать простой загрузчик новых данных в уже известный формат хранилища. С такой задачей легко справится служба поддержки компании, без нашей помощи. Алгоритм формирования документов 1С:ERP при этом менять не нужно – он использует данные хранилища, которые не менялись.
При постановке проектных задач нужно всегда стараться применить этот подход, пытаться обобщить задачи и решить их наиболее универсальным способом. Во-первых, при таком подходе вместо множества мелких задач мы делаем одну большую. Это упрощает управление и снижает риски кодирования, ведь каждая отдельная задача несет отдельный риск создания ошибок. Проконтролировать же качество в одной крупной задаче проще, чем во множестве мелких. Во-вторых, уменьшается количество постановок задач и их приемок. Эта условно-платная часть работы. Она необходима, но клиенту сложно объяснить, почему он должен за это платить, поэтому чем такой деятельности меньше, тем лучше. В третьих, универсальные решения можно применить на других проектах для других клиентов, сэкономив время и средства для решения более важных задач.
Заполнение реквизитов. На этапе опытной эксплуатации заказчик поставил задачу реализовать контроль заполнения некоторых реквизитов в документе «Заказ клиента». Вместо того, чтобы добавить эти проверки в модуль этого документа, я после согласования с клиентом поручил программисту разработать функцию, которая проверяла бы заполнение любого реквизита в любом объекте. Кроме того, функция должна была проверять соответствие значения, указанного пользователем, заданному списку, а также возможность выполнить произвольную проверку данных объекта при помощи запроса. То есть, мы решили задачу выполнения любой сколь угодно сложной проверки любого реквизита в любом объекте системы.
Зачем я это сделал? Я понимал, что заказчик начинает выстраивать в системе регламент работы сотрудников. Он устанавливает для них какие-то ограничения и хочет автоматически проверять корректность их действий в системе. Следовательно, скоро понадобятся проверки и ограничения в других справочниках и документах, и на других участках. Дальнейший ход опытной эксплуатации показал, что я прав – заказчик начал вводить новые проверки. При этом он уже не обращался к нам, а самостоятельно пользовался созданной нами функцией. Это сократило для нас количество мелких дешевых доработок и позволило не отвлекаться от решения более важных и дорогих задач.
Права на изменения статуса. При запуске подсистемы управления денежными средствами заказчик попросил ограничить права сотрудников на изменение статуса заявки на расход денежных средств. Следуя логике, описанной выше, я принял во внимание, что в 1С:ERP во многих важных документах есть статус, и что задачи по ограничению прав на изменение статуса других документов вскоре обязательно появятся. Поэтому я поручил разработчику создать небольшое дополнение к системе прав доступа – в карточке пользователя добавить возможность указать любой объект со статусом, и статусы, при которых пользователь может изменять объект. Действительно, через некоторое время возникла потребность ограничить права доступа для заказов, клиента, складских ордеров и других документов. При этом никаких доработок делать уже не было нужно, работа свелась к настройке карточек пользователей, которую выполнил сам заказчик.
Загрузка данных от разных контрагентов. При автоматизации компании, занимающейся интернет-торговлей, возникла задача загружать в систему данные от разных служб доставки. На основании этих данных нужно было формировать складские документы, документы реализации и возвратов, а также обновлять данные о состоянии заказов. Кроме того, требовалось сверять сведения об оплате товаров, переданные службами доставки с данными из банка. Компания работала с несколькими службами доставки, и все они предоставляли данные в разном формате. Поэтому задача была выполнена следующим образом: сначала мы разработали универсальные объекты для хранения всех данных, передаваемых перевозчиками. Данные перевозчиков сначала загружались в это единое хранилище отдельными обработками. А документы 1С:ERP формировались уже с использованием хранилища.
Почему был использовано такое решение? Формирование учетных документов 1С:ERP – сложная и дорогая задача. Мы решили ее один раз, разработав модуль, который использовал для этого данные универсального хранилища. А загрузка данных из службы доставки – задача простая. Службы доставки могут измениться, или они могут поменять формат своих файлов. С выбранным нами решением в этом случае нужно только написать простой загрузчик новых данных в уже известный формат хранилища. С такой задачей легко справится служба поддержки компании, без нашей помощи. Алгоритм формирования документов 1С:ERP при этом менять не нужно – он использует данные хранилища, которые не менялись.
При постановке проектных задач нужно всегда стараться применить этот подход, пытаться обобщить задачи и решить их наиболее универсальным способом. Во-первых, при таком подходе вместо множества мелких задач мы делаем одну большую. Это упрощает управление и снижает риски кодирования, ведь каждая отдельная задача несет отдельный риск создания ошибок. Проконтролировать же качество в одной крупной задаче проще, чем во множестве мелких. Во-вторых, уменьшается количество постановок задач и их приемок. Эта условно-платная часть работы. Она необходима, но клиенту сложно объяснить, почему он должен за это платить, поэтому чем такой деятельности меньше, тем лучше. В третьих, универсальные решения можно применить на других проектах для других клиентов, сэкономив время и средства для решения более важных задач.
