Alber

Такая обработка у нас уже реализована. Заданы соответствия артикулу СО в 1С. И выгрузка спецификации по изделию и по заказу есть. Нет обратной связи - контроля цен, контроля норм расхода материалов и комплектующих. В СО бухгалтерия и кладовщики склад вести не хотят (думаю правомерно, двойная работа), потому что им оттуда брать особо нечего, а то что возьмут все равно вручку лопатить. Склад больше нужен инженерам да логистам. Я так понимаю эту задачу удалось решить только частично и все ведут два склада (в СО и в 1С) или только в 1С.

Всем, здравствуйте. Интересует, такой вопрос. Реализовал ли кто связку СО и 1С? Есть блок выгрузки в 1С, можно выгрузить данные по счету и складским накладным через экспорт в текст в XML формате. Есть блок для 1С, открывающий прямой доступ к базе СО. Но все эти данные для 1С не подходят. В 1С определяющим является название комплектующего, т.е. названия комплектующих и материалов в приходных и расходных накладных должны полностью совпадать. У каждого поставщика свои названия. В СО свои названия с ограничением в 25 знаков. Есть ли возможность, как-то решить эту проблему? Или кто-то, может, по другому принципу построил связь?

Занимаюсь деревянными окнами. Деревянное окно ничего не решит. Будет еще хуже , вплоть до полного разрушения из-за разбухания.. Полностью согласен с Boris'ом. Вся проблема в последнем этаже и вытяжке. Ставить приточный клапан имеет смысл если работает вытяжка. Сам клапан воздух не всасывает, он только регулирует его поток. Это главная проблема. В вопросе не написано какой дом. По опыту, сталкивался с такой проблемой только в блочных домах, высокая влажность в помещении возникает дополнительно из-за того, что стены тонкие и точка выпадения росы внутри стены и влага испаряется внутрь помещения. Вторая причина - неправильная установка. Граница "тепло/холод" в углах проема заходит внутрь помещения. Опять же точка росы и влажность провоцирует выпадение росы в углах. Нужна хорошая термо и влаго изоляция. Возможно, что проблема вентиляции автоматом решит все другие, а приточный клапан самой причины не устранит.

Все понятно. Нет переключения в заголовке по счетам. Формируется один раз заголовок. Данные есть, поэтому заголовок печатается, но один раз. Надо организовать перечисление по номеру счета. Перед элементом [Спец: склад2] создайте элемент, в котором разместите бэнд 'master header', на нем разместите поле с [Номер счета]. Установите свойство Visible бэнда и поля в False. Должно получиться. В прикрепленном файле скрин выбора счетов, скрин результата работы и сам отчет. И еще - не обязательно делать два бэнда с 'master data', у вас может получится, что какие-то комплектующие выдут два раза, потому что элементы тоже являются комплектующими изделия. Хотя это зависит от настроек. Мне хватило одного бэнда. Все вышло, даже расширители, которые являются элементами. Отчет.rar

В любом случае для того чтобы заголовок не печатался, когда не надо, он должен быть на 'master head' и привязан к данным на 'master data'. Если данных не будет, то и заголовок выводится не будет. На 'master head' [номер счета] ставить можно, равно как и другие объекты. Вам все портит побэндовый вывод на печать. Если возможно, надо объединить комплектующие под одним типом распечатки. Тогда побэндовый вывод будет не нужен.

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

Надо в элементе [Спец склад2] увеличить высоту бэнда 'Master header' и перенести на него объект из элемента [Загл комп]. Элемент [Загл комп] - удалить. В элементе [Загл комп] у Вас только бэнд 'Master header'(заголовок), естественно, что он все время печатается. В элементе [Спец склад2] есть и 'Master header' и 'Master data'. Если в 'Master data' не появится ни одной строки, то и 'Master header' не будет печататься.

Спасибо Роман. Я кажется понял в чем дело. В моем счете, на котором я обкатываю документы, есть стоечно-ригельное изделие и отдельно построенные расширительные брусы. Эти изделия в этот документе ненужны. В документе много циклов и фильтров. Видимо есть проходы по циклам, в результате которых, через фильтры никакая информация не проходит и соответственно формируется по умолчанию пустой RichText со стандартными размерами. А поскольку он не умещается на моих суженых страницах, редактор формирует другую со стандартными полями. Проверить, правда, уже не смогу, документ переделал, точнее доделал, там еще много чего надо было, но сейчас у меня нет пустых страниц. Попробую еще на других счетах обкатать. Должно все нормально быть.

Я хотел примерно такой же реакции как от Hirurg/

