Трудно представить, сколько бессмысленной механической работы приходится выполнять нашим библиотекарям до тех пор, пока сам не окажешься на их месте. Из-за проблем с компьютером, комплектаторы попросили меня перенести описания 10 журналов из базы Подписки(Post) в CMPL. Я взялся за работу, предполагая, что это займёт не больше 5 минут; на это ушло около часа! Проблема оказалась в том, что ряд полей не переносились в CMPL.
Предлагаю способ их заполнения основанный на использовании «Настроек пользователя». За счёт этого добавляются возможности автоматического заполнения полей:
1. Цены
2. Года
3. Периода
4. Шифра(при его отсутствии запись не может быть сохранена)
5. Авторского знака

Вот изменения, которые необходимо внести для этого в файл MOVEKPS.FST
903 0 &unifor('+Khav.mnu|',&unifor('+S0',v200^a" ")),'-',&unifor('R')
908 0 &unifor('+Khav.mnu|',&unifor('+S0',v200^a" "))
33 0 &unifor('IPRIVATE,GOD,'),&unifor('IPRIVATE,PP,')
34 0 if &unifor('IPRIVATE,PP,'):'/1-1' then v3411^A else if &unifor('IPRIVATE,PP,'):'/1-2' then v3412^A else if &unifor('IPRIVATE,PP,'):'/1-3' then v3413^A else if &unifor('IPRIVATE,PP,'):'/1-2' then v3414^A else if &unifor('IPRIVATE,PP,'):'/0' then v340^A else if &unifor('IPRIVATE,PP,'):'/1' then v341^A else if &unifor('IPRIVATE,PP,'):'/2' then v342^A else fi fi fi fi fi fi fi

1. Предложения относительно формирования полей 33 и 34 касаются варианта работы, когда из БД POST в БД комплектования переносятся (копированием) отмеченные записи без предварительной работы с ними; при этом признак для "Переноса заказанных" (по предлагаемой технологии), которым служит число подписанных комплектов (^B в полях 3411, ...) не вводится.
Если комплектаторы сами работают в БД POST по предложенной технологии, а не переносят (или просят администратора перенести) записи копированием, то работает основной вариант, а предложенный можно добавить в качестве альтернативного.

2. При отсутствии поля 903 в новых описаниях (РЛ OJK) оно формируется автоматическии, правда, без использования авторского знака (поле 908)

Да, действительно, в первоначальном варианте так же есть возможность переноса цены, и периода. Но работа по этой технологии связана с целым рядом неудобств:
1. Требуется выделять и редактировать записи в двух базах вместо того, чтобы делать это в одной. Ведь сведения об отделе библиотеки, куда должен поступить журнал и количестве экземпляров нельзя указать в базе Post.
2. Приходится вносить сведения о периоде подписки в каждую запись каталога Post, вместо того, чтобы делать это в пакетном режиме. В случае, когда переносится 10-20 записей это очень утомительно.
3. Создание уникального шифра из поля 903 записи типа Post невозможно, так как это поле отсутствует в рабочем листе и не предусмотрено конвертерами. (903 0 if v903.1='-' or a(v903) then v200.1"!" else v903 fi). Нельзя это сделать и взяв первый символ строки заглавия, так как это маркер подполя – символ «^». И такая структура поля в записях нашей базы определена конвертером (!iк1.fst), который создаёт подполе ^A в поле 200. (200 0 (|^A|v10,/)).
4. Заполнение поля Шифр значками «^!» не позволяет сохранять запись после редактирования, вызывая недовольство ФЛК.
5. Учитывая, что в autoin.gbl для простановки шифра используется оператор ADD, единственным способом создать правильный шифр на основе ББК и т.п. является удаление символов «^!» и сохранение.

Конечно, все эти недостатки не мешают объединить оба способа переноса, предоставив выбор самим библиотекарям.

PS. Пожалуйста, обратите внимание на то, что в каталоге post последней демонстрационной версии (с FTP [ftp.gpntb.ru]) находится два файла конвертера !iк1.fst !ik1.fst, различающиеся, буквой К в имени; у первого – латинская, у второго – кириллическая. В Importw.mnu прописан конвертер с кириллической буквой, который в отличие от своего аналога с латинской как раз и формирует подполе ^A.

Да, относительно формирования шифра в movekps.fst Вы правы - мы упустили поправить эту строку для второго варианта формирования поля 200 (первоначально оно формировалось без подполя), хотя для строки 200 0 ... это изменение было учтено.
Поправим строку для поля 903 следующим образом.
903 0 if v903.1='-' or a(v903) then if v200:'^a' then v200^a.1"!" else v200.1"!" fi else v903 fi.
Ваш вариант, как альтернативный вариант работы, также учтем.