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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 03.12.2008, 12:09   #1  
karol is offline
karol
Участник
 
19 / 10 (1) +
Регистрация: 02.12.2008
->
Можно ли стандартными настройками при учете документа проверять поле Примен. Товар Операция № на заполнения и в случае не заполнения не проводить документ?
Старый 03.12.2008, 12:42   #2  
Eugeny_F is offline
Eugeny_F
Участник
 
371 / 30 (2) +++
Регистрация: 18.11.2003
Адрес: Москва
Смотря о каком виде документа Вы говорите. Для возвратов покупки и продажи обязательность заполнения этого поля может быть достигнута проставлением "галки" в поле "Точный возврат себестоимости" в настройках соответствующего модуля. Если Вы говорите про заказы продажи, то такой функциональности в явном виде нет. В некоторых случаях можно поэкспериментировать с трассировкой.
Старый 03.12.2008, 12:49   #3  
karol is offline
karol
Участник
 
19 / 10 (1) +
Регистрация: 02.12.2008
Я имею ввиду Заказ Продажи, не возвратные документы. А что Вы имеете в виду "Поэкперементировать с трассировкой..."???
Товар по партияи и по серийным номерам в организации не ведется, стоит ли вводить понятие трассировка для пользователей в данном случае?
Старый 03.12.2008, 13:08   #4  
Eugeny_F is offline
Eugeny_F
Участник
 
371 / 30 (2) +++
Регистрация: 18.11.2003
Адрес: Москва
Да, под трассировкой я имел в виду партии и серийные номера. Чтобы кто-либо ответил стоит или не стоит их использовать, нужна более конкретная постановка задачи. Пока не очень понятно, зачем Вам в обязательном порядке нужно заполнение данного поля. Обратите также внимание на то, что одной строчке в заказе продади может соответствовать несколько приходных партий. В этом случае Вам придется из одной строки делать несколько.
Старый 03.12.2008, 13:43   #5  
karol is offline
karol
Участник
 
19 / 10 (1) +
Регистрация: 02.12.2008
Цитата:
Сообщение от Eugeny_F Посмотреть сообщение
Пока не очень понятно, зачем Вам в обязательном порядке нужно заполнение данного поля.
Проверка необходима для того чтобы к строке подтягивалось правильное ГТД из списка покупок этого товара. а если пользователь забывает заполнить поле Примен. Товар Операция №, то в учтенный документ может подтянуться совсем не то ГТД, которое необходимо.
Старый 03.12.2008, 13:47   #6  
Eugeny_F is offline
Eugeny_F
Участник
 
371 / 30 (2) +++
Регистрация: 18.11.2003
Адрес: Москва
Тогда попробуйте настроить обязательное резервирование.
Старый 03.12.2008, 14:22   #7  
karol is offline
karol
Участник
 
19 / 10 (1) +
Регистрация: 02.12.2008
Цитата:
Сообщение от Eugeny_F Посмотреть сообщение
Тогда попробуйте настроить обязательное резервирование.
Документа формируется упрощенным способом - Счетом Продажи, а там, к сожалению, нет резервирования.

Наверное ответ напрашивается уже сам собой - НЕОБХОДИМА ДОРАБОТКА для того чтобы документ запрашивал заполненное поле Примен. Товар Операция №.

Евгений спасибо за помощь!!!!
Старый 03.12.2008, 17:35   #8  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от karol Посмотреть сообщение
Можно ли стандартными настройками при учете документа проверять поле Примен. Товар Операция № на заполнения и в случае не заполнения не проводить документ?
Попробуйте настройку "Exact Cost Reversing Mandatory" в "Sales & Receivables Setup".
Старый 04.12.2008, 09:46   #9  
karol is offline
karol
Участник
 
19 / 10 (1) +
Регистрация: 02.12.2008
Цитата:
Сообщение от RedFox Посмотреть сообщение
Попробуйте настройку "Exact Cost Reversing Mandatory" в "Sales & Receivables Setup".
Настройка неодходима, к большому моему сожалению, только для обязательного заполнения поля "Appl.-from Item Entry", а не для "Appl.-to Item Entry"
Старый 04.12.2008, 10:04   #10  
Romul is offline
Romul
Участник
 
186 / 11 (1) +
Регистрация: 26.12.2007
Ну так посмотрите соответствующий CU учета и по каждой строке Sales Line пробегайтесь, проверяя - проставлен ли номер примененной приходной операции или нет...
Старый 04.12.2008, 10:15   #11  
rmv is offline
rmv
Участник
 
481 / 11 (1) +
Регистрация: 15.02.2005
К сожалению не указан номер версии Nav.
Возможно проще работать через Заказы Продажи, либо научить резервирование понимать счета.
В противном случае как было уже сказано выше придется множить строки по номерам примененных приходных операций. В этом ничего страшного нет, просто многие клиенты удивляются - зачем один товар на ТОРГ-12 дублирован несколько раз? Особо впечатлительные при виде разных сумм НДС на один и тот же товар с одинаковым количеством впадают в ступор.
Старый 04.12.2008, 11:17   #12  
Geo is offline
Geo
Участник
Аватар для Geo
 
258 / 47 (2) +++
Регистрация: 04.04.2008
Я не уловил, а чем привязка строк обычной продажи к приходам отличается от партионного учета?
Имхо смысл использования полей Примен. Товар Операция № в том, что они позволяют ОТМЕНЫ прогнать по точной себестоимости, а ничего другого не трогать. Но если у Вас по бизнесу должна быть связь между продажами и покупками - то имхо партионный учет (т.е. трассировка) для того и существует...
Старый 04.12.2008, 12:20   #13  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от Georgea Посмотреть сообщение
Я не уловил, а чем привязка строк обычной продажи к приходам отличается от партионного учета?
Имхо смысл использования полей Примен. Товар Операция № в том, что они позволяют ОТМЕНЫ прогнать по точной себестоимости, а ничего другого не трогать. Но если у Вас по бизнесу должна быть связь между продажами и покупками - то имхо партионный учет (т.е. трассировка) для того и существует...
Абсолютно был бы согласен, если бы функционал ГТД был бы доработан. То, что вы предлагаете, это подменить ГТД номером партии и следить за синхронизацией данных ГТД и Партия Но.
 


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

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

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