Добрый день!
Возможно ли в БЭСТ-5-3.4 реализовать следующую задачу?
Многосегментную аналитику в типовых операциях формируют FileEval().
Хотелось бы перед генерацией проводок проверить - все ли необходимые поля заполнены и правильно ли. Если нет, то на экран выдается сообщение чего не хватает и что нет так. Проводки в этом случае не генерируются. Если все Ок!, то проводки генерируются.
Вариант вставлять сообщения в FileEval(), формирующие аналитики не подходит. Проводки в этом случае формируются. Но основная беда в том, что сообщение появляется столько раз сколько строк фактурной части документа. Как от этого уйти не знаю.
Да, есть такое дело.
Если поставить обработку плагина в поле суммы и возвращать 0, то проводки не сформируются, но обработка производится по позициям документа.
Может сделать решение с буфером, в который сложить найденные проблемы и вывести отчетом на последней строке?
Или сделать проще, выдавать сообщение на первой или последней позиции документа.
Не лучший вариант, но попробуем.
Не лучший потому, что если типовая операция из нескольких проводок, то плагин на суммы надо ставить в каждом, чтобы проводки не формировались. Поскольку плагины к тому же формируют аналитики, то на одну типовую операцию их становится "много".
Хотелось бы чего-нибудь по-проще и по-надежней. Типа события "Перед формирование проводок". Если .Т., то формируем. Если.F., то не формируем.
И от параметров шапки и от введенных позиций.
Но хотелось бы иметь Событие и не как частный случай, а как правило. И не только для складских документов, но и для имущества и других возможных подобных документов.
Нет конечно.
Как показало практика, даже при штатном программировании проводок в других ПП, поддерживать это не получается. Чаще бывает проще добавить новую простую конкретную типовую операцию, чем снова погружать в старый алгоритм.
Виктор Балановский пишет:
И от параметров шапки и от введенных позиций.
Но хотелось бы иметь Событие и не как частный случай, а как правило. И не только для складских документов, но и для имущества и других возможных подобных документов.
Плаги в алгоритме расчета суммы, как предлагалось выше мне видится единственным решением на сегодня.
Не пробывал, но думал.
Здесь два момента:
1) Что начинается вперед: генерация проводок или сохранение полей документа? Конечно, это можно проверить.
2) Но как после проверки заполнения полей, снова перенаправить программу на работу с полями документа, а потом снова выйти на плагин и т.д. (как организовать такой цикл)?
Виктор Балановский пишет:
Не пробывал, но думал.
Здесь два момента:
1) Что начинается вперед: генерация проводок или сохранение полей документа? Конечно, это можно проверить.
2) Но как после проверки заполнения полей, снова перенаправить программу на работу с полями документа, а потом снова выйти на плагин и т.д. (как организовать такой цикл)?
Проверку поставить на "перед записью", а "продолжение" сделать на после записи...
Если проверка вернет .F., то Б-5 сам заставить оператора продолжать редактировать документ до тех пор, пока он не отменит корректировку\ввод или проверка вернёт .Т. .
Если еще требуется передача параметров, то можно сделать чз глоб переменные. Я такое делал из события работа в реестре в другие... Если переменная была объявлена она не уничтожается до тех пор, пока пользователь не вышел из реестра.
Код
//Плагин по событию перед записью
CheckIfCorrect()
Function CheckIfCorrect()
Local something,lResult:=.F.
.........
If (somthing=="OK")
lResult:=.T.
else
SayAndWait ("Mistake!")
endif
return lResult
Добрый день!
Проверяем заполнение полей в складских документах, используя вызов "перед записью". Наряду с полями документа, надо проверить правильность заполнения атрибутов карточек номенклатур и партий, вводимых в фактурной части документа. Но на момент вызова плагина строки документа еще не в базе данных, а во временных переменных и массивах.
.
Как "вытащить" параметры строк документа, а именно {Grup, Nnum, MDim, Partia} из памяти?
Просматривая все подряд переменные Private, нашел строки документа в нескольких местах. К примеру в строке (не знаю, как это правильно называется): aWindow - 2 - 7 - CARGO[1,i]. Там все параметры каждой строки документа хранятся в своей строковой переменной.
.
Как их оттуда "вытащить"? Или есть другие возможности?
Проверяем заполнение полей в складских документах, используя вызов "перед записью". Наряду с полями документа, надо проверить правильность заполнения атрибутов карточек номенклатур и партий, вводимых в фактурной части документа. Но на момент вызова плагина строки документа еще не в базе данных, а во временных переменных и массивах.
.
Как "вытащить" параметры строк документа, а именно {Grup, Nnum, MDim, Partia} из памяти?
Просматривая все подряд переменные Private, нашел строки документа в нескольких местах. К примеру в строке (не знаю, как это правильно называется): aWindow - 2 - 7 - CARGO[1,i]. Там все параметры каждой строки документа хранятся в своей строковой переменной.
.
Как их оттуда "вытащить"? Или есть другие возможности?
Добрый день!
При считывании MDIM система "ругается" на отсутствие _LEN_NNOPER.
Определил равным 22. Вроде прошло. Во избежание возможных сбоев на будующее при считывании других переменных, прошу уточнить 22 - это правильно?
Это не длина таблицы. Это длина временной переменной для определения позиции других переменных слитых в одну символьную строку, являющейся элементом массива.
Я понимаю что переменная. Но для какой таблицы ?
Для mlabel или для mdocm - там подходы разные и длина разная
В mlabel хранится указатель на значение аналитики и у него длина 22.
В накладной самой в mdim хранится непосредственное значение и там длина 30.
Длины полей через foxbro Вы можете посмотреть.
А вот про какой конкретно MDIM у Вас в задаче идет речь и
какую длину надо давать - это мне надо время чтобы разбираться.
Отсюда и предложение Вам посмотреть внимательнее какое конкретно назначение будет иметь именно Ваш MDIM. Можно,например,просто в
отладчике посмотреть какое значение Вы в него пишете отсюда и
длина будет понятна.
не тривиальный и уточнение я Вам запросил не просто так