Предложение по оплате поставщику аванса

[glibs]

Цитата:

Сообщение от ppson

...
аксапта и по безналу не может планировать авансовые платежи
...

Планировать может :-)

См. cashflow forecast и LedgerCov.

Предложение по оплате не хочет делать.

На Микрософт нынче надежды минимальные. В последних планах гораздо больший упор делается на интерфейс и технологию, а не на функционал (как и в последних версиях окнонных операционных систем). Так что допишите, что вам нужно.

Я пока вижу только одну сложность. Предложение по оплатам строится не просто на основании "накладной" поставщика, а на основании одобренной "накладной". Для одобрения даже есть специальный функционал (альтернативный, и у нас многие им не пользуются).

Ощущаете в чем суть?

[ppson]

Цитата:

Сообщение от glibs

Планировать может :-)

См. cashflow forecast и LedgerCov.

Предложение по оплате не хочет делать.

ээээ glibs, луквавишь
Аксапта может планировать оплаты, но не предоплаты. Разве в условиях оплаты можно указать - оплатить за 10 дней до даты поставки .
И счета на оплату (точнее на предоплату, так как аксапта предусматривает только такие счета) никак в прогнозе ДДС не участвует.

[glibs]

Цитата:

Сообщение от ppson

...ээээ glibs, луквавишь ...

Ну что вы, отнюдь :-)

Цитата:

Сообщение от ppson

...
Аксапта может планировать оплаты, но не предоплаты. Разве в условиях оплаты можно указать - оплатить за 10 дней до даты поставки .
...

Может, может. Начиная с 3.0.

С вашим утверждением согласен, но в поле Оплатить до можно поставить любую дату. С графиками проблемы, а одну конкретную дату поставить можно. Легко. И будет вам прогноз предоплат.

Так что не смотря на то, что в Аксапте все сильно запущено, она все-таки не безнадежна. Просто неухожена, как дите. Микрософт для нее — мачеха.

Цитата:

Сообщение от ppson

...
И счета на оплату (точнее на предоплату, так как аксапта предусматривает только такие счета) никак в прогнозе ДДС не участвует.
...

Ну, счета на оплату в поставщиках писали локализаторы. В 1С cashflow forecast не было, вот и в Аксапту не срисовали. Задача "осмыслить и увязать...", судя по всему, перед постановщиками не стояла.

Но счетов на оплату м.б. много (они ведь не удаляются и не перепроводятся). И не по всем нужно платить. И все-равно счет могут оплатить частично. И как знать, по какому счету заплатили уже, а по какому нет? Так что в этой идее придется еще что-нибудь доделывать. Плюс есть ситуация, когда счет на оплату по поставщику есть, а закупки уже нет.

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

В общем, дурацкая это идея делать из Аксапты 1С. Это как из мальчика сделать девочку. Можно что-то где-то отрезать, что-то где-то нарастить, еще чего-то там сделать, но ведь детей рожать не сможет (природа у него другая, а против природы не попрешь — она отомстит).

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

[Alex_R2]

Цитата:

Сообщение от glibs

Ну что вы, отнюдь :-)

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

В общем, дурацкая это идея делать из Аксапты 1С. Это как из мальчика сделать девочку. Можно что-то где-то отрезать, что-то где-то нарастить, еще чего-то там сделать, но ведь детей рожать не сможет (природа у него другая, а против природы не попрешь — она отомстит).

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

))) замечен в любви к 1с в первый раз ))) Никогда ей не занимался и вряд ли буду...
Просто дело в том, что используя предложение по оплате, как минимум можно споставление ручное не проводить.
А начет : "Но счетов на оплату м.б. много (они ведь не удаляются и не перепроводятся). И не по всем нужно платить. И все-равно счет могут оплатить частично. И как знать, по какому счету заплатили уже, а по какому нет? "
ИМХО моно использовать такой же механизм как и для накладных в журналах регистрации накладных без разноски и последуещго их разнесения из другого журнала...
Зато до разноски можно было бы проводки помеченные к сопоставлению, а после разноски накладной по заказу они бы радосто слились в сопоставленнии...

[Pavel]

Цитата:

Сообщение от Alex_R2

Просто дело в том, что используя предложение по оплате, как минимум можно споставление ручное не проводить.

