Има ли изискване ДДС дневниците освен в текстови формат да се подготвят и в екселски формат?

В Правилника за прилагане на ЗДДС е много ясно казано. Дадена и подробна информация на структурата на файловете.
Така, че от страна на бирниците - няма изискване за ексел. Освен ако някой бирник-натегач пред пенсия не ти прави проверка и да иска и това...

Пък и ти - питаш нещо. Кажи поне кой и откъде ти го е искал тва?


^{Отговор на scheti2(16.11.2020 11:16):
scheti2 каза:
Има ли изискване ДДС дневниците освен в текстови формат да се подготвят и в екселски формат?}

Ако подавате по ел. път се формират тхт файлове, които се подават.
Ако носите на място - подавате тхт файлове на носител и разречатани на хартишка.
Та питането ми е - тези на хартишка по какво ще се познае на какъв софтуер са измъдрени?

Въпроса ми идва оттам че се занимавам със счетоводен софтуер и един клиент ми казва че софтуера трябва да генерира и дневници в ексел формат. И аз нищо такова не намирам в ЗДДС и Правилника за ЗДДС. Само deklar.txt, pokupki.txt, prodagbi.txt.

^{Отговор на scheti2(16.11.2020 11:49):
scheti2 каза:
Въпроса ми идва оттам че се занимавам със счетоводен софтуер и един клиент ми казва че софтуера трябва да генерира и дневници в ексел формат. И аз нищо такова не намирам в ЗДДС и Правилника за ЗДДС. Само deklar.txt, pokupki.txt, prodagbi.txt.}


Няма такова изискване, но какво пречи да може да се експортира в ексел?
Разните справки нали могат да се експортират в ексел? Ако не могат, моля споделете името на продукта, за да не се докосвам до него :)))

Ясно че може да се експортират, но искат съвсем точно да отговарят на текстовия формат, сякаш ще изпращат и файлове в ексел.

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

Ще се опитам кратко, колкото мога да изясня ситуацията на твоя човек. Изискването е дневниците да се предават във формат csv. Този формат е стандарт за предаване на „компютърно четими данни“*. Друг такъв формат е xml. Сигурно си го чувал(а). С това не казвам, че csv и xml си приличат по нещо.

Та csv е създаден за нуждите на електронните таблици и системите за управление на бази от данни. Това се е случило далеч преди да има M$ Excel.

По своята същност това е обикновен текстов документ, а не двоичен такъв. Затова се отваря без проблем от Notepad да речем.

Структурата му е всеки ред да съответства на ред от таблицата или базата. За определител на колоните служат различни знаци. Името означава comma separeted value. Това ще рече, че разделител за колоните е най-често запетайка. Така е и в този случай. Но може да е почти всякакъв. Много често е интервал или табулация. Друг пример е отвесна черта или точка и запетая.

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

Две последни неща.

1. Този формат не предполага да съдържа (и не съдържа) форматиране на данните в него. Такова можеш да направиш на ръка или макрос, но за да го запазиш, трябва да смениш и формата на документа. Става малко объркване, защото за външен изглед на данни и за вид документ все се използва думата формат, но се надявам да разбираш;

2. Този вид документ (csv) също така предполага чисти данни. В него не могат да се запазват формули и други такива, а единствено стойности. Ако запазиш някакъв документ като csv то всички формули ще се загубят и ще останат единствено резултите от пресмятането им.

Поради тези причини, можеш да правиш дневници в електронна таблица дори без използването на макроси. Това е формат поддържан от ел. таблици, но не е собствен формат на M$ Excel. Той има всичко на всичко два собствени формата (xls и xlsx), но поддържа десетина други. В действителност има още няколко собствени вида документи, но те са за специални случаи, като например шаблони.

=*=

Ще си позволя да не се съглася с нашия хоноруван събрат Лигльо. Много добре си личи, когато един документ е оформен от програма за ел. таблици. Няма значение дали е разпечатан. Личи си ясно.







-----
*Тъпо словосъчетание измислено от някой като твоя човек.

Благодаря за подробните разяснения.
Но къде всъшност пише че трябва да са във формат CSV? Аз намирам в правилника да пише за файлове с разширение .TXT.
И програмата на НАП за ДДС, която съм тествал, генерира TXT файлове и портала на НАП приема TXT файлове.

