Комментарии
Избранное
Подписка
Сортировка:
Древо
Задумка хорошая, но сделана как-то "на скорую руку". Рекомендую довести до ума следующим образом:
1. Сделать чёткую иерархию по уровням субконто (Контрагент -> Договор) с агрегацией данных в отдельных строках.
2. Вместо статуса выводить сумму остатка. Если остаток не равен нулю, то, очевидно, что аванс не закрыт и наоборот: если равен нулю, то, столь же очевидно, что аванс закрыт.
3. В заголовке надо обязательно выводить дату отчета, иначе он вообще теряет какой бы то ни было смысл.
4. Отработать предложение (5) с обязательным указанием номера бухгалтерского счета и валюты цены договора (в отдельных колонках). В идеале суммы по каждой задолженности надо выводить в две строки: в валюте цены договора и в рублях.
Предложение (9) весьма разумное, но под него лучше сделать отдельный отчет, целью которого была бы именно выверка НДС посредством сопоставления дебиторки-кредиторки с суммами НДС. Алгоритм будет "тяжелее" на ставки НДС и на револьверные разборы частичного погашения авансов "N в M".
1. Сделать чёткую иерархию по уровням субконто (Контрагент -> Договор) с агрегацией данных в отдельных строках.
2. Вместо статуса выводить сумму остатка. Если остаток не равен нулю, то, очевидно, что аванс не закрыт и наоборот: если равен нулю, то, столь же очевидно, что аванс закрыт.
3. В заголовке надо обязательно выводить дату отчета, иначе он вообще теряет какой бы то ни было смысл.
4. Отработать предложение (5) с обязательным указанием номера бухгалтерского счета и валюты цены договора (в отдельных колонках). В идеале суммы по каждой задолженности надо выводить в две строки: в валюте цены договора и в рублях.
Предложение (9) весьма разумное, но под него лучше сделать отдельный отчет, целью которого была бы именно выверка НДС посредством сопоставления дебиторки-кредиторки с суммами НДС. Алгоритм будет "тяжелее" на ставки НДС и на револьверные разборы частичного погашения авансов "N в M".
При работе бухгалтерии могут образовываться остатки не закрытые по тем или иным причинам автоматическими проводками, также могут возникать ошибки в связи с разнесением аванса и основной задолженности по разным договорам, т.е. развернутое сальдо в балансе будет отражатся неверно.
Данная программа выбирает только тех контрагентов у которых есть по тем или иным причинам ситуации незакрытых авансов, что более удобно чем работать со стандартной ОСВ
В стандартной ОСВ если задавать счет первого уровня то сальдо показывается свернуто и не видно по каким контрагентам возникла данная ситуация. Можно конечно выдавать две ОСВ одну например по 62.1 а вторую по 62.2 и сравнивать либо вручную либо с помощью дополнительных программ, что не очень удобно. Кроме того при работе со стандартной ОСВ нет возможности автоматически выбрать именно данный вид ошибки и следовательно выдается полный список всех контрагентов, что тоже не очень удобно.
Данная программа выбирает только тех контрагентов у которых есть по тем или иным причинам ситуации незакрытых авансов, что более удобно чем работать со стандартной ОСВ
В стандартной ОСВ если задавать счет первого уровня то сальдо показывается свернуто и не видно по каким контрагентам возникла данная ситуация. Можно конечно выдавать две ОСВ одну например по 62.1 а вторую по 62.2 и сравнивать либо вручную либо с помощью дополнительных программ, что не очень удобно. Кроме того при работе со стандартной ОСВ нет возможности автоматически выбрать именно данный вид ошибки и следовательно выдается полный список всех контрагентов, что тоже не очень удобно.
Удивительно. Явно слабый и по задумке и по реализации отчет столь популярен,
а целая группа аналогичных по назначению отчетов (в демо варианте - 20):
никому не интересна. Почему?
Почему этот отчет слаб по содержанию? Потому что при работе "от документа"
проблемы отсутствия зачета аванса решаются перепроведением
документов, и именно к этому нужно приучать пользователей. Тем более, что регламентное проведение документов нужно также для правильного расчета себестоимости ТМЦ, обнаружения ряда ошибок типа путаницы с субсчетами учета
ТМЦ и т.п.
Почему этот отчет слаб по реализации? Коротко. Если отчет строится по одному контрагенту нельзя выполнять запрос по всем контрагентам, да еще потом
обрабатывать результат запроса в цикле "до упора", т.е. продолжать цикл даже
после того, когда нужная запись уже найдена. Это грубая ошибка.
Что называется, ничего личного. Просто хочется понять, почему так происходит.
а целая группа аналогичных по назначению отчетов (в демо варианте - 20):
никому не интересна. Почему?
Почему этот отчет слаб по содержанию? Потому что при работе "от документа"
проблемы отсутствия зачета аванса решаются перепроведением
документов, и именно к этому нужно приучать пользователей. Тем более, что регламентное проведение документов нужно также для правильного расчета себестоимости ТМЦ, обнаружения ряда ошибок типа путаницы с субсчетами учета
ТМЦ и т.п.
Почему этот отчет слаб по реализации? Коротко. Если отчет строится по одному контрагенту нельзя выполнять запрос по всем контрагентам, да еще потом
обрабатывать результат запроса в цикле "до упора", т.е. продолжать цикл даже
после того, когда нужная запись уже найдена. Это грубая ошибка.
Что называется, ничего личного. Просто хочется понять, почему так происходит.
(18)
А в чем халява? У нас 20 отчетов, на каждый из них никаких ограничений. Ограничение демо-версии только в том, что в
каждый момент времени можно использовать один, а не все 20
сразу. Это равносильно тому, что вы скачали бы двадцать отчетов
с инфостарта и запускали бы их поочереди. Код закрыт? Так код
этого отчета никакой ценности не представляет.
А в чем халява? У нас 20 отчетов, на каждый из них никаких ограничений. Ограничение демо-версии только в том, что в
каждый момент времени можно использовать один, а не все 20
сразу. Это равносильно тому, что вы скачали бы двадцать отчетов
с инфостарта и запускали бы их поочереди. Код закрыт? Так код
этого отчета никакой ценности не представляет.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.