Вопрос по счетам на оплату поставщикам

[sergey_alekseev]

Привет всем!
Ах3.0 Вопрос заключается в следующем.
При отгрузке товара со склада поставщика, возникает задолженность. До оприходования на складе покупателя закупка меняет свои статусы, может неоднократно изменится, и даже не прийти вовсе, но задолженность должна сохранится.
По моему полный бред. Пытались решить с помощью счета на оплату. Но по закупке я могу выписать бесконечное количество Счетов на оплату и даже с одним и тем же номером.
Как решить вопрос, хотябы не по задолженности на 60 счете (без формирования проводок в ГК), а в виде информации к оплате поставщику которую можно просмотреть неким запросом или отчетом. Условие: Действие однозначно определяет задолженность (необходимость оплаты поставщику)???
Лучше без каких либо ДОРАБОТОК. Хотя........
Заранее всем спасибо!

[EVGL]

Дело - дрянь. Без доработок эту проблему решать не удается. Колумбус в свое время целый модуль написал. Еще хуже: все доработки получаются неполноценными, поскольку задача слишком громоздкая и на Аксапту ложится плохо. Делают так:

- выписывают и разносят счет на оплату и одновременно ставят какой-то маркер на строки закупки, чтобы не выписывать счет на оплату повторно. Если делать хорошо, то надо не просто ставить маркер, но еще и запоминать суммы, чтобы при изменении суммы в строке иметь возможность создать еще один счет на оплату на "дельту" и т.д. и т.п.

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

- а потом напрашивается функция, которая дает генерировать накладные по закупке на базе зарегистрированных счетов на оплату. Еще работа программисту на неделю-две.

[mazzy]

ну... EVGL, не нахо хвататься за шашку сразу.

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

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

[glibs]

Цитата:

Изначально опубликовано sergey_alekseev
...При отгрузке товара со склада поставщика, возникает задолженность. До оприходования на складе покупателя закупка меняет свои статусы, может неоднократно изменится, и даже не прийти вовсе, но задолженность должна сохранится.

По моему полный бред...

Абсолютно точно!

Вы же, наверное, знаете, что Аксапта является непримиримым врагом схем а-ля "продали, а потом передумали и не продали" или "отгрузили одному, а потом передумали и оформили отгрузку на другого" или количество поменяли, или цены, или, например, "пришли деньги в кассу, а потом бац... и не пришли". Такие вещи делаются только через сторно.

Цитата:

Изначально опубликовано sergey_alekseev
...Хотя...

Переделывать вам придется полцарства, пардон, полаксапты. А то и всю.

Главное, результат достоверно известин уже сейчас...

Если автоматизировать бардак, то получится автоматизированный бардак.

Если автоматизировать полный бред, то...

Цитата:

Изначально опубликовано sergey_alekseev
...Как решить вопрос, хотябы не по задолженности на 60 счете (без формирования проводок в ГК), а в виде информации к оплате поставщику которую можно просмотреть неким запросом или отчетом. Условие: Действие однозначно определяет задолженность (необходимость оплаты поставщику)???...

Честно говоря, ничего не понял. Если уточните, то подумаю (если будет что сказать — напишу)...

Цитата:

Изначально опубликовано sergey_alekseev
...но задолженность должна сохранится...

Можно "попробовать" регистрацию инвойсов с разноской, но нужно прояснить задачу...

[EVGL]

Регистрация инвойсов им не пойдет, поставщик хочет предоплату, но реально задолженности еще нет. А регистрация накладных сразу жа на первом этапе создает кредиторскую задолженность.
Маззи хорошую мысль подал: заводить эти "счета на оплату" как бюджетные проводки или вносить их в прогнозы покупок в сводном планировании, чтобы потом отразить в прогнозе движения по счету ГК. Только последняя фраза непонятна: если "в разноске поставщика указать в качестве счета закрытия прогнозный субсчет", то тогда в прогнозе будет показана "оплата", которой реально еще не было. В любом случае, надо еще не забывать стирать эти проводки (опять вручную) после оплаты (или регистрации накладной?).

*) Черт, только сейчас вчитался: "возникает задолженность". В голову прийти не могло. Тогда все не так.

[sergey_alekseev]

Всем прочитавшим и особенно ответившим огромное СПАСИБО. Очень интересен момент с прогнозным счетом. Есть направления подумать, Еще раз Мерси.

[glibs]

To EVGL:

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

То, что в Аксапте человеческого решения для предоплат в стандартной функциональности не реализовать, полностью согласен.

Кстати. Пользуясь случаем хотелось бы спросить, а на счетах на оплату в поставщиках почему не сделали возможность их "попадать" в предложения по оплатам? ...Хотя нет. Хорошо, что не трогали. А то и предложения по оплатам работать перестанут по-человечески... И поле "оплатить до" в счетах на оплату поставщиков как-то не так, как везде, используется...

[EVGL]

Цитата:

Изначально опубликовано glibs
Пользуясь случаем хотелось бы спросить, а на счетах на оплату в поставщиках почему не сделали возможность их "попадать" в предложения по оплатам?

Хороший вопрос. И я на него в первом reply ответил. Сделал этот счет на оплату, попробовал его подключить к предложениям по оплате и только тут увидел упомянутые три НО. Лучше было оставлять как есть, чем создавать второпях паллиатив, который идеально работать принципиально не сможет. Зато теперь у партнеров есть официальная таблица "счетов на оплату поставщиков", на которую можно навешивать частные решения общей проблемы.

P.S. Да нет, это я, кажется, стал плохо понимать по-русски.

[mazzy]

Цитата:

Изначально опубликовано EVGL
заводить эти "счета на оплату" как бюджетные проводки или вносить их в прогнозы покупок

Не бюджетные и не прогнозы закупок.
А прогноз движения средст на бух.счетах.
Главная книга \ План счетов \ Настройки \ Прогноз движения средств

Тогда и последняя фраза станет понятной

Цитата:

Изначально опубликовано EVGL
Черт, только сейчас вчитался: "возникает задолженность". В голову прийти не могло. Тогда все не так.

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

[glibs]

Цитата:

Изначально опубликовано EVGL
...Хороший вопрос. И я на него в первом reply ответил...

Упс... теперь я протормозил. Точнее, о другом думал, когда читал...

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

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

"напрашивается функция, которая дает генерировать накладные по закупке на базе зарегистрированных счетов на оплату" — это не понял. А как же склад? А как же фактическое движение материалов? А как же модуль "Управление складом"? ...Хм...

[EVGL]

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

2. Плохо выразился. Просто переписать там все придется к чертовой матери.

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

[glibs]

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

2. Наверное, я не знаю, что счета на оплату поставщиков реализованы на том же классе, который используется для счетов на оплату клиентов, который теоретически даже мог делать Колумбус, когда я еще был маленьким? Ну или что-то в этом роде? Ладно, это не важно. Проехали...

3. Не понял. По-моему вы все усложняете. Считаю вполне нормальным текущий механизм сопоставления инвойсов/накладных с предоплатами. Ссылаться на документы, которые ни нас, ни поставщиков ни к чему не обязывают... Хм...

"...Ведь предоплату удобно пользователю соотносить со счетом на оплату..." — ну разве что для того, чтобы снова по ней не генерить предложения по оплате... Так ведь в функциональности по предложениям по оплате ее можно было бы "погасить" в рамках механизма контроля. А накладную потом можно будет через предоплату со счетом на оплату сопоставлять, раз уж вам так этого хочется. Но только на что это будет похоже, если по счету на оплату будет, например, два платежа? Или переплата?