Конструктивный форум бухгалтеров Казахстана

Учет адреса и его частей.

Курсаков С.А.


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

Внешний вид адреса – обманчивая простота.
Все знают, как выглядит адрес – например –
«Республика Казахстан, г. Астана, ул. Абая, д.35, кв.67».
И вроде бы все здесь просто – но эта простота обманчивая.
Во-1-х, в отличие от простой атомарной информации вроде «наименование=принтер», адрес состоит из логических смысловых частей (страна, регион, область, город, район и т.д.). И эти части как-то надо вводить в программу и учитывать.
Во-2-х, эти части адреса бывают разными в разных странах. Как по названию, так и по количеству уровней.
В-3-х, адреса бывают разных видов (типов) – почтовый, юридический и т.д.
В-4-х, адреса присваиваются самым разным объектам – например, юрлицу в целом, его складам, отдаленным торговым точкам, подразделениям, физлицам и т.д.
Если у Вас не заболела голова от всех этих сложностей и подробностей, тогда пойдем далее.

Бухгалтерские и налоговые аспекты адреса.
Для бухгалтерских и налоговых целей существуют такие давно знакомые всем виды адресов, как «юридический адрес», «почтовый адрес» и «адрес места нахождения». В основном они используются в счете-фактуре. Когда-то давным-давно вокруг этих адресов в СФ бушевали штормы споров, эксперты определяли, какой адрес, в каком виде, когда, как и куда писать и т.д.
Спрашивается по прошествии нескольких лет, и какой толк был от этих бурлящих псевдонаучных споров? Зачем все это было нужно? Бумажная форма СФ постепенно отходит, и заменяется формой электронной (ЭСФ). В новой форме ЭСФ (вступает в силу с 01.10.2017) уже планируется использовать такие понятия, как «адрес отправки» и «адрес доставки» в разделе информации «грузоотправителя» и «грузополучателя» - только вот что-то бурлящих споров по этой теме не видать. Таким образом, мы видим, что – хочешь не хочешь - учетная ситуация всегда развивается в направлении усложнения, в данном случае количество видов адресов увеличивается. И вместо «бурных продуктивных споров» на тему «что же подразумевал законодатель» похоже, нужно раскладывать фактические ситуации по полочкам, анализировать участвующие в них объекты, укладывать их в системы понятий и предлагать для использования.
Например, «адрес доставки» и «адрес отправки» реально существует (вне зависимости от того факта, определил ли это существование законодатель). «Адрес отправки» и «адрес доставки» может не совпадать с адресом юридическим/почтовым/места нахождения. (В этом месте предполагаем, что уже отгремели «бурные продуктивные споры», и бухгалтера, ориентируясь на новые разъяснения, вместе с используемыми ими программами стали исправно писать эти новые адреса в новых полях документов). Но и даже от того, что эти новые адреса будут указаны в ЭСФ, это даст всего лишь – неанализируемые программно текстовые строки типа «Республика Казахстан, г. Астана, ул. Абая, д.35, кв.67». Кто будет эти строки разбирать, и кто поймет, что указанные в этих строках по ошибке «Астана» и «Атсана» - один и тот же город?

Непонимание учетными работниками многообразия видов адресов, их нужности и необходимости.
Многие учетные работники не понимают, что многообразие видов адресов будет неуклонно расти. Это вызвано прежде всего усложнением хозяйственной деятельности, ростом экономики, и не в первую очередь – требованиями регуляторов. Однако, фактически, все вопросы учета адресов зачастую сводятся к иногда вспыхивающим «псевдополезным» дискуссиям о том, в каком поле счета-фактуры какой адрес и как ставить. Излишне даже говорить, что такой подход – «создание искусственных проблем и их последующее благополучное разрешение» - ничего не дает ни для роста предприятия и экономики, ни для профессионального роста самого бухгалтера.
По мнению автора статьи, пока проблематика учета адресов не будет структурно продумана и решена для удобства всех ее пользователей, наращивание объемов этих строковых адресных данных ничего не даст.