Действительно, хорошая функциональность для планирования денежных средств и расчетов с поставщиками (по фактурам, закупкам, поставщикам, валютам, с учетом времени оплат и кредитного лимита), она должна быть очень востребована при дефиците платежных средств и правильном их распределении. Однако, обработка авансовых платежей в российском учете имеет свою специфику (бух.проводки, порядок отражения в финансовой отчетности).

[Alex_R2]

Прошу прощения "за серость в фискальном учете" а какая специфика в бух проводке оплата аванса поставщику (она же предоплата))) ?

[Pavel]

Цитата:

Сообщение от Alex_R2

Прошу прощения "за серость в фискальном учете" а какая специфика в бух проводке оплата аванса поставщику (она же предоплата))) ?

Эта не только специфика "фискального учета", но и финансовой отчетности. При оплате товаров/услуг поставщика формируется проводка Д60 - К51, а при авансовом платеже система автоматически должна формировать проводку на выделенном субсчете 60", т.е. Д60" - К51. Затем при выполнении поставщиком обязательств, возникает кредиторская задолжность предприятия (проводка Д41 или 10 или 08 или 26 - К60), которая сопоставляется с суммой выплаченного раннее аванса. В момент сопоставления система автоматически должна делать проводку Д60 - К60" на сумму отработанного аванса.

В балансе суммы выплаченных авансов указываются в разделе активы нашего предприятия (со счета 60" по контрагентам), по гражданскому кодексу суммы выплаченных авансов принадлежат предприятию, до исполнения поставщиком своих обязательств, а в случае их не исполнения подлежат возврату.

Отдельная тема - Книга покупок, зачет отработанных поставщиком авансов приводит к факту погашения кредиторской задолжности и возможности возмещения НДС (проводка Д68 - К19).

Всю перечисленное относится к локализованной функциональности и никаким образом не отрабатывается в стандартной функции формирования предложений указанной glibs.

[glibs]

Цитата:

Сообщение от Alex_R2

...
замечен в любви к 1с в первый раз ))) Никогда ей не занимался и вряд ли буду...
...

На всякий случай уточню, что я вас ни в чем подобном не обвинял. Процитированный вами текст относится преимущественно к локализаторам и в какой-то мере к участнику ppson (за то, что он хочет закладываться в финансовом планировании на функциональность счетов на оплату в модуле Расчеты с поставщиками; аргументы есть в тексте).

Цитата:

Сообщение от Alex_R2

...
Просто дело в том, что используя предложение по оплате, как минимум можно споставление ручное не проводить.
...

М-м-м... ну это пока предложения по оплате работают на основании "накладной". В стандартной версии при вводе в журнал платежей платежа, его можно пометить на сопоставление с уже разнесенной "накладной". Это автоматически происходит при создании предложения на оплату.

Но если вы вводите в журнал платежей предоплату (накладной еще нет), то установить отметку на сопоставление ее... не с чем :-)

Возможность установить отметку на сопоставление появится только после того, как журнал будет успешно разнесен. При этом придется лезть в закупку.

Так что не в одних предложениях на предоплату тут дело. Для описанного вами эффекта функционал еще придется допиливать.

Но по отношению к бизнес-процессу регистрации ПКО и РКО, IMHO, предложения по оплате в общем случае не актуальны.

[Alex_R2]

Цитата:

Сообщение от glibs

Но если вы вводите в журнал платежей предоплату (накладной еще нет), то установить отметку на сопоставление ее... не с чем :-)

Возможность установить отметку на сопоставление появится только после того, как журнал будет успешно разнесен. При этом придется лезть в закупку.

Так что не в одних предложениях на предоплату тут дело. Для описанного вами эффекта функционал еще придется допиливать.

Дело в том что я хотел бы сопоставить платеж (аванс в частонсти) с ещё не разнесенной заупкой. Такая то возможность есть) Помеченное к сопоставлению повесит пока в spectrans, а когда накладная по закупке разнесется проводки окончательно сопоставятся. Вся функциональность в наличии есть, кроме предложения по оплате на основании разнесенных счетов на оплату (те предоплат)...о чем плачу горькими слезами

ЗЫ Глеб возможно задать Вам вопрос о способе оплаты с использоваением промежуточного счета, разумеется в соответвующей существующей ветке ?

[glibs]

Цитата:

Сообщение от Alex_R2

