Праблемы і рашэньні арганізацыі складскога ўліку
Галоўная / Пра кампанію / Артыкулы / Праблемы і рашэньні арганізацыі складскога ўліку

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

Некалькі ўласных юрыдычных асобаў.

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

 

Бачым, што гандлёвая надбаўка размяркоўваецца па некалькіх юрыдычных асобах. Прычым замест фірмы можа выкарыстоўвацца сяброўскі індывідуальны прадпрымальнік с патэнтнай сістэмай падаткаабкладаньня.

Часта ўласьнік спадзяецца абысціся аўтаматызацыяй бухгальтарскага ўліку ў кожнай са сваіх юрыдычных асобаў. Аднак час ад часу нават мінімальнай аўтаматызацыі свядома не праводзіцца. Гэта датычыцца выпадкаў, калі некаторыя свае фірмы карыстаюцца спрошчанай сістэмай падаткаабкладаньня альбо падрыхтоўка бухгальтарскай справаздачнасьці перададзена на аўтсорсынг.

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

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

З названай праблемы вынікае наступнае:

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

2. З першага пункту выцякае немагчымасьць рэальнай ацэнкі прыбытковасьці бізнэсу. Уласьнік можа ўбачыць толькі аб'ём продажу канчатковым пакупнікам, аднак сабекошт прададзенага тавару патрабуе асобнага складанага разьліку.

3. Арыфметычная сума прыбытку ці аб'ёму продажу па кожнай кампаніі таксама будзе няправільнай - завышанай за справаздачны перыяд за кошт унутранага продажу, які, вядома, павінен вылічвацца.

4. Неабходнасьць выключэньня ўнутраных запазычанасьцяў з арыфметычнай сумы дэбіторска-крэдыторскай запазычанасьці па сваіх кампаніях і інш.

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

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

Перад запускам такой базы дадзеных неабходна правесці разавую працаёмкую працэдуру стандартызацыі даведнікаў: выключыць элементы, якія дубліруюцца, ва ўсіх кантрагентаў можна ўказаць УНП альбо ІНН, усім таварным пазіцыям надаць унікальны артыкул. Пажадана, каб артыкулы неслі ў сабе сэнсавую нагрузку: напрыклад, першыя разрады могуць азначаць таварную групу, другія - вытворцы, трэція - унікальны код тавара і г.д.

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

 


 

У першым выпадку (мал. 2) праграмісты павінны запусьціць сістэму сінхранізацыі бухгальтарскіх праграм так, каб пры з'яўленьні новых таварных пазіцый альбо кантрагентаў у любой з баз дадзеных гэта інфармацыя аўтаматычна дадавалася ва ўсе астатнія базы. Такім чынам, будзе падтрымлівацца аднастайнасьць інфармацыі і ўнікальнасьць тавараў і кантрагентаў у рамках усяго холдынга. Адначасова настройваюцца модулі экспорту-імпарту таварных накладных з бухгальтарскіх праграм у кансалідаваную базу дадзеных. Пры гэтым продаж паміж сваімі кампаніямі павінен аўтаматычна трактавацца як унутранае перадаваньне тавараў альбо ўнутраны продаж па трансфертным кошце. Гэта неабходна для таго, каб не адбывалася штучнага завышэньня рэальнага сабекошту тавару, аб'ёму продажу і дэбіторска-крэдыторскай запазычанасьці.

 


 

Другі варыянт кансалідацыі патрабуе дабаўленьня яшчэ адной базы дадзеных - для першаснага ўліку. Здаецца, што схема ўскладняецца, але яна забясьпечвае больш зручную і празрыстую працу холдынга (мал. 3). У гэтым выпадку ўся першасная інфармацыя па таварнаму руху першапачаткова заносіцца ў спецыялізаваную праграму для складскога ўліку. Як правіла, для гэтых мэтаў выкарыстоўваюцца 1С:Гандаль альбо модулі складскога ўліку карпаратыўных сістэм Галактыка, Аксапта і інш. Праграма для першаснага ўліку павінна быць простай і зручнай, каб яе маглі хутка засвойваць складскія работнікі і мэнэджэры па продажу. Адначасова гэта праграма павінна дазваляць улічваць тавар па некалькіх юрыдычных асобах. Калі гэтыя патрабаваньні выконваюцца, то праца з таварнымі плынямі робіцца нагляднай і зручнай: мэнэджэр пры дапамозе аднаго праграмнага прадукта можа бачыць наяўнасьць тавару на ўсіх юрыдычных асобах, кантраляваць яго рух паміж імі і выпісваць рахункі і накладныя ад імя любой кампаніі. Пасля ўводу інфармацыі ў праграму для першаснага ўліку ўсе накладныя павінны аўтаматычна пераносіцца ў адпаведныя бухгальтарскія базы дадзеных, а таксама ў базу для эканамічнага аналізу і бюджэтаваньня.

