Для правильного подсчета базы без НДС нужно ,чтобы кол-во знаков после запятой в "количестве" было более 6-ти!!!
Почему Медок это до сих пор не сделает??? Мне услугу оплачивают 6 раз разными суммами-не целыми, поэтому в пропорциях нужно указать части предоплат.
Как Вы выходите правильно из подобных ситуаций??

Потому, что он выполняет требования налоговой, в отличии от Вас.

Нет таких требований от ДФС - не выдумывайте!!! есть элементарная математика - база бухгалтерских вычислений, правильность которых ДФС и проверяет! Вы -сотрудник /разработчик Медка?

Из ресурса "ЗІР" раздел 101.19

Згідно із п. 201.2 ст. 201 Податкового кодексу України від 2 грудня 2010 року № 2755-VI із змінами і доповненнями форма та порядок заповнення податкової накладної затверджуються центральним органом виконавчої влади, що забезпечує формування та реалізує державну податкову і митну політику.
Відповідно до п. 3 Порядку заповнення податкової накладної, затвердженого наказом Міністерства фінансів України від 22.09.2014 № 957, зареєстрованим в Міністерстві юстиції України 13.10.2014 за № 1235/26012, із змінами та доповненнями (далі – Порядок № 957), усі графи податкової накладної, що мають вартісні показники, заповнюються в гривнях з копійками.
Водночас пунктом 15 Порядку № 957 передбачено, що графа 7 заповнюється у гривнях з копійками, якщо інше не передбачено чинним законодавством.
Таким чином, вартісні показники податкової накладної повинні містити не більше двох знаків після коми (крім показника графи 7, якщо для нього інше передбачено чинним законодавством).
При цьому Порядком № 957 не визначено обмеження щодо кількості знаків, яку можуть містити після коми кількісні показники, що зазначаються у графі 6 податкової накладної, а також правила округлення як вартісних так і кількісних показників, отриманих внаслідок розрахунку.
Необхідною кількістю знаків після коми у кількісному показнику вважається така кількість, якої достатньо для вірного розрахунку вартісного показника у графах 8-13 податкової накладної.
Розрахунок вартісного показника, у якому внаслідок добутку показників граф 6 та 7 податкової накладної отримується число, у якому кількість знаків після коми перевищує два, вважається вірним, якщо з метою скорочення такої кількості знаків до другого знаку після коми округлення не призводить до збільшення такого знаку на «1» (одиницю).

tiger1 не сперечайтесь - ви оперуєте законодавчими поняттями,
а для Медка і інших айтішників, які роблять програмки для нас і
здохликів є ще й технічні умови, які вони мають виконувать...



Ну і що шо в голові вітер?!
Зате думки завжди свіжі!!!

Шустрик логично будет, если Тех задание будет опираться на нормативку ! иначе оно будет идти вразрез... Я не могу законно воспользоваться правом и обязанностью правильно отразить графы 6 и 8 НН , как того требует здравый смысл и нормативный Порядок, а мне говорят,что МОИ требования не подлежат рассмотрению в то время, как требования ДФС в данном вопросе ИДЕНТИЧНЫ с моими! Навязали ПЗ, которому абсолютно все равно как его пользователи будут реализовывать требования нормативки ...Упор нужно делать как всегда - не на форме , а на содержании - мне неважно какого цвета у Медка будут модули, и подобная требуха, Соната в сравнении с Медком - вообще скромница , но выбор пал на Медок- прогрессивный, развивающийся и проч.Мне важно,чтобы он не чинил препятствий для соблюдения действующего законодательства, а был помощником для реализации налогово-бухгалтерских беспорных прав налогоплательщика!

Ну погодьтесь - ні Медок, ні ОПЗ, ні Соната не винні
в тому шо здохлики не дотримуюцця законодавчих
нормативів при розробці тех.завдань..., хоча я й
розумію ваші емоції...



Ну і що шо в голові вітер?!
Зате думки завжди свіжі!!!

tiger1
Вы здесь новичёк, поэтому прощаю Ваше невежество и хамство. Когда попадаете на какой-либо форум, неплохо ознакомиться с его постоянными форумчанами, почитать их посты и все такое прочее. Если говорю что законодательно установлено, так оно и есть. Впредь будьте сдержанней и осмотрительней. С уважением.

А теперь собственно ликбез:
1) все размерности ячеек устанавливаются контролирующими органами. Стандартном является формат ХМЛ.
Вся нормативка неплохо подобрана здесь: [opz.org.ua]

Собственно, интересными являются вот эти пункты:

Quote
1. Затвердити формат (стандарт) електронного документа звітності платників податків на основі специфікації eXtensible Markup Language (XML) (додаток 1).

2. Установити, що контроль електронних документів у XML-форматі здійснюється із застосуванням схем контролю XML-документів (XML-Schema). Схеми контролю XML-документів розробляються і поширюються для кожного конкретного документа звітності Державною податковою адміністрацією України або уповноваженою нею організацією.

3. Установити, що розробка електронних форм документів звітності та кодування відповідних полів документів здійснюється у форматі Adobe Portable Document Format (PDF). Електронні форми розробляються для кожного документа окремо.

2) Практической реализацией являются схемы, опубликованные на оффсайте налогвоой:
[ftp.sta.gov.ua]

3) Скачиваем J1201007.arg и открываем собственно, схему J1201007.PDF, видим нужное поле RXXXXG5, перходим к схеме J1201007.XSD, вот свойства нашего поля:

Quote
<xs:element name="RXXXXG5" type="Decimal6Column_R" nillable="true" minOccurs="0" maxOccurs="9999"/>

