ПРОТОКОЛ

       

Година 2017,01.11.                                                                           град  Бургас

АДМИНИСТРАТИВЕН СЪД                     ПЪРВИ административен състав       

На първи ноември                                     две хиляди и седемнадесета година

В публично заседание в следния състав:

                                                    

                                   ПРЕДСЕДАТЕЛ: ПАНАЙОТ ГЕНКОВ

                                                                                                    

Секретар: Кристина Линова    

Прокурор:

Сложи за разглеждане докладваното от съдия Генков

Административно дело номер 865 по описа за 2017 година.                     

На именното повикване в 14.10 часа се явиха:

 

За ЖАЛБОПОДАТЕЛЯ „ЮТОРЕСТ“ ООД, редовно уведомен, се явява адв.Д. с представено пълномощно, находящо се на лист 9 от делото.

 

За ОТВЕТНИКА Директор на Дирекция „Обжалване и данъчно-осигурителна практика” гр.Бургас, редовно уведомен, се явява юрисконсулт М. с представено пълномощно, находящо се на лист 391 от административно дело № 1397/2015г. по описа на Административен съд гр.Бургас.

 

Явява се ВЕЩОТО ЛИЦЕ Щ.В.П., който е депозирал допълнително заключение в законоустановения срок.

 

Съдът ПРЕДОСТАВЯ възможност на страните да изразят становище по хода на делото.

 

ПЪЛНОМОЩНИЦИТЕ: Нямаме възражения по хода на делото.

 

По хода на делото съдът, след като констатира, че не са налице процесуални пречки

 

О П Р Е Д Е Л И:

         ДАВА ХОД НА ДЕЛОТО.

 

         ПРИСТЪПИ към разпит на вещото лице със снета по делото самоличност.

 

ВЕЩОТО ЛИЦЕ: Поддържам допълнителното заключение, което съм представил с отговор на допълнителна задача, а именно, да отговоря Как се попълва колона RD_SUM, генерира се от софтуер или по друг начин; какви данни са обобщени в тази колона и по какви признаци, като съобразя коментираното на стр.7 от ревизионния доклад.

Обяснил съм всичко в заключението.

Правих връзка между двете таблици, за да може да се хванат коя сума към коя дата се отнася на базата на една колона, която е връзката между двете таблици.

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

 

Адв.Д.: В отговора на стр. 1 от допълнителното заключение, при отговора на Раздел ІV е написано следното „Колона RD_SUM  се съдържа в таблицата POSREPORT_DATA. Таблицата съдържа 7 полета (колони) и съдържа общо 5 732 записа. Таблицата съдържа данни за отчета – плащане, служебно въвеждане/изваждане, връщане на стоки и т.н.…“.

Да разбирам ли, че за извеждане на данни в колона RD_SUM не е необходимо да се извършват някакви допълнителни преобразувани изчисления, а автоматично софтуера ги генерира.

ВЕЩОТО ЛИЦЕ: Да, тази колона се генерира автоматично от софтуера.

Адв.Д.: В тази връзка посочено е да съобразите посоченото в ревизионния доклад на стр.7. На стр.6 и стр.7 има подробно описание на конкретни действия –как са обработвани данни, как са се свързали със сумата, в резултат на което е получена колона RD_SUM.

Колоната RD_SUM на стр.6 и стр.7 от ревизионния доклад дали е получена в резултат на допълнително преобразуване и свързване на таблицата или това е същата тази колона, която е генерирана от софтуера?

ВЕЩОТО ЛИЦЕ: Дефакто колона RD_SUM, която се намира в таблицата POSREPORT_DATA, която е в данните на фирма „Юторест“, се генерира от софтуера. А самите данъчни са си генерирали една тяхна екселска таблица, която има три колони – месец, RD_SUM и брой. Това е на стр.6 от ревизионния доклад.

 Понеже двете колони носят едно и също име, Вие се обърквате.

Адв.Д.: Дали тази колона в таблица 1 RD_SUM, дали отговаря на автоматично генерираното от софтуера, ползван в ресторанта или е  образувана по друг начин.

ВЕЩОТО ЛИЦЕ: Колона RD_SUM, която е в таблицата POSREPORT_DATA се генерира автоматично от софтуера, а цифрите в колоната RD_SUM в таблицата на данъчните, която е на  стр. 6 и следващите в ревизионния доклад, цифрите са образувани чрез обработка на информацията от първичните данни, като обработката на информация става по следния начин:

Използва се колона RD_SUM от таблица POSREPORT_DATA, за да се вземат цифрите и се прави връзка с таблица POSREPORT_HDR, за да може да се уточнят за кои дати се отнасят тези цифри. В таблицата на данъчните са разбити по месеци.

Адв.Д.: Виждам на стр.3 от заключението, втората таблица, че за всеки един от операторите началната дата е в един ден, а крайната в следващия или след 4 дни.

Можете ли да кажете по какъв начин тези данни са разпределяни в отделните дни, за да се формира точно сума за определен месец при преобразуването на данните от органа.

ВЕЩОТО ЛИЦЕ: Това трябва да го каже колегата от данъчните, който е обработвал съответните таблици. Аз не мога да кажа. По принцип това е таблица, която данъчните са образували и тя е по месеци. Предполагам, че този случай, за който говорим е за месец септември.

Адв.Д.: Например оператор „Н. – от 17.09. до 24.11“ -тук пък имаме два месеца.

 ВЕЩОТО ЛИЦЕ: Към кой месец са отнесли това, могат да отговорят само хората, които са съставили тази таблица.

