06.02.2009, 13:42 | #1 |
Участник
|
Предприятие планирует перейти на взаиморасчеты с клиентами в У.Е.
В бухучете будут рассчитываться курсовые разницы, в налоговом - суммовые разницы, при этом начисленный в налоговом учете НДС с суммовых разниц - должен быть отражен проводками в бухучете и на него сформирована счет-фактура с попаданием в книгу продаж. Как решать на 4.03? |
|
06.02.2009, 14:18 | #2 |
Moderator
|
Для 4.0 то же выпускали все изменения связанные с расчетами в валюте и у.е.
Там надо понастраивать систему (в демо БД ) нужных настроек нет. А счета на НДС с суммовых разниц формируется отдельным отчетом. Правда в нем была ошибка, но к ней точно выходило исправление |
|
09.02.2009, 11:02 | #3 |
Участник
|
|
|
09.02.2009, 13:29 | #4 |
Moderator
|
Все релизы по суммовым/курсовым разницам снабжены White Paper (не слишком короткими ) вот по ним и надо пройтись.
Если есть интерес может найду времяя сделать краткий перечень настроек по которым надо пройтись, что бы все печаталось. Большинство настроек распологаются на закладках Суммовые разницы и Предоплаты |
|
11.02.2009, 12:04 | #5 |
Участник
|
Gala,
я пока застрял в самом начале: - 10/01/09 делаю оплату в Руб (валюта - пусто) сумма 1000 USD по курсу ЦБ , - 15/01/09 делаю заказ продажи в валюте USD сумма 1180 USD, ...учитываю, применяю - рублевая оплата пересчитывается по курсу USD на дату отгрузки. соответственно получаю сумму остатка продажи в валюте на 180 USD а больше. NAV 4.03 + все последующие обновления на сегодняшний день. |
|
13.02.2009, 11:11 | #6 |
Участник
|
Цитата:
Сообщение от MaxPC
Gala,
я пока застрял в самом начале: - 10/01/09 делаю оплату в Руб (валюта - пусто) сумма 1000 USD по курсу ЦБ , - 15/01/09 делаю заказ продажи в валюте USD сумма 1180 USD, ...учитываю, применяю - рублевая оплата пересчитывается по курсу USD на дату отгрузки. соответственно получаю сумму остатка продажи в валюте на 180 USD а больше. NAV 4.03 + все последующие обновления на сегодняшний день. |
|
13.02.2009, 12:19 | #7 |
MCTS
|
Цитата:
Плюс потребуется еще несколько настроек - тогда сумма счета будет изменена согласно курсу на дату оплаты. Настройки описаны в White Paper RU Cancel Currency Prepayment Adjusment.pdf из NAV RU50SP1FP1_PS35160 |
|
03.04.2009, 16:34 | #8 |
Участник
|
А можно подробнее - какие настройки приводят к коррекции суммы счета? Настроила по описанию. Применяется замечательно, аванс не пересчитывается, проводки по авансовой разнице создаются, кредит-нота на ав. разницу тоже создается. Но счет не корректируется! А еще не совсем понятна такая вещь: вообще-то документы обычно печатаются до учета отгрузки. А так получается, что правильные документы мы получаем только после учета отгрузки и счета?
Nav 4.0 SP3 |
|
04.04.2009, 19:03 | #9 |
Участник
|
Поняла, почему не корректировалась сумма в печатных формах. Поставила галку в Русский Продажа Строки Расчет. Но все-таки - как правильно напечатать неучтенные документы? У нас менеджеры с бухгалтерией готовят отгрузочные документы, а сама отгрузка может быть и ночью, когда никого из них нет. Работник склада учитывает отгрузку (если все нормально), а бухгалтерия потом учитывает счет и применяет. В принципе, в заказе продажи есть поля "Примен. Тип Документа" и "Примен. Документ Но.", но на сумму в накладной они не влияют, да и как быть, если было несколько авансов по заказу? Кромсать стандартный функционал? Посоветуйте, пжл, как вы выходить из таких ситуаций?
|
|
07.04.2009, 17:52 | #10 |
Moderator
|
А как это должно работать, если сумма счета зависит от того к какому авансу (и авансу ли) будет применен счет, а у Вас
Цитата:
Цитата:
Они вам как помонут, если все равно Цитата:
Пока да. Но если здесь будет какое-то разумное обсуждение требований, то возможны варианты , хотя бы в будущем |
|
07.04.2009, 22:12 | #11 |
Участник
|
Мне кажется, что раз Навижен все-таки не бухгалтерская, а управленческая программа, и пользователь вправе требовать, чтобы правильный документ формировался в момент совершения операции, а не тогда, когда бухгалтер будет закрывать дебиторку. Какие могут быть варианты (на мой дилетантский взгляд):
1. Сейчас при учете Заказа продажи идет сначала отгрузка, т.е. товарные движения, потом учет счета. Может быть, стоит разрешить пользователю самому выбирать порядок учета. Т.е. мы учитываем счет, задаем применение, печатаем документы, а уже потом учитывает склад. 2. Хотя бы при заданном автоматическом применении рассчитывать автоматом правильную сумму для Заказов продажи. Т.е. мы предполагаем, что все Заказы будут учтены и применены в хронологическом порядке (по Дате учета и учетному номеру) к оплатам. Согласна, что ошибки могут быть, но хоть какой-то выход. 3. Механизм ручного применения на этапе Заказа продажи, при учете - заказ автоматически применяется так, как это было задано в заказе. Может быть, есть и другие варианты? Буду очень благодарна, если кто-то подскажет, в каком направлении стоит копать, чтобы хоть как-то решить эту проблему. Мне больше нравится п3, но бухгалтерия начала ныть, что им и так тяжело с этими применениями, а тут еще про авнсы надо думать, и если будет все автоматом, то они будут счастливы, даже если будут ошибки... |
|
07.04.2009, 23:07 | #12 |
Administrator
|
Цитата:
перед тем, как поручить ее программисту, попросите, чтобы он процитировал свои любимые места из 12-го и 21-го кодеюнита. Цитата:
Сообщение от lenok
2. Хотя бы при заданном автоматическом применении рассчитывать автоматом правильную сумму для Заказов продажи. Т.е. мы предполагаем, что все Заказы будут учтены и применены в хронологическом порядке (по Дате учета и учетному номеру) к оплатам. Согласна, что ошибки могут быть, но хоть какой-то выход.
3. Механизм ручного применения на этапе Заказа продажи, при учете - заказ автоматически применяется так, как это было задано в заказе. великолепная фраза! можно, я ее время от времени буду цитировать? |
|
08.04.2009, 01:02 | #13 |
Moderator
|
Цитата:
Цитата:
Судя по Вашему описанию вариантов 2 и 3 значит все-таки бухгалтера (ну или кто-то) могут определить заранее примерение (может даже и автоматом). И при нарушении хронологии, переприменении придется перепечатывать документы.... Цитата:
"Новая функциональность работает, но не всегда. Ошибки возможны.......", если после этого можно будет печатать неучтенный документ (может быть и не всегда правильный), который бухгалтера будут перепроверять и перепечатывать (пусть и не всегда).... |
|
08.04.2009, 10:01 | #14 |
Участник
|
Цитата:
Цитата(lenok @ 07.04.2009,21:12) *
1. Сейчас при учете Заказа продажи идет сначала отгрузка, т.е. товарные движения, потом учет счета. Может быть, стоит разрешить пользователю самому выбирать порядок учета. Т.е. мы учитываем счет, задаем применение, печатаем документы, а уже потом учитывает склад. стоимость подобной доработки на вскидку 10 - 20 тысяч долларов. перед тем, как поручить ее программисту, попросите, чтобы он процитировал свои любимые места из 12-го и 21-го кодеюнита. Цитата:
Но если здесь будет какое-то разумное обсуждение требований, то возможны варианты wink.gif , хотя бы в будущем
Остальное - это не решения, а заплатки, я совершенно согласна с их абсурдностью, и не жду подобных решений от Майкрософта. Но по крайней мере, это то, что я могу сделать, и если наша бухгалтерия пойдет на это - то это уже их проблемы. Цитата:
Цитата(lenok @ 07.04.2009,21:12) *
...если будет все автоматом, то они будут счастливы, даже если будут ошибки... великолепная фраза! можно, я ее время от времени буду цитировать? wink.gif Всем спасибо! |
|