Зацикливание на проблемах текущей локации (страны). Невозможность создания универсальной нормативной (или общепринятой) структуры адресов, применимой для всех стран.
Зачастую человек (автор книги, бухгалтер, программист, разработчик, налоговый работник и т.д.), сталкиваясь с проблематикой учета адресов, зациклен рамками своей текущей локации (проще говоря, своей страны). И подходит к вопросам адреса и его частей именно с родных, домашних позиций, закрывая глаза, либо совсем не зная, как учитываются адреса в других локациях (странах, частях света). Например, в одной из книг (А. Бондарь «Microsoft SQL Server 2014 в подлиннике», Спб, 2015) я наблюдал, как ее автор выстраивает структуру хранения частей адресов, последовательно вводя следующие таблицы – «страна», «регион», «район» (правда, в учебных целях). Батенька, помилуйте – ну если «страна» еще есть универсальное, общечеловеческое понятие – то тот же «регион» существует в основном в России (откуда родом автор книги). Да и «район» (следующий уровень после «региона» по мнению автора книги) – в разных странах называется по-разному. Например, в США иерархия адресов выглядит так – «штат», потом «графство» или «округ». Во Франции «департамент», потом «регион». В Казахстане – «область», потом «район». Поэтому, кажется мне, что не следует в решении проблем адреса и его частей зацикливаться на своих местных особенностях, закрывая глаза на весь остальной мир.
Мне могут возразить следующее. А зачем автору книги, находящемуся в России, знать и учитывать особенности адресов Франции? А зачем нам, находящимся в Казахстане, учитывать особенности адресов США? Все очень просто – глобализация, интернационализация, импорт, экспорт, приграничная торговля, торговля через интернет, доставка почтой, кредитные банковские карточки и т.д. – все эти факторы приводят к тому, что даже находясь в одной стране, приходится иметь дело с особенностями адресов других стран. Или Вы предпочитаете самоизоляцию от всего остального мира и полное самообеспечение? Поэтому приходится понимать, учитывать и вводить в программу структуру адресов России и Китая, чтобы не отправить товар не туда, или не получить отказ не оттуда.
Однако, осознав необходимость универсального подхода к классификации адреса и его частей, на следующем шаге мы натыкаемся на отсутствие единого общемирового и/или общепринятого нормативного (именно нормативного) классификатора адресов и их частей, который бы упростил взаимодействие через границы разных «адресных систем». Насколько я знаю, такого классификатора нет ни на уровне ООН, ни на уровне ЕС, ни на уровне ТС. Почему это так - понять нетрудно, никто не заинтересован создавать универсальную структуру, потому что она скорее всего не будет признана остальными игроками. Даже в рамках самых длительных по времени успешных межстрановых союзов (например, ЕС) структура адресов разных стран веками остается различной, насильно не унифицируется.

Попытка опереться на государственные классификаторы (КАТО, почтовые коды, транспортные способы адресации и т.д.).
Еще одни подход к работе с адресной информацией заключается в попытке опоры полностью на административный справочник-классификатор КАТО («Классификатор административно-территориальных образований») как на «альфу и омегу». Слов нет, справочник КАТО дает хорошую основу для начала работы с адресами. Но, однако, нужно понимать, что классификатор КАТО изначально создан совсем с другими целями, нежели основные цели коммерческих субъектов. КАТО создан в основном для административно-государственного управления территориями, для расчета налогов, поступлений в бюджет, для трансфертов субсидий, пенсий, пособий и т.д. КАТО не предназначен для торгово-коммерческих целей хозяйствующих субъектов. Если, предположим, некое ТОО (исходя из своих целей, а не целей государства) захочет использовать более подробное членение города – оно не найдет в КАТО ничего для этого. Хотя потребность в таких неформальных членениях довольно велика. Например, хозяйствующие субъекты в своих рыночных целях могут делить город на «субрайоны» (термин условный) – например, «район мясокомбината», «проспект Абая», «вокзал» - и любому торговому агенту этого города сразу становится понятно, о чем идет речь. И более того - такое членение города для рыночных целей более справедливо и необходимо, потому что отражает специфику работы данного ТОО на данном рынке, реально отражает экономико-географические микроусловия данных территорий. Но только вот беда – классификатору КАТО нет дела до потребностей рынка и его субъектов, да он и не обязан их учитывать.
Впрочем, это с другой стороны и хорошо. Представляю, в какую кашу превратился бы классификатор КАТО, если бы рыночные субъекты (разные) давали сюда свои предложения по членению городов на «субрайоны». Ведь у разных ТОО такие «субрайоны» могут быть совсем разными.
Или на другом уровне – общеказахстанские субъекты зачастую анализируют итоги своей работы на неофициальном уровне членения – «Север», «Юг», «Запад», «Восток». И опять же субъекты не находят в справочнике КАТО ничего в этом направлении им нужного.
Еще один способ уложить адреса в стройную схему заключается в попытке использовать схемы почтовых кодов. И это способ точно также проваливается, потому что «субрайоны» не имеют почтовых кодов. Да и опять же почта работает совсем с иными целями, нежели коммерческие ТОО.
Также иногда в попытке быстро решить проблему адресации хватаются за систему указания адресов, «пунктов отправления» и «пунктов назначения» у железной дороги, у транспортных перевозочных компаний и т.д. Проблему это, конечно, не решает. Правда, «пункт отправления/назначения» в предлагаемой нами ниже системе адресации будет просто «частью страны» (объектной частью адреса) – то есть по сути тем же адресом.
Резюмируя, можно сказать, что поиски полного решения проблемы учета адресов в тех местах, где, казалось бы, кто-то должен ее, эту проблему, успешно решить, результата не дают.