^{Отговор на scheti2(16.11.2020 13:12):
scheti2 каза:
Благодаря за подробните разяснения.
Но къде всъшност пише че трябва да са във формат CSV? Аз намирам в правилника да пише за файлове с разширение .TXT.
И програмата на НАП за ДДС, която съм тествал, генерира TXT файлове и портала на НАП приема TXT файлове.}



Правилника е писан за данъчни и счетоводители, а не за компютърджии. Не съм питал нарочно Инфо71, защо е избрал разширението да е txt. Само като лична спекулация, за да е възможно за счетоводители лесно (лесно за нетехичари) да променят данните. Но си е жив csv.

Както вече ти написах, csv не е двоичен формат, затова свободно може да се отваря от почти всякакви програми. Така е и проектиран. Това е формат за пренос на данни.

Ако прочетеш частта в ППЗДДС или просто отвориш някой готов дневник, лесно ще ти стане ясно, че вътре става въпрос за това, което описвах в предното си мнение.

В крайна сметка разширението на името на един документ е само нещо, което да служи за ориентация на хората, а не за прочитане на съдържанието му.

^{Отговор на scheti2(16.11.2020 11:49):
scheti2 каза:
Въпроса ми идва оттам че се занимавам със счетоводен софтуер и един клиент ми казва че софтуера трябва да генерира и дневници в ексел формат. И аз нищо такова не намирам в ЗДДС и Правилника за ЗДДС. Само deklar.txt, pokupki.txt, prodagbi.txt.}

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

Алмера това, което казваш в общи линии е разликата между техничари и нетехничари. Разликата е в отговора на проблема „трябват ми данни“. Техничаря казва „добре, ще ги генерирам“. От своя страна другия ще каже: „добре, ще ги създам“. Сиреч единия има подход към автоматизация, а другия към ръчна намеса.

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

Разбирам, че на света има безгрешни гении, но аз не съм такъв, правя грешки, затова избягвам по всякакъв начин ръчна намеса. А проверката на работата ми също предпочитам да е автоматична, колкото е възможно. Така пестя време.

^{Отговор на Liglyo(16.11.2020 11:30):
Liglyo каза:
Ако подавате по ел. път се формират тхт файлове, които се подават.
Ако носите на място - подавате тхт файлове на носител и разречатани на хартишка.
Та питането ми е - тези на хартишка по какво ще се познае на какъв софтуер са измъдрени?}


Амнезията ли се шегува?
На хартишка беше само справката-декларация, а в магнитен носител- справката-декларация и дневниците.
Имаше един период, в който "документи и на тоалетна хартия да представят трябва да се приемат".

<sup>Отговор на TaNikKa(16.11.2020 15:16):
TaNikKa каза:


Амнезията ли се шегува?
На хартишка беше само справката-декларация, а в магнитен носител- справката-декларация и дневниците.
Имаше един период, в който "документи и на тоалетна хартия да представят трябва да се приемат".</sup>


На мен от НАП са ми искали, какво ли не, само не дневниците разпечатани. Били си ги имали.

До преди петнадесетина години ги искаха. И на дискета и на хартия. По някое време се съжалиха и искаха на хартия до 5000 записа.
Бях се изгаврил още в началото с бирника на гишето. Дневника ми беше разпечатан на А4 формат - портрет. Еми събрах към 200 реда на един лист. На гърба на листа- покупките. Бирника изрева и отказа. Познавах тогавашния шеф на данъчното лично. предупредих го /приемащия/, че ако не ги приеме, ще се оплача на баш шефа. Нали са напечатани? Никъде в правилника не пише с какъв шрифт!
и така. Прие ги, но при всяка засечка с него и оня ме гледаше като партиен секретар и размахмаше пръст: "Знам те аз тебе!!!!"

^{Отговор на typtadrynka(16.11.2020 16:17):
typtadrynka каза:
На мен от НАП са ми искали, какво ли не, само не дневниците разпечатани. Били си ги имали.}

Даже са по-малко от 15. Там до 2013-та (мисля) последно приемаха максимум 5 реда. Откакто няма подаване на гише, не ги искат. Всеки месец се чудя, защо харча хартия. Освен за отмятането, дето каза Алмера.

Както и да е било те тия данни не подлежат на чистене на грешки служебно, но при ГОД какви олелии са. Като изкарат списъците с грешки- чистете по филтрите, ръководителите на предприятията казват: "Няма да ни сторнирате отчетите. Както сме ги подали и валидирали така да си останат. Изкарайте си таблици и там си чистете грешки." Другите натегачи пък:" Тия отчети още светят- нищо не е чистено по филтрите."