Выкладывать в текстовом виде смысла нет, там одни самодельные элементы со скриптами. Прикрепляю файл RFF. СО6 сборка 20. Уважаемый Rexther. По поводу: "А написание отчета силами разработчика - оптимальный метод решения задачи. Просто надо уметь поставить ТЗ - тут как раз у большинства пользователей проблема - не знают чего хотят. Не до конца представляют ..." позволю себе сильно не согласиться по всем пунктам. Во-первых, время идет и документы устаревают всвязи с развитием производства и расширением ассортимента. Каждый раз перезаказывать? Во-вторых, в моем случае, сей документ я представляю до мельчайших подробностей, он вымучен временем. А вот объяснить исполнителю, почему и зачем имено так, боюсь, будет затруднительно. В-третьих, на создание документа такого рода уходит день-два, а сколько продлится переписка и разработка у КСТ. ТЗВаймы.rar

joiner ( To KCT support ) 27.03.2012 15:05 Вопрос такой. При создании страницы в дизайнере отчета пытаюсь увеличить поле слева. При выводе на просмотр появляются пустые страницы. Открываю их в редакторе. На них на всех пустой RichText объект с именем MainRich. Причем страница со стандартными полями и ширина этого объекта как у страницы. Откуда этот объект берется и как от него избавиться? KCT support 27.03.2012 15:07 "Откуда берётся этот объект" нужно спросить у автора документа. joiner ( To KCT support ) 27.03.2012 15:10 Я такой объект не ставлю, он появляется независимо от меня. Причем от пропадает, когда устанавливаются поля по умолчанию. KCT support 27.03.2012 15:12 Читайте документацию фаст репорта. По умолчанию на пустой страницы появляется Rich text..... joiner ( To KCT support ) 27.03.2012 15:20 Антон, у меня страница не пустая. В том-то и дело. Ситуация такая. Документы нужно подшивать в папки. Для этого нужно увеличить отступ слева на странице. В документах стоят отступы по умолчанию 36 точек. В свойствах страницы во всех элементах увеличиваю отступ слева до 72 точек (соответственно передвигаю все объекты, чтобы умещались). При печати или просмотре появились пустые страницы и на них этот объект RichText. Стоит вернуть отступ назад - пустые страницы и RichText пропадают. KCT support 27.03.2012 15:21 Значит как-то не так передвигаете. joiner ( To KCT support ) 27.03.2012 15:28 Пробовал просто один элемент в середину бэнда ставить. Тоже самое. Пустые страницы все равно появляются. Тут именно от поля зависит. Увеличиваю поле - появляются пыстые страницы с RichText объектом. Возвращаю к стандартному значению - пропадают. KCT support 27.03.2012 15:31 Грамотно созданные документы в нашей программе работают. Если у вас не получается, мы можем написать вам документ от 80 евро без скриптов и от 200 евро со скриптами. KCT support 27.03.2012 15:31 В рамках возможностей программы. Это пример общения с тех.поддержкой KCT-софт. Самое примечательное - это финал. Наводит на некоторые мысли. А теперь по существу. Кто-нибудь сталкивался с такой проблемкой. Я имею ввиду сам вопрос о полях на странице. Заранее спасибо.

Все data бэнды имеют свойство "Columns", соответственно им можно пользоваться. Свойством "ColumnWidth" можно задать ширину столбца, а "ColumnGap" - расстояние между столбцами.

На счет FBScaner идея хорошая, только его освоить придется. А версии FB одинаковые, с одного диска CО6 ставилось, отдельно FB нигде не ставили, тем более 64 разрядный. У нас все машины 32. Может стоит попробовать везде FB 2.1 вместо 1.5 поставить?

Настройки проверил. Пробовал по всякому менять и на сервере и на семерке. Результат 0. Нарыл вот такую информацию. Число 9223372036854775807 (именно оно и появляется в спецификации, только с запятой после 5 знака и со знаком "-") в двоичном исчислении выглядит как 15 цифр "1", то есть с учетом знака это минимальное число в 4 байтах. Отсюда возникает предположение, что число попросту обрезается по дороге на семерку. Вопрос где. Или винды или FireBird не стыкуется правильно. Может что в настройках Firebird надо поменять?

Всем доброго времени суток. Столкнулся с такой проблемой. Если отпускная цена какого-либо комплектующего более цифры 92233,72, то в спецификации в столбце "цена" появляется это число со знаком минус. Соответственно себестоимость тоже неверная. Пробовал подключить чужую базу. Та же самая песня. Значит проблема не в настройках СО. КСТ точного ответа не дают. Пишут, что - "не могу сказать почему, что-то не так видимо всё же. Сервер, клиент, сама база (или настройки в ней)." Вторая проблема. База и сервер стоят на отдельном компе под ХР. На нем никто не работает. Рабочие компьютеры работают под ХР, кроме одного нового. Он под "семеркой". На одном и том же изделии себестоимость под ХР и семеркой одинаковая, а вот стоимость почему-то разная, причем значительно. Кто знает как решить эти проблемы? Заранее благодарен. Супер Окна 2006 сборка 20, Firebird 1.5.

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

