Образец исследования по ведению справочника Контрагентов и Договоров для большого предприятия для 1С
//
//
//
//
Образец исследования по ведению контрагентов
Приведен пример исследования по ведению справочника Контрагенты и Договоры для большого предприятия с филиалами, при том, что справочники используются в двух параллельных учетах — управленческом и оперативном. Рассмотрены основные проблемы, возникающие при этом. Можно использовать как каркас.
Термины
Управленческий учет
Оперативный учет
Контрагент
Договор
Вид взаимодействия
Юридические контрагенты
Фактические контрагенты
Условие договора
Центральная база
База филиала
Синхронизация аналитики между учетами
Синхронизация аналитики между филиалами
Дублирование аналитики распределенное
Дублирование аналитики в учете
Задержка центральной аналитики
Источник распределенной аналитики
Внутренняя неоднородность аналитики
Участок аналитики
Инструменты свертки дублей
Регламентные работы по поиску дублей
Ведущая аналитика
Ведомая аналитика
Исследование
Данный документ описывает предполагаемую структуру ведения справочников контрагентов и договоров, в целях унификации этой области учета в управленческом и оперативном учете.
Решение: Справочник контрагентов в управленческом учете называется «Контрагенты».
Справочник контрагентов иерархический, причем группы элементов тоже являются контрагентами.
Решение: Иерархия контрагентов не несет никакой функциональной нагрузки, используется только для визуальной группировки контрагентов.
Контрагенты могут быть разделены по видам взаимодействия с нашей организацией – «поставщики», «покупатели» и т.п. Один контрагент может участвовать в нескольких видах взаимодействия.
Справочник контрагенты разбит на папки, т.е. для каждого контрагента независимо может быть указана некоторая папка из иерархического справочника «Папки контрагентов».
Решение: Папки контрагентов соответствуют видам взаимодействия. Контрагент помещается в папку, соответствующую основному виду взаимодействию с контрагентом, однако контрагент может выступать и в другом качестве
Справочник контрагенты содержит реквизит «Головной контрагент», ссылающийся на контрагента.
Решение: Для каждого контрагента указывается головной контрагент (холдинг). Для контрагента, не входящего ни в какую структуру (не имеющего головного контрагента) указывается он сам.
Контрагенты могут быть юридическими и фактическими. Юридические контрагенты являются зарегистрированными субъектами хозяйственной деятельности и однозначно идентифицируются по совокупности реквизитам «Инн» и «КПП». Фактические контрагенты используются для указания конкретного контрагента, они могут подразумевать юридического контрагента, а могут вообще описывать не зарегистрированного субъекта хозяйственной деятельности.
Договоры описывают некоторые договоренности, заключенные с контрагентами. Аналогично договоры могут быть фактическими и юридическими.
Каждый договор может разбиваться на несколько условий договора. Каждое условие описывает этапы или направления работы по договору, например «предоплата», «поставка первой партии товара», «поставка образцов товара» и т.п. Обычно условия договора прописываются в самом договоре, но в целях учета нужно знать, по какому условию договора выполняется та или иная хозяйственная операция.
Решение: Смысл иерархии договоров:
· Первый уровень – договор (реальный)
· Второй уровень – условия договора
Различные условия договора могут группироваться по значению реквизита «Контрагент УУ», ссылающегося на справочник «Аналитика Контрагентов УУ». Это нужно для построения отчетов по одинаковым видам условий договоров.
Важно учесть, что разные контрагенты или договоры могут по-разному использоваться в базе данных. Какую-то аналитику могут заводить и использовать одни пользователи, какую-то другие, разная аналитика имеет разный жизненный цикл и т.п. Т.е. в пределах даже одного вида аналитика она неоднородна. Назовем это вопросом внутренней неоднородности аналитики. Поэтому обычно имеет смысл выделить участки аналитики для каждого вида аналитики и описать их.
Решение:
Выделены следующие участки аналитики контрагентов:
(… пропущено…)
Управленческий и оперативный учет обмениваются друг с другом данными, поэтому возникает вопрос синхронизации аналитики между учетами.
Кроме того, даже в пределах одного вида учета могут существовать центральная база и базы филиалов. Возникает вопрос синхронизации аналитики между филиалами.
Оперативный учет требует постоянной доступности базы, вне зависимости от наличия интернет, поэтому для оперативного учета строго необходимо наличие базы на филиале.
Управленческий учет не требует постоянной доступности базы, допустимы некоторые перебои, поэтому можно рассматривать вопрос о работе исключительно в центральной базе в терминальном режиме, в зависимости от доступности каналов связи.
Решение:
В управленческом учете используется центральная база и базы филиалов. В оперативном учете также используется центральная база и базы филиалов.
Если аналитика заводится не только в центральной базе, но и в филиалах, то есть вероятность того, что одна и та же аналитика может быть заведена в нескольких филиалах, при обмене она попадет в центральную базу и в центральной базе образуются дубли. Это вопрос распределенного дублирования. Проблема не обозначает ситуацию, что все элементы будут дублироваться между собой, но некоторое количество дублей все-таки будет возникать. Если для заведения аналитики используется некоторая центральная база, то проблема распределенного дублирования отсутствует.
Решение: т.к. одна и та же аналитика может заводиться на филиалах и в центре, то вопрос распределенного дублирования актуален.
Если аналитика заводится только в центральной базе, то базы филиалов не смогут работать по данной аналитике, пока не произойдет обмен с центральной базой. Будем называть это задержкой центральной аналитики. Поэтому для оперативного учета вариант заведения аналитики строго неприемлем. Тем не менее, можно предусмотреть вариант, когда филиалы оперативного учета работают с центральной аналитикой, а в случае недоступности центральной базы иметь право заводить центральную аналитику самостоятельно. Но здесь возникает человеческий фактор, т.к. мы не можем точно проконтролировать, когда действительно нет связи с центральной базой, а если заведение аналитики из центра будет сложной процедурой, то пользователи предпочтут заводить аналитику самостоятельно, ссылаясь на отсутствие связи с центральной базой.
Решение: Задержка центральной аналитики для управленческого учета допустима, а для оперативного — нет. Специальная база для ведения центральной аналитики не используется.
Для уменьшения задержки центральной аналитики:
1. Подбор оптимальной частоты обмена, так , чтобы минимизировать задержки центральной аналитики.
2. Использование одного централизованного хранилища аналитики. Это может быть центральная база, доступная в терминальном режиме, из которой пользователи могут получить нужные им элементы, не дожидаясь обмена, или же это может быть некоторая изолированная база, в которой хранится только аналитика, из которой так же пользователи могут получить нужную им аналитику, и с которой синхронизируются все остальные базы.
Даже если аналитика заводится в центре, существует еще одна проблема – пользователи центральной базы могут не знать, какая и когда аналитика понадобится пользователям филиалов. Т.е. если аналитика исходит от пользователей филиалов, им придется высылать заявки на заведение аналитики в центре, а пользователи в центре иногда могут быть менее компетентны по проблемам заведения данной аналитики, чем пользователи на местах. Назовем эту проблему источником распределенной аналитики.
В пределах одной базы, если справочник контрагентов плохо структурирован, то один и тот же контрагент может быть заведен дважды. Однако, это является ошибкой учета, а не организации базы данных и исправляется стандартными средствами – удалением ошибочно заведенного контрагента и заменой его на правильного контрагента. Это вопрос дублирования аналитики в учете.
Если распределенное дублирование допускается, то в системе должны быть инструменты свертки дублей. Эти инструменты могут быть использованы и для решения проблем дублирования аналитики в учете. Инструмент в платформе 1С реализуется довольно просто, здесь гораздо больше организационных вопросов, т.к. в данном случае должны быть оговорены регламентные работы по поиску дублей. Кто именно и с какой периодичностью (ежедневно, еженедельно, по заявкам) обнаруживает дубли и формирует заявки на замену дублей. Как часто удовлетворяются заявки на замену дублей и т.п.
Решение: Инструменты свертки дублей и регламент его использования необходимы.
Если дублирование допустимо, то в целях упрощения поиска дублей можно использовать следующие варианты решения:
Синхронизация учета между учетами
Если используется централизованное хранилище справочников, то проблем синхронизации между учетами не стоит – они и так синхронизированы по кодам этого хранилища.
В противном случае возникают проблемы синхронизации справочников.
Частично проблему можно решить, если указать, какие участки аналитиков являются ведущими и ведомыми в разных учетах, т.е. указать, какие справочники заводятся в каком учете. У одного элемента справочника могут быть поля, используемые для разных учетов, но ключевые поля, позволяющие идентифицировать объект аналитики, должны заполняться в этом случае только в одном из учетов.
Если подобное разделение ответственности можно выполнить, то проблема решается автоматически – элемент может быть заведен только в одном виде учета, после обмена между учетами он сразу попадает в другой учет.
Здесь нужно не забыть решить проблему с оперативностью заведения аналитики, т.е. чтобы у потребителей аналитике не было проблем с появлением аналитики в их учете.
Если разделение ответственности на ведущие (ведомые) выполнить нельзя, то решением проблемы может быть некоторая система кодировки. Просто объединять аналитику нельзя, т.к. может появиться дублирование, а исправлять дубли между учетами сложно.
Система кодировки подразумевает, что элементам справочников назначаются одинаковые кода для синхронизации. В данном случае не следует забывать о том, что элементы аналитики должны иметь одинаковый смысл. Если в одном учете контрагент рассматривается как холдинг, а во втором – как организация, возможно, придется завести нового контрагента — холдинг.
У некоторых видов аналитики можно использовать для синхронизации имеющийся уникальный код. Например, юридических контрагентов можно синхронизировать по совокупному значению ИНН и КПП.
Нужно стараться избегать такой параллельной ответственности, т.к. синхронизация через систему кодировки подразумевает ручной труд.
Решение: За различными участками аналитики строго закреплена ведущая и ведомая система, поэтому пересечения ответственности быть не должно. Элементы синхронизируются между системами по уникальному идентификатору объекта.
Нужно для каждого вида аналитики и каждого участка аналитики тщательно проработать вопрос, кто является источником и потребителем данного участка аналитики. При этом сразу проявятся проблемы рассогласования:
1. Задержки потребителя, связанные с отсутствием аналитики, не полученной из источника.
2. Большая компетентность потребителя аналитики по сравнению с источником аналитики.
3. Сложность процедуры получения аналитики для потребителя.
4. Сложность процедуры заведения аналитики для источника.
При переходе на новые системы нужно перенести остатки по контрагентам и договорам, поэтому необходимо знать, как в настоящее время учитываются данные по контрагентам и договорам.
(… пропущено …)
Имеет смысл подумать об ограничении видимости элементов аналитики для пользователей, т.е. чтобы пользователи видели только ту аналитику, которая им нужна для работы. Это поможет, в том числе, и решению проблемы дублирования аналитики в учете.
Очевидно, что вопросы видимости контрагентов связаны с видом взаимодействия с контрагентами.
Решение: Пока доступно только решение через механизм избранных объектов. Пользователь сам формирует свой персональный список часто используемых контрагентов и у него есть возможность выбора объекта из этого персонального списка при отборе, например: «мой любимый поставщик».