Трудности учета адресов порождают ненужное дробление счетов на субсчета.
Неурегулированность общепринятого подхода к учету адресов и их частей толкает субъектов и аналитиков подчас на странные, громоздкие и явно неоптимальные решения. Например, в одной монографии по бюджетированию (К. Щиборщ. «Бюджетирование деятельности промпредприятий России», М, 2005) – выдвигается пожелание разбивать счета разделов «доходы», «расходы» и «производственный учет» на субсчета для отдельного выделения показателей нужных регионов, причем предлагается это делать в оперативном (т.е. не бухгалтерском) учете, да еще и создавать иерархии субсчетов для отражения иерархии частей адресов. Мда, если начать кромсать счета на субсчета по принципу регионов или иных частей адресов, то получится весьма большая каша. Даже если делать такое разбиение в оперативном учете, громоздкость и неоптимальность такого решения обязательно породят проблемы в дальнейшем сопровождении подобной рекомендации. Адреса (или их части – регионы, районы и т.д.) нельзя учитывать на счетах и/или субсчетах - и точка.

Создание избыточного количества справочников, эмулирующих части адреса.
В другой литературе (А. Бондарь «Microsoft SQL Server 2014 в подлиннике», Спб, 2015) – констатируется, что «…в некоторых случаях структуризация адреса не получается слишком уж простой» (стр. 329). В данном примере А.Бондарь предлагает сделать три таблицы – страна, регион, район, создать в них центры этих сущностей и похоже, что это только начало. Решение весьма спорное, кроме того, подходящее только для страны (Россия), где находится автор.
Действительно, что делать, если, например, при учете части какого-либо адреса у нас встретится «штат», или «провинция», или «графство»? И если «графство» Великобритании – это совсем не то же самое, что «графство» в США? Хорошо, похоже все, что нам остается в рамках устаревшей парадигмы - записать адрес аморфной и программно-неанализируемой строкой. Но как тогда выделить из контрагентов реализацию по «графствам» США отдельно от «графств» Великобритании (пример условный)? Или же заполнить всю конфигурацию огромным количеством справочников типа «графство», «провинция», «российский регион» и т.д. Громоздкое и некрасивое решение, значит – оно обязательно неверно.

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

