ПРОМЕНИ, СВЪРЗАНИ С ВЪВЕЖДАНЕ НА ЕВРОТО

Тук са изброени някои проблеми свързани с версиите, за които националната валута ще стане EUR.

ПЕРИОД, ВКЛЮЧВАЩ ДАННИ ПРЕДИ И СЛЕД 01.01.2026

Желателно е версията, с която се рабoти след 01.01.2026 да може да работи и с данни преди тази дата, като винаги, когато крайната дата за справките е преди  01.01.2026 валутата да е BGN, а в противен случай да е EUR. Ако периода за някоя справка включва документи за 2 години, тези, които са в BGN автоматично ще се преизчисляват в EUR.

След приключване на 2025 г. макар и по рядко ще се налага да се работи с данни за няколко години - напр. при справките, които използват данни за приключените години.

ПРОБЛЕМИ СЪС ЗАКРЪГЛЕНИЯ.

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

Пример:
Многоредова фактура за доставка. Ако формално превалутираме всички редове крайното салдо в EUR с голяма вероятност няма да е точно крайното салдо в BGN / 1.95583. Затова е добре на някой от детайлните редове да се записва корекцията.
Някой свръхнаблюдателен потребител може да открие, че в някой от детайлните редове има неточност: примерно 2 * 2 = 4.01. Но е важно, че при общия сбор няма да има аномалии.

Пример за проблемите със закръгленията с реални данни на конкретен потребител:

В случая се вижда какво се случва когато крайната дата за периода на справката е през 2026 г. стойностите до 2025 г. трябва да се преизчислят в евро. Въпреки, че това не е много голямо приложение и стойностите са преизчислени с голяма точност в сборния ред се вижда разлика от няколко стотинки. Може да се скрият такива разлики в някои случаи като се добавят коригиращи записи с дата 01.01.2026, но не знам дали е възможно да се избегнат във всички случаи

ПРОБЛЕМИ ПРИ ИЗЧИСЛЯВАНЕ НА САЛДАТА КЪМ 01.01.2026 г.

За всяка партиди, които са с крайно салдо # 0 с голяма вероятност при превалутирането ще има разлики от закръгления. За сметки, при които има много партиди превалутираното крайно салдо за сметката ще е различно от сбора на салдата за превалутираните партиди. Трябва да се измисли разумно решение за този проблем за да няма разлики между салдата на 31.12.2025 и 01.01.2026. Въпросните разлики ще се появяват за повечето сметки, за които има много партиди.

При приключване на годината в данните за началните салда трябва да се появят записи, които да коригират тези разлики. Освен това с дата 01.01.2026 г. ще се появят записи, които закриват тези разлики като се дебитира или кредитира някоя сметка.

Пример: Сметка доставчици с много крайни салда към 31.12

След превалутирането се вижда, че крайното салдо в лв.  / 1.95583 се различава от сумата на превалутираните партиди.

ВАЛУТНИ СМЕТКИ В EUR

След 01.01.2026 г. те вече би трябвало да се трансформират в сметки, които не са валутни.

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

СМЕТКИ В BGN СЛЕД 31.12.2025

Сметки 501* и 422* ако имат салда след 31.12.2025 трябва да се трансформират във валутни.

ПРОМЕНИ, СВЪРЗАНИ СЪС ЗАПЛАТИТЕ

При приключване на м.12.2025 към всеки трудов договор ще се създаде доп. споразумение в сила от 01.01.2026 в което вече заплатата ще е в EUR. Вероятно ще се наложи да има забрана за въвеждане на отсъствия, за които периода включва дни от 2 години. 

ДОКУМЕНТИ ЗА ПОКУПКИ ОТ ДРУГИ ПРИЛОЖЕНИЯ

Когато има много фактури за покупки от някои доставчици една ефектна възможност на ПИТАГОР ще ви помогне да ги осчетоводите лесно.

Необходимо е данните за покупките да включват следните атрибути:

• ЕИК и ДДС НОМЕР на доставчика
• Номер, Дата и Дата на падеж на фактурата
• ЕИК и ДДС НОМЕР на получателя
• Вид валута и обща стойност за документа
• Име и наименование на артикула за всеки детайлен ред
• Количество, Стойност без ДДС Стойност вкл. ДДС за всеки детайлен ред.

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

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

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

Когато източника на документите използва също ПИТАГОР има възможности това да става достатъчно лесно.

ВАРИАНТ 1.
Данните на някои доставчици са достъпни в друга папка на същия компютър, на който са данните за конкретната фирма. В този случай може да използвате възможността ИМПОРТ ОТ ДРУГИ ПАПКИ от меню ДОКУМЕНТИ на счетоводния модул.

ВАРИАНТ 2.

Получили се по някакъв начин файлове с данните от друг доставчик. Той е използвал възможността СПОДЕЛЯНЕ НА  ФАКТУРИ ЗА ПРОДАЖБИ от модул ПРОДАЖБИ.

В този случай трябва да използвате възможността ИМПОРТ ОТ ДРУГИ ИЗТОЧНИЦИ от меню ДОКУМЕНТИ на счетоводния модул.

Дати на фактурите и Дати на падеж

Освен датата на счетоводната операция за всеки документ може да се въвежда и дата на първичния документ. 

За документите, които са свързани с фактури може да се въвежда и дата на падеж, която е различна от датата на документа. Тази дата е свързана със справките РАЗЧЕТИ С КОНТРАГЕНТИ и с възможностите ПЛАНИРАНЕ НА ПЛАЩАНИЯТА.

За опцията ВАУЧЕРИ ЗА ХРАНА

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

