Два invoice, один с нулевым количеством

[vazerdim]

Пытаюсь понять как лучше реализовать один из бизнес процессов компании в AX.

Что имеем:
1. Разносят Sales order на клиента, один invoice с ценой и кол-вом. К примеру:
Кол-во: 5
Цена: 100
Сумма: 500

2. Пока груз идет до клиента, может измениться цена на товар и компания хочет провести новый invoice на увеличение стоимости:
Стало:
Кол-во: 5
Цена: +5
Сумма: 25

Сейчас они делают следующим образом: сторнируют старый invoice и проводят новый с новой ценой, но это не решает вопрос с датами оплаты, invoice на +5 должен иметь свою дату оплаты, отличной от invoice на 100(у которой дата оплаты остается первоначальная).

Как вариант выхода из данной ситуации я вижу следующий:
1. Первый invoice на 100 мы не трогаем.
2. Проводим новый Free text invoice на +5, с новой датой оплаты.

Но бухгалтерии не нравится этот вариант, потому что для них Free text invoice, это исключительно разноска услуг.

Может я не прав? Может есть какой то другой вариант выхода из данной ситуации?

[ashu]

использовать корр фактуры на изменение цены? это первый вариант который приходит в голову.
кроме того что как то пересмотреть процесс

[vazerdim]

Счет-фактур тут нет, европейская AX.

[EVGL]

Цитата:

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

Как вариант выхода из данной ситуации я вижу следующий:
1. Первый invoice на 100 мы не трогаем.
2. Проводим новый Free text invoice на +5, с новой датой оплаты.

На моем текущем проекте делаем именно так.

[mazzy]

Цитата:

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

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

для этого в системе предусмотрен не один invoice, а несколько документов.
есть packing list (или как он сейчас называется)
и есть invoice

packing list - документ, который отвечает за переход прав на физическое количество.
packing list может содержать цены. но это так называемые "физические цены" или другими словами ориентировочные цены

invoice - документ, котрый отвечает за переход прав на финансовую составляющую товара.
invoice фиксирует суммы сделки.
количество в invoice может отличаться от количества в packing list на величину допустимого отклонения (по умолчанию допустимое отклонение отсутствует).

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

аксапта вполне допускает выписывать как один инвойс по нескольким packing list'ам, так и несколько разных инвойсов по одному packing list, а также по разному комбинировать.

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

таким образом,
сперва разносите packing list по Sales Order.
затем фиксируйте окончательные условия сделки инвойсами.

[trud]

Цитата:

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

таким образом,
сперва разносите packing list по Sales Order.
затем фиксируйте окончательные условия сделки инвойсами.

У нас кстати тоже используется подобный подход(первоначальный инвойс, далее он сторнируется, делается нормальный)
я как-то пытался выяснить почему так криво, но так и не понял
mazzy, а можно расписать не для консультантов, в чем твое предложение?
схема работы такая - клиенту выставляется инвойс (разносится Sales Invoice в АХ) далее он может или прислать деньги, или (что происходит часто) какие-то коррекции (в приведенном примере к примеру сумму перевозчика или сумму за таможню). при этом исходный инвойс сторнируется, создается новый с новыми суммами.

Ну т.е. Invoice Proforma и Packing slip не подходят, ибо они не создают задолжности по клиенту
Кроме этого нет какого-то момента Х, когда можно выставлять инвойс(и известно что больше коррекций не будет) и более того, все хотят видеть задолжность по клиенту сразу именно в момент отправки товара

[mazzy]

отличный вопрос.

Цитата:

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

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

1. регистрировать в системе только то, что известно
2. фиксировать аспекты сделки, происходящие во времени, различными документами в различные моменты времени.
3. перестать путать печатную форму с заголовком Invoice и документ, который фиксирует в системе сделку, и имеет название Invoice.
4. использовать функционал Аксапты. А для этого хотя бы почитать документацию. Хотя бы раздел Цепочка поставок.

В частности, стандартный функционал умеет:
= работать с цепочками документов, отличных от 1-к-1. Т.е. инвойс может быть выставлен по нескольким packing slip, а также по одному packing slip может быть выставлено несколько инвойсов. и так далее.
= работать с физической и финансовой стоимостью

Хинт:
= чтобы выдать клиенту ПЕЧАТНУЮ форму совсем не обязательно разносить этот документ. В аксапте можно создавать, например, подтверждение, в печатной форме которого будет написано Invoice. Правда в этом случает придется делать модификации, которые запрещают Аксапте создавать произвольные цепочки документов, а создавать документы 1-к-1. Но такой запрет сделать гораздо легче, чем сторнировать-модифицировать..

