![]() |
#1 |
Участник
|
![]()
Спецификация А состоит из двух деталей Б и трёх В. Создаём журнал спецификаций (неважно, каким способом, эффект устойчивый), приходуем одну А, расходуем 2*Б и 3*С, жмём "Проверить" и получаем:
----------- Warning Проверка - Журнал\Журнал: Журнал17\Номер строки: 1.00\Номенклатура: А К документу должна быть привязана, по крайней мере, одна строка Warning Проверка - Журнал\Журнал: Журнал17\Номер строки: 2.00\Номенклатура:Б Строка без маркировки должна существовать в строке спецификации Warning Проверка - Журнал\Журнал: Журнал17\Номер строки: 3.00\Номенклатура:С Строка без маркировки должна существовать в строке спецификации Info Проверка - Журнал\Журнал: Журнал17 Журнал содержит ошибки. Info Проверка - Журнал\Журнал: Журнал17 Журнал содержит 3 строк(и) с ошибками. ----------- Вопрос: чего он от меня хочет? v.3.0 |
|
![]() |
#2 |
Участник
|
Все таки важно, каким способом создаете. Поставьте около Б и В галочки, около А галочки не надо, но кол-во д.б. <>0. Почему не создать нормально?
__________________
"...жизнь проходит, пока мы строим планы на жизнь..." с уважением, ESys. |
|
![]() |
#3 |
Участник
|
Я имел в виду, что журнал, создаётся он вручную или автоматически, внешне выглядит одинаково. Галочки расставлены именно так, как Вы описали, количество расходуемых номенклатур соответствует числу приходуемых спецификаций, но ошибка всё же возникает. Я теряюсь в догадках. Может ли проблема заключаться в использовании (или неиспользовании) лотов? маркировок? Или, может быть, не хватает лицензии на какой-нибудь модуль?
|
|
![]() |
#4 |
Участник
|
Попробовала создать руками, все нормально прошло, ошибок нет...
А, - 1, без галочки, тип номенкл. спецификация Б, В - по +1, с галочками. странно. А зачем это: "количество расходуемых номенклатур соответствует числу приходуемых спецификаций"? Лицензии - вряд ли, как и лоты с маркировками.
__________________
"...жизнь проходит, пока мы строим планы на жизнь..." с уважением, ESys. |
|
![]() |
#5 |
Участник
|
Что странно то странно, согласен.
Зачем соответствует? Я первое письмо с этого начал: одно А у меня состоит из двух Б и трёх В, это указано через конструктор спецификаций. Причём это необязательно именно так, А может состоять и из одного Б и одного В, пробовалось и на других сочетаниях номенклатур и спецификаций. Ошибка возникает устойчиво. Т.о., вопрос остаётся открытым. |
|
![]() |
#6 |
Участник
|
А если создать стандартно?
__________________
"...жизнь проходит, пока мы строим планы на жизнь..." с уважением, ESys. |
|
![]() |
#7 |
Участник
|
в т.ч. и стандартно
|
|
![]() |
#8 |
Dynamics 365 MR
|
Цитата:
Изначально опубликовано Lol14
в т.ч. и стандартно Просто вручную созданный журнал вполно нормально проверяется. |
|
![]() |
#9 |
Участник
|
а не глюк ли это?
Хм, полагаю, что это очередная ошибка Аксапты.
Действительно, если создавать пакет журнала спецификаций автоматически через операцию Приемка (например, в Периодических операциях), то при разноске появляется описанная выше ошибка. Если же создать АБСОЛЮТНО такой же пакет журнала вручную, самостоятельно создавая строчки и проставляя галочки, то при разноске никакого сообщения об ошибке не выдается. Лично я пользуюсь таким методом: 1. Создаю пакет журнала автоматически с помощью операции Приемка (мне лень создавать вручную строчки, особенно если спецификация состоит из 20 и более компонентов). Да, во время этой операции нужно снять галочку с поля "Выполнить проводку сейчас", чтобы была возможность поправить нашу ошибку... 2. Иду в журнал спецификаций, нахожу нужный мне пакет, захожу в строки, а дальше делаю вид, что строчки созданы вручную... Для этого просто меняю что-нибудь в одной из строк (например, дату вручную перебиваю заново) ![]() 3. Делаю разноску, ошибки как и не было ![]()
__________________
Всё может быть и быть всё может, и только то не может быть, чего быть может быть не может, или вообще не может быть... |
|
![]() |
#10 |
Участник
|
двойная ошибка
Благодаря Fluffy выяснилось следующее: приведённая ранее ошибка возникает не только при приёмке и автоматическом формировании журнала, но и при создании журнала вручную, когда даты расхода номенклатуры и прихода спецификации отличаются.
Но бывает нужно, чтобы эти даты отличались, т.к. в промежутке между списанием и оприходованием (или наоборот) может происходит процесс переработки (сборки или разборки соответственно). Таким образом, вопросов стало два: - как автоматически, через приемку, сформировать журнал без ошибок - как в внести в журнал операции прихода и расхода разными датами Глюки? |
|
![]() |
#11 |
Участник
|
1) автоматически через приемку разнести журнал без некоторых исправлений не удастся. Журнал вообще-то формируется правильно, но система почему-то этого не понимает
![]() Мой вариант: поправить "туда-сюда" что-нибудь в строках сформированного журнала, сохранить эти "изменения". Визуально ничего не изменится, но Аксапта ошибки больше не увидит. Затем надо разнести журнал. 2) к вопросу о датах... Насколько я помню, журнал спецификаций именно тем и отличается от производственных заказов, что в нем процесс списания компонентов и приходование готовой спецификации производится одновременно на одну дату. Если нужно эти даты разделить, то, пожалуйста, пользуйтесь производственными заказами...
__________________
Всё может быть и быть всё может, и только то не может быть, чего быть может быть не может, или вообще не может быть... |
|
![]() |
#12 |
Участник
|
А не противоречит ли это общим принципам построения модуля УЗ?
Например, в строках журнала складских проводках можно менять даты, в журналах переноса тоже. Следуя этой логике в данных журналах следовало бы тоже запретить устанавливать разные даты у строк. |
|
![]() |
#13 |
Участник
|
Хм, не факт.
В журналах переноса и складских проводок по каждой строке формируется свой набор складских проводок. Строчки между собой никак не связаны, поэтому системе на даты плевать. В журнале спецификаций строчки связаны между собой. Думаю, в журнале не должно быть разрывов в датах... На самом деле, с точки зрения логики это кажется неправильным, ведь редкое производство заканчивается одновременно со списанием компонентов... Но если кому-то что-то не нравится, есть же производственные заказы, вот и альтернатива... Возможно, было бы правильнее в журналах спецификаций обрабатывать сборку лишь какой-нибудь фигни, которая много времени не занимает и укладывается в один день...
__________________
Всё может быть и быть всё может, и только то не может быть, чего быть может быть не может, или вообще не может быть... |
|
![]() |
#14 |
Участник
|
Журнал разносится, но проблемы со стоимостью.
При разноске приход и списание осуществляется без финансовой стоимости и проводок (v 3.0). В журнале "Спецификации" стоимость списанных и оприходованных единиц стоит (но это не должно иметь значения) . После разноски списанные единицы числятся "В заказе" , оприходованная единица "Закуплена". И те и другие без стоимости. Мгновенная средняя для списанных единиц на складе <> 0. В чем проблема? |
|