Като казвате че файловете са csv моля споделете какъв точно сепаратор ползват за да отделят полетата. Така де все пак csv идва от separated

<sup>Отговор на typtadrynka(16.11.2020 12:54):
typtadrynka каза:
Твоя човек е учил, недоучил. За съжаление, след като стана модерна професия се напълни с всякакви. Така беше и нашата професия към края на предното хилядолетие.

Ще се опитам кратко, колкото мога да изясня ситуацията на твоя човек. Изискването е дневниците да се предават във формат csv. Този формат е стандарт за предаване на „компютърно четими данни“*. Друг такъв формат е xml. Сигурно си го чувал(а). С това не казвам, че csv и xml си приличат по нещо.

Та csv е създаден за нуждите на електроннит...</sup>

Приложение № 12 към чл. 113, ал. 4

(Изм. - ДВ, бр. 101 от 2006 г., изм. - ДВ, бр. 3 от 2007 г., в сила от 01.01.2007 г., изм. и доп. - ДВ, бр. 6 от 2010 г., в сила от 01.01.2010 г., изм. и доп. - ДВ, бр. 10 от 2011 г., в сила от 01.02.2011 г., изм. - ДВ, бр. 15 от 2012 г., попр. - ДВ, бр. 16 от 2012 г., изм. - ДВ, бр. 20 от 2013 г., в сила от 15.03.2013 г., доп. - ДВ, бр. 110 от 2013 г., в сила от 01.01.2014 г., изм. - ДВ, бр. 8 от 2016 г., в сила от 29.01.2016 г., изм. и доп. - ДВ, бр. 24 от 2017 г., в сила от 21.03.2017 г., изм. и доп. - ДВ, бр. 3 от 2019 г., в сила от 01.07.2019 г., изм. и доп. - ДВ, бр. 25 от 2020 г., в сила от 20.03.2020 г.)

Параметри, структура и изисквания към файловете на техническия носител (Загл. изм. - ДВ, бр. 24 от 2017 г., в сила от 21.03.2017 г.)

Общи изисквания към структурата на файловете
(Доп. - ДВ, бр. 10 от 2011 г., в сила от 01.02.2011 г.) Файловете DEKLAR.TXT, POKUPKI.TXT, PRODAGBI.TXT трябва да са текстови файлове с кодиране cp-1251/windows-1251.
Между отделните полета на един запис във файловете няма разделители.
Между отделните записи (редове) се поставя стандартен разделител за край на ред на текстов файл - знак за Carriage Return с последващ знак Line Feed.
(Изм. - ДВ, бр. 24 от 2017 г., в сила от 21.03.2017 г., изм. - ДВ, бр. 25 от 2020 г., в сила от 20.03.2020 г.) Файловете "DEKLAR.ТХТ", "POKUPKI.ТХТ" и "PRODAGBI.ТХТ" се разполагат на технически носител.

Изисквания към подредбата на записите във файловете
Записите във файловете "POKUPKI.ТХТ" и "PRODAGBI.ТХТ" са подредени по полето "Номер по ред на документа в дневника" в нарастващ ред.
Полето "Номер по ред на документа в дневника" се попълва с поредния номер на записа в дневника за съответния данъчен период. В първия запис във файловете "POKUPKI.ТХТ" или "PRODAGBI.ТХТ" полето има стойност "1". Стойностите в полето в следващите записи са нарастващи с 1 без пропуски и без дублиране. При положение че информацията се предава на повече от един носител, поредната номерация в полето "Номер по ред на документа в дневника" не се нарушава. Номерацията не се нарушава и в случаите, когато предаваните данни са за повече от един клон.
При обединяването на информацията от дневниците за покупки и продажби на регистрираното лице и клоновете му в един файл записите следва да са подредени във възходящ ред, по поле "Номер на клона на регистрираното лице, който е издал документа" ("Номер на клона на регистрираното лице, в който е получен документът"), като съответно се спазват изискванията за попълването на полето "Номер по ред на документа в дневника".
Полетата във файл "DEKLAR.TXT", описващи стойност, съдържат сумата на стойностите на съответните полета във файлове "POKUPKI.ТХТ" и "PRODAGBI.ТХТ".
При положение че за съответния данъчен период в дневника за покупките или в дневника за продажбите няма отразени документи, файловете "POKUPKI.ТХТ" и/или "PRODAGBI.ТХТ" няма да съдържат нито един запис.

