Кто каким образом делает "тонкую настройку" печатных форм (СФ, накладные и т.п.) под конкретного клиента?

[Владимир Максимов]

*** выделено отсюда Ошибки в русских накладных, фактурах итп. ****

Я не уверен, не будет ли мое сообщение Offtop (может стоило начать новую тему?), однако...

Разные клиенты хотят видеть разные бланки и разные способы заполнения как счетов фактур, так и накладных. Понятно, есть "Постановление...", но "Постановление..." не запрещает печатать некую дополнительную информацию "сверх". Как дополнение.

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

У меня вопрос: неужели все реализуют всю эту кучу требований от разных клиентов через ОДИН отчет и ОДИН класс по подготовке данных? Имею в виду стандарт. И как в этом случае происходит выбор того или иного способа формирования? Неужели напрямую в коде делается ветвление по значению кода контрагента?

Кто каким образом делает "тонкую настройку" печатных форм под конкретного клиента?

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

[Ivanhoe]

Смысл есть. Как минимум должно работать то, что явно прописано в "Постановлениях". Желательно, чтобы стандарт закрывал 70-80% потребностей. Иногда хороший стандарт - дополнительный аргумент не менять систему, а менять подход к клиентам

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

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Я не уверен, не будет ли мое сообщение Offtop (может стоило начать новую тему?), однако...

конечно стоит начать новую тему.
интересная тема же.

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


но не всегда получается расширить наименование (и/или код).
я бы тоже послушал что люди делают.

[BOAL]

У нас как раз сейчас идет такая доработка
- с-ф + акты к ним - печатные формы в Ехеле
- генерятся на базе накладных через стандартные механизмы Фактур (которых как выяснилось и нет для массового создания, это вам не SalesFormLetter и клепание накладных) пачкой за период по всем договорам, объединяя разные начисления по клиенту в одну фактуру
- нумерация идет в разрезе Юрлиц и вида услуги, то есть номера есть 001, а есть 001-а и тп, это разные нумерации, даже внутри одного ЮЛ
- текст в строках фактуру выводится совсем не тот, что был в строках накладной, а по определенным правилам
- фактуры могут печататься сразу на принтер по кучи выделенных строк

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

Аналогично был мод по счетам на оплату - там уж форма счета стандарта в АХ вообще "не стандарта", а какая-то недобумажка. Счет в итоге стал по форме похож на 1Сный (тоже Ехель). По алгоритму он генерился совсем не стандартно из других данных (не на заказах), тк по бизнесу на момент счета нет ни накладных, ни заказов - ну и тоже массово по критериям.

[EVGL]

Цитата:

Сообщение от Владимир Максимов

У меня вопрос: неужели все реализуют всю эту кучу требований от разных клиентов через ОДИН отчет и ОДИН класс по подготовке данных? Имею в виду стандарт. И как в этом случае происходит выбор того или иного способа формирования? Неужели напрямую в коде делается ветвление по значению кода контрагента?

Бог миловал. Пока очень редко приходилось такое делать, почти во всех странах и во всех предприятиях был стандарт для всех клиентов. России в этом плане лучше, поскольку во всем остальном мире формат не регламентирован в принципе.

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

[pedrozzz]

Аналогично, спец-формы накладных и СФ сделаны отдельными дизайнами. ТТН, в зависимости от спец-формы, имеет "специфическое" заполнение полей в Excel. Настройка вынесена на уровень управления печатью. Сделана возможность задавать настройки управления печатью на уровне договоров.

[Владимир Максимов]

Уточняющий вопрос к тем, кто делал отдельный функционал

Если делается собственный функционал, то печать встраивается в печать из формы "Обработка" или обработка сама по себе, а печать через отдельную кнопку?

[George Nordic]

Привет!

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

Если первое - это, действительно, *FormLetter*, то со вторым можно поступить по-разному.
1. "Стандартная" настройка - Параметры - Формы - Настройка форм (можно выбрать тип печать: внутренний / Excel)
2. "Собственная" кнопка или механизм.

Я писал огромный механизм с наследованием ролей и очень гибкой настройкой, где каждому этапу разноски мастером добавлялось:
1. Группы пользователей
2. Какая группа пользователей какие документы имеет право печатать
3. На какой принтер печатается какое количество того или иного оригинала документа
4. На какой принтер печатается какое количество той или иной копии документа
5. Возможно ли печать проформы (без расностки)

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

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

С Уважением,
Георгий

[Ace of Database]

Делал отдельный функционал. Печать комплекта документов по заказу (или рейсу, в который входит группа заказов), закупке .
Есть базовый класс, от которого наследуются все отчеты.
Базовый класс берет настройки из отдельной таблицы, в которой задается код плательщика, название шаблона, количество копий.
У некоторых плательщиков есть разные точки, для которых надо печатать разное количество копий, либо даже использовать разные шаблоны. Это тоже поддерживается.

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

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

Если клиент делает возврат, то он предъявляет нашу накладную со штрих-кодом, наш бухгалтер сканирует штрих-код, и в Аксапте автоматически создается возврат на основании исходного заказа.

