Проблемы и решения организации складского учета
Главная / О компании / Статьи / Проблемы и решения организации складского учета

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

Несколько собственных юридических лиц

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

 

Как видим, торговая надбавка распределяется по нескольким юридическим лицам. Причем вместо фирмы может использоваться дружественный индивидуальный предприниматель с патентной системой налогообложения.

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

Схемы консолидации информации.

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

Названная проблема порождает следующее:

1. Собственник не может отследить движение товара по цепочке своих юридических лиц. Таким образом, нет возможности оценить эффективность работы с конкретными товарными позициями с точки зрения всего холдинга.

2. Из первого пункта вытекает невозможность реальной оценки прибыльности бизнеса. Собственник может увидеть только объем продаж конечным покупателям, однако себестоимость проданного товара требует отдельного сложного расчета.

3. Арифметическая сумма прибыли или объема продаж по каждой компании также будет неверной - завышенной за отчетный период за счет внутренних продаж, которые, как известно, должны вычитаться.

4. Необходимость исключения внутренних долгов из арифметической суммы дебиторско-кредиторской задолженности по своим компаниям и др.

Названные проблемы обойти нельзя. Разумеется, можно поступить, как аудиторы: собрать све бухгалтерские данные и свести их вручную либо при помощи таблиц Excel. Но это разовое решение, которое не годится для оперативного управления бизнесом.

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

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

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

 


 

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

 


 

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

Организация парионного учета

У читателя может возникнуть вопрос: зачем нужна еще одна база для экономического анализа? Дело в том, что зачастую товарная номенклатура даже в единой программе для первичного учета не является идеальной. Серьезную проблему при консолидации информации представляет использование бухгалтерских товарных партий.

Напомним, для чего используется партия товара. Партионный учет нужен для расчета себестоимости проданного товара и складских остатков в том случае, если в учетной политике используются методы ФИФО, ЛИФО либо персональная идентификация партий. Связывает эти методы четкая сортировка всего товара на складе по приходным накладным.

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

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

Внедрение правильного партионного учета уменьшает справочник номенклатуры в несколько раз и позволяет производить эффективный экономический анализ продаж.

Заметим, однако, что даже при правильной постановке учета партии все-таки иногда "всплывают" в справочнике номенклатуры. Это обусловлено тем, что один и тот же товар (одинаковое наименование, одинаковый изготовитель и даже дата изготовления) может поступить на фирму разными путями: часть закупили в России, часть - в Беларуси у посредника, часть - вообще взяли на комиссию. С экономической точки зрения это один и тот же товар, но в первичной или бухгалтерской программе он будет заведен тремя позициями. Именно поэтому и нужна не только программа для первичного учета, но обязательно еще и экономическая для окончательной консолидации информации.

Территориально-распределенные компании

Теперь рассмотрим ситуацию, когда холдинг имеет территориально распределенную структуру: несколько офисов и складов в разных городах. Возникает вопрос. Если планируется единая первичная база данных, как же организовать ее работу в этом случае?

 


 

Существует два варианта решения данной проблемы.

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

Второй вариант предполагает использование единой базы данных на центральном сервере (рис. 5). Удаленные пользователи подключаются к ней через Интернет как удаленные терминалы: передавая на сервер нажатия клавиш и получая оттуда изображение. Это решение удобно и красиво, но требует серьезной технической проработки и более дорогих широких каналов связи. Как правило, в пределах Беларуси такая схема с терминальным доступом работает достаточно надежно.

 


 

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

© 2006-2012 «Синкевич Технолоджис»
Разработка сайта «Сайтекс»