Уточню трохи для розуміння ситуації.
Щодо неправильних станів із квитанцій. Програми не можуть орієнтуватися на текст квитанції, як це робить людина - для цього існують певні технічні параметри у файлі квитанції. Зазвичай, усе гаразд і ці параметри відповідають тексту квитанції. Але за якоїсь людської чи технічної помилки на сервері ДПС ця відповідність може порушитися. Тоді "помилкові" квитанції можуть мати ознаку "прийнято", квитанції про зупинення - ознаку реєстрації і т.д. Виправити таку помилку шлюзу програма не може.
Щодо станів ПН взагалі. Податкова накладна може отримати певний стан від одного з двох джерел: квитанція або витяг.
Квитанція, окрім некоректних технічних параметрів (описано вище) має ще одну ваду - вона прив'язана до технічного номеру ("номер у періоді"), а не до порядкового номеру накладної. Оскільки ці два показники не обов'язково повинні збігатися, то може виникнути ситуація, коли до ПН прикріплюється "чужа" квитанція, змінюючи стан накладної некоректним чином. Таке може бути, якщо реєструвати накладні у різних програмах, імпортуючи та експортуючи їх туди-сюди.
Витяг з ЄРПН у цьому сенсі більш коректний. Він, зокрема, може змінити стан "зупиненої" ПН, якщо ДПС дозволила її зареєструвати на момент подання запиту. Тоді під накладною буде прикріплено квитанцію про зупинення, але ПН цілком чесно буде мати стан "прийнятий".
Це - "позитивна несподіванка", але зазвичай у подібних випадках винна одна з попередніх двох причин: некоректно сформований податковою файл квитанції, або некоректне прикріплення квитанції від іншої ПН.
Добрий день. Виникла проблема, такого характеру. Клієнту був виставлений рахунок на оплату на суму 136613,33 грн. Клієнт оплатив двома платежами 80 000,00 грн і 56 613, 33 грн. З реєстрацією ПН на суму 80 000, 00 грн, проблем не було. При реєстрації ПН на суму 56 613,33 грн. виникає проблема такого плану.
56613,33/1,2=47177,78 грн 47177,78*1,2=56613,34 грн
Що можна зробити в такому випадку ? Наперед вдячний за відповідь.
Тут уся справа в точності округлення. А корінь проблеми полягає у ПДВ: у таблиці (Розділ Б) точність ціни та кількості (графи 6 та 7) складає 12 знаків після коми, точність ПДВ (графа 11) 6 знаків, а точність бази оподаткування (графа 10) тільки 2 знаки після коми. Тобто Базу доводиться округлювати з 12 до 2 знаків після коми, а ПДВ з 12 до 6 знаків. Потім, у Розділі А ми маємо ще одну перепону - точність усіх полів тільки 2 знаки після коми, тобто вже округлене ПДВ доводиться округлювати знову з 6 до 2 знаків після коми. І тільки потім ми маємо сумувати базу з ПДВ, отримавши кінцеву суму. Тобто, для накладної з одним рядком у таблиці алгоритм такий:
Така кількість округлень (особливо подвійне округлення ПДВ) сильно збільшує математичну похибку. Це у свою чергу призводить до "стрибань" копійок у кінцевому результаті.
Простими словами, існують такі кінцеві суми з ПДВ, для яких (за чинними правилами округлення в податковій накладній) математично неможливо підібрати потрібну ціну. Ви завжди будете отримувати або на копійку більше, або на копійку менше.
У такому випадку вам може допомогти тільки коригування кількості, якщо це допускається правилами оподаткування (наприклад для деяких послуг допустимо вказувати кількість не "1", а 1,000999 або 0,99998877). Якщо у вашому випадку кількість має бути суворо "1", тоді з такої ситуації виходу немає, ви не зможете зареєструвати ПН на таку суму. Про це важливо пам'ятати заздалегідь, коли визначаєте кінцеву ціну товару.
ПС. Я зараз близько півгодини калькулятором намагався підібрати вам підходящу ціну, але теж не зміг)
ППС. Ще спало на думку, що ситуація може покращитися, якщо у накладну додати ще один рядок з іншим товаром/послугою. Тоді схема округлень дещо зміниться і є шанс вийти на потрібну суму. Але це теж не завжди можливо з бухгалтерської точки зору.
Дуже дякую за відповідь. Я пробував різні варіанти і здається, що сами хороший, щоб клієнт вносив кошти, якщо не одним платежем, то хоча б, щоб суми відповідали ціні певній кількості товару з рахунку.
Доброго ранку. Виникла проблемка з відправкою ПН на реєстрацію. Два дні тому надсилав все було в порядку. На сьогодні після підписання в режимі "відправити" викидає повідомлення такого змісту: "Сертифікат не чинний за строком дії або закінчився строк дії відповідного особистого ключа". Це при тому що ключі дійсні до 16.06.2024 року. Що це може бути, чи значити? Після оновлення криптобібліотеки та перезавантаження ключів нічого не змінилося. В чому може бути причина? Дякую.
Питання??? РКЕ надіслані контрагентом після підписання та надання на реєстрацію знаходяться в статусі "неприйняті" Контагент хоче щоб йому надіслати неприйняті коригуючі та квитанції в програму Медос. Такої відправки в програмі СОНАТА не знайшов. Чи можна відправити РКЕ та квитанції контрагенту на інше ПЗ в даному випадку в Медок? Чи тільки на електронку у вигляді PDF файлів? Дякую.
тільки на електронку у вигляді PDF файлів
Доброго дня! Чому неможливо створити ПН на послуги від нерезидента? Програма автоматично ставить продавця фірму з поточного профілю з її реквізитами. Хоча згідно правил виписки там має бути зазначена іноземна фірма з ІПН 500000000000. Що можна зробити?
Якщо це вхідна ПН, то її треба створювати у вкладці "Отримані".
Добрий день. Підкажіть чи можна якось змінити номер накладної у властивостях, там де стовбчик номер звіту у періоді, якщо вона вже прийнята? Міняла місцями накладні и не змінила у властивостях, а теперь наступну с таким самим номером не пускає. зображення
Ні, прийнятих вже не можно
Добрий день. Підкажіть чи можна якось змінити номер накладної у властивостях, там де стовбчик номер звіту у періоді, якщо вона вже прийнята? Міняла місцями накладні и не змінила у властивостях, а теперь наступну с таким самим номером не пускає. зображення
... номер документу/звіту у періоді - це лише для податкової, він присвоюється автоматично кожною програмою і вноситься в ім'я файлу під час збереження звіту, Номер звіту у періоді повинен бути унікальним на приймальному шлюзі ДПС (щоб в подальшому звіт зареєструвався у ДПС). Це не є саме номером податкової "всередині", це не те, що виписано покупцю та видиме на папері. Це як лічильник кількості унікальних звітів, що подані до ДПС.
Добрий день. Підкажіть чи можна якось змінити номер накладної у властивостях, там де стовбчик номер звіту у періоді, якщо вона вже прийнята? Міняла місцями накладні и не змінила у властивостях, а теперь наступну с таким самим номером не пускає. зображення
Гадаю, ви хочете "зробити гарно", щоб номер накладної і номер у періоді збігалися. Для накладних за лютий так зробити вже не вийде, бо накладна з номерами "6-7" вже зареєстрована у податковій. За березень у вас почнеться нова нумерація і знову буде все гарно.
ПС. Як зазначили вище, така розбіжність номерів не має жодного юридичного та податкового значення, тому щодо цього можна не перейматися.
Всім, дякую за відповіді ))
Технічна підтримка: support@sonata.biz.ua