В ПП Питагор се поддържат  следните типове за ваучери за храна:

VAU - Стойността се редуцира според отработените дни + дните в платен отпуск
VAu  - Стойността се редуцира според отработените дни + дните в платен отпуск + дните в болнични
Vau - Стойността се редуцира според отработените дни

VaU  - Стойността се редуцира според отработените дни + дните в платен отпуск + дните в болнични + дните за гледане на дете, т.е.- изключват се само  дните в непл.отпуск

През 2024г. ваучерите за храна стават електронни.

Зареждането на картите (електронните ваучери) за Томбоу става по следния начин:

За всеки служител в досието еднократно трябва да се въведе Акаунт ID на картата (който се предоставя от операторът при първоначалното издаване на картите на служителите) . При първоначално подаване на информацията към оператора трябва да се включи и ЕГН-то на служителите.

При извеждане на справка за разплащателно перо от тип за ваучери се появява бутон за файл за ваучери. Тук трябва да се избере файла „Допълване..“ , който трябва да се извлече от системата на Томбоу, който се попълва като се създава нов файл с попълнени данни за сумите по картите на всеки служител

Документи, свързани с протоколи за самоначисляване на ДДС

В случаите, когато ДДС трябва да се начисли от получателят на сделката, могат да се използват специални типове документи, които генерират свързаните с тях протоколи.  Необходимо условие за използване на тази възможност е въпросните протоколи да се включват в регистрите на покупките и продажбите през един и същи месец. В този случай счетоводната операция, свързана с протокола, който се включва в двата регистъра е една с контировка  Д-т 4531 К-т 4532

Случаите, когато тази възможност може да се използва са следните:

• ВОП чл. 84 ЗДДС 
  Протоколът (09) се включва в регистъра на  ПРОДАЖБИ - като данъчната основа е в к.13, ДДС в к.15
  Фактурата за доставка, на базата на която се създава протокола, не се включва в регистъра на покупките
  
  
• УСЛУГИ ВНОС   чл. 82(2) т.3
  Протоколът (09) се включва в в регистъра на  ПРОДАЖБИ - като данъчната основа е в к.14, ДДС в к.15
  Фактурата за доставка,  на базата на която се създава протокола, не се включва в регистъра на покупките 
  
  
• Чл.82 ал.5 ЗДДС - Доставки на стоки и услуги по Приложение 2 от ЗДДС
•  Чл. 163а   - Част I - СКРАП...
  Фактурата за доставка, на базата на която се създава протокола се записва в регистъра на покупките без стойности, а в колона 8а се записва "01"
  
• Чл. 163а  - Част II - ЗЪРНО, СЕМЕНА
  Фактурата за доставка, на базата на която се създава протокола се записва в регистъра на покупките без стойности, а в колона 8а се записва "02"
  
• Протоколът се отразява в кол.14 и 15 на дневник Продажби                                                                     
• ВНОС чл. 57, ал. 6 от  ЗДДС
•  Отложено начисляване на ДДС при внос на стоки, изброени в приложение 3  от ЗДДС
• Митническата декларация (07) се посочва в двата дневника (Покупки и Продажби) в колони от 1 до 8, т.е. без стойности
• Протоколът (09) за самоначисляване на ДДС, който се генерира се отразява в
• Дневник Покупки - дан.основа в кол. 9, 10 или 12, ДДС в кол.11
• Дневник Продажби - дан.основа  в кол. 9 и 11, ДДС  в кол.10 и 12
• в колона 8а и на двата дневника се посочва "03"

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

Контировки, свързани с документите за продажби

Всеки документ за продажби е свързан с партида от разчетна сметка КЛИЕНТИ /411* / ако документа е фактура или с партида от сметки 501* или 422* ако става дума за касови продажби.

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

Задължителна е партидата за отчитане на продажбите. Това в общия случай е партида от сметка 70*. Ако в артикула е зададена сметка от група 412* /аванси/ партидата се формира като към сметката се добави клиента и фактурата.
Ако реда от продажната е свързан с конкретен материален актив се записва и партида от сметка 30*.

Има възможност зададените партида в данните за избрания артикул да се променят при конкретни продажби. Може да се променя аналитичността /без сметката/. Ако това се направи при въвеждане на някой ред при всички следващи нови редове за артикулите от същата сметка по подразбиране се попълват променените стойности.

Ако в данните за потребителя са зададени стойности по подразбиране за партидите, свързани с артикулите при всеки нов ред от документите за продажби контировките се променят според данните за потребителя, ако сметките за артикула са същите.

Използване на ПП ПИТАГОР от отдалечени работни места.

 ПП ПИТАГОР не е веб базиран софтуер.
Това не означава, че има проблеми да се работи от компютри, които са извън локалната мрежа, където са конкретните данни. Добро и надеждно решение е да се работи чрез отдалечен достъп до компютър от локалната мрежа, на който е инсталиран ПП ПИТАГОР. На отдалечения компютър няма нужда да е инсталиран наш софтуер.
Може да се използват възможностите на операционната система WINDOWS REMOTE DESKTOP.  Може също да се използва всеки софтуер за отдалечен достъп  - напр. ANYDESK, TEAMWEAWER.

Ако се работи по този начин надеждността и производителността е същата, както при работата от всеки компютър в локалната мрежа.

По принцип има техническа възможност да се работи директно с данните като се използва инсталация на ПП ПИТАГОР на отдалеченото работно място. Това обаче не е добра идея, защото има рискове, свързани с прекъсвания по време на достъпа до данните и в някои случаи ще има значително забавяне.