CбИС++ «БИТ»
   О ПРОГРАММЕ   
   О КОМПАНИИ   
   ЗАГРУЗИТЬ   
   ДОКУМЕНТАЦИЯ   
   · Руководство пользователя 
   · СБиС news
   · Статьи
   · Функции
   ПРАЙС-ЛИСТ   
   ВАКАНСИИ   
   АВТОМАТИЗАЦИЯ ТОРГОВЛИ   
СБиС news №44 от 12.04.01

Содержание

Фильтрация данных при экспорте

Ещё в 1.8 появилась возможность настроить файл импорта-экспорта – «sbis.io» таким образом, чтобы экспортировались только записи, соответствующие определенному условию. Делается это примерно так:

+Расходные накладные:GIVE.TBL =Тема!="РОЗ"

То есть просто после имени таблицы ставим знак равенства – «=» и пишем некоторое условное выражение. Результат вычисления выражения и будет использоваться для фильтрации данных – выполнилось успешно, запись будет записана во внешний файл, не выполнилось, запись будет пропущена.

При импорте данных это условие просто игнорируется.

Используя данное свойство, можно фильтровать и записи из связанной таблицы. Скажем, если нужно отобрать наименования в накладных, пишем:

+Расход:GIVEA.TBL = ПодСтрока(Признаки,7,1)==" "

При экспорте расходных накладных с такой настройкой непросчитанные (белые) наименования  экспортироваться не будут.

Указание точного положения внешних файлов

По умолчанию при импорте/экспорте СБиС запрашивает имя каталога, в котором должны находится файлы с внешними данными. Чтобы избежать этого запроса, достаточно явным образом указать в sbis.io имя каталога. Например, так:

+Организации:c:\DIR\ORG.TBL

Если с такой настройкой экспортировать организацию, диалог запроса пути не появится, а в каталоге «C:\DIR» будет создано три файла – «org.tbl», «bank.tbl», «raccs.tbl». При импорте – всё аналогично.

Задание формата внешнего файла

Как правило, импорт-экспорт используется в СБиС’е для решения трех основных задач: обмен данными между филиалами предприятия, начальное заполнение данных при внедрении комплекса и выдача данных в формате DBF для обработки другими программами.

В последнем случае очень часто бывает важен формат полей (тип, длина, точность) во внешнем файле. Одним из вариантов решения этой проблемы была бы возможность задавать формат в конфигурационном файле «sbis.io». Однако в настоящий момент предлагается более простое решение – создавать dbf-файл нужного формата средствами других программ и использовать его при экспорте данных из СБиС'а. В версии 1.8 это было, мягко говоря, не совсем удобно: файл должен был иметь хотя бы одну запись, иначе он удалялся и на его месте создавался такой же с форматом по умолчанию. В версии же 1.9 ситуация коренным образом улучшилась: даже если внешний файл пустой, выдается соответствующее сообщение и предлагается четыре варианта действия:

1.  Удалить файл.

2.  Удалить записи (по умолчанию).

3.  Добавить в файл.

4.  Отмена.

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

Импорт-экспорт иерархии

Для экспорта/импорта иерархической таблицы теперь достаточно в файле «sbis.io» в списке экспортируемых/импортируемых полей этой таблицы добавить поле иерархии. Тогда при экспорте будут добавлены во внешний файл и записи разделов, а импорте соответственно записи попадут в нужные разделы.

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

+Организации:ORG
 Наименование
 ИНН
 ОКПО
 ОКОНХ
 . . . .
 Организации

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

При импорте с иерархией узлы ищутся по тем же правилам, что и листья. То есть, например, для идентификации организаций используется поле «ИНН».

К сожалению, экспортировать/импортировать иерархию документов не получится.

Привязка наименований документов к складам при импорте-экспорте

Данная заметка поясняет механизмы, по которым наименования при импорте-экспорте привязываются к карточкам на соответствующих складах. Поскольку с этим вопросом часто возникают сложности, давайте проясним ситуацию.

В комплексе СБиС++ склад определяется номером (поле «N склада» в складской картотеке). При переносе складских документов из одной базы в другую могут возникать проблемы, связанные с нумерацией складов. Одинаковые склады могут иметь как и одинаковые номера, так и разные.

В последних выпусках 1.8 склад, к которому будет отнесен документ (и, соответственно, его наименования) определяется по следующим правилам.

1.  Если вместе с документом экспортировался номер склада (в «sbis.io» есть строка «N склада»), документ попадает на склад с таким номером.

2.  Если номер склада не экспортировался, но на папке документов склад указан, документ попадает на него.

3.  В противном случае документ попадает на самый верхний склад в списке.

Теперь разберём несколько возможных ситуаций и пути их решения.

>  Если номер склада указан, но его требуется игнорировать, вставьте в «sbis.io», используемый при импорте, следующию строку:

N склада:qq

«qq» – поле, которого реально нет в таблице. В этом случае склад подставится по правилам 2 или 3.

>  Если же необходимо передать документ на определенный склад, то можно написать так:

N склада:=8

В этом случае документ подставится на склад «8», вне зависимости от других настроек.

Счета, в отличие от накладных, не задают склад в шапке документа. Кроме того, разные наименования в них могут относиться к разным складам. Поэтому для этих документов строку «N склада» нужно вставить в описания импорта/экспорта таблиц «Наименования счета», «Наименования фактуры» или «Наименования заказа».

В версии 1.9 номер склада автоматически экспортируется для всех накладных, его можно не определять специально в «sbis.io»

Михали Сергеев (sbis@tensor.ru)

Загадочное Ctrl+L на документе

Оказывается, уже начиная с версии 1.8, в реестре документов можно нажать <Ctrl+L> на документе и… впрочем, предоставим слово первоисточнику.

Ctrl+L - изъять документ из документооборота. При этом из папок сотрудников удаляются все события по данному документу, а сам он помечается минусом в крайней правой позиции.

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

Операция обратима, то есть при повторном нажатии <Ctrl+L> документ вернется к нормальному состоянию.

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

Дмитрий Волков (volf@tensor.ru)


<<< Предыдущий выпуск | Архив выпусков | Следующий выпуск >>>