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

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

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

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

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

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

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

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

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

[Ivanhoe]

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

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

[mazzy]

Цитата:

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

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

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

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


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

[BOAL]

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

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

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

[EVGL]

Цитата:

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

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

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

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

[pedrozzz]

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

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

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

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

[Ace of Database]

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

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

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

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

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

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

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

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

[Maxim Gorbunov]

Цитата:

Сообщение от Ace of Database

Использую движок отчетов FastReport от Борланда.

А по цене FastReport Вы не могли бы сориентировать? Что-то я у них на сайте посмотрел, разные комплекты поставки стоят от 500 до 3,500 долларов. Какой именно набор их продуктов Вы использовали? И как он лицензируется?

Спасибо.

[George Nordic]

Привет!

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

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

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

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

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

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

[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

Парочка вопросов:

1. Я так понимаю, что по кнопке "Обработка" галка "Печать" - не активна и всегда снята? Печать выполняется через отдельную кнопку? Кстати, возможна ли печать проформы или только уже обработанных документов?

2. Как решается задача одинакового дизайна отчета, но разного формирования содержимого?

Ну, например, один клиент хочет, чтобы было напечатано "тел: 999999, факс: 888888", а другой хочет наоброт: "факс: 888888, тел: 999999"

Делаются разные классы?

[Ace of Database]

Ответы на вопросы:
1. Кнопку обработки накладной спрятали. На заказе сделали кнгопку "Документы", внутри которой есть пункты "Накладная", "Счет-фактура" и т.д.В момент убытия машины накладная и счет-фактура автоматически печатаются в составе комплекта документов. В дальнейшем их можно напечатать отдельно по кнопке.
Накладная обрабатывается программно при переводе рейса в статус "Убыло". В этот момент обрабатывается только отборочная накладная. Если разнесена отборочная, то печатается по данным отборочной, если финансовая накладная, то по данным финансовой. Через некоторое время бухгалтерия выполняет так называемое "Закрытие накладной", после которого разносится финансовая накладная и счет-фактура. Она может отличаться от отборочной. После этого накладная по той же кнопке печатается на основании нормальной накладной. Накладную можно печатать из нескольких мест: из журнала накладных, из комплекта документов, из заказа. Все стандартные кнопки печати спрятаны, выведены новые кнопки печати. Сами пользователи не знают понятий "Проформа", "Отборочная накладная". Для них существует заказ и рейс. По заказу можно напечатать одну накладную, по рейсу - столько накладных, сколько заказов в рейсе.

2. Для одного типа документа независимо от количества различных шаблонов, всегда один и тот же класс. В случае каких-то отличий делается только новый шаблон. В приведенном Вами примере, будет создано два шаблона, в котором два поля будут поменяны местами. Новый код писать не надо. Например, для счетов-фактур у нас порядка 20 разных шаблонов, но все данные заполняются одним и тем же кодом. Аксапта просто заполняет все поля, которые используются во всех возможных шаблонах. Если создается новый шаблон, и в нем появляется новое поле, которого нет в других шаблонах, то в код Аксапты достаточно добавить строку, которая заполняет новое поле. Отсутствие данного поля в других шаблонах не критично.