От съдържанието на картотека СТАТИИ зависи дали аналитичните справки за салдата и оборотите за сметки 61* ще са полезни или на практика ще са неизползваеми.
Картотеката трябва да включва само съществените видове разходи свързани със съответната дейност. Често срещана грешка е да се добавят много излишни записи в тая картотека. Понякога това, което се въвежда като статия може да се въведе в текста свързан със съответната счетоводна операция.
За да се предотврати въвеждането на случайни записи в тази важна картотека програмата има настройка, която забранява промените на статиите при въвеждане на партиди. Препоръчваме да се използва тази възможност и да се работи с картотека която сте подготвили предварително.
понеделник, 20 октомври 2014 г.
вторник, 14 октомври 2014 г.
ЗАЯВКИ ЗА ПРОДАЖБИ и НЕФАКТУРИРАНИ ПРОДАЖБИ
Има малка разлика между тези възможности:
ЗАЯВКИ ЗА ПРОДАЖБИ се използва когато се съставя оферта /проформа/ за евентуална продажба.
НЕФАКТУРИРАНИ ПРОДАЖБИ създава документи за реални продажби за които още няма официални фактури. Тези документи могат да се включват в справките за продажбите.
И в двата случая тези документи може лесно да се трансформират във фактури.
понеделник, 9 юни 2014 г.
ПЛАНИРАНЕ НА ПЛАЩАНИЯТА
Тази част от системата е предназначена за създаване на документи за бъдещи плащания. Това е разширение на възможностите на функциите БАНКОВИ ДОКУМЕНТИ от старите версии.
Плащанията може да са свързани освен с банкови документи на хартиен носител, но може да се правят и с файлове, които се използват от електронното банкиране.
До момента се поддържат 2 вида документи:
- ДОКУМЕНТИ ЗА КРЕДИТЕН ПРЕВОД
- БЮДЖЕТНИ ПЛАТЕЖНИ НАРЕЖДАНИЯ.
Бюджетни платежни нареждания може да се създават освен от функцията в главно меню ПЛАНИРАНЕ НА ПЛАЩАНИЯТА и с функция БАНКОВИ ДОКУМЕНТИ от подсистема ЗАПЛАТИ.
Документи за кредитен превод може да се създават на базата на данните за задълженията към конкретния доставчик, като се избират фактурите които ще се плащат.
Плащанията може да са свързани освен с банкови документи на хартиен носител, но може да се правят и с файлове, които се използват от електронното банкиране.
До момента се поддържат 2 вида документи:
- ДОКУМЕНТИ ЗА КРЕДИТЕН ПРЕВОД
- БЮДЖЕТНИ ПЛАТЕЖНИ НАРЕЖДАНИЯ.
Бюджетни платежни нареждания може да се създават освен от функцията в главно меню ПЛАНИРАНЕ НА ПЛАЩАНИЯТА и с функция БАНКОВИ ДОКУМЕНТИ от подсистема ЗАПЛАТИ.
Документи за кредитен превод може да се създават на базата на данните за задълженията към конкретния доставчик, като се избират фактурите които ще се плащат.
ИМПОРТ НА БАНКОВИ ИЗВЛЕЧЕНИЯ
ИМПОРТ НА БАНКОВИ ИЗВЛЕЧЕНИЯ е полезна възможност която сравнително рядко се използва.
Необходимо е само да отделите еднократно няколко минути за да зададете папката в която се записват файловете и да свържете контрагентите за които има най много обороти с техните банкови сметки. След това когато осчетоводявате банката за датата може да виждате данните от извлечениятаи в много случаи да създавате счетоводни операции само с кликване. Освен това имате допълнителни справки, които показват евентуални разлики между осчетоводяванията и данните от банковите извлечения,
Автоматичното генериране на счетоводни операции от банковите извлечения изглежда доста сложно и може би затова много потребители игнорират тези възможности. Всъщност в много случаи има начин програмата да се "досети" каква е съответната счетоводна операция и да ви спести малко време.
Идентифициране на контрагента:
Ако е зададена банковата сметка на контрагента програмата ще ви спести търсенето в картотеката
Идентифициране на фактурата свързана с плащането:
В общия случай това изглежда невъзможно. Но в случай, че плащането е свързано с една фактура и не става дума за частично плащане по стойността на плащането програмата ще се опита да познае коя е фактурата. Ако е необходимо можете да корегирате това което предлага, но в масовия трябва само да потвърдите записа.
Осчетоводяване на плащанията за осигуровките: Ако се плаща цялото начислено задължение, което почти винаги е така, партидите свързани с плащането се определят автоматично от записите за осчетоводяване на осигуровките от подсистема ЗАПЛАТИ.
За да импортирате документите за определен период е достатъчно от интернет банкирането да запазите банковото извлечение в папката която сте задали в настройките на PtgSupport. Трябва да изберете XML формат - подробен вариант а името на файла да започва с първите 4 символа на БИК - напр. UBBS; STSA; BPBI Специално за ДСК след STSA трябва да се запише IBAN на потребителя. Подробно описание за тези функции има в хелп-а.
Необходимо е само да отделите еднократно няколко минути за да зададете папката в която се записват файловете и да свържете контрагентите за които има най много обороти с техните банкови сметки. След това когато осчетоводявате банката за датата може да виждате данните от извлечениятаи в много случаи да създавате счетоводни операции само с кликване. Освен това имате допълнителни справки, които показват евентуални разлики между осчетоводяванията и данните от банковите извлечения,
Автоматичното генериране на счетоводни операции от банковите извлечения изглежда доста сложно и може би затова много потребители игнорират тези възможности. Всъщност в много случаи има начин програмата да се "досети" каква е съответната счетоводна операция и да ви спести малко време.
Идентифициране на контрагента:
Ако е зададена банковата сметка на контрагента програмата ще ви спести търсенето в картотеката
Идентифициране на фактурата свързана с плащането:
В общия случай това изглежда невъзможно. Но в случай, че плащането е свързано с една фактура и не става дума за частично плащане по стойността на плащането програмата ще се опита да познае коя е фактурата. Ако е необходимо можете да корегирате това което предлага, но в масовия трябва само да потвърдите записа.
Осчетоводяване на плащанията за осигуровките: Ако се плаща цялото начислено задължение, което почти винаги е така, партидите свързани с плащането се определят автоматично от записите за осчетоводяване на осигуровките от подсистема ЗАПЛАТИ.
За да импортирате документите за определен период е достатъчно от интернет банкирането да запазите банковото извлечение в папката която сте задали в настройките на PtgSupport. Трябва да изберете XML формат - подробен вариант а името на файла да започва с първите 4 символа на БИК - напр. UBBS; STSA; BPBI Специално за ДСК след STSA трябва да се запише IBAN на потребителя. Подробно описание за тези функции има в хелп-а.
вторник, 11 март 2014 г.
КОНТРОЛ НА НОМЕРАТА НА ФАКТУРИТЕ В МОДУЛ "ПРОДАЖБИ"
При създаване на нова фактура в модул ПРОДАЖБИ е желателно да се гарантира коректно подсказване на следващия пореден номер при нов документ и да се изключи възможността за въвеждане на документи номерата на които се дублират с фактури от минали години.
Във версиите до м. 03.2014 това се прави като за всеки потребител се задават номерата на документите които може да се въвеждат от този потребител. Имаше известно неудобство ако един потребител работи с няколко вида фактури с поредни номера напр.
11001, 11002, ....
12001, 12002, ...
....
В такива случаи понякога се създаваха няколко фиктивни потребителя като всеки се свързваше с определен вид фактури.
След приключване на всяка година се препоръчваше да се корегират допустимите номера за потребителите за да се изключи дублиране с номера от приключената година.
Във версиите след 11.03.2014 г. се появи нова възможност която е полезна в такива случаи: Може да се дефинират поредните номера на фактурите независимо от данните за потребителите и се въвеждат поредни номера за които има забрана за създаване на нови документи.
При приключването на годината автоматично се добавяха забрани за използваните номера през годината.
При първо изпълнение на функцията за дефиниране на видовете документи автоматично се добавят видовете, свързани с потребителите. Освен това се попълваха и забраните за използваните документи през минали години ако папките за данните за миналите години са в основната папка с данните /т.е там където е редно да се намират/
Във версиите до м. 03.2014 това се прави като за всеки потребител се задават номерата на документите които може да се въвеждат от този потребител. Имаше известно неудобство ако един потребител работи с няколко вида фактури с поредни номера напр.
11001, 11002, ....
12001, 12002, ...
....
В такива случаи понякога се създаваха няколко фиктивни потребителя като всеки се свързваше с определен вид фактури.
След приключване на всяка година се препоръчваше да се корегират допустимите номера за потребителите за да се изключи дублиране с номера от приключената година.
Във версиите след 11.03.2014 г. се появи нова възможност която е полезна в такива случаи: Може да се дефинират поредните номера на фактурите независимо от данните за потребителите и се въвеждат поредни номера за които има забрана за създаване на нови документи.
При приключването на годината автоматично се добавяха забрани за използваните номера през годината.
При първо изпълнение на функцията за дефиниране на видовете документи автоматично се добавят видовете, свързани с потребителите. Освен това се попълваха и забраните за използваните документи през минали години ако папките за данните за миналите години са в основната папка с данните /т.е там където е редно да се намират/
сряда, 19 февруари 2014 г.
За данъчната основа и стойността без ДДС във фактурите
Данъчната основа не винаги е точно стойността без ДДС във фактурите.
Това се вижда от следния пример: ДДС 2.00 лв. съответства на стойност на сделка 10.00 лв., но също и на 9.98, 9.99; 10.01; 10.02
На стойност 11.99 вкл. ДДС съответства ДДС 2.00 лв.
Ако в една фактура има 10 такива реда резултата ще е
Стойност вкл. ДДС 119.90 ДДС: 20.00
Стойност без ДДС 99.90 * 0.2 = 19.98
Когато някой види сборен ред в един многоредов документ за 119.90 и съответно ддс 20.00 вместо 19.98 е трудно да разбере, че няма грешка. Програмата на НАП също ще покаже предупредително съобщение в такива случаи. Затова в такива случаи попълваме в регистъра по ДДС данъчна основа която съответства на ДДС-то - т.е стойност различна от стойността без ДДС. Когато фактурата се създава с нашия модул ПРОДАЖБИ когато се открие подобна аномалия предлагаме на потребителя да избере дали да се “скрие” аномалията. Това става за сметка на неточно изчисляване на стойността в някой от детайлните редове където разликата не се забелязва лесно.
Във фактурите които отпечатваме има възможност да попълваме както стойността без ДДС така и данъчната основа. Задължителен атрибут по ЗДДС е ДАНЪЧНА ОСНОВА, но ако попълним корегираната в горния пример стойност, а не стойността без ДДС получателя на такава фактура ще е изненадан, че данъчната основа +ДДС не е точно общата стойност. Възможно е ако освен данъчната основа във фактурата се отбелязва и стойността без ДДС, но досега не сме виждали такива варианти на фактури..
Това се вижда от следния пример: ДДС 2.00 лв. съответства на стойност на сделка 10.00 лв., но също и на 9.98, 9.99; 10.01; 10.02
На стойност 11.99 вкл. ДДС съответства ДДС 2.00 лв.
Ако в една фактура има 10 такива реда резултата ще е
Стойност вкл. ДДС 119.90 ДДС: 20.00
Стойност без ДДС 99.90 * 0.2 = 19.98
Когато някой види сборен ред в един многоредов документ за 119.90 и съответно ддс 20.00 вместо 19.98 е трудно да разбере, че няма грешка. Програмата на НАП също ще покаже предупредително съобщение в такива случаи. Затова в такива случаи попълваме в регистъра по ДДС данъчна основа която съответства на ДДС-то - т.е стойност различна от стойността без ДДС. Когато фактурата се създава с нашия модул ПРОДАЖБИ когато се открие подобна аномалия предлагаме на потребителя да избере дали да се “скрие” аномалията. Това става за сметка на неточно изчисляване на стойността в някой от детайлните редове където разликата не се забелязва лесно.
Във фактурите които отпечатваме има възможност да попълваме както стойността без ДДС така и данъчната основа. Задължителен атрибут по ЗДДС е ДАНЪЧНА ОСНОВА, но ако попълним корегираната в горния пример стойност, а не стойността без ДДС получателя на такава фактура ще е изненадан, че данъчната основа +ДДС не е точно общата стойност. Възможно е ако освен данъчната основа във фактурата се отбелязва и стойността без ДДС, но досега не сме виждали такива варианти на фактури..