Разные формы для учтенных и неучтенных документов

[rem2]

Добрый день!

Подскажите, пожалуйста, в чем смысл того, что для неучтенных и учтенных документов (накладные, фактуры и т.д.) в NAVе назначены разные формы (отчеты)?
В реальной жизни бланк же не меняется от того, учтен документ или нет. Может чтобы проще было контролировать следование определенным бизнес-правилам?
Или что еще может быть?

[Milk]

Можно назвать несколько причин. Например, навскидку: таблицы разделены, чтобы отделить "архив" - учтеные документы - от тех, что в работе. За несколько лет работы в базе может накопиться очень большое число учтенных докуметов, и если их хранить там же, где неучтенные, это затормозит работу базы с таблицей и оперативнное оформление документов. Кроме того, таблицы заголовка и строк неучтенных документов "обвешаны" триггерами, которые не нужны для учтенных документов. Разные формы - понятно, что в учтенных документах почти все поля должны быть нередактируемы и разный набор полей должен быть видим для накладной и счета-фактуры. И вообще, таким образом наглядно разделяется товарный и финансовый учет. В общем, можно назвать много причин, но ни одна из них не является решающей. Можно было бы реализовать и все в одной таблице. При большом желании, можно и покупки с продажами было объединить, только вот неудобно А, например, в производственном модуле сначала завершенные заказы были выделены в отдельную таблицу, а в более поздних версиях уже объединены в одну с заказами других статусов. Так что все относительно.

[apanko]

Я думаю, REM интересуется почему используется разные отчеты для фомрирования одного и того же документа (например ТОРГ-12) для Заказа покупки и Учт. Счет Покупки.

Как сказал Milk - учтенные и неучтенные документы храняться в разных таблицах.
Значит отчеты должны использовать разные датаайтемы.
Для разных датаайтемов испольуются разные секции.
Соотвественно нет смысла запихивать печать учтенного и неучтенного документа в один объект. Т.к. все равно датайтемы будут разными, секции будут разными, да и формы запроса для фильтров будут разными (две закладки вместо одной).

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

Можно конечно сделать печатные формы на нейтральных датаайтемах типа Integer, а обход записей через цикл.
Но проще сделать один отчет c помощью стандартных средств (фильры, вложенность датаатемов), а потом его скопировать и подменить датаайтемы и при необходимости SourceExpr.

[rem2]

Спасибо!

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

Вы мне повернули мозги в нужном направлении

[artkashin]

Цитата:

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

Можно конечно сделать печатные формы на нейтральных датаайтемах типа Integer, а обход записей через цикл.
Но проще сделать один отчет c помощью стандартных средств (фильры, вложенность датаатемов), а потом его скопировать и подменить датаайтемы и при необходимости SourceExpr.

Тут я немного не согласен. Правильнее, на мой взгляд, было пойти по методу 1С-ников. За техническую точность не ручаюсь, но смысл сводится к следующему:
Там есть специальный объект для ТОРГ, на основании которой строится накладная и печатается. Вам просто необходимо заполнить поля этого документа из своего источника и вызвать печать. Следовательно, печатную форму ТОРГ, в случае необходимости, нужно менять только в одном месте.
Это немного похоже на функционал 12401 Standard Report Management, ведь все отчеты, в итоге, строятся на Sales Line или Purchase Line. Только в Наве не хватает таблицы для ТОРГ и из-за этого весь функционал 12401 кажется бесполезным. По мне, так кажется разработчики остановились где-то на середине, "создав" 12401, но оставив кучу отчетов, печатающих одно и то же.

[apanko]

Цитата:

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

Тут я немного не согласен. Правильнее, на мой взгляд, было пойти по методу 1С-ников. За техническую точность не ручаюсь, но смысл сводится к следующему:
Там есть специальный объект для ТОРГ, на основании которой строится накладная и печатается. Вам просто необходимо заполнить поля этого документа из своего источника и вызвать печать. Следовательно, печатную форму ТОРГ, в случае необходимости, нужно менять только в одном месте.
Это немного похоже на функционал 12401 Standard Report Management, ведь все отчеты, в итоге, строятся на Sales Line или Purchase Line. Только в Наве не хватает таблицы для ТОРГ и из-за этого весь функционал 12401 кажется бесполезным. По мне, так кажется разработчики остановились где-то на середине, "создав" 12401, но оставив кучу отчетов, печатающих одно и то же.

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

А что касается вот этих локальных конструкторов типа "Выгрузка деклараций в Эксель" и "Электронная отчетность". У меня сложилось мнение, что они настолько сложны, что с ними по доброй воле могут разобраться только консультранты/разработчики, из пользователей - единицы.
Но консультантам и разработчикам этот инструмент не нужен, т.к. у них есть дизайнер отчетов, которым они погут построить, что им надо и как и им надо.
Это исключительно мое мнение. Я неоднократно порывался с этими штуками разобраться и не получал от этого никакого удовольствия.
Возможно, если бы к ним шел тренинговый курс, по типу стандартных (Основы, Финансы, Девелопмент 1 и 2), где шаг за шагом объясняют концепцию и практическое применение, то результат был бы лучше.

[artkashin]

я, все-таки в качестве примера, имел ввиду накладную ТОРГ-12. Если обратить внимание, то печатная форма, в учтенных и в неучтенных документах, строится на основании темповой таблицы Sales Line. Заполняется эта таблица следущим кодом:

StandRepManagement.GetSalesDoc(DocumentType::"Posted Invoice","No.",
  SalesLine1,AmountInvDiscount,ShowDiscount,QtyType::General);

В обезличенном dataitem Integer есть код:

IF Number = 1 THEN BEGIN
  IF NOT SalesLine1.FIND('-') THEN
	CurrReport.BREAK;
END ELSE
  IF SalesLine1.NEXT(1) = 0 THEN
	CurrReport.BREAK;

т.е. каждая итерация в Integer - новая запись в SalesLine1. Это потому, что Навижн не умеет работать с темповой переменной в Dataitem.
Далее из строки SalesLine1 формируются данные в некоем виртуальном формате, с которыми и работает отчет:

StandRepManagement.RepValFromSaleDocLine(SalesLine1,
  ShowDiscount,FALSE,ReportValue,TotalAmount);

и этот код - в каждом отчете, что в заказе продажи, учтенной накладной, учтенном счете для ТОРГа и для СФ
а все ради чего?
Все равно, при изменении печатной формы надо править все отчеты - необоснованная трата времени программиста. И очень вероятная рассинхронизация печатных форм.

[apanko]

Понял. Это я о наболевшем высказался, не совсем вас поняв.

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

Так это примерно то, о чем я говорил.

Цитата:

Можно конечно сделать печатные формы на нейтральных датаайтемах типа Integer, а обход записей через цикл.