Если Вы имеете ввиду размер 960 вместо 920, то исправьте укорочение с 40 на 80. (В доборах действительно укорачивается на одну сторону почему-то), а так считает все правильно, но как точно заметил уважаемый viollan, при таких настройках расчет будет верен при обвязке расширителями. Точнее сказать так, горизонтальный расширитель будет всегда укарачиваться, даже если он один. Чтобы этого не происходило для одиночного расширителя нужен другой абстрактый артикул, ну и естественно все прочее, вставки, соединения. Еще один минус такой настройки, то, что она работает только для одинаковых расширителей, потомучто укорочение ставится именно на ширину добора. Из-за этого у меня, если честно, настроено через соединения, а не вставки. Но я боюсь пытаться объяснить как настроить. Там все абстрактно и плюс ко всему действительно есть баг в программе. Только он в угловых соединениях. Если построить раму с чередующимися профилями (на пластике такого по-моему не бывает, а на дереве сплош и рядом), и вставки прописывать именно в соединении, то вместо 4 элементов рамы программа может выдать 8, 6 или 5 элементов, взависимости от настройки других соединений. Я кое-как обошел этот баг, и до конца сам не понимаю принципа настройки. Имея 24 рамных профиля, пришлось каждую пару проверять, разбивать на разные соединения с разными настройками. То же самое просходит, если пытаться настроить доборы с разной шириной. Там как раз чередование просходит. Два вертикала одной ширины, два горизонтала другой. Я просто не смогу объяснить принцип. У меня все это работает корректно, но добился я этого экспериментальным путем.

Некий произвольный парень, я сам, а к человеку я обратился за помощью, хоть как-то обойти этот косяк СО. О невиновности никто и неговорил. А для обучения сотрудников решили открыть платные курсы "Осторожно, СуперОкна" и тренажерный зал, чтобы веселее толкали погрузчик со с/п за ворота. А теперь снимем лапшу уважаемого Observer, дабы не мешала. Видимо я сильно отстал от жизни. Всю дорогу считал, что СУБД это контейнер, а программа это программа, и они взаимодействуют друг с другом по определенным правилам. Ан нет, оказывается программный код управляет. Как же это вам ребята, написавшие FireBird, разрешили такое. Структурирование,смещение - это так интересно. За инженеров внатуре обидно. А вот КСТ-ым математикам-аналитикам и Observerу не помешало бы тоже книжки почитать. Например таких авторов, как Канторович и Мухина. А то раскрой в СО какой-то отстойный, а листовой. так вообще убыточный. У нас работяга с похмелья на производстве экономнее раскраивает. И еще совсем уж непонятно, почему после раскроя в изделии нельзя даже цвет ручки поменять, наверное структурирование и смещение при шифровании мешает. По поводу выложить реализацию тетриса. Мог бы выложить свою версию раскроя на PHP, да боюсь сдуете и скажете, что ваше. А я его для других целей готовлю. Да, очень простое, но мы не ищем легких путей. А вообще, повторюсь. Не здесь ли собака зарыта.

Айболит, человек, который отлично знает настройки Супер Окон. Я обращался к нему за помощью в настройке с/п в программе (тему настройки на этом форуме тоже я поднимал). Проблема для моей компании довольно серьезная. Результатом некорректной работы СО стали с/п на общую сумму 500тыс.р., которые просто вывезли за проходную для всеобщего растаскивания. А причина всего этого невозможность правильного вывода формулы стеклопкета. Для маленьких цехов это небольшая проблема. Один человек обычно и менеджер и логист и тех.задания он же. У него все в голове. А более крупным компаниям что делать. Есть фирмы в которых отдельно логист занимается только с/п. У нас проблема возникла, когда пришел новый логист. Ввиду запарки и нехватки времени, никто ей толком не объяснил как и чего, она и назаказывала как СО6 выдает. Пол-лимона на помойку. А проблемы с увеличением поля в БД я тоже особой не вижу. Работаю с БД очень давно. Начинал еще с dBASE на 16-разрядных компьютерах, потом Clipper, FOX. C Access сравнивать не буду он идет уже с оболочкой. Но обращение к БД стандартизировано языком SQL и я не думаю, что CO, написанные на Delphy, как то по другому работают с БД. Язык запросов не зависит от длины поля. Ради интереса скачал драйвер FireBird для ODBC. Спокойно открыл базу в Access, можно и в Excel открыть. Может, конечно, есть затруднения именно при шифровании и дешифровании, но это, ИМХО, не такой большой объем переделок. Видимо тут все гораздо проще. Зарезервирована возможность подзаработать за отдельную плату по индивидуальному запросу. Попробуйте определить процент пользователей, которых устраивают настройки с/п. И кому повредит увеличение длины поля?

