POS отчети за много обекти: как да съберете всички магазини в един отчет

Всяка каса във вашата верига записва всяка продажба. Проблемът започва, когато поискате вчерашните продажби на всички магазини. Системата на всеки магазин има собствена представа какво е продажба, кога свършва денят, как се казва магазинът и как се казва всеки продукт. Съберете отчетите на магазините и ще получите обща сума, но не и такава, по която да сравнявате магазин с магазин.

Затова консолидирането на POS данните е най-вече въпрос на договорка, а не на аритметика: едно определение на продажба, един търговски ден, един код за всеки магазин и всеки продукт и проверка, че всеки магазин наистина е подал данни. Това ръководство ги разглежда в този ред. То важи независимо дали магазините ви работят с една POS система, или с няколко.

Защо сборът от отчетите на магазините дава грешен резултат

Вземете два магазина с различни системи. И двата приключват деня и изпращат отчет, а отчетите изглеждат еднакво:

Всеки отчет е верен по собствените си правила. Събрани заедно, те смесват продажби с и без ДДС, третират отстъпките по два начина и прехвърлят част от петъчната вечер в събота. Статистическите служби, които изчисляват ценови индекси от касовите данни на търговците, срещат същите проблеми в национален мащаб. Службата за национална статистика на Великобритания (ONS) отбелязва, че някои търговци изпращат връщанията като отделни редове, че някои дават нов код на продукт, който пускат отново на пазара, и че собствените продуктови йерархии на търговците не се съпоставят чисто с нейните категории¹.

Договорете се за едно определение на продажба

Запишете веднъж какво означава продажба в отчетите на вашата верига и приведете всеки магазин към него. За сравнение между магазините обичайният избор са нетните продажби: след отстъпките, без ДДС и с приспаднати връщания. ДДС трябва да отпадне, защото ставките се различават между държавите и между видовете продукти, така че два магазина с еднакъв оборот могат да покажат различни брутни продажби. Две други решения си струва да заявите изрично:

• Връщания: осчетоводявайте ги в деня, в който се случват, в магазина, който приема стоката обратно, и ги показвайте на отделен ред. Магазин, който приема обратно продаденото от други магазини, не бива да изглежда като магазин, който продава по-малко.
• Отстъпки: дръжте ги видими до продажбите, а не само приспаднати от тях. Магазин, чиито продажби се държат благодарение на отстъпки, изглежда здрав, ако гледате само нетните продажби.

Връщанията не са грешка от закръгляване. Търговците в САЩ са преценили, че 15,8% от продажбите им за 2025 г. ще бъдат върнати, като се броят заедно онлайн продажбите и тези в магазините². Именно там се крият и загубите на касата. В американското Национално проучване за сигурността в ритейла (National Retail Security Survey) измамите с връщания са сред четирите най-често посочвани начина за кражби от служители, а отчетите по изключение и сигналите за необичайни POS транзакции са сред петте най-използвани защити³. Нито едното, нито другото работи, ако връщанията и отстъпките на всеки магазин не стоят на едно и също място в отчета.

Дайте на всяка продажба един търговски ден и един магазин

Продажба след полунощ принадлежи на вечерта, която я е донесла, а не на търговията през следващия ден. Задайте за всеки магазин търговски ден в собственото му местно време, който приключва след последната възможна продажба, и датирайте всяка транзакция по него:

Без това правило магазин, който затваря късно, изглежда слаб в петък и силен в събота, а магазините в различни часови зони никога не се съпоставят коректно.

Всеки магазин има нужда от един код, воден в един списък, който свързва с него идентификатора на магазина от всяка система и посочва какъв вид обект е: магазин, склад, онлайн магазин. GS1, организацията зад баркодовете, определя за тази цел глобалния номер на местоположение (Global Location Number), идентификатор на физическо място⁴. Не са ви нужни номера от GS1, за да поддържате списъка, но списъкът ви е нужен, както и проверка, която ви казва, когато някоя система отчита магазин, който не познава.

Съпоставете продуктите, не само магазините

За сумите по магазини стигат кодовете на магазините. Щом сравнявате продукт или категория между магазините, продуктите също се нуждаят от една идентичност, а баркодовете помагат по-малко, отколкото бихте очаквали. GTIN, номерът зад баркода, идентифицира търговска единица, а отделен GTIN се изисква всеки път, когато единицата се промени по начин, който има значение за търговията⁴. Промяна в нетното количество, отпечатано на опаковката, например, изисква нов⁵. Така един и същ продукт на един и същ рафт може да има два кода в рамките на година, а стоките, които се теглят или преопаковат в магазина, често носят собствени кодове на веригата, които се различават между системите.

На практика веригите първо разпределят всички продукти в едно общо дърво от категории и свързват отделните продуктови кодове само там, където им трябва сравнение на ниво продукт. ONS работи по същия начин с данните на търговците: отнася всеки продукт към собствените си категории чрез това, което нарича ръчна класификация с помощта на машина, и свързва повторно пуснатите продукти с оригиналите¹.

Проверете дали всеки магазин е подал данни, преди да четете числата

Магазин, чиито данни не са пристигнали, изглежда точно като магазин, който не е продал нищо. Преди някой да сравнява магазините сутринта, прекарайте данните на всеки магазин през едни и същи проверки:

Закъснелите данни са нещо нормално. Каса, която е загубила връзка, качва данните, когато връзката се възстанови, а POS системата може да коригира ден, след като е приключен. Затова всяка нощ презареждайте последните няколко дни, а не само вчерашния, и оставете коригирания ден да замени старите числа, вместо да се добави към тях.

Сверете отчета с парите

Продажбите от касата са твърдение, а банката и сейфът са доказателството. Плащанията с карти пристигат в банката на партиди, ден или повече по-късно, а парите в брой се броят в магазина. В еврозоната през 2024 г. в брой са платени 52% от транзакциите в точките на продажба, а по стойност картите са 45% срещу 39% за парите в брой⁶. Ако сверявате продажбите от касата само с банковите постъпления, голяма част от деня остава непроверена.

Сверявайте по магазин и по ден, а не за веригата като цяло. Разлика, която се повтаря в един магазин, сочи процес там; разлика, която се мести от ден на ден, обикновено се дължи на времето, в което постъпват парите.

Какво трябва да показва консолидираният отчет

Щом всички магазини работят с едни и същи определения, сутрешният отчет е лесната част: за всеки магазин нетните продажби, броят бонове, средният бон и маржът, където има данни за себестойността, всяко до същия ден от седмицата преди седмица. Как оттам да сравнявате магазините коректно и как да различите лоша седмица от реален спад е темата на ръководството за ритейл табло за управление.

Как marql консолидира POS данните

marql чете продажбите от POS и ERP системите на веригата такива, каквито са, без да заменя нито една от тях. Проверява всяка свързана система на всеки пет минути и всяка нощ препрочита изминалата седмица, така че закъснелите качвания и коригираните дни заменят по-ранните числа, вместо да се добавят към тях. Всяка продажба се датира по местния търговски ден на магазина, а идентификаторите на магазините от всяка система се свързват с един списък на магазините на веригата.

Всяка нощ продуктите се разпределят в едно дърво от категории, а тези, за които класификаторът не е сигурен, отиват при човек за потвърждение. Отстъпките и връщанията се показват до приходите, а не са скрити в тях, и за всеки източник се вижда колко свежи са данните му: закъснели след шест часа, остарели след едно денонощие. Страницата за потока на данните показва пътя от касата до сутрешния отчет, а страницата с интеграциите изброява системите, с които marql се свързва.