Искам да вметна нещо – разговарях с управителя и програмистите на продукта. Увериха ме, че информацията в тези две таблици е само да се генерират. Не може да се каже, че тази информация е коректна. Не може един сервитьор да започне работа в един ден и 4 дни по-късно да не е приключил работа. Това явно е някаква грешка в отчитането на това работно време.

Като разговарях с управителя на фирмата, която разработва продукта, той потвърди, че тези две таблици, които се изследват POSREPORT_DATA и POSREPORT_HDR се                                                                                                                                                                   използват за генериране на дневния отчет и след това данните не се съпоставят. Изрази мнение, че може би има такива несъответствия, които се откриват в момента и че таблицата в която 100% има вярна информация е SALES_BON, таблицата, в която се натрупват явните обороти, която в нашия случай е празна. В нашия случай не се съдържат никакви данни в нея.

 

Адв.Д.: На стр.3 от Вашето заключение в цялата таблица има повтарящи се записи. На какво се дължи това дублиране.

 

СЪДЪТ към ВЕЩОТО ЛИЦЕ: Защо са поставени три знака след десетичната запетая?

 

ВЕЩОТОЛИЦЕ: Сумата е 1 146.60 лева. По принцип в компютъра числата, които се ползват са с много по-голяма точност отколкото до втория знак. И се използват поради една причина - понякога при деление се получават неправилни дроби, които имат много числа зад запетаята и когато се ползват закръглени до стотинка, често се случва от такива закръгления да се получават разминавания от това, което вади  програмата и това, което е записано във финансовата бележка. За да се избегне тази грешка, в програмирането се използват повече числа след десетичната запетая.

Адв.Д.: Защо на втория ред е отразено една и съща начална дата и крайна дата и час; на едното е записано тотал 1146.60, а на другото има нула?

ВЕЩОТО ЛИЦЕ: По принцип има два начина на плащане. Единият в брой, другият с карти  - кредитна, дебитна или други карти, ваучери и т.н. Едното показва сумата, която е платена в брой, а другото показва сумата, която е платена по банков път. Затова има две суми, които се различават. Тук съм дал един отрязък от тази таблица, но има места, на които има плащане в брой и на същата дата е плащано и с платежен документ.

 

Адв.Д.: Защо оператор № 41  е без име?

ВЕЩОТО ЛИЦЕ: Сигурно не са вкарали името на служител. По принцип компютърът идентифицира хората по потребителско име и парола. Сервитьорът вкарва потребителско име и паролата и така компютърът разбира кой е. Ако на потребителско име не е вкарано нищо, тогава излиза празно. Може и да е правена някаква проба.

 

Моето заключение е, че тези таблици съдържат информация, върху която не може да се стъпи на 100% за реални и верни данни.

Адв.Д.: Нямам повече въпроси.

 

Юрисконсулт М.: За коя таблица става дума. Защото едната е ползвана само за датите, а другата е ползвана само за дата в ревизионното  производство, за да могат да се вкарат датите на отчетите.

ВЕЩОТО ЛИЦЕ: По принцип основната таблица, която са ползвали е POSREPORT_DATA, но тя ляга на информация, която се съдържа в POSREPORT_HDR. Ако събирате цифрите от POSREPORT_HDR се получават цифри на обобщени данни. Направих няколко опита, но в някои случаи излязоха, в някои не.

В таблица POSREPORT_DATA са обобщени суми, които в колона RD_SUM трябва да се получат като се събират сумите по дати от таблица POSREPORT_HDR. Аз обаче като събрах, на някои места сумите не излизат. Най-добре могат да обяснят логика колегите, които са изготвили тези таблици.

Юрисконсулт М.: Да уточним. Бихте ли казали информацията, която следва да се съдържа в таблица SALES_BON, данните, които следва да бъдат генерирани в таблица SALES_BON, където следва да се съдържат, се генерират на други места от програмата включително в таблица POSREPORT_DATA.

ВЕЩОТО ЛИЦЕ: Всяка една таблица се генерира от програмата. Всички данни във всички таблици са генерирани от програмата.

Юрисконсулт М.: Нямам повече въпроси.

 

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

 

О П Р Е Д Е Л И:

ПРИЕМА представеното и изслушано заключение в съдебно заседание на 27.09.2017г. и изслушаното днес допълнително заключение, като на вещото лице да се изплати възнаграждение общо в размер на 400.00 лева изцяло от внесения депозит.

 

         Адв. Д.: Нямам други искания.

Юрисконсулт М.: Също нямам искания по доказателствата.

 

         Съдът счете делото за изяснено от фактическа страна, поради което

 

 О П Р Е Д Е Л И:

ПРИКЛЮЧВА събирането на доказателства.

ДАВА ход на делото по същество.

 

Адв. Д.: Поддържам жалбата. Моля да ни присъдите направените по делото разноските.

Моля да ни предоставите срок за представяне на писмена защита.

Юрисконсулт М.: Оспорвам жалбата. Моля да ни присъдите юрисконсултско възнаграждение в размер на 3922 лева и в подходящ срок ще представя писмена защита.

 

Съдът ПРЕДОСТАВЯ на страните 7-дневен срок за депозиране на писмени бележки по съществото на спора.

 

ОБЯВИ, че ще се произнесе с решение в срок.

 

Протоколът се изготви в съдебно заседание.

Заседанието приключи в 14.37 часа.

 

СЕКРЕТАР:                              ПРЕДСЕДАТЕЛ: