Форум

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

3. Теория применения MetaBo в БЭСТ-5
Для начала рассмотрим простую задачу.
Допустим мы создаем решение по работе с документами, которые состоят из шапки, строк и дополнительной таблицы к каждой строке. Назовем ее аналитикой строк.
Рассмотрим задачу удаления документа:
- Стиль БЭСТ-4+
Мы по индексному ключу обращаемся к таблицам, делаем поиски интересующих строк и их удаляем
- Объект MetaBO
Мы удаляем документ и вместе с ним удаляются все нужные строки.
Итак, что получается нам дает объект.
Получается, что мы работаем со всеми таблицами документа одновременно, как с неразрывным целым. Т.е. мы можем рассматривать все строки текущего реестра (В дальнейшем буду писать «Грида») и их дочерние строки (в дальнейшем буду писать «чайлды») как одно единое целое и при работе со строкой конкретного документа я на самом деле работаю не только с его заголовочной частью, а со всем документом.
Итак, если говорить коротко объекты MetaBO нам позволяют:
- при работе в форме грида одной таблицы обеспечивать одновременную работу в этом же гриде с другими таблицами
- объект позволяет при выполнении событий (например, создание, редактирование, удаление) осуществлять контроль их выполнения сразу в нескольких таблицах
- с помощью объекта в гриде легко организовывать столбцы, значения в которых являются результатом расчета из других столбцов
Применение в форме объектов MetaBO предоставляет нам механизм одновременного использования событий к нескольким таблицам или полям, отображаемым в шапке или подвале грида.
Исходя из сказанного выше, становится понятно, что сами события, такие как ввод, удаление, сортировка являются свойствами объекта. Таким образом, в случае использования MetaBO ,например, при удалении строки – событие выполняется в соответствии с тем как оно описано в классе, а стало быть во всех гридах БЭСТа будет выполняться именно по правилам, установленным разработчиком. Изменения в штатном механизме событий разработчиком будут унаследованы во всех созданных плагинах пользователем.
Отсюда основным минусом объектов является отсутствие многообразия свойств, если сравнивать с гридом в общеизвестных системах программирования. Т.е. разработчик сделал основные возможности, которые имеют применение в БЭСТе. Дополнительные возможности предстоит дорабатывать по мере появления такой необходимости

2. Структурное программирование и объектная парадигма .

Рассмотрим задачу – изменить значение поля FIELD1 ( новое значение – “Привет”) таблицы TABLE1 у записи с № 10.

Решение (структурное программирование XBase++):

1 DbSelect(0)
2 DbUse(“TABLE1”)
3 DbGoTo(10)
4 DbRLock()
5 DbPutField(“FIELD1”,”Привет”)
6 DbRUnlock()
7 DbCloseArea()

Решение 2: (структурное программирование XBase++)

1 Local cAlias := Alias()
2 DbUse(“TABLE1” , cAlias)
3 (cAlias )->(DbGoTo(10))
4 (cAlias )->(DbRLock())
5 (cAlias )->(DbPutField(“FIELD1”,”Привет”))
6 (cAlias )->(DbRUnlock())
7 (cAlias )->(DbCloseArea())

Решение 3: ( классовый подход БЭСТ5)

1 Local x := new DbTable(“Table1”)
2 x:Goto(10)
3 x:PutField(“Field1”,”Привет”)
4 x:Close()

Объектная парадигма, а затем и целая плеяда ОО Языков, реализующих ее, возникли не случайно. “Все что существует – необходимо” (Гегель). Наследование, инкапсуляция, полиморфизм – вот основные идеи ООП. Какие задачи призваны решать эти идеи. Когда Ваш проект состоит из сотен строк кода, то я думаю принципиальной разницы между структурным программированием и ООП – нет. А вот когда проект разрабатывает бригада, состоящая из нескольких десятков разработчиков – проект “стремится” выйти из под контроля, структурные подходы значительно проигрывают.

Инкапсуляция.
Основное назначение инкапсуляции – сокращение числа ошибок и периода тестирования. Если не играться в дефиниции, то инкапсуляцию можно определить как способ объединения данных и методов, обрабатывающих эти данные в одном месте (классе). В нашем примере (3) метод PutField класса DbTable реализует блокировку таблицы, модификацию данных и снятие блокировки. Использование класса дает нам не столько сокращение числа строк в проекте, сколько избавляет нас от человеческой забывчивости (обычно – забывают не только блокировать, но и снимать блокировки). Думаю, вполне очевидно, что когда речь идет о сотнях тысяч строк кода выигрыш будет весьма ощутим. Инкапсуляция, как впрочем ООП в целом призвана скрыть от пользователя (программиста, использующего класс) тонкости реализации.
Пример из жизни. В процессе использование класса DbTable прикладные программисты (пользователи класса DbTable) предложили реализовать возможность использовать SQL SEL ECT предложения. Они хотели писать примерно так:

Local x := CreateDbTable( ;
“SEL ECT Code,Left(Name,20) AS NAME FR OM TABLE1 WHERE NAME LIKE “%ПРИВЕТ%”);

Сейчас так можно писать в БЭСТ5. Вся дальнейшая работа с экземплярами (объектами) класса DbTable не изменилась. x:PutField(“FIELD1”,”Привет”) .

Более того, можно писать и так x:Field1 := “Привет”. Но это уже нюансы.

Полиморфизм.
Рассматривать идею полиморфизма в не строго типизированных языках нет смысла, поэтому мы пропустим этот . Если будет особая необходимость рассмотрим дополнительно.

Наследование.
Наиболее прозрачная . Класс MetaBO наследуется от класса DbTable и инкапсулирует DbTable. Но если класс DbTable призван реализовать и скрыть реализацию всех правил работы с отдельной таблицей, или выборкой на основе SQL запроса, то класс MetaBO призван реализовать самые абстрактные идеи бизнес логики, а точнее правила работы с несколькими таблицами, которые хранят одну бизнес сущность.
Примером может выступать любой, более-менее сложный документ – накладная, карточка и т.д. Наследуясь от класса MetaBO, можно порождать конкретные бизнес сущности и использовать их в самых разных подсистемах БЭСТ5. Так к примеру подсистема Счета Фактуры использует классы подсистем Главная книга (типовые проводки), Общие справочники (классы Партнеры, Подразделения и т.д.). При этом разработчики подсистемы Счета Фактуры не должны знать тонкости реализации классов из других подсистем.

Любая задача программирования может быть решена и с использованием ОПП и структурным методом. Любая! Программирование - было, есть и будет еще очень долго искусством. Если мы сели писать программу – значит у нас есть новая проблема. Новая – не решавшаяся ранее. Способ решения всегда несколько. Единственные наручники, которые можно надеть на разработчика – это единство концепции проекта. Если уж мы используем DbUse ( или x:Use ) то лучше это делать всюду и всеми.

Вот примет: (реализация С++)
EXPORT VMAPI DBUSE()
{
// работа с таблицами DBF
DBFWorkArea *rs = new DBFWorkArea();
…
}
Или

EXPORT VMAPI DBUSE()
{
// работа с базой MSQ SQL Server
MSSQLRecordSet *rs = new MSSQLRecordSet();
Rs->Open(“SEL ECT * FROM MAIN” , “SQLSERVER:MyServer;DataBase=master;”)
…
}

1. Введение.
Для создания решений в новых окнах разработчики БЭСТа создали класс MetaBO. Изначально при создании тем-уроков я планировал рассматривать создание решений двумя путями – с применением объектов и без них, чтобы попытаться показать путем сравнения удобство их применения. В процессе более тщательного изучения предмета моя точка зрения изменилась и поэтому целью данной темы является задача разъяснить суть объектов MetaBO и необходимость их применения. Иными словами все дальнейшие темы будут освещаться с применением возможностей MetaBO, а другие пути решения будут оставлены для самостоятельных экспериментов.
Попытаюсь ниже почему и зачем я предлагаю именно такой путь изучения программирования. Для начала отвечу на простые ы.
- Можно ли при программировании в новых окнах добиться цели без применения объектов MetaBo ?
- Да, можно
- Существуют у объектов MetaBO недостатки ?
- Да, существуют
- Стиль создания решений с MetaBO обязателен для программ в БЭСТе ?
- Он не обязателен – он рекомендуем

Цитата
nordk пишет: Запускаю по ctrl + F5 плагин который описал выше.

Где Вы нажимаете ctrl-F5
ПОдробно осветите плз как Вы запускаете то, что у Вас работает

Цитата
Сергей Шелудько пишет: запускаю из №2 - проводки генерятся

Каким образом запускаете ?

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

Как его подключать.
Копируете файл в папку
C:\Program Files\BEST\BEST5_34\SERVER\DATA\PRO\PLUGINS\EXTENSNS\SCLAD
Потом запускаете БЭСТ-5.
Заходите в накладную прихода.(Я провобовал на первом типе прихода - закупки)
Ввод/корректировка -> список ->ALT-F4 (картотека)
В картотеке нажимаем CTRL-F5, F4
Наименование : отражение цены поставщика
Имя файла: test.hrb
Параметры: пропускаем
Вызов: пробелом выбираем "работа в реестре"
Горячая клавиша: пропускаем

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

Вот примерно так легко и непринужденно за несколько минут можно решить плагином (иногда) частные просьбы.
И этот подход в автоматизации тоже не стоит исключать

Лена я охотно верю что в каждой фирме свое удобство работы.
Но вот с этого момента разговор переходит в разрез общепризнанного удобства работы и частного.
Исходя из этого вознивает изменение штатного механизма или разработки дополнительного плагина под заказчика.

Механизм прихода в туже партию убирать нельзя потому как существуют режимы и решения в стиле возврата или обмена между магазинами в сети товарами действительно одной и той же партии.
Карточка партии на самом деле кроме цены содержит поставщика, дату поступления, срок годности и так далее. В связи с этим цена поставщика не единственный параметр в общем случае который надо анализировать и задача распадается на множество мелких.
Получается что разработчик должен дать инструмент, при котором пользователь сам будет определять состав формы экрана. Как только это будет сделано - ТУТЖЕ !!! - появятся требования специализированных фильтров, поисков и сортировок. И что самое любопытное многие клиенты взгялнув на все это скажут а нам это и не надо было - лучше бы сделали что-то другое..... А еще есть многосегментная аналитика, возможность применения нескольких штрих-кодов к одной номенклатуре и так далее...
Это все частные, редко встречающиеся случаи. Их разнообразие велико.
Их можно реализовать плагином именно под Ваши конкретные пожелания на самом деле.

Т.е. путей решения несколько:
- пересмотреть организацию труда с учетом возможностей версии 3.4
- заказать плагин
- просить изменение штатного решения под частный случай....

Каждый вариант имеет право на существование, кроме одного - БЭСТ-4 не имел очень много из того что теперь есть в БЭСТ-5, поэтому к оценке а нельзя подходить со старыми стереотипами. Они изменились и это стоит принимать во .

p.s.
Честно говоря мне искренне жаль операторов в рознице, которые заносят документы прихода вручную - это убивает столько времени, что непонятно где они могут найти время на работу более значимую для розницы. Оформление приема товара у своих клиентов я всегда пытаюсь убедить автоматизировать и ускорить. Это моя субъективная точка зрения.

Обязательства свои исполнил.
Получил ответ разработчика, что текст в отредактированном виде а может и переписанном полностью получу ориентировочно в понедельник.

Цитата
Лена пишет: Добрый день. С моделью калькуляции все нормально. А цена поставки, если мы используем старую партию, не садится. Я уже писала, что нам не удобно разводить сотню партий

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

Цитата
Лена пишет: Почему в БЭСТ4+ такой проблемы не было?

БЭСТ-4 при наличии движения по партии также не позволял никогда просто так менять цену партии - вероятно Вы что-то путаете.

Цитата
Лена пишет: Да и потом, когда мы выбираем нужную позицию в картотеке при оприходовании, показывается только складская цена

И это правильно - если Вы все время приходуете в партию - зачем Вам тогда партионный учет ?

Цитата
Лена пишет: Методом "тыка" выбираем нужную позицию, приходуем, делаем кучу ошибок, исправляем. Не слишком ли много минусов в программе? Почему бы не посмотреть, как это делается в БЭСТ4+? Во всяком случае когда мы перешли на БЭСТ5_33 в 2007 году, там все работало.

Лена наверно Вам стоит посмотреть на организацию труда. В БЭСТ-5 все режимы БЭСТ-4 работают. Но Стиль жизни как в БЭСТ-4 устарел. Приглядитесь к БЭСТ-5 внимательнее.
Не спешите, поробуйте понять удобства. Я готов Вам помогать и подсказывать.
Но заносить в одну и туже партию приходы - это правило дурного тона эксплуатации системы. Очень не рекомендую так работать.

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

Цитата
Александр Гершанов пишет: Скорее всего буду делать внешнюю программу с использованием FOX (правда, раньше не работал с memo полями, а они там используются существенно (для разных ставок НДС). Но полагаю, в FOX есть соответствующий оператор.

Фокс не умеет корректно работать с индексами харбора в БЭСТ-4. Будьте аккуратны.
И еще Вам нужны счета-фактуры или записи в книгу продаж ? Или и то и другое ?

Цитата
Пчелка пишет: Коллега, совершенно с Вами согласна, процесс очень Творческий переписки процентов на 90. А особенно если учесть сложность наших плагинов: например, генерация расходных накладных в товарах из внешней системы. Послышалось привычное эхо.

Я бы не спешил с такими утверждениями. У меня есть плагины которые на 100% подходят к БЭСТ-5. В частности написанная задача инвентаризации розничного магазина прекрасно запустилась сразу.
В БЭСТ-5 такой же харбор.
Вы путаете язык программирования с методологией работы. БЭСТ-5 имеет множество улучшений, которых в БЭСТ-4 просто не было и в связи с этим прямой перенос старых
технологий работы не всегда оправдан.

Что касается генерации документов извне это был изначально подход программирования в нерекомендованном стиле и соответственно наследовать такие решения для БЭСТ-5 было бы неправильно.

Если это как-то поможет могу выложить исходный код NUMTOC

Поменяйте ключ на USB и не мучайтесь
Через переходник гарантий работы ключа никаких нет.
Могу более того сказать что даже не при всякой настройке БИОСа материнской платы при наличии ЛПТ порта ключ должен видется, а Вы хотите чтобы обязательно через переходник заработал.

Ну тогда все должно работать.
Описание есть в хелпе.
У Вас что-то конкретное не получается ?

GenPro - это функция для генерации проводок в модуле Товары либо Материалы.
Вы про какие документы пишете ?

А можно подробнее описать параметры раб станции ?

Цитата
Пчелка пишет: Спасибо за понимание. Меня директор спрашивает конкретные сроки, и хотелось бы знать самим писать или подождать какое-то время.

Если Вы можете написать сами, то я бы на Вашем месте пока написал.
То, что Вам надо через объекты БЭСта за один день можно реализовать плагином с
узкими настройками под Вашу специфику....
Другими словами объем работ не такой большой, что позволяет рассуждать о временном решении...

На этой неделе начну публикацию материалов дальше

Я Вам аытаюсь помочь, но мне для эотго нужно понять Ваши задачи.
Обмен данных сейчас сделан гораздо правильнее, чем был в БЭСТ-4.
Вас же интересует по сути не обмен данных а передача первичных документов из модуля Товары - это не одно и тоже.

Т.е. если я Вас правильно понял товар на центральном складе реально отгружается на филиалы ?
Или только документ заводится ?

Дело в том, что удаленные филиалы и обмена накладными в БЭСТ-4 это далеко не одно и тоже. И спопоб организации труда соответственно должен различаться.

Давайте более детально рассмотрим именно Ваш
Какими документами Вы обмениваетесь 3 раза в день и какова цель частоты такого обмена.

Если говорить про решение со стороны программного обеспечения.
Для весов масса-к у нас есть плагин для БЭСТ-4+ готовый.
Работает с 2001 года.
У Вас какой БЭСТ ?

Если со стороны железа - у вас должная стоять специализированная плата и специализированная программа к нему. Мы из плагина обмениваемся с этой программой.
Вообще весы Масса-К по цене/качеству не лучший выбор в этот ценовой диапазон можно было приобрести весы с прямым общением через TCPIP