Изисквания към съдържанието на полетата във файловете
Предвидената дължина (брой знаци) за всяко поле е задължителна. Позициите, които не се използват, следва да са запълнени със знак за интервал. При положение че полето е празно (не е попълнено), отделените му позиции са запълнени със знак за интервал.
(Изм. - ДВ, бр. 15 от 2012 г., в сила от 01.03.2012 г., попр. - ДВ, бр. 16 от 2012 г.) Полетата в условен формат "Символен" могат да съдържат символи от кодовата таблица Windows 1251 с код от 20 до FF включително. Съдържанието е ляво изравнено, като не се позволява допълване на празните позиции в полето с нули (0), за да се спази изискваната дължина на полето.
Пример: Номер на документ 250 - попълва се "250".
Пример: Номер на документ 6000ЕХ0412345 - попълва се "6000/ЕХ/04/12345".
Полетата в условен формат "Цифров" могат да съдържат само арабски цифри. Съдържанието е дясно изравнено. Когато полето описва стойност, то може да съдържа и разделител "." за стотинки и знак минус, без други знаци и разделители. Не се позволява допълване с нули (0) пред дадената сума, за да се спази изискваната дължина на полето. Попълнените стойности трябва да са в български левове.
Пример: Стойност 100,00 лв. - попълва се "100.00".
Пример: Стойност -200,00 лв. - попълва се " - 200.00".
Полетата в условен формат "Дата" съдържат само цифри и знака "/". Съдържанието на полето е в следния формат: "дд/мм/гггг", където: дд е денят, мм - номерът на месеца, гггг - годината.
Пример: Дата 3 декември 2007 г. - попълва се "03/12/2007".
Пример: Дата 25 март 2007 г. - попълва се "25/03/2007".
Пример: Полето е празно (не се попълва) - то съдържа " " или " / / ".


Изисквания към конкретни полета

Полетата "Идентификационен номер на регистрираното лице, подаващо данните", "Наименование на регистрираното лице, подаващо данните", "Лице, подаващо данните" се попълват задължително.
Полето "Отчетен период" съдържа периода, за който се отнася подаваната информация на носителя. Полето съдържа само цифри. Съдържанието на полето е в следния формат: "ггггмм", където: гггг е годината, за която се отнасят данните, мм - номерът на месеца, за който се отнасят данните. Полето се попълва задължително.
Пример: Подава се информация за периода 01 март 2007 г. - 31 март 2007 г. - попълва се "200703".
Пример: Лицето прекратява регистрацията си на 7 май и подава информация от дневниците за периода 01 май 2007 г. - 07 май 2007 г. - попълва се "200705".
Пример: Лицето е регистрирано на 13 май 2007 г. и подава информация от дневниците за периода 13 май 2007 г. - 31 май 2007 г. - попълва се "200705".
Полетата "Номер на клона на регистрираното лице, в който е получен документът" и "Номер на клона на регистрираното лице, в който е издаден документът" се попълват с уникален номер за всеки от клоновете. За документите, получени или издадени от централното управление, полето се оставя празно (не се попълва) или се попълва със стойност нула (0).
Пример: За документ, издаден от клон номер 1 - попълва се "1".
Пример: За документ, издаден от централното управление на регистрирано лице или от регистрирано лице, което няма клонове - попълва се " " или "0".
(Доп. - ДВ, бр. 24 от 2017 г., в сила от 21.03.2017 г., доп. - ДВ, бр. 25 от 2020 г., в сила от 20.03.2020 г.) Полето "Вид на документа" се попълва със следните кодове:


и т.н.

[[/citat]] ^{Отговор на iavorski(21.12.2020 22:36):}

^{Отговор на iavorski(21.12.2020 22:36):
iavorski каза:
Като казвате че файловете са csv моля споделете какъв точно сепаратор ползват за да отделят полетата. Така де все пак csv идва от separated}





Яворски, ще извиняваш, че ти отговарям ден по-късно, но нямаше да видя, че си писал, ако не беше Боко Коко. Той обича да е подробен и точен. Това е похвално, но аз съм мързелив.

Щях да отговоря, че точно в този случай е интервал. Някъде нагоре бях писал за запетая, ама там имах предвид декларациите 1 и 6 (вероятно и 3, никога не ми се е налагало, слава на небесата да работя за държавата).

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

Поздрави!