AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 02.11.2017, 18:03   #21  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
То, что вы называете противоречием, в реальной жизни называется "внешнеэкономическая деятельность".
Не, противоречие всего лишь в вашей формулировке.
В реальной жизни противоречия нет.


Цитата:
Сообщение от Napalm Посмотреть сообщение
Вообще один Sales Order может иметь несколько Invoice-ов.
может.
мало того, один Sales Order "может иметь" несколько других Sales Order'ов )))

Цитата:
Сообщение от Napalm Посмотреть сообщение
И если цена меняется, то в Sales Order можно добавить еще одну линию (или несколько) для разницы в цене (используя как вариант специальный Item, Category, Service) и сделать для нее свой Invoice.
можно.
но это будет другая "линия", с другим лотом
и с другой историей одобрения/контроля.
под другую линию система будет планировать другое пополнение склада.
под другую линию система будет ожидать прихода других денег.

в общем, печать таким способом "вылечить" конечно можно.
но при этом будет безнадежно убита система планирования и контроля. а мощная аксапта превратится в тыкву.
https://youtu.be/ju5gQaBEsH8?t=5m31s

Цитата:
Сообщение от Napalm Посмотреть сообщение
Для этого надо будет разработать соответствующую модификацию.
ну... модификации то можно и похитрее придумать.


Цитата:
Сообщение от Napalm Посмотреть сообщение
Если без модфикаций - линию надо добавлять заранее, так сказать на всякий случай.
му-ха-ха-ха!!!
Ребяты, жжоте!
__________________
полезное на axForum, github, vk, coub.
Старый 02.11.2017, 18:12   #22  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
Не, противоречие всего лишь в вашей формулировке.
В реальной жизни противоречия нет.
Есть. Если таможенная стоимость исчисляется как 5% от стоимости в счете, а стоимость по контракту фиксируется после прохождения границы, то противоречие есть. А если стоимость от экспедитора включает доставку до Сингапура, а таможня - в Амстердаме, то помимо противоречия есть еще и невозможность вычленить доставку до границы без дополнительной информации.
Старый 02.11.2017, 18:27   #23  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
Господа вы, упорно делаете вид, что не понимаете вопроса, пытаясь подобрать лишенное экономического смысла техническое решение. Проблема в том, что в момент отгрузки продавец не знает цены товара, когда он придет в Сингапур 3 недели спустя. Как в систему занести информацию, которая принципиально не существует? При этом если не выставлять счет, то этот товар никогда не пройдет таможню, например.
Цитата:
Сообщение от EVGL Посмотреть сообщение
Есть. Если таможенная стоимость исчисляется как 5% от стоимости в счете, а стоимость по контракту фиксируется после прохождения границы, то противоречие есть. А если стоимость от экспедитора включает доставку до Сингапура, а таможня - в Амстердаме, то помимо противоречия есть еще и невозможность вычленить доставку до границы без дополнительной информации.
блин, вот все же у всех перед глазами.
Как лихо исчезло условие "в момент отгрузки" ))))

В момент отгрузки продавец и не должен знать цену товара.
фактические 5% от стоимости в счете исчисляется в таможне, а не "в момент отгрузки" ))))

оценочную величину 5% в момент аксапта вполне может прикинуть по физической стоимости. )))

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

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

=======================
повторюсь, в аксапте есть физическая и финансовая стоимости.
Если стоимость меняется со временем, то так или иначе задачу надо сводить к этим понятиям.
Для процесса продажи в аксапте предусмотрены документы Packing slip и invoice для работы с физической и финансовой стоимостью.

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

Не надо насиловать девушку. Она сама даст что вам надо.
Просто хотя бы прочитайте документацию наконец то!
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 02.11.2017 в 18:30.
Старый 02.11.2017, 18:29   #24  
Napalm is offline
Napalm
Участник
 
80 / 88 (3) ++++
Регистрация: 23.05.2012
Цитата:
Сообщение от mazzy Посмотреть сообщение
может.
мало того, один Sales Order "может иметь" несколько других Sales Order'ов )))
См. первый пост о бизнесс процессе - один Sales Order, два Invoice-а.

Цитата:
Сообщение от mazzy Посмотреть сообщение
можно.
но это будет другая "линия", с другим лотом
и с другой историей одобрения/контроля.
под другую линию система будет планировать другое пополнение склада.
под другую линию система будет ожидать прихода других денег.