Поддерживается двух-сторонняя и односторонняя печать.

Для некоторых клиентов нужно печатать по две разных формы накладных и счетов-фактур. Это тоже поддерживается.

Использую движок отчетов FastReport от Борланда. Сочетает в себе преимущества Экселя, Ворда, Crystal Reports в одном флаконе. Из Аксапты передаю данные в FastReport в виде XML-файла. Для удобного формирования XML-файла есть интерфейс, с помощью которого данные передаются в виде "Имя набора данных"."Имя поля", "Значение поля".

Если у кого есть интерес, можете подъехать, посмотреть. В вечернее время или в выходные.

[EVGL]

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

[Ace of Database]

Никто на алтарь счета-фактуры не клал.

Надо печатать по 90 документов на каждый рейс. Разных документов.
Эта разработка предназначена для промышленного использования, где печатается огромное количество разных документов, не только счетов-фактур. В конвейерном режиме круглосуточно работают 4 принтера. Несколько минут простоя считаются критичными.

На разработку механизма ушло пару месяцев. За полгода прошло внедрение всего контура торговли.

[EVGL]

Понятно! Респект.

[Ace of Database]

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

[Ace of Database]

На 1-м рисунке пример настройки задания шаблона печатной формы и количества копий в разрезе плательщика (или общей печатной формы для всех). Там, где количество копий нулевое, оно берется из настроек копий из рисунка моего предыдущего поста.

На 2-м рисунке указывается количество копий в разрезе точек доставки, принадлежащих одному платедьщику (если плательщика не указать, то можно просто перечислять всех клиентов с указанием количества копий для каждого, если клиента не указать, то количество копий для него будет взято из настроек верхнего уровня).

В данный механизм изменения не вносились уже длительное время. Он позволяет гибко настраивать любые пожелания бухгалтерии. Даже бухгалтера сами пользуются им без обращения в ИТ.

[Ace of Database]

Вот так выглядит редактор отчетов в Fast Report
В строке ТОВАРНАЯ НАКЛАДНАЯ № [CTD_PageHeader1."CTDNumber"] от [CTD_PageHeader1."CTDDate"] в квадратных скобках заданы имя источника данных и после точки имя поля. Источники данных и значения полей передаются из Аксапты, для этого есть удобный интерфейс. Т.е можно чередовать обычный постоянный текст и переменные данные.
Можно копировать элементы из одного шаблона в другой. Перемещать элементы пачками.
Никаких запросов напрямую к базе данных Аксапты нет, все данные передаются из Аксапты в виде строки в формате XML. Разработчику не надо работать с XML на низком уровне, для заполнения данных есть отдельный класс, который предоставляет удобный интерфейс.

[Ace of Database]

Еще пара рисунков.
На 1-м рисунке предварительный просмотр накладной. Нажата кнопка "В файл". Просмотрщик позволяет сохранять файл в 4 форматах. (В PDF самый красивый внешний вид получается, на 100% соответсвующий реальности!). Мы отправляем клиентам по почте файлы в формате Excel. Никто до сих пор не жаловался.

На 2-м рисунке внешний вид файла в формате Excel. Показана часть данных в целях конфиденциальности.

[imir]

Тоже делали подобную штуку, функционал практически один в один. Тему подняли не зря - подобная штука нужна в стандарте.

[Ace of Database]

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

[Ace of Database]

Для программистов.
При взаимодействии с Fast Report никаких Active-X объектов не используется. Вызывается либо DLL-библиотека либо web-интерфейс через отправку веб-запроса.
DLL-библиотека устанавливается автоматически при первом запуске клиента Аксапты (реализовано через класс SysFileDeploymentFile)

[Ace of Database]

По поводу скорости разработки печатных форм с использованием данного инструмента.

1. Заморачиваться с XML и вызовами DLL не надо. Все делает специальный класс. Достаточно в нем вызвать метод printReport(). С точки зрения разработчика никаких технических заморочек нет, только работа с предметной областью. Заполнение данными конкретного поля выглядит так:

zReport.addValue("CTD_ReportTitle1", "CReceiverPhone", custTableReceiver.Phone);

где 1-й параметр - название источника данных, 2-й параметр - название поля, 3-й параметр - значение поля. Числовые поля можно округлять до любого количества знаков, оставлять только целую часть, не выводить нули и т.д.

2. Если вам не надо использовать настраиваемое количество копий и включать ваш отчет в комплект, то можно разработать свой класс с нуля и вызывать в нем класс, который заполняет XML данными и выводит отчет на экран либо на принтер.

3. Если вам надо использовать настраиваемое количество копий и\или включать ваш отчет в комплект, то нужно свой новый класс унаследовать от одного базового класса, и перекрыть в нем методы, которые выводят данные в поля источников данных отчета и задают название шаблона. В комлекте документов нужно указать код своего нового класса, чтобы он начал вызываться вместе с классами, отвечающими за печать других документов из комплекта.