Дальше можно не смотреть, т.к. в имени типа поля уже видно, сколько символов может содержать:
type="Decimal6Column_R"
но для ликбеза некоторых особ, так и быть, пройдем до конца:
типы данных здесь: common_types.xsd
открываем его, находим тип данных Decimal6Column_R, видим:

Quote
<!--Загальний тип "Числові дані 6 знаки після коми спец"-->
<xs:complexType name="Decimal6Column_R">
<xs:simpleContent>
<xs:extension base="DGdecimal6_R">
<xs:attribute name="ROWNUM" type="rowInt" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>

И конечно вспоминаем, что незнание не освобождает от ответственности, b]tiger1[/b]...

Inkognito , будьте любезны , ведите себя как мужчина!-если Вы мужчина, не устраивайте разборок и выяснений отношений на форумах, и уж точно не приписывайте другим свои грехи и огрехи! И будьте внимательны к цифрам - 2009год - не 2012г.
Теперь по существу:
- Вы представляете контору фискальную-ТОВку ДФС или независимую? Фискальная не будет сопоставлять Закон и нормативные акты с требованиями фискалов -что сверху спустили-то она безоговорочно примет за истину, а если пользователи будут "брыкаться", "тыкать пальцами в Закон" - отсылает куда подальше, ей главное ,чтобы пиджачок не помялся! Что сделала бы независимая контора- она задала бы вопрос фискалам - ну, не сама по себе, а после обращений пользователей на актуальные темы,- в законе право/требование есть, а технически независимая и платная контора выполнить не может - что за бардак, давайте приводить технику в соответствие с вашими законами !!!!
То,что Вы потрудились изложить ниже - лишний раз доказывает ,что Медок не состыковывается с некоторой частью (прим.-немаловажной!) параграфов нормативки! Но Вы-то сами -ничего не сделали,чтобы этих несостыковок не было, ибо вам оно и не надо!!!ибо ни вы , ни кто-либо другой перед вами из этой же конторы, задач подобных и не ставил! намного легче, да и приятнее в 100раз (по вашему упоению из письма видно) пользователей выставлять этакими недалекими хамами...
И напоследок - был задан конкретный рабочий вопрос - на который был получен от вас хамский ответ, где по существу "0". Не хамите,когда не знаете, что ответить,уж лучше пропустите.

Quote
Inkognito
tiger1
Вы здесь новичёк, поэтому прощаю Ваше невежество и хамство. Когда попадаете на какой-либо форум, неплохо ознакомиться с его постоянными форумчанами, почитать их посты и все такое прочее. Если говорю что законодательно установлено, так оно и есть. Впредь будьте сдержанней и осмотрительней. С уважением.

А теперь собственно ликбез:
1) все размерности ячеек устанавливаются контролирующими органами. Стандартном является формат ХМЛ.
Вся нормативка неплохо подобрана здесь: [opz.org.ua]

Собственно, интересными являются вот эти пункты:

Quote
1. Затвердити формат (стандарт) електронного документа звітності платників податків на основі специфікації eXtensible Markup Language (XML) (додаток 1).

2. Установити, що контроль електронних документів у XML-форматі здійснюється із застосуванням схем контролю XML-документів (XML-Schema). Схеми контролю XML-документів розробляються і поширюються для кожного конкретного документа звітності Державною податковою адміністрацією України або уповноваженою нею організацією.

3. Установити, що розробка електронних форм документів звітності та кодування відповідних полів документів здійснюється у форматі Adobe Portable Document Format (PDF). Електронні форми розробляються для кожного документа окремо.

2) Практической реализацией являются схемы, опубликованные на оффсайте налогвоой:
[ftp.sta.gov.ua]

3) Скачиваем J1201007.arg и открываем собственно, схему J1201007.PDF, видим нужное поле RXXXXG5, перходим к схеме J1201007.XSD, вот свойства нашего поля:

Quote
<xs:element name="RXXXXG5" type="Decimal6Column_R" nillable="true" minOccurs="0" maxOccurs="9999"/>

Дальше можно не смотреть, т.к. в имени типа поля уже видно, сколько символов может содержать:
type="Decimal6Column_R"
но для ликбеза некоторых особ, так и быть, пройдем до конца:
типы данных здесь: common_types.xsd
открываем его, находим тип данных Decimal6Column_R, видим:

Quote
<!--Загальний тип "Числові дані 6 знаки після коми спец"-->
<xs:complexType name="Decimal6Column_R">
<xs:simpleContent>
<xs:extension base="DGdecimal6_R">
<xs:attribute name="ROWNUM" type="rowInt" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>

И конечно вспоминаем, что незнание не освобождает от ответственности, b]tiger1[/b]...

Про хамство tiger1 я би промовчала на
вашому місці - складаєцця враження шо кожен
бачить те шо хоче бачить...



Ну і що шо в голові вітер?!
Зате думки завжди свіжі!!!

Шустрик, я открыла тему-я ее и закрываю, если Вы не против, по сути здесь уже ничего не будет, кроме перетирания:Кто хам?-Я хам? .

Та заради Бога - шо бажаєте те і робіть...
Як кажуть - флаг вам в руки...



Ну і що шо в голові вітер?!
Зате думки завжди свіжі!!!

ну слава богу, третьего хама искать не надо

Quote
tiger1
Для правильного подсчета базы без НДС нужно ,чтобы кол-во знаков после запятой в "количестве" было более 6-ти!!!

столкнулась с такой же проблемой.
Прочитала всю переписку, но так и не поняла, можно ли настроить чтобы было больше 6-ти знаков в количественном показателе?
иначе арифметика не идет, получается расхождение на 0,02 грн.

К сожалению, - все осталось без изменений.