«Вид адреса» - первая структура данных, которую обязательно следует ввести.
Первый факт, к которому мы приходим, заключается в том, что информация «адреса» бессмысленна без указания «вида адреса». Исстари в конфигурациях (программах) эту проблему просто обходили, вводя реквизиты (поля) вида «Контрагент.ПочтовыйАдрес», или «Контрагент.ЮридическийАдрес». И это работало, пока количество видов адресов было относительно невелико. Но что дальше делать, если виды адресов начали «плодиться и размножаться», аки грибы после дождя, и эта тенденция, похоже, долгосрочная? Продолжать по аналогии клепать поля типа «Контрагент.АдресНовый», и «Контрагент.АдресЕщеНовее»? Решение явно неверное, громоздкое, и сложное в сопровождении.
Похоже, нужно вводить вспомогательную таблицу (справочник) – «Вид адреса». Возможные значения – почтовый адрес, юридический адрес, адрес прописки (регистрации), домашний адрес, адрес фактического проживания, адрес офиса, адрес объекта, адрес доставки, адрес места рождения, и т.д. Благодаря таблице (справочнику) «Вид адреса» разработчик будет готов к любому возможному в будущем расширению темы адресов законодателем или пользователем.
Логику программ нужно перерабатывать в том смысле, что сам адрес как таковой без вида адреса не имеет смысла. Фактически ведь это так и есть, просто ранее вид адреса маскировался в наименовании поля – «ПочтовыйАдрес», и т.д. Да и если разобраться, во многих полях мало смысла без указания дополнительной уточняющей информации – измерителя. Например, цена не имеет смысла без указания валюты и строки прайса. Количество не имеет смысла без указания единицы измерения. Сумма не имеет смысла без указания валюты и даты курса валюты, и т.д. Просто об таком подходе и о его применении к адресу и его частям никто ранее не задумывался.

«Страна» в широком понимании – это страна и ее части в едином справочнике – многоуровневая иерархическая структура, с родителями и подчиненными элементами, включающая в себя «части страны», которые можно устанавливать произвольно.
Если подойти к справочнику «Страны» не в узком, а в широком понимании – то можно преодолеть массу проблем адреса и его частей. Нужно осознать, что «страна» состоит из своих «частей» (по иерархии), эти части могут быть любыми (административно-выделенными или нет), и пользователь может расширять состав «страны», добавлять какие-то элементы – нужный ему «субрайон» «проспект Абая», например.
Еще раз – мы делаем большой трансформационный шаг, и превращаем справочник «Страна (в узком смысле) – как линейный перечень (список) стран», в «страну в широком смысле» - как иерархическую структуру, на верхнем уровне которой находится корневой элемент (например, «Республика Казахстан»), на следующем уровне – «области», и так далее по иерархии.
При таком подходе отпадает нужда плодить массу промежуточных справочников («область», «регион», «район» и т.д.) – все они записаны в едином справочнике «страна (части страны)». Можно для ясности обозначить это справочник как «Страна – классификатор КАТО». Или «Страны + части стран». Или «Страны в широком понимании» - это уже неважно. Гораздо важнее логика работы данного справочника (таблицы).
Огромный плюс такого справочника, недостижимый при использовании КАТО или почтовых кодов, заключается в том, что пользователь может самостоятельно расширять справочник «Страна (часть страны)», предположим, добавляя свои, нужные ему «субрайоны» - «мясокомбинат», «проспект Абая», «вокзал» и т.д. Единственное, пользователю нужно указать родителя такого нового элемента (например, «проспект Абая» принадлежит «Сарыаркинскому району»). Таким образом, пользователь может детализировать адрес до нужных ему степеней, кастомизировать программу под себя, не мучая разработчиков требованиями создать служебный объект «субрайоны» по направлениям продаж и доставки товаров.
Международные организации и союзы стран (ЕС, ЕАС, ВТО, ОЭСР, ООН и т.д.) тоже могут быть признаны «странами в широком смысле». Иначе логика манипулирования этими объектами сильно усложняется. Пока у нас в учете не так много этих объектов, их можно сосчитать на пальцах, но что будет, если по аналогии с видами адреса количество международных организаций и союзов стран станет быстро расти? Нужно будет учитывать их разнообразные требования, пошлины, законы, инструкции и т.д. Учитываем же мы сейчас требования ВТО и ТС и имеем на этом массу проблем. Можно уверенно сказать, что это только начало.

Как выглядит сам «адрес и его части» после такого новшества.
«Адрес» после такого новшества становится структурным, состоящим из нескольких полей-реквизитов, и примерно выглядит так –
-вид адреса, например – «почтовый» (тип «справочник»), это отдельное поле адреса
-объектная часть адреса (страна-КАТО) (тип «справочник»), это отдельное поле адреса
-последняя часть адреса (назовем ее «улица-дом») (тип «строка»), и это тоже отдельное поле адреса.