Цитата:

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

схема работы такая - клиенту выставляется инвойс (разносится Sales Invoice в АХ)

Сразу вопрос - зачем выставлять инвойс в этот момент?

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

Если нужно получить печатную форму, то для этого не нужно палить из пушки по воробьям и разносить именно инвойс. Можно получить инвойс-проформу, можно получить confirmation и так далее.

Цитата:

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

далее он может или прислать деньги

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

Цитата:

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

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

воооот!
что значит "коррекции" применительно к данному вопросу про задолженность?
это значит, что сумма задолженности клиента меняется?
это значит, что клиент должен что-то доплатить или мы должны вернуть?
а на основании чего происходит фиксация новой задолженности?

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


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

на ранних этапах можно зафиксировать оценку/accruals.
но не инвойс.

Цитата:

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

Ну т.е. Invoice Proforma и Packing slip не подходят, ибо они не создают задолжности по клиенту

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

Цитата:

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

Кроме этого нет какого-то момента Х, когда можно выставлять инвойс(и известно что больше коррекций не будет)

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

в реальной жизни всегда есть человек, который может сказать, что сделка завершена. это тот человек, который получает бонус за завершенные сделки ))))

Цитата:

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

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

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

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

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

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

примерно так.

[trud]

Цитата:

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

1. регистрировать в системе только то, что известно
Сразу вопрос - зачем выставлять инвойс в этот момент?

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

ну вот именно для этого его и выставляют, посчитать себестоимость, сделать задолжность и т.д. т.е. после этого мы ожидаем оплаты.

через месяц вместо оплаты можем получить что пришли результаты экспертизы, и зерно которое мы продали не класса А, а класса Б. инвойс перевыставляется
а можем и не получить

Цитата:

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

воооот!

что значит "коррекции" применительно к данному вопросу про задолженность?
это значит, что сумма задолженности клиента меняется?
это значит, что клиент должен что-то доплатить или мы должны вернуть?
а на основании чего происходит фиксация новой задолженности?

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

да, меняется инвойс. т.е. старый полностью сторнируется, новый создается(с новыми значениями)

[mazzy]

Цитата:

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

ну вот именно для этого его и выставляют, посчитать себестоимость, сделать задолжность и т.д. т.е. после этого мы ожидаем оплаты.

через месяц вместо оплаты можем получить что пришли результаты экспертизы, и зерно которое мы продали не класса А, а класса Б. инвойс перевыставляется
а можем и не получить


да, меняется инвойс. т.е. старый полностью сторнируется, новый создается(с новыми значениями)

как скажете

[mazzy]

Цитата:

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

Как вариант выхода из данной ситуации я вижу следующий:
1. Первый invoice на 100 мы не трогаем.
2. Проводим новый Free text invoice на +5, с новой датой оплаты.

Ужос, нах.

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

[EVGL]

Цитата:

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

Ужос, нах.

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

Конечно теряем. Но это проблема не сколько процесса, сколько системы, в которой это не предусмотрено. Аналогичная ситуация в закупках решена только в русской локализации. Так что отчет "структура стоимости" (хм, "стоимости"?) делаем по аналитике "cost purpose" = номер продукта в модуле Cost Accounting.

Я проводил тренинг для конечных пользователей в России для формирования корректировочных фактур в условиях отгрузки по палетам, партиям и/или серийным номерам, спасибо: вероятность сделать ошибку и породить еще одну пару сторнировочных проводок - это где-то 50:50 даже для образованного пользователя типа меня.

Что касается длинного поста перед этим, то packing slip невозможно оплатить, как вы знаете, и в стандарте он не содержит цен. Почему счета выставляются до момента перехода права собственности - это вопрос к автору темы. Солидаризуясь с автором, я замечу, что так делают сплошь и рядом, поскольку процесс отслеживания товара в условиях доставки типа DAP в системе [Dynamics 365 fFO EE] технически почти не поддерживается (опять-таки кроме России и "отложенного перехода права собственности" или TMS с уведомлениями о местонахождении груза - опять все вручную) и почти всегда реализуется как-то вовне системы.

[mazzy]

Цитата:

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

Но это проблема не сколько процесса, сколько системы, в которой это не предусмотрено.

да, ну?

Цитата:

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

Аналогичная ситуация в закупках решена только в русской локализации.

му-ха-ха-ха!!!

Цитата:

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

Что касается длинного поста перед этим, то packing slip невозможно оплатить, как вы знаете, и в стандарте он не содержит цен.

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

но документ packing slip цены таки содержит.

Цитата:

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

Почему счета выставляются до момента перехода права собственности - это вопрос к автору темы.

