Інформація щодо випуску оновлень
-
priup
- Повідомлень: 7713
- З нами з: 22 червня 2011, 12:23
Повідомлення
priup » 16 квітня 2021, 16:39
Sagius писав: ↑16 квітня 2021, 16:26
Ирина Шадрина писав: ↑16 квітня 2021, 11:42
Добрый день. Уже два звонка - в Декларацию по НДС, вернее в додаток 1 не тянет обязательства из реестра отриманих та виданих. Налоговый кредит подтягивает нормально.
Підтверджую, повторне формування Реєстра не допомогає.
И НЕ ДОЛЖНО!!!!
priup писав: ↑16 квітня 2021, 11:58
Ирина Шадрина писав: ↑16 квітня 2021, 11:42
Добрый день. Уже два звонка - в Декларацию по НДС, вернее в додаток 1 не тянет обязательства из реестра отриманих та виданих. Налоговый кредит подтягивает нормально.
Вот Вы проглядели:
viewtopic.php?f=6&t=15642&start=160
-
Mihail_67
- Повідомлень: 7
- З нами з: 16 квітня 2021, 13:33
Повідомлення
Mihail_67 » 16 квітня 2021, 19:33
polyk писав: ↑16 квітня 2021, 15:53
Mihail_67 писав: ↑16 квітня 2021, 14:34
Тобто, треба імпортувати звіти з ЄСВ кожного окремого місяця в "старий" Додаток 4 (правила заповнення звіту з ЄСВ не змінились, але змінились типи деяких полів, наприклад, Start_dn та End_dn додатку, тому файл імпорту треба перероблювати), потім з них формувати звіти вже в об'єднану звітність? Я від цієї команди очікував іншого, а саме "автоматичну конвертацію латинських символів". Тоді чому при імпорті до "старого" Додатку 4 помилок із ПІП в ср866 не виникає, а в об'єднаній звітності - все червоне через "неукраїнські символи". Питання, можливо, риторичне....
Тому що в старому додатку 4 перевірки на латинські букви банально не було, а в об'єднаній звітності цю перевірку підключили.
Не згоден. При імпорті до старого додатку 4 контроль на некириличні символи проводився і при наявності хоч одного такого символу імпорт скасовувався. А зараз при імпорті помилок немає, а при перевірці в середині додатку - констатується помилка. І це при тому, що попередньо було замінено всі кириличні символи в ПІП на шаблони ПІП, вивантажені з довідника співробітників в кодовій таблиці ср866. Ось в чому й проблема. Якщо кодова таблиця ср866 вже не підтримується, навіщо залишили діалог її вибору (і при імпорті, і при експорті). Приберіть можливість її вибору і всі знатимуть, що відтепер весь експорт/імпорт тільки в win1251.
-
shershen
- Повідомлень: 286
- З нами з: 12 грудня 2011, 18:15
Повідомлення
shershen » 16 квітня 2021, 21:58
polyk писав: ↑16 квітня 2021, 13:53
...
Большая просьба предусмотреть в следующем обновлении пункт меню
"Консолідувати звіти" или хотя бы
"Додати рядки з DBF".
Да, очень нужно
-
D_Elenka
- Повідомлень: 42
- З нами з: 29 січня 2014, 21:25
Повідомлення
D_Elenka » 17 квітня 2021, 00:06
Mihail_67 писав: ↑16 квітня 2021, 19:33
polyk писав: ↑16 квітня 2021, 15:53
Mihail_67 писав: ↑16 квітня 2021, 14:34
Тобто, треба імпортувати звіти з ЄСВ кожного окремого місяця в "старий" Додаток 4 (правила заповнення звіту з ЄСВ не змінились, але змінились типи деяких полів, наприклад, Start_dn та End_dn додатку, тому файл імпорту треба перероблювати), потім з них формувати звіти вже в об'єднану звітність? Я від цієї команди очікував іншого, а саме "автоматичну конвертацію латинських символів". Тоді чому при імпорті до "старого" Додатку 4 помилок із ПІП в ср866 не виникає, а в об'єднаній звітності - все червоне через "неукраїнські символи". Питання, можливо, риторичне....
Тому що в старому додатку 4 перевірки на латинські букви банально не було, а в об'єднаній звітності цю перевірку підключили.
Не згоден. При імпорті до старого додатку 4 контроль на некириличні символи проводився і при наявності хоч одного такого символу імпорт скасовувався. А зараз при імпорті помилок немає, а при перевірці в середині додатку - констатується помилка. І це при тому, що попередньо було замінено всі кириличні символи в ПІП на шаблони ПІП, вивантажені з довідника співробітників в кодовій таблиці ср866. Ось в чому й проблема. Якщо кодова таблиця ср866 вже не підтримується, навіщо залишили діалог її вибору (і при імпорті, і при експорті). Приберіть можливість її вибору і всі знатимуть, що відтепер весь експорт/імпорт тільки в win1251.
Не треба прибирати cp866. Хай вже хочь при переносі зі щомісячних звітів працює, а краще виправити імпорт в нову звітність або контроль
-
polyk
- Повідомлень: 84
- З нами з: 27 лютого 2013, 17:25
- Звідки: м. Харків
Повідомлення
polyk » 17 квітня 2021, 01:35
Імпорт переривався, якщо в файлах DBF зустрічалися не "некірілічні символи", а відверто не українські букви Ы Э Ъ.
===============================
Протокол імпорту даних
===============================
17.04.2021 1:29:31 Початок імпорту даних
Таблиця 5.
Рядок 1 ІПН 2151800756 :
- В ПІБ "КУЧЕРЫНКО" допустимі лише українські літери!
Імпорт таблиці 5 скасовано.
Тривалiсть iмпорту: 1 сек.
А на латинські букви імпорт не реагував.
Никакую проблему нельзя решить на том же уровне, на котором она возникла.
Альберт Эйнштейн
-
Mihail_67
- Повідомлень: 7
- З нами з: 16 квітня 2021, 13:33
Повідомлення
Mihail_67 » 17 квітня 2021, 17:36
polyk писав: ↑17 квітня 2021, 01:35
Імпорт переривався, якщо в файлах DBF зустрічалися не "некірілічні символи", а відверто не українські букви Ы Э Ъ.
===============================
Протокол імпорту даних
===============================
17.04.2021 1:29:31 Початок імпорту даних
Таблиця 5.
Рядок 1 ІПН 2151800756 :
- В ПІБ "КУЧЕРЫНКО" допустимі лише українські літери!
Імпорт таблиці 5 скасовано.
Тривалiсть iмпорту: 1 сек.
Ніколи раніше не стикався із такою термінологією: "відверто не українські букви". Є український алфавіт, в ньому - українські літери. Всі інші літери, що відсутні в українському алфавіті - є не українськими. Що значить Ваше "відверто"?
А питання не в тому, що було в Додатку 4 (було і загуло), а в тому, що зараз в об'єднаній звітності імпорт з DBF в ср866 проходить вдало, а перевірка таблиць показує помилки в ПІП (попередня підстановка в поля інформації, експортованої з довідника співробітників не допомагає). Тому я і підняв питання: чому після імпорта звіту в форматі DBF в ср866 констатується помилка в інформації, яку було перед цим експортовано в ср866? І чи буде це виправлено в наступних оновленнях? Чи не чекати і переходити на win1251?
-
polyk
- Повідомлень: 84
- З нами з: 27 лютого 2013, 17:25
- Звідки: м. Харків
Повідомлення
polyk » 17 квітня 2021, 19:59
Даруйте за мою не досить вдалу украінську мову. Звичайно "літери". А проблема з cp866 в тому (я вже писав про це і розробники медка це зрозуміли і навіть виправили при "Заповнити пакет звітів J0500106"), що в цій кодіровці немає окремого кода для українських Іі. Використовуються латинські Ii. При перекодуванні з cp866 до win1251 латинські Ii залишаються зі своїм кодом, а інші літери перекодуються.
При імпорті з DBF в об'єднану звітність вони контроль на не українські літери прибрали, а в додатках посилили (в старому додатку 4 не перевіряли на наявність латинських літер, в об'єднаній звітності перевіряють). Зараз розробники медка при виконанні "Заповнити пакет звітів J0500106" вставили додаткове перекодування латинських Ii в українські Іі, а при прямому імпорті з DBF цього не зробили, ось тому їх просять додатково модіфікувати прямий імпорт з DBF в об'єднану звітність.
Никакую проблему нельзя решить на том же уровне, на котором она возникла.
Альберт Эйнштейн
-
polyk
- Повідомлень: 84
- З нами з: 27 лютого 2013, 17:25
- Звідки: м. Харків
Повідомлення
polyk » 17 квітня 2021, 20:05
А кодова таблиця cp866 потрібна тому, що, як не дивно, досить багато організацій досі користуються програмами, які розраховують зарплату в ДОСі.
Никакую проблему нельзя решить на том же уровне, на котором она возникла.
Альберт Эйнштейн
-
Mihail_67
- Повідомлень: 7
- З нами з: 16 квітня 2021, 13:33
Повідомлення
Mihail_67 » 17 квітня 2021, 22:56
polyk писав: ↑17 квітня 2021, 19:59
Даруйте за мою не досить вдалу украінську мову. Звичайно "літери". А проблема з cp866 в тому (я вже писав про це і розробники медка це зрозуміли і навіть виправили при "Заповнити пакет звітів J0500106"), що в цій кодіровці немає окремого кода для українських Іі. Використовуються латинські Ii. При перекодуванні з cp866 до win1251 латинські Ii залишаються зі своїм кодом, а інші літери перекодуються.
При імпорті з DBF в об'єднану звітність вони контроль на не українські літери прибрали, а в додатках посилили (в старому додатку 4 не перевіряли на наявність латинських літер, в об'єднаній звітності перевіряють). Зараз розробники медка при виконанні "Заповнити пакет звітів J0500106" вставили додаткове перекодування латинських Ii в українські Іі, а при прямому імпорті з DBF цього не зробили, ось тому їх просять додатково модіфікувати прямий імпорт з DBF в об'єднану звітність.
Оце-ж і про цю саму проблему і пишу. А написав, бо в попередніх дописах (на цій гілці, на на гілках оновлень 034 та 035) я не побачив звернення з цією проблемою до розробників (або погано дивився). Якщо розробники вже оповіщені, то будемо чекати змін в наступному оновленні. Хоч більшість моїх клієнтів вже по-перевибирали ПІП із довідника співробітників в усіх додатках...
-
Mihail_67
- Повідомлень: 7
- З нами з: 16 квітня 2021, 13:33
Повідомлення
Mihail_67 » 17 квітня 2021, 23:11
polyk писав: ↑17 квітня 2021, 20:05
А кодова таблиця cp866 потрібна тому, що, як не дивно, досить багато організацій досі користуються програмами, які розраховують зарплату в ДОСі.
Частково погоджуюсь, проте проблема не стільки в DOS-додатках, а більше в тому, що використовується формат бази даних DBF III (хоч і програма розрахунку вже під WIN32). Перепроектовувати базу даних - це таких геморой, + потрібен доступ до архівів за минулі роки (довідки та інше). В мене є клієнти, в яких база зберігається ще з 1995 року...
Тому і потрібно залишити імпорт/експорт в кодуванні ср866 та або модифікувати контроль в середині додатків або виконувати перекодування "з льоту".
-
Mihail_67
- Повідомлень: 7
- З нами з: 16 квітня 2021, 13:33
Повідомлення
Mihail_67 » 19 квітня 2021, 10:46
Клієнти наступили ще на одні граблі (сьогодні вже було біля десятка звернень): при повторному виборі в таблицях додатків даних із довідника співробітників помилка про наявність неукраїнських символів не зникає. Знов вилізла проблема з кодування ср866: в далеких 90-х (ще в до-Медоковську епоху) список співробітників до програми АРМ-Звітність набирався саме в кодовій таблиці ср866 (або імпортувався із dbf), от і залишились там англійські "і" та "І". А зараз, ні при експорті довідника співробітників в кодовій таблиці ср1251 ні при повторному виборі ПІП працівника із довідника проблема не лікується. Єдиний вихід - перенабирати всіх працівників, де є українські "і" чи "І".
-
DmitryM
- Повідомлень: 78
- З нами з: 14 вересня 2016, 16:19
Повідомлення
DmitryM » 20 квітня 2021, 17:27
s0600318. Контроль ввели а отчет заполнить корректно невозможно.
-
Вкладення
-
- Безымянный.png (40.46 Кіб) Переглянуто 2857 разів
-
priup
- Повідомлень: 7713
- З нами з: 22 червня 2011, 12:23
Повідомлення
priup » 20 квітня 2021, 17:50
А Вы красное прочитали??? Прежде чем батон крошить??
Ставите 4810100000 - МИКОЛАЇВ !!
-
ferret
- Повідомлень: 1028
- З нами з: 13 липня 2012, 15:20
- Звідки: Острова Зеленого Мыса
Повідомлення
ferret » 21 квітня 2021, 11:19
Mihail_67 писав: ↑19 квітня 2021, 10:46
Клієнти наступили ще на одні граблі (сьогодні вже було біля десятка звернень): при повторному виборі в таблицях додатків даних із довідника співробітників помилка про наявність неукраїнських символів не зникає. Знов вилізла проблема з кодування ср866: в далеких 90-х (ще в до-Медоковську епоху) список співробітників до програми АРМ-Звітність набирався саме в кодовій таблиці ср866 (або імпортувався із dbf), от і залишились там англійські "і" та "І". А зараз, ні при експорті довідника співробітників в кодовій таблиці ср1251 ні при повторному виборі ПІП працівника із довідника проблема не лікується. Єдиний вихід - перенабирати всіх працівників, де є українські "і" чи "І".
Не лише "І". Сьогодні, наприклад, знайшов імена з латинськими "Н" та "С".
На этом месте должна была быть какая-то подпись
-
uefa
- Повідомлень: 46
- З нами з: 12 жовтня 2011, 17:18
Повідомлення
uefa » 21 квітня 2021, 11:21
Здаю Об'єднану звітність ПДФО та ЄСВ Звітну нову
Медок знаходить помилку:
Для Податкового розрахунку з типом 'Звітний' ('Звітний новий') у рядку 07 не заповнено 'Код основного виду економічної діяльності'
Значення елементу Код КВЕД недопустиме. - Значення має недопустимий тип даних.
Заповнюю рядок 07 і тоді Звіт неприйнято, а у 2 квитанції:
Помилка Для Податкового розрахунку (крім тип "Звітний") в
загальній частині рядки 07 - 110 не заповнюються.
Виправте помилки та надішліть повторно електронний документ.
Кому вірити?
-
segamel
- Повідомлень: 117
- З нами з: 21 травня 2012, 11:17
Повідомлення
segamel » 21 квітня 2021, 12:20
ferret писав: ↑21 квітня 2021, 11:19
Mihail_67 писав: ↑19 квітня 2021, 10:46
Клієнти наступили ще на одні граблі (сьогодні вже було біля десятка звернень): при повторному виборі в таблицях додатків даних із довідника співробітників помилка про наявність неукраїнських символів не зникає. Знов вилізла проблема з кодування ср866: в далеких 90-х (ще в до-Медоковську епоху) список співробітників до програми АРМ-Звітність набирався саме в кодовій таблиці ср866 (або імпортувався із dbf), от і залишились там англійські "і" та "І". А зараз, ні при експорті довідника співробітників в кодовій таблиці ср1251 ні при повторному виборі ПІП працівника із довідника проблема не лікується. Єдиний вихід - перенабирати всіх працівників, де є українські "і" чи "І".
Не лише "І". Сьогодні, наприклад, знайшов імена з латинськими "Н" та "С".
Вигрузіть довідник в DBF cp1251, та переконвертуйте всі ПІБ та ІНН. Потім знову імпортуйте. Так буде швидше.
Я скористався VisualFoxpro (заміна подібних по напису анг-рус. літер на українські):
lcEngRus = [ABCEHIKMOPTXYЫыЭэaceikopxy"`1]
lcUkr = [АВСЕНІКМОРТХУІіЄєасеікорху''І]
replace LASTNAME with CHRTRAN(ALLTRIM(LASTNAME),lcEngRus,lcUkr);
FIRSTNAME with CHRTRAN(ALLTRIM(FIRSTNAME),lcEngRus,lcUkr);
MIDDLENAME with CHRTRAN(ALLTRIM(MIDDLENAME),lcEngRus,lcUkr) ALL
Заміна кодової сторінки для анлійська-українська I - i
replace LASTNAME with strt(LASTNAME,'i','і'),FIRSTNAME with strt(FIRSTNAME,'i','і'),MIDDLENAME with strt(MIDDLENAME,'i','і') all
replace LASTNAME with strt(LASTNAME,'I','І'),FIRSTNAME with strt(FIRSTNAME,'I','І'),MIDDLENAME with strt(MIDDLENAME,'I','І') all
replace NUM with strt(NUM,'I','І') all
-
segamel
- Повідомлень: 117
- З нами з: 21 травня 2012, 11:17
Повідомлення
segamel » 21 квітня 2021, 12:28
segamel писав: ↑21 квітня 2021, 12:20
ferret писав: ↑21 квітня 2021, 11:19
Mihail_67 писав: ↑19 квітня 2021, 10:46
Клієнти наступили ще на одні граблі (сьогодні вже було біля десятка звернень): при повторному виборі в таблицях додатків даних із довідника співробітників помилка про наявність неукраїнських символів не зникає. Знов вилізла проблема з кодування ср866: в далеких 90-х (ще в до-Медоковську епоху) список співробітників до програми АРМ-Звітність набирався саме в кодовій таблиці ср866 (або імпортувався із dbf), от і залишились там англійські "і" та "І". А зараз, ні при експорті довідника співробітників в кодовій таблиці ср1251 ні при повторному виборі ПІП працівника із довідника проблема не лікується. Єдиний вихід - перенабирати всіх працівників, де є українські "і" чи "І".
Не лише "І". Сьогодні, наприклад, знайшов імена з латинськими "Н" та "С".
Вигрузіть довідник в DBF cp1251, та переконвертуйте всі ПІБ та ІНН. Потім знову імпортуйте. Так буде швидше.
Я скористався VisualFoxpro (заміна подібних по напису анг-рус. літер на українські):
lcEngRus = [ABCEHIKMOPTXYЫыЭэaceikopxy"`1]
lcUkr = [АВСЕНІКМОРТХУІіЄєасеікорху''І]
replace LASTNAME with CHRTRAN(ALLTRIM(LASTNAME),lcEngRus,lcUkr);
FIRSTNAME with CHRTRAN(ALLTRIM(FIRSTNAME),lcEngRus,lcUkr);
MIDDLENAME with CHRTRAN(ALLTRIM(MIDDLENAME),lcEngRus,lcUkr) ALL
Заміна кодової сторінки для анлійська-українська I - i (кодування cp1251 тому різниця в написанні не помітна, але коди різні)
replace LASTNAME with strt(LASTNAME,'i','і'),FIRSTNAME with strt(FIRSTNAME,'i','і'),MIDDLENAME with strt(MIDDLENAME,'i','і') all
replace LASTNAME with strt(LASTNAME,'I','І'),FIRSTNAME with strt(FIRSTNAME,'I','І'),MIDDLENAME with strt(MIDDLENAME,'I','І') all
replace NUM with strt(NUM,'I','І') all
Можливо все те ж проробити в cp866, але для імпорту довідника співробітників потрібно конвертувати ПІБ в cp1251.
-
ferret
- Повідомлень: 1028
- З нами з: 13 липня 2012, 15:20
- Звідки: Острова Зеленого Мыса
Повідомлення
ferret » 21 квітня 2021, 14:27
segamel писав: ↑21 квітня 2021, 12:20
Вигрузіть довідник в DBF cp1251, та переконвертуйте всі ПІБ та ІНН. Потім знову імпортуйте. Так буде швидше.
Я скористався VisualFoxpro (заміна подібних по напису анг-рус. літер на українські):
lcEngRus = [ABCEHIKMOPTXYЫыЭэaceikopxy"`1]
lcUkr = [АВСЕНІКМОРТХУІіЄєасеікорху''І]
replace LASTNAME with CHRTRAN(ALLTRIM(LASTNAME),lcEngRus,lcUkr);
FIRSTNAME with CHRTRAN(ALLTRIM(FIRSTNAME),lcEngRus,lcUkr);
MIDDLENAME with CHRTRAN(ALLTRIM(MIDDLENAME),lcEngRus,lcUkr) ALL
Заміна кодової сторінки для анлійська-українська I - i
replace LASTNAME with strt(LASTNAME,'i','і'),FIRSTNAME with strt(FIRSTNAME,'i','і'),MIDDLENAME with strt(MIDDLENAME,'i','і') all
replace LASTNAME with strt(LASTNAME,'I','І'),FIRSTNAME with strt(FIRSTNAME,'I','І'),MIDDLENAME with strt(MIDDLENAME,'I','І') all
replace NUM with strt(NUM,'I','І') all
Саме так і робив, але проблема набагато глибше- латинські літери в ПІБ наявні в обліковій програмі, familiaris vs M.E.Doc.
На этом месте должна была быть какая-то подпись
-
buh_buhv2
- Повідомлень: 15
- З нами з: 01 жовтня 2019, 14:29
Повідомлення
buh_buhv2 » 21 квітня 2021, 19:06
В програмі пише, що в 0500106 повинен обов'язково заповнюватись рядок 105 Кількість застрахованих осіб, яким нараховано заробітну плату ...Але в мене три місяці співробітники були без збереження з/п в зв'язку з карантином.
З пустим рядком 105 звіт не приймається. Я так бачу, що контролі у Вас однакові з податковою чи пенсійним (вже не розбереш хто відповідальний за цей бардак). Що робити і куди бігти?
-
wadim1c
- Повідомлень: 116
- З нами з: 06 серпня 2013, 14:21
- Звідки: Україна, Одеса
Повідомлення
wadim1c » 22 квітня 2021, 00:13
uefa писав: ↑21 квітня 2021, 11:21
Кому вірити?
Тому, хто не хоче прийняти звіт. Медок лиш попереджає (в цій ситуації, мабуть, помилково) про наявність помилки у звіті.
Відправляйте, незважаючи на попередження Медка.
В минулому декілька разів бували ситуації, коли "Медок" малює червоним, а звіт (чи документ) прийнято.