Например –
-«почтовый адрес» - вид адреса
-«Казахстан\Астана\Сарыаркинский район» - объектная часть адреса. То есть в этой части поля адреса нужно указывать именно самую нижележащую часть объектного адреса - «Сарыаркинский район», вышележащих владельцев которого – «Астана», и затем «Казахстан» - легко найти вверх по иерархии,
-Аблаева, дом 6, кв56 – строковая часть адреса.

Почему именно так? Нет большого смысла расширять справочник «Страны (часть стран)» дальше чем «субрайон». Уже «улицу-дом» желательно вводить руками (как и весь адрес раньше, впрочем). Наименования улиц часто меняются, да и в коммерческих целях нет смысла забивать справочник «Страна КАТО» еще и улицами.
Еще один несомненный плюс такого подхода – нет нужды кромсать план счетов, чтобы отловить реализацию в разрезе «районов», «регионов», «субрайонов» и вообще иных любых территориальных членений. Если в накладных есть адрес доставки покупателя, и, как читатель понял, одна из частей «адреса доставки» – объектная иерархия с полным указанием всех вышестоящих владельцев (это -«Казахстан\Астана\Сарыаркинский район»), то не составит большого труда запросами манипулировать этой объектной информацией с нужным уровнем детализации внутри «страны».
Однако, минус новой системы адресации – количество информации в адресе увеличилось, вырос объем работы при вводе нового адреса. Впрочем, и раньше-то при вводе адреса работы тоже было немало. И в конце все равно получался неанализируемый массив строковых символов.

Справочник «Вид страны (части страны)».
Поскольку «Страна (и части страны)» становится многоуровневой, то для каждой ее части-уровня теперь необходим реквизит-определитель «вид страны». Возможные его значения – страна, союз стран, международная организация, регион, область, район области, город, поселок, село, район, улица, дом, строение, территория, субрайон, локация, и т.д.
Виды частей стран могут быть разными для разных «стран» (в узком смысле). Например, «регион» России, и «регион» Франции.
Большой плюс такого подхода в том, что перечень частей страны становится гибким, легко расширяющимся на уровне пользователя (то есть без реструктуризации базы).

Учет адресной информации контрагентов (лиц).
Поскольку адреса теперь представлены 3-мя полями, нет смысла их набивать отдельными полями в карточку контрагента. Логичнее будет создать таблицу (справочник, регистр) «Адресные данные контрагента (лица)». Примерный состав полей-реквизитов такой таблицы –
-Код,
-Владелец (контрагент где ведется учет),
-Наименование,
-Лицо (контрагент) – чей адрес записан,
-Склад (если это адрес склада),
-Отдел (если это адрес отдела, цеха, подразделения),
-Вид адреса,
-Страна (объектная часть адреса),
-УлицаДом (строковая часть адреса).

Похожая система ввода адреса используется в ф.911.
Весьма похожая система ввода адреса, как оказалось, используется в налоговой форме 911. Аналогично, вышележащие части адреса выбираются из справочника, а нижележащие (улица, дом, квартира) – вводятся вручную, с использованием подсказки.

Резюме.
За полями обсуждения осталось еще множество проблем. Например, что делать, если в одном СФ/ЭСФ несколько адресов доставки и/или несколько адресов отправки? Что делать, если даже одна строка товара СФ/ЭСФ расщепляется на несколько адресов доставки (такое часто бывает в строительстве – бетон в одном бетоновозе везут по 2-3 адресам в целях экономии, допустим)? Но данная статья не призвана одним махом решить все проблемы, как хотелось бы. Это скорее начальный опорный пункт для работы над этой ситуацией.
Предлагаемая система понятий для «адреса и его частей» пока широко не используется. Правда, ничто не мешает взять ее, доработать и использовать в любом программном комплексе. Например, вполне реальная логика объединения унаследованных программ и нового подхода может заключаться в следующем. Понятия «юридический адрес» и «почтовый адрес», учитывая их долгое использование и укорененность, можно оставить так, как они есть и совсем не трогать. Однако новые понятия «адресов» (адрес доставки, адрес отправки и т.д.) уже использовать в новой системе координат.




Курсаков С.А.

Дата последнего редактирования – 26 июля 2017 г.

Статья впервые была опубликована в журнале "Бухгалтер+Компьютер" в 2017 г.