потому что до перехода прав собственности этот документ называется invoice proforma. в россии аналогом является счет на оплату.

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

особенность аксапты - этот документ не имеет номера.

Цитата:

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

Солидаризуясь с автором, я замечу, что так делают сплошь и рядом, поскольку процесс отслеживания товара в условиях доставки типа DAP в системе [Dynamics 365 fFO EE] технически почти не поддерживается

Му-ха-ха-ха...
Бедные разработчики целого модуля доставки... Они отчитались еще для акс2012...

[EVGL]

Цитата:

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

Му-ха-ха-ха...
Бедные разработчики целого модуля доставки... Они отчитались еще для акс2012...

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

• в TMS есть таблица для отслеживания, но никаких штатных средств, чтобы ее заполнять. Стало быть, процесс информирования продаж о достижении точки "Сингапур" не автоматизирован.
• проформа-инвойс - один из способов решения проблемы. Отсутствие номера - это "особенность", которую приходится учитывать и исправлять.
• другой способ решения проблемы - это печатать цены в особой печатной форме на базе таблицы Packing slip, этот подход используем на текущем проекте. Неприятность в том, что цен там нет даже физически в таблице, они заполняются только в польской и русской локализации, если не ошибаюсь.

[ashu]

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

[ashu]

если говорить с точки зрения возможной реализации- из серии пофантазировать. а если разницу в ценах отражать через ГК и привязывать затем через накладные расходы к накладной по реализации?

[mazzy]

Цитата:

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

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

Может просто документацию наконец прочитать?
Это базовые механизмы Аксапты.

Цитата:

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

может кто то примет за офтоп, но только меня смущает:
прошла отгрузка товара, по какой то цене.

"по какой-то цене" - лишнее.
может просто произойти отгрузка товара.
например, передали количество, но не передали права собственности.
или например, передали количество по оценочной стоимости.

так вот, на такие случаи в Аксапте как раз и существуют несколько разных документов в Аксапте.

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

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

на этом была, есть и будет аксапта.
эти механизмы исопльзуются не только в продажах, но и в производстве (план/факт), и в модуле проекты.

собственно вся аксапта, это обвязка вокруг физического, финансового и их расхождений.

Цитата:

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

мы потом в одностороннем порядке меняем цену отгрузки (или по соглашению с клиентом)?

это не так малешко.

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

а вот если с покупателем более хитрые условия. например, дополнительные скидки в зависимости от выбранного за период объема. или за отчетный период клиента перевели в другую колонку прайс-листа. или рибейт. или какие-нибудь другие условия, которые становятся известны ПОСЛЕ физической поставки. например, широко известное условие "бери или плати" для поставок газа.

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

то тогда и возникают отличия между условиями поставки и финансовыми условиями. в этом случае инвойсы (финансовые документы) выписываются сильно позже. в этом случае в качестве сопроводительных к товару документов выступают НЕ инвойсы (как бы их не называли). В аксапте такой документ называется packing slip (я таки посмотрел в систему). Документ содержит передаваемое количество и оценочную сумму.

Цитата:

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

как по мне- если прошла отгрузка- значит есть какой то договор- или договор "шапочный" без цен и сумм?

Какой-то - это правильное слово.
Договор может не содержать конкретных сумм.
Договор может не содержать конкретных количеств.

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

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

А для работы с физической и финансовой составляющей при продажах, в Аксапте предусмотрены документы packing slip и invoice соответственно.

[potential]

Цитата:

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

Но бухгалтерии не нравится этот вариант, потому что для них Free text invoice, это исключительно разноска услуг.

вариант с оприходованием 10 шт вместо 5 шт вряд ли понравится складу

Цитата:

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

это не решает вопрос с датами оплаты, invoice на +5 должен иметь свою дату оплаты, отличной от invoice на 100(у которой дата оплаты остается первоначальная).

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

[vazerdim]

Цитата:

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

вариант с оприходованием 10 шт вместо 5 шт вряд ли понравится складу

в Free text invoice нет кол-ва, модуль запасов мы не затрагиваем.

[mazzy]

Цитата:

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

invoice на +5 должен иметь свою дату оплаты, отличной от invoice на 100(у которой дата оплаты остается первоначальная).

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

для каждой проводки custTrans можно создать несколько открытых проводок custTransOpen.

это было так во всех версиях аксапты.
руками можно рассплитить открытую проводку в форме сопоставления (см. скриншот)

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

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

[EVGL]

Цитата:

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

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

для каждой проводки custTrans можно создать несколько открытых проводок custTransOpen.

это было так во всех версиях аксапты.
руками можно рассплитить открытую проводку в форме сопоставления (см. скриншот)

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

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

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