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

В статье автор дает краткое введение в проблематику учета адресов и их частей и предлагает решения, которые помогут просто и точно вести учет адресной информации контрагентов.

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

Обманчивая простота внешнего вида адреса

Все знают, как выглядит адрес, например: «Республика Казахстан, г. Астана, ул. Абая, д. 35, кв. 67». Вроде бы просто, но эта простота обманчивая.

Во-первых, в отличие от простой информации вроде «наименование = принтер», адрес состоит из логических смысловых частей (страна, регион, область, город, район и т. д.). И эти части как-то надо вводить в программу и учитывать.

Во-вторых, эти части адреса бывают разными в разных странах, как по названию, так и по количеству уровней.

В-третьих, адреса бывают разных видов (типов): почтовый, юридический и др.

В-четвертых, адреса присваиваются самым разным объектам, например юрлицу в целом, его складам, отдаленным торговым точкам, подразделениям, физлицам и т. д.

Бухгалтерские и налоговые аспекты адреса

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

Бумажная форма СФ постепенно отходит и заменяется формой электронной. В новой форме электронного счета-фактуры (далее – ЭСФ) (с введением новых правил заполнения ЭСФ с 1 октября 2017 года) намечено использование таких понятий, как «адрес отправки» и «адрес доставки» в разделе информации грузоотправителя и грузополучателя.

В данном случае количество видов адресов увеличивается. Следовательно, необходимо раскладывать фактические ситуации по полочкам, анализировать участвующие в них объекты, укладывать их в системы понятий и предлагать для использования.

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

Необходимость многообразия видов адресов

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

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

Универсальная нормативная структура адреса невозможна

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

Например, в одной из книг (А. Бондарь «MicrosoftSQLServer 2014 в подлиннике», Спб, 2015) автор выстраивает структуру хранения частей адресов, последовательно вводя следующие таблицы: «страна», «регион», «район» (правда, в учебных целях).

Но если «страна» – универсальное, общечеловеческое понятие, то тот же «регион» существует в основном в России (откуда родом автор книги). Да и «район» (следующий уровень после «региона», по мнению автора книги) в разных странах называется по-разному. Например, в США иерархия адресов выглядит так: «штат», потом «графство» или «округ». Во Франции – «департамент», потом «регион». В Казахстане – «область&r">

...