УНФ, версии 1.1.5.2, 1.2.2.3
Отчеты Расчеты с покупателями / Расчеты с поставщиками / Взаиморасчеты

Расчет итогов - только Движения, в СКД-запросе ДвиженияИГраницы не использованы.

Результат - неверные начальные и конечные остатки по группировкам, получатели отчетности в шоке и трепете, сверка расчетов невозможна.

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

Вопрос в студию:
Как можно было не заметить таких проблем при текущем номере релиза 1.2.2.3? Или это "не баг, а фича"? Кто-то копался?

фича

только Движения стоит везде

Это видно, что везде. Непонятно зачем. Ведь с границами отрабатывает гораздо естественнее.

При попытке объяснить управленцу и самому себе смысл отчета о взаиморасчетах с контрагентами за период, в котором начальные и конечные остатки считаются только для полей попавших в период сломало мне мозг. На вопрос "А зачем?" ответа не нашлось :)

Дальше больше. Используем механизм зачета предоплат. Опа-па, обороты в отчетах по контрагентам удваиваются. Как же так? Все просто, оказывается. Есть вид движения Аванс и есть Долг. Начислили аванс - Приход Аванс. Отгрузили товар - Расход Аванс, Расход Долг, Приход Долг. Вроде все логично, ровно до вопроса а как же посчитать оборот по контрагенту? А никак, отвечает нам УНФ. Или отбирайте и смотрите только  авансы, или только отгрузки, третьего не дано.

Мне вот интересно, за УНФ явно просматривается некая методика ведения упр.учета, необычная для наших просторов (судя по тем же Движения без границ). Где бы получить список литературы по упр. учету, которым разработчики руководствовались? Может надо управленцев просветить сирых, что не нужна им вовсе сверка взаиморасчетов в разрезе регистраторов или сумма оборота с контрагентом за период?

я для себя решил авансы только зачитывать только в документах оплат, двоение не происходит. Написал регл.задание и забыл про них.

все механизмы именно для небольшой фирмы, у которой мало и сотрудников и документов. Понимание механизмов у пользователей по сравнению с УПП на порядок лучше и обучение происходит быстрее. При всем при этом конфигурация не должна составлять конкуренции более дорогим и зрелым решениям.

(5) сверку взаиморасчетов конечно в небольшой фирме надо делать заполняя суммы документов вручную в разлинееной тетрадочке, поглядывая в журнал документов :)

Я не ругаюсь, мне нравится концепция УНФ, действительно удобно, действительно пользователи начинают работать "с лёту". И если то, что сделано есть не грубые  ляпы, а "затычки", чтобы не уронить продажи КА (внедрение которой есть страшный сон для небольшого до среднего торгового предприятия) - то ситуация можно сказать терпимая. Как обычно в 1С - после покупки упорно дорабатывать напильником.

(4) Регл.задание корректирующее документы оплат задним числом? Снимает галку аванса и проставляет документ отгрузки "в будущее"? А как с обменом с БП в этом случае, полетит же все?

и сверку сделал, а выгрузка типовая не нужна

saaken!
1. А если предоплата в мае 2010 г., а поступление товара (услуг) в ноябре 2010 г. Как документом оплаты закрыть аванс?
2. Если не секрет, что это за такое регл. задание, что авансы закрывает?

1. Главное сам факт, что аванс закрылся. Напомню - программа остатки контролирует без дат.
2. Пример для расчетов с покупателями

Процедура ЗачетАвансов() Экспорт
   Запрос = Новый Запрос;
   Запрос.Текст =
       "ВЫБРАТЬ
       |    ПокупателиОстатки.Контрагент КАК Контрагент,
       |    ПокупателиОстатки.Договор КАК Договор,
       |    ПокупателиОстатки.Документ КАК Документ,
       |    ВЫБОР
       |        КОГДА ПокупателиОстатки.ТипРасчетов = ЗНАЧЕНИЕ(Перечисление.ТипыРасчетов.Аванс)
       |            ТОГДА ПокупателиОстатки.СуммаОстаток
       |        ИНАЧЕ 0
       |    КОНЕЦ КАК СуммаАванса,
       |    ВЫБОР
       |        КОГДА ПокупателиОстатки.ТипРасчетов = ЗНАЧЕНИЕ(Перечисление.ТипыРасчетов.Долг)
       |            ТОГДА ПокупателиОстатки.СуммаОстаток
       |        ИНАЧЕ 0
       |    КОНЕЦ КАК СуммаДолга,
       |    ПокупателиОстатки.Документ.Дата КАК ДокументДата
       |ИЗ
       |    РегистрНакопления.РасчетыСПокупателями.Остатки КАК ПокупателиОстатки
       |
       |УПОРЯДОЧИТЬ ПО
       |    Контрагент,
       |    Договор,
       |    ДокументДата";

   Результат = Запрос.Выполнить();

   ВыборкаДокумент = Результат.Выбрать();                              
   Пока ВыборкаДокумент.Следующий() Цикл
       Если ТипЗнч(ВыборкаДокумент.Документ) = Тип("ДокументСсылка.ПоступлениеНаСчет") или
           ТипЗнч(ВыборкаДокумент.Документ) = Тип("ДокументСсылка.ПоступлениеВКассу")
           Тогда            
           ЗаполнитьДокументПостНаСчет(ВыборкаДокумент.Документ);                
       КонецЕсли;        
   КонецЦикла;                                                            
КонецПроцедуры

Функцию "ЗаполнитьДокументПостНаСчет" вышлю за доп.плату :))

saaken спасибо!
Похоже к работе с УНФ надо не совсем стандартно подходить.
По моему мнению за УНФ неплохое будущее. Закрытие авансов и "удвоенные" обороты напрягали. Еще раз спасибо за подсказку.

Все таки не совсем хорошо. Если закрытие авансов производить только документами оплаты, то регистрация дохода по регистру "Доходы и расходы. Кассовый метод" производится на дату документа оплаты. Что есть плохо. Получается, что правильные обороты получить нельзя?

унф - хавно...

(12) Я не пошел по пути (9). Пошел вот так:

1. Поменял в конфе контроль на момент документа.
2. Поменял знаки и вид движения при проведении приходных и расходных документов по регистрам расчетов с покупателями таким способом:

1. Получение предоплаты
Аванс Расход Сумма
2. Отгрузка
Аванс Расход -Сумма
Долг Приход Сумма
Долг Расход Сумма

Аналогично по поставщикам. Получил верные обороты и работающую систему зачетов. Осталось прикрутить фичу автозачета по тем контрагентам где нужно и можно жить. По остальным отчетам собираюсь разбираться по мере внедрения.

(14) А, забыл, таки еще поставил ДвиженияИГраницы в отчетах по расчетам