...
Дело в том что я хотел бы сопоставить платеж (аванс в частонсти) с ещё не разнесенной заупкой. Такая то возможность есть)
...

Если после разноски журнала платежей, то да. Но предложения по оплате устанавливают пометку на сопоставление еще при создании журнала (до разноски).

Так что мои слова остаются в силе.

Цитата:

Сообщение от Alex_R2

...
Помеченное к сопоставлению повесит пока в spectrans, а когда накладная по закупке разнесется проводки окончательно сопоставятся.
...

А если будет частичная поставка, куда денется ваш SpecTrans?

Цитата:

Сообщение от Alex_R2

...
Вся функциональность в наличии есть
...

А я говорю, что не вся... Но сделать можно. И это не очень сложно.

Цитата:

Сообщение от Alex_R2

...
кроме предложения по оплате на основании разнесенных счетов на оплату (те предоплат)...
...

Не факт, что это решение оптимальное.

Цитата:

Сообщение от Alex_R2

...
возможно задать Вам вопрос о способе оплаты с использоваением промежуточного счета, разумеется в соответвующей существующей ветке ?
...

Давайте попробуем.

[Maxim Gorbunov]

Цитата:

Сообщение от glibs

М-м-м... ну это пока предложения по оплате работают на основании "накладной".

Не совсем точно. Вообще-то, на основании проводки по поставщику.

Счет на оплату никакой проводки по поставщику не формирует, поэтому и сопоставлять не с чем платеж, который еще и непроведен (правильнее сказать, отметить для сопоставления не с чем).

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

Конечно, приходится при этом контролировать, чтобы не было счетов с одинаковыми номерами от одного поставщика. Но чем-то надо жертвовать

[glibs]

Цитата:

Сообщение от Maxim Gorbunov

...
Вообще-то, на основании проводки по поставщику.
...

Упс. Неправильно сформулировал мысль. Спасибо.

На самом деле предложения формируются по CustTrans'ам. Причем не только по проводкам по "накладным", но и по переплтам/авансам тоже.

Я имел в виду, что предложения по оплате в обычном режиме формируется по CustTrans'ам, которые созданы по "накладным" поставщиков.

Цитата:

Сообщение от Maxim Gorbunov

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

М-да... мы что-то подобное делали в модуле Расчеты с клиентами. Жаль только, что в стандартная версия по этому поводу "не чешется".

Да и еще. Раз уж на то пошло, то нужно было начать с того, что разработка счетов на оплату является проявлением недостаточной компетенции постановщиков задачи, т.к. счет на оплату по своей сути абсолютно ничем не отличается от Quotation, и по-сути его дублирует. Нужно было просто доделать печатную форму над quotation.

[glibs]

Цитата:

Сообщение от glibs

...
Я пока вижу только одну сложность. Предложение по оплатам строится не просто на основании "накладной" поставщика, а на основании одобренной "накладной". Для одобрения даже есть специальный функционал (альтернативный, и у нас многие им не пользуются).
...

Кажется, я уже передумал.

Мы на одном проекте закупки вводим через форму журнала закупок (Расчеты с поставщиками\Журналы\Закупки\Журнал закупок). Немного допилили, чтобы менеджеры не могли фильтр по полю Тип закупки изменить (в результате в этой форме менеджеры могут править только журналы). И форме создания строк пришлось немного "мозги вправить" (точнее кнопке, которая ее открывает). В "трацдиционной" форме закупок менеджеры могут смотреть, но ничего не могут редактировать. Те, кто утверждают (утверждение сводится к смене типа закупки с "Журнал" на "Закупка") работают в "традиционной форме" с правами на редактирование.

Так что утверждение сделать можно.

Осталось только допилить графики и функциональность предложений по оплате.

Опционально можно сделать, чтобы платеж по предложению по оплате по предоплате помечался на сопоставление с закупкой после разноски.

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

В результате с помощью финансовых отчетов можно делать оценку по показателям:
Статья............Бюджет..............Факт...........Утверждено в закупках...........Остаток

Например:
Реклама.........100.....................70...............20...........................................10

Расходы в отчет попадут по методу начислений... но все равно полезная табличка получится. "Утверждено в закупках" можно и по прогнозной дате оплаты развернуть. С финансовыми аналитиками нужно еще подумать.