Арганізацыя партыённага ўліку

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

Нагадаем, для чаго выкарыстоўваецца партыя тавару. Партыённы ўлік патрэбны для разліку сабекошту праданага тавару і складскіх астаткаў ў тым выпадку, калі ва ўліковай палітыцы выкарыстоўваюцца метады FIFO, LIFO альбо персанальная ідэнтыфікацыя партыяў. Зьвязвае гэтыя метады дакладная сартыроўка ўсяго тавару на складзе па прыходных накладных.

На рэальным складзе названыя метады ўжываюцца надзвычай рэдка з-за іх тэхнічнай складанасьці: кладаўшчык павінен маркіраваць кожную ўпакоўку і адпускаць тавар строга ў адпаведнасьці з бухгальтарскай уліковай палітыкай. Звычайна склад працуе па прынцыпе "бяры з бліжэйшай паліцы". І гэтаму прынцыпу лепш за ўсё адпавядае простая методыка падліку сярэднеўзважанага сабекошту. Аднак бухгальтэрыя часта выкарыстоўвае іншыя метады: гэта дазваляе ёй аптымізаваць падаткаабкладаньне, а ў беларускіх умовах - яшчэ і кантраляваць лімітавую аптовую надбаўку.

Пры пастаноўцы ўліку мы рэгулярна сутыкаемся з сітуацыяй, калі бухгальтары ўводзяць у праграму партыі тавару як звычайныя таварныя пазіцыі. Пры гэтым даведнік наменклатуры павялічваецца ў разы, а выбар тавару для продажу адбываецца шляхам ручнога перабору гэтых партыяў. Даводзіцца тлумачыць кліентам, што гэта "каменнае стагодзьдзе" - так працавалі гадоў дзесяць таму. Зараз практычна любая бухгальтарская праграма забясьпечвае магчымасьць "нябачнай" работы з партыямі. Гэта значыць бухгальтар бачыць адну таварную пазіцыю, а тыя некалькі партыяў, якімі паступаў тавар, апрацоўваюцца аўтаматычна.

Укараненьне правільнага партыённага ўліку памяншае даведнік наменклатуры ў некалькі разоў і дазваляе рабіць эфектыўны эканамічны аналіз продажу.

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

Тэрытарыяльна-размеркаваныя кампаніі

Зараз разгледзім сатуацыю, калі холдынг мае тэрытарыяльна-размеркаваную структуру: некалькі офісаў і складоў у розных гарадах. Узнікае пытаньне. Калі плануецца адзіная першасная база дадзеных, як жа арганізаваць яе работу ў гэтым выпадку?

 


 

Існуе два варыянты рашэньня гэтай праблемы.

Як правіла, сучасныя ўліковыя праграмы маюць убудаваныя механізмы рэплікацыі (мал.4). Гэта значыць на адным з офісаў усталёўваецца цэнтральная база дадзеных, на астатніх - перыферыйныя. Перыферыйныя базы з пэўнай перыядычнасьцю (раз у дзень, раз у гадзіну і г.д.) абменьваюцца інфармацыяй па электроннай пошце з цэнтральнай базай. Працэдуру сінхранізацыі можна выконваць як ручным спосабам, так і аўтаматычна. Вартасьць дадзенай схемы: таннасьць каналаў сувязі і сэрвернага абсталяваньня. Аднак трэба мець на ўвазе, што агульную інфармацыю мы бачым з некаторым адставаньнем - на момант апошняй сінхранізацыі.

Другі варыянт мае на ўвазе выкарыстаньне адзінай базы дадзеных на цэнтральным сэрверы (мал. 5). Аддаленыя карыстальнікі падключаюцца да яе праз Інтэрнэт як аддаленыя тэрміналы: перадаючы на сэрвер націсканьне клавішаў і атрымліваючы адтуль выяву. Гэтае рашэньне зручнае і прыгожае, але патрабуе сур'ёзнай тэхнічнай працы і больш дарагіх шырокіх каналаў сувязі. Як правіла, у межах Беларусі такая схема з тэрмінальным доступам працуе дастаткова надзейна.

 


 

Адзначым, што праблемы складскога ўліку не абмяжоўваюцца дадзеным артыкулам. Аднак аптымізацыю складскога ўліку варта пачынаць менавіта з рашэньня названых задачаў.

© 2006-2012 «Sinkevich Technologies»
Зроблена ў «Сайтекс»