В данной ситуации, насколько я понял, ненужно использовать переменную. Прямо в текстовое поле можно ввести [[Изделие:закуп.стоимость]*0.3]. Переменные есть смысл использовать, если необходимо несколько раз к ней обращаться или накапливать какие-то данные по всему документу. Например просуммировать ZP по всем изделиям. А для конвертации String в Double, используются функции ONLYDIGITAL (удаляет все кроме цифр, десятичную запятую тоже, поэтому осторожно) и DOUBLE (преобразует строку цифр в число). В случае с ZP ошибка скорее всего возникает на переменной ZP, видимо Вы ее неправильно описали, потомучто [Изделие:закуп.стоимость] имеет цифровой формат.

Тогда попробуйте конкретнее описать сам параметр. Напишите, например: "Форма штапика для с/п 24 мм". У меня похожая ситуация была с цветами ручек. Позже переделал, но временно выкручивался именно таким способом. В принципе менеджеры ни разу не ошиблись.

Просто разделите на разные соединения. В соединении со с/п 24мм испльзуйте параметр выбора штапика, а в соединении 32мм вставьте, только нужный единственный штапик без параметра.

Yojik, что же Вы такой злой-то. Я спросил совета, чтобы уменьшить общие трудозатраты сотрудников на работе. Что такое настоящая технология Вы и понятия не имеете. Потому что Вы не имеете понятия о технологии сушки древесины, о технологии резания древесины, о технологии склейки древесины, о нанесении прозрачных, лессирующих, непрозрачных, огнеупорных, термостойких и с разными эффектами покрытий. То что вы называете технологией, существует на дереве как дополнительная опция в виде дерево-алюминиевых конструкций и деревянных окон с защитно-декоративными алюминиевыми накладками (думаю Вы даже не знаете, чем одно от другого отличается). И если Вы один за полдня справляетесь с СО и с клиентами, то в нашей компании клиентами занимаются 6 человек 6 дней в неделю (в сезон), не считая дилеров, с постоянными задержками на сверхурочные работы. А СО6 не обеспечивает решение даже простейших задач в дереве, хотя бы потому, что в ней нет соединения трех профилей в одной точке. Я бы вообще перешел на другое программное обеспечение типа Klaes. Просто приходится пользоваться тем, что есть. И четкие формулы и цифры для стеклопакетов нам нужны, чтобы избежать ошибок и задержек в этом потоке. P.S. Прошу прощения, если кого-то обидел. Сравнивать пластик, алюминий и дерево вообще нет никакого смысла. Все равно, что сравнивать работу хлебопекаря и кондитера. Оба тесто месят, а на выходе продукты разного назначения и содержания.

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

В общем , подвожу итог всего вышесказанного. Извините господа, не хочу никого обидеть, но не сравнивайте пластик и алюминий с деревом. У Вас все профили, расширители, подоконники в типовых стандартных размерах, однажды забитые в базу стоят там без изменений всегда. У нас постоянные доработки, подстройки, добавления. На пластике никому и в голову не придет вставлять створку в створку или добавить расширитель на 345 мм. На дереве это и многое другое в порядке вещей. Некоторые профили и настройки изменяются на 1 раз, после просчета все обратно. Это вступление к моей занятости по времени. Теперь о с/п. Мне формулы нужны не для клиентов. Я с дилерами и клиентами вообще не общаюсь, для этого 5 менеджеров сидит. Поэтому от точного написания артикулов стеклопакетов, отказаться и не могу. Свои и чужие менеджеры, примечания читать попросту не будут. Они просто тупо переписывают формулы и процесс пошел дальше. Им думать и принимать решения категарически запрещено. Поэтому, прислушиваясь к советам, думаю отказаться от цветов ( я об этом и раньше думал, нет смысла тянуть весь список, из которого реально используется 25%), а прописывать каждый стеклопакет индивидуально. Для точного написания формулы использовать артикул+название. Для этого, чтобы менеджер, который просчитывает заказы, не путался, вставки к стеклопакетам прописать через вкладку "типовые стеклопакеты". Там можно задать название из 50 знаков, а на печать артикул+название, так ни у кого вопросов не будет, ни у дилера, ни у поставщика. Для правильного расчета себестоимости косых и арочных с/п использовать разные вставки с коэффициентами во вкладке "Стеклопакеты". Для защиты от "пролета" на малых и больших размерах, прописать наценки во вставках на вкладке "Заполнения". Не знаю только, будет ли все это работать в комплексе. Цены, видимо, так и придеться просчитывать в Excel, потом закачивать в СО6.