в общем, печать таким способом "вылечить" конечно можно.
но при этом будет безнадежно убита система планирования и контроля. а мощная аксапта превратится в тыкву.
https://youtu.be/ju5gQaBEsH8?t=5m31s
Подумайте о том, что я имел ввиду под "специальный Item, Category, Service" и как это может быть связано с лотом, складом и сводным планированием.

Цитата:
Сообщение от mazzy Посмотреть сообщение
ну... модификации то можно и похитрее придумать
Придумайте похитрее и поделитесь.

Цитата:
Сообщение от mazzy Посмотреть сообщение
му-ха-ха-ха!!!
Ребяты, жжоте!
С клиентами также общаетесь?
Старый 02.11.2017, 18:35   #25  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Napalm Посмотреть сообщение
См. первый пост о бизнесс процессе - один Sales Order, два Invoice-а.
да-да... вы правы, конечно. это я extra-информацию выдал. )
в исходном запроса на эту информацию не было

Цитата:
Сообщение от Napalm Посмотреть сообщение
Подумайте о том, что я имел ввиду под "специальный Item, Category, Service" и как это может быть связано с лотом, складом и сводным планированием.
да-да. а также о контроле, об аппрувах продаж, о планировании денежных средств (это я уже говорил)
а также об агентских вознаграждениях и комиссионной торговле.

подумайте - это очень правильный совет.


Цитата:
Сообщение от Napalm Посмотреть сообщение
Придумайте похитрее и поделитесь.
Уже придумано. Уже реализовано. Ни в коем разе не буду делиться. Контроль изменения стоимости и себестоимости. Тем более на границе... Это очень чувствительные и интимные области.
И да! Ни у одного из моих клиентов таких вещей никогда не было, конечно.

Цитата:
Сообщение от Napalm Посмотреть сообщение
С клиентами также общаетесь?
С какой целью интересуетесь?
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 02.11.2017 в 18:37.
За это сообщение автора поблагодарили: EVGL (-3).
Старый 02.11.2017, 18:40   #26  
Lemming is offline
Lemming
Участник
Аватар для Lemming
 
1,144 / 343 (14) ++++++
Регистрация: 20.04.2004
Адрес: Москва, Чайнатаун в Люблино
Записей в блоге: 10
;)
Цитата:
Сообщение от mazzy Посмотреть сообщение
С какой целью интересуетесь?
Простите, не удержался: Свидетели Иеговы, позвонившие в квартиру пьяного преподавателя философии, приняли ислам прямо возле домофона.
За это сообщение автора поблагодарили: mazzy (2).
Старый 02.11.2017, 21:00   #27  
mnt_dx is offline
mnt_dx
Участник
Axapta Retail User
Лучший по профессии 2014
 
1,744 / 188 (10) ++++++
Регистрация: 17.02.2011
Адрес: К Северу через Северо-Запад
Чтобы печатать документ для оплаты на одном из проектов печатали Confirmation - у него есть номер, список товаров с ценами и суммами.
За это сообщение автора поблагодарили: mazzy (2).
Старый 02.11.2017, 21:31   #28  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
блин, вот все же у всех перед глазами.
Как лихо исчезло условие "в момент отгрузки" ))))
В момент отгрузки продавец и не должен знать цену товара.
фактические 5% от стоимости в счете исчисляется в таможне, а не "в момент отгрузки"
оценочную величину 5% в момент аксапта вполне может прикинуть по физической стоимости.
...
Повторюсь, в реальной жизни противоречия нет. Противоречие только в вашей формулировке.
Это - ложное утверждение: как алгоритмы D365 не описывают хозяйственную деятельность во всей полноте, так и таможенный кодекс не может учесть всех нюансов торговли. Поэтому для разрешения объективно существующего противоречия приходится применять предположения и делать упрощения:
  • если нет счета, то применяется оценочная стоимость товара
  • если цена продажи по неизвестной нам причине (привязка к сырьевой бирже? эффект расчетов в валюте? особые условия продажи через Интернет-магазин типа "не дороже чем у остальных участников рынка"?), то хорошей оценкой будет цена продажи на момент отгрузки
  • таможенную службу интересует то, что у нее под носом пересекает границу; если будем постфактум присылать корректировки и добавлять им работы, там только покрутят у виска
Цитата:
Сообщение от mazzy Посмотреть сообщение
повторюсь, в аксапте есть физическая и финансовая стоимости.
Если стоимость меняется со временем, то так или иначе задачу надо сводить к этим понятиям.
Для процесса продажи в аксапте предусмотрены документы Packing slip и invoice для работы с физической и финансовой стоимостью.

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

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

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

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

Будьте скромнее.
Старый 02.11.2017, 23:02   #29  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
да-да. а также о контроле, об аппрувах продаж, о планировании денежных средств (это я уже говорил)
а также об агентских вознаграждениях и комиссионной торговле.

подумайте - это очень правильный совет.
Я вот подумал: как раз сейчас тестирую массивный ISV, в котором есть контроль и одобрение продаж. Там бы фокус с отдельной строкой не прошел. Однако, в стандартной D365 нет контроля и одобрения продаж. Более того, в исходной постановке задачи подразумеваются некие внешние условия или темные силы, которые приводят к изменению цены. Если они внешние или неотвратимые, зачем и как их контролировать? Их надо тогда не контролировать, а автоматизировать. К примеру, если речь идет об объемных скидках, то Rebates в D365 формируют отдельный месячный счет и суммарный журнал ГК. Выгода в управляемости и прозрачности есть, но связь с оригинальным заказом тоже весьма опосредованная.

В текущей версии нет планирования денежных средств; более того, зачем планировать краткосрочные отклонения в цене, и как это улучшает качество принятых по результату планирования решений? Нужно ли думать об агентских вознаграждениях если их нет?

Последний раз редактировалось EVGL; 02.11.2017 в 23:09.
Старый 03.11.2017, 03:21   #30  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от mazzy Посмотреть сообщение
таким образом,
сперва разносите packing list по Sales Order.
затем фиксируйте окончательные условия сделки инвойсами.
У нас кстати тоже используется подобный подход(первоначальный инвойс, далее он сторнируется, делается нормальный)
я как-то пытался выяснить почему так криво, но так и не понял
mazzy, а можно расписать не для консультантов, в чем твое предложение?
схема работы такая - клиенту выставляется инвойс (разносится Sales Invoice в АХ) далее он может или прислать деньги, или (что происходит часто) какие-то коррекции (в приведенном примере к примеру сумму перевозчика или сумму за таможню). при этом исходный инвойс сторнируется, создается новый с новыми суммами.

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

Последний раз редактировалось trud; 03.11.2017 в 03:30.
Старый 03.11.2017, 08:06   #31  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
отличный вопрос.
Цитата:
Сообщение от 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 )))) )
= таки разобраться какого документооборота ожидает клиент. Обмен только инвойсами - это тривиальный докуменооборот, который приводит к кажущимся "противоречиям".

примерно так.
__________________
полезное на axForum, github, vk, coub.
Старый 03.11.2017, 10:06   #32  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от mazzy Посмотреть сообщение
1. регистрировать в системе только то, что известно
Сразу вопрос - зачем выставлять инвойс в этот момент?

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

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

Цитата:
Сообщение от mazzy Посмотреть сообщение

воооот!

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

порвать и забыть старый документ и выписать новый? можно. но потеряется вся цепочка и потеряется вся суть контроля. А erp-система превращается в тривиальную и дешевую программу, которая только регистрирует факт.
да, меняется инвойс. т.е. старый полностью сторнируется, новый создается(с новыми значениями)
Старый 03.11.2017, 10:49   #33  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от trud Посмотреть сообщение
ну вот именно для этого его и выставляют, посчитать себестоимость, сделать задолжность и т.д. т.е. после этого мы ожидаем оплаты.

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


да, меняется инвойс. т.е. старый полностью сторнируется, новый создается(с новыми значениями)
как скажете
__________________
полезное на axForum, github, vk, coub.
Старый 03.11.2017, 11:04   #34  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
чтобы он прислал деньги совершенно не обязательно разносить инвойс и фиксировать задолженность. а печатную форму можно получить и другим способом. штатный - инвойс-проформа. а оценку будущего движения денежных средств система может выполнить и без разноски документа.
Этот подход часто применяли на мини-внедрениях под сотню пользователей, когда открытые инвойсы все знают наизусть. Типа меня: один клиент, один счет в месяц, когда поступают средства на счет, я знаю от кого и за что : ) На крупных компаниях с импортом выписки такой подход не работает: вы убиваете возможность сопоставления банковской выписки (тут мы умолчим, что даже advanced bank reconciliation неспособна сопоставить пришедшую оплату с открытым счетом - на https://ideas.dynamics.com/ideas/dyn...ions/ID0001314 есть предложение - голосуйте!) Вы убиваете акт сверки задолженности с клиентом. Поэтому спросили в начале темы: как платить-то будем?

Поэтому на моем D365 проекте в Швейцарии я локализовал : ) для Западной Европы чешские счета на предоплату в расчетах с клиентами. Там, правда, настоящие предоплаты на долю общей суммы, а не версии того же счета, так сказать. Но эти чешские Advance invoice могут иметь множество строк и в принципе их можно использовать в более сложных сценариях. Основная доработка, которую пришлось сделать - это возможность сопоставления этих счетов с оплатами, поскольку в чешском стандарте они автоматически сопоставляются с реверсом счета, который формируется в момент разноски финального инвойса.

P.S. Для интересующихся - ссылка:
https://docs.microsoft.com/en-us/dynamics365/unified-operations/financials/localizations/emea-advance-invoice

И вот еще сходная голосовалка по банку: https://ideas.dynamics.com/ideas/dyn...ions/ID0001555
Сара Шилке обещает Long term, давайте навалимся и сделаем Mid-term!

Последний раз редактировалось EVGL; 03.11.2017 в 11:11.
За это сообщение автора поблагодарили: Logger (1).
Старый 03.11.2017, 11:17   #35  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
Этот подход часто применяли на мини-внедрениях под сотню пользователей, когда открытые инвойсы все знают наизусть. Типа меня: один клиент, один счет в месяц, когда поступают средства на счет, я знаю от кого и за что : ) На крупных компаниях с импортом выписки такой подход не работает: вы убиваете возможность сопоставления банковской выписки (тут мы умолчим, что даже advanced bank reconciliation неспособна сопоставить пришедшую оплату с открытым счетом - на https://ideas.dynamics.com/ideas/dyn...ions/ID0001314 есть предложение - голосуйте!) Вы убиваете акт сверки задолженности с клиентом. Поэтому спросили в начале темы: как платить-то будем?
Му-ха-ха-ха!
Конечно же нет.

Работает. И акт сверки работает. И сопоставлять можно не только с разнесенными инвойсами (открытыми проводками). И по sales order можно создавать не только инвойсы, но и другие sales order, с которыми можно сопоставлять.

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

==================
Цитата:
Сообщение от EVGL Посмотреть сообщение
Поэтому спросили в начале темы: как платить-то будем?
Опять подмена на ходу.
Поначалу спрашивали как клиент платить будет. Я так понимаю, что разницы вы не категоричеки видите.

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

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

Ребяты, жжоте!
__________________
полезное на axForum, github, vk, coub.
Старый 03.11.2017, 11:24   #36  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
Му-ха-ха-ха!
Конечно же нет.

Работает. И акт сверки работает. И сопоставлять можно не только с разнесенными инвойсами (открытыми проводками). И по sales order можно создавать не только инвойсы, но и другие sales order, с которыми можно сопоставлять.

я так понимаю, что документацию вы так и не прочитали. и не собираетесь читать.
как скажете.
Кончайте ржать, на грубость нарываетесь. В покажите место в документации, в котором proforma invoice показывается в акте сверки. Продемонстрируйте акт сверки, в котором видно сопоставление оплаты с заказом на продажу, умник. Продемонстрируйте, как в журнале оплат дама из Accounts Receivable сопоставляет оплату с заказом одним нажатием кнопки.

Последний раз редактировалось EVGL; 03.11.2017 в 11:26.
Старый 03.11.2017, 11:39   #37  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
Кончайте ржать, на грубость нарываетесь.
му-ха-ха-ха!!!
http://coub.com/view/z38rp

Цитата:
Сообщение от EVGL Посмотреть сообщение
В покажите место в документации, в котором proforma invoice показывается в акте сверки.
такого места я конечно же не покажу.
потому что с какой стати показывать в акте сверки proforma invoice, которая означает что сумма окончательно не зафиксирована.

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

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

Цитата:
Сообщение от EVGL Посмотреть сообщение
Продемонстрируйте акт сверки, в котором видно сопоставление оплаты с заказом на продажу, умник.
Зачем?! Фантазер, вы наш.

Неотвойсированный заказ означает что по этому заказу сумма не зафиксирована. что эта сумма всего-лишь accruals.

Акт не содержит accruals. И не должен содержать.

=========================================
Смешной народ, с которого хочется ржать,
вернитесь к исходному вопросу

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

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

А если первая версия уже в суд как вещественное доказательство ушло?


EVGL, почитайте наконец документацию.
__________________
полезное на axForum, github, vk, coub.
Старый 03.11.2017, 11:50   #38  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
Зачем вы хотите включить сумму 100 на шаге 1 в акт сверки?
И что вы собираетесь сделать с актом сверки после шага 2?
Его тоже порвать, отсторнировать и выписать новый?
Вот это правильный вопрос. Зачем? Не знаю. Автор топика этого не пояснил. Мое предположение: хочется деньги, и пораньше. На базе какого такого интересного договора: не знаем.

В примере trud понятно, зачем: чтобы получить деньги. Далее проводится экспертиза зерна, первый акт по сути рвется и выписывается новый. В моем примере с Advance invoice сначала появляется первая строка на предварительный счет, потом она закрывается оплатой, потом появляется финальный счет с разницей. Это если печатаем только открытые проводки. Если печатаем все, то результат такой:

01.10.2017 счет 1 +100
05.10.2017 оплата 1 -100
31.10.2017 реверс 3 -100
31.10.2017 счет 2 +105 открыто 5
Старый 03.11.2017, 12:19   #39  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
Вот это правильный вопрос. Зачем? Не знаю. Автор топика этого не пояснил.
автор и не спрашивал про акт )

Цитата:
Сообщение от EVGL Посмотреть сообщение
Мое предположение: хочется деньги, и пораньше. На базе какого такого интересного договора: не знаем.
если платеж выполнен, но не закрыт ни инвойсом, ни актом приемки работ (да, у буржуев есть аналог такого документа!), то платеж будет трактоваться любым судом как аванс. А авансы подлежат возврату в случае чего.

Даю маячок: инвойс - не единственный документ, по которому возможна оплата.
и инвойс - не единственный документ, который юридически закрывает передачу товаров/работ.

инвойс - это документ, который фиксирует СУММУ сделки.
Не больше. Но и не меньше.

Цитата:
Сообщение от EVGL Посмотреть сообщение
В примере trud понятно, зачем: чтобы получить деньги.
Даю маячок... Врочем уже давал ))))


Цитата:
Сообщение от EVGL Посмотреть сообщение
Далее проводится экспертиза зерна, первый акт по сути рвется и выписывается новый. В моем примере...
Му-ха-ха-ха...
Как скажете )))))
__________________
полезное на axForum, github, vk, coub.
Старый 03.11.2017, 12:31   #40  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Всем:

вопросы частичных закрытых поставок,
вопросы частично выполненных работ (незавершенка, WIP),
вопросы этапов, их бюдетирования и закрытия документами
в предельно явном виде проявляются в проектной деятельности.
в аксапте эти процессы реализованы в модуле "Управление проектами".

соответственно, если кто-то хочет понять что и как юридически выставляется и закрывается,
то стоит изучить вопросы Проектной деятельности и документацию к модулю Управление проектами в Аксапте.

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

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

В общем, читайте документацию.
__________________
полезное на axForum, github, vk, coub.
Теги
accrual

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
dynamicsax-fico: Vendor invoice recording (Part 9) Blog bot DAX Blogs 0 01.07.2017 17:13
organicax: Vendor invoice with working, matching test and posting to GL Blog bot DAX Blogs 0 01.10.2016 04:15
dynamicsax-fico: Duplicate vendor invoices Blog bot DAX Blogs 0 08.06.2016 16:11
emeadaxsupport: Vendor invoice - A currency to convert from is required to retrieve exchange rate information when trying to access a Vendor Invoice that is linked to a Purchase Order Blog bot DAX Blogs 0 05.12.2014 19:11
ax-erp: Posting Invoice from Sales order/ Purchase order. Blog bot DAX Blogs 0 06.11.2012 15:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 17:43.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.