Возникла проблема, возможно связанная с использованием fileeval в формуле вычисления аналитики.
При попытке сформировать свод за текущий расчетный период по счетам затрат выдается ошибка:
При открытии reestr возникла ошибка:
salary_svod_period_schet.openarea ...salary.vct error in line 262
File 'fileeval.prg' does not exist.1
Ошибка, как я понял, напрямую связана с тем, что в файле opercont в поле dtf стоит вызов функции. Как можно избежать этой ошибки?
Хотелось бы и проводки по формуле оставить, уж больно красиво они формируются, и отчеты получить )))
Итак,
в типовые операции по начислениям и налогам ЕСН добавляем проводки по упр. плану счетов.
На один счет одну проводку, в формуле суммы условие по категории P12 ( в нашем случае)
Всего три проводки, в итоге.
Т.к. счета аналитические, в формуле расчета аналитики делаем вызов функции fileeval('@CodeCfoSal')
сама процедура:
Код
Procedure CodeCfoSal()
Local cCodeCfo
Do Case
Case cardspri->c_struct="100410"
cCodeCfo:="1-01"
Case cardspri->c_struct="100420"
cCodeCfo:="1-02"
Case cardspri->c_struct="100430"
cCodeCfo:="1-03"
Case cardspri->c_struct="100450"
cCodeCfo:="1-04"
OtherWise
cCodeCfo:="6-"
EndCase
Return cCodeCfo
В итоге получаем расширенную картину проводками по упр. плану счетов.
на каждое подразделение возможно использование конструкций IF ENDIF по должностям либо другим признакам.
А вот по промежуткам..
Наверное экран подготовить надо.
Думаю, что игра с цветом интерфейса не предусмотрена, кроме случаев выделения цветом полей с данными.
И все-таки есть способ не плодить проводки с разными аналитиками
Необходимо написать блок анализа и вызывать его из формулы расчета аналитики.
В кор.счете должен быть определен счет, с активированным аналит. учетом, тогда при выполнении расчета типовая операция будет выполняться для каждого вида начисления, для которого определена. И если в формуле тип.оп. будет 3 проводки с таким вызовом, то на каждую запись в начислениях будет вызываться блок анализа.
Насколько будет замедлен расчет - надо проверять, но уже сразу надо ориентироваться на неприменение функций, открывающих и связывающих БД. Т.е. блок анализа должен быть исключительно аналитическим. Проверка условия и результат.
Что получится - напишу.
Вот: "новый заказ"->Выбор партнера "Реестр партнёров" (с этим все в порядке)->Выбор изделия по нажатию кнопки добавить изделие "Реестр изделий"(тоже номально)->"создание изделия" тоже все норм->Возврат в исходную позицию, там где кнопка добавить изделие
А при каждом добавении в окошке висит то, что уже пользователем выбрано. Вот именно с этим списком и проблема, не знаю как реализовать
Сделать реестр, запись либо во временный файл либо непосредственно в заказы.
С временным файлом тормозов быть не должно
ОК.
а что мешает "(завести партию в картотеке скл учета, включить в прайс и набить заказ.)" в программном режиме?
Если содержимое заказа формируется индивидуально по определенной таблице соответствия, т.е. если с этой задачей можно справится программно.
Как я понял для изделия, которое будет в заказе, базовыми данными являются геом. размеры.
Если такая цепочка осуществима, не проще ли реализовать ее?
1. поступление данных от клиента (заказ на услугу изг.)
2. Обработка данных -> новая номенклатура (по событию - сохр.заказа)
3. Инициализация нового объекта ТМЦ в системе (партии, картотека скл. прайс) (плагин)
4. Генерация нового заказа (плагин)
5. Вывод сообщения с номером заказа
6. Оператор входит в заказ и печатает документы.
Если нет, то
1. Поступление данных от клиента оператору
2. Обработка данных оператором с помощью плагина
3. Инициализация оператором (номенклатура, и т.д.)
4. В реестре заказов по горяч. клавише оператором вызывается процедура создания заказа
5. открывается свой инитлист (при этом надо заполнить шапку)
6. Оператор набивает заказ, включая в него подготовленную номенклатуру
7. Выходим в реестр, заходим вновь чтобы распечатать заказ.
Мне сложно представить все ваши БП, это просто как рекомендация к просмотру всех доступных вариантов.
Если делать свой реестр заказов, на базе системного, затем еще и притягивать печать.
Представляете объем работы?
Услуга на изготовление, новая услуга = старт бизнес процесса по подготовке пр-ва заказанного изделия. Далее (я на ходу уже проигрываю), скажем по сохранению плагин обрабатывает заказ, если создана новая номенклатура запускается ваш плагин для создания номенклатуры, проводятся все необходимые действия, в режиме диалога, и формируется заказ (обычный или производственный). оператору останется зайти и распечатать.
В итоге используем системные реестры, и свою математику.
В стандартном заказе есть возможность использования спецфункций.
А почему бы в вашем случае не использовать заказ на услуги, работы, допускающий ввод номенклатуры.
Скажем, услугу по изготовлению такого то изделия.
Потом уже после технол. обработки создавать на основании этого заказа и номенклатур заказ продажи или производственный заказ.
Сразу , чем не устраивают штатные средства ведения заказов?
Тем более если используется системный файл. Если использовать свои таблицы - дело другое, и с удалением решается несложно.
Лично я стараюсь придерживаться принципа - создавать запись в системную таблицу только в том случае, когда прекрасно понимаю смысл значений всех полей. Иначе потом можно наступить на серьезные грабли.
На старом форуме, как упомянул Константин - уже все самое необходимое рассматривалось.
Основные и необходимые функции приведены в отдельной теме.
Дело в том, что при написании пользовательских программ "БЭСТовские" функции нужны в строго определенные моменты. Если вы только не собираетесь писать новый модуль по всем внутренним правилам БЭСТа. Описание по XBA не отражает полно, но близко соответствует программированию в Б5.
initlist - основная функция для работы с реестрами. Составить картину по работе с ней легко, материала достаточно. В инструментарии функции разработчика по Б4 приведены в исходных кодах.
По классам - тема интересная, пока малопонятная. Со временем разберемся, я думаю.
Сегодняшний БЭСТ-5 система молодая, хотя бренд старый.
Разобрался, когда счет задан из плана счетов, не параметром, то все работает как надо.
Если есть аналитика, конечно же, в противном случае формула просто не обрабатывается.
С параметрамм #12324 БЭСТ ругнулся, но использование параметров и не требуется.
Спасибо)
Какой размер базы?
Это отдельной темы, открывайте - обсудим.
Больше интерфейсных отличий, первое время непривычны отчеты, но из практики, персонал, выполняющий функции операторов на складах, вошел в рабочий режим практически сразу, после смены ярлыка на рабочем столе с 4+ на 5.
Для них ничего не изменилось кроме экрана.
ОК.
Зарплата.
Типовые операции.
Проводки операции.
Параметры формулы расчета аналитики.
Конечная задача:
Сейчас есть P01-P39, но среди них нет необходимого, в моем случае аналитики счета из управленческого плана счетов.
Если взять и добавить поле в картотеку сотрудников, то потом можно использовать его значение для формирования проводок из функции.
Имея некий опыт в обнаружении недокументированных возможностей )) Предполагал, что если я в формуле расчета аналитики сделаю вызов функции пользователя из userlib, то она будет обработана (хотя про то что выдавать она должна прописанный параметр как-то не додумал сразу ).
Т.е. хотелось, чтобы вызов функции из формулы расчета аналитики, fileeval('@CodeCfoSal') возвращал необходимое значение аналитики.
Но функция, размещенная в этом поле, вызывается при настройке операции и не вызывается при расчете, в связи с чем и возникла эта тема.
Если рассматривать этот как доработку, то необходимо доп.измерение и механизм его использования.
Есть задача сформировать проводки по УУ (тема в форуме Б5)
Проверяю работу спецфункций.
Задаю вызов функции в формуле расчета аналитики и в формуле суммы.
При вызове процедуры расчета проводок в расчетной ведомости вызов функции из формулы аналитики не происходит (формула суммы обрабатывается штатно). В связи с чем , возможно ли формирование аналитики программно по алгоритму пользователя?
Самый лучший способ научиться, проанализировать исходники рабочих примеров.
Т.к. initlist перекочевала из БЭСТ-4, все что есть по БЭСТ-4 - применимо и в Б5.
В инструментарии к Б4 приведены рабочие примеры, вот один из них:
Код
#include "s_public.ch"
FIELD Grup,NNum,Ed //объявление полей, чтобы компилятор не давал подозрительных ссылок
PROCEDURE Reestr()
LOCAL aSetKey:=SaveSetKey() //запоминаем навешанные ранее горячие клавиши
LOCAL cScreen:=SAVESCREEN() //запоминаем экран
LOCAL nTop:=5,nBottom:=19 //верхняя и нижняя границы initlist
LOCAL cHead:='Мой номенклатурный справочник' //первый заголовок
LOCAL cHead1:='тестовый пример' //второй заголовок (под первым)
LOCAL cHelp:="F8:Удалить" //строка помощи внизу экрана
LOCAL cColHead:=; //заголовок колонок
"Группа Ном.номер Наименование Ед.изм"
*12345 1234567890123 12345678901234567890123456789012345678901234567890 12345
*1234567890123456789012345678901234567890123456789012345678901234567890123456789
LOCAL aBlockCols:={;
{{||Grup},1},; //отображаем поле Grup, начиная со 1 позиции экрана
{{||NNum},7},; //поле NNUM, начиная с 7 позиции
{{||LEFT(Name,50)},21},; //первые 50 символа наименования, начиная с 21 позиции
{{||Ed},73}; //поле Ed, начиная с 73 позиции
}
//открываем таблицу по пути sclad\mlabel.dbf c алиасом MLabel;
//функция БЭСТ LoadPath() возвращает путь до папки с БД выбранного предприятия
IF NetUse("MLabel",LoadPath()+"sclad\mlabel.dbf") //если открытие успешно
InitScreen(cHead,cHead1,cColHead,,cHelp) //специальная функция БЭСТ для подготовки экрана
InitList(nTop,nBottom,cColHead,aBlockCols) //основная процедура БЭСТ для работы с реестром
ENDIF
DbCloseArea() //закрываем таблицу
RestScreen(,,,,cScreen) //возвращаем экран, какой был до этого
RestSetKey(aSetKey) //возвращаем горячие клавиши, которые были до этого
RETURN
/**********
В результате выполнения этой процедуры, мы получили отображение простейшего
реестра, с уже готовыми горячими вызовами (по Alt) калькулятора, блокнота,
курсов валют и экспорта в Excel. Работает также клавиша F8 - удаление.
*********/
Там же есть примеры и более функциональных процедур.
Сам пакет можно скачать здесь.
БЭСТ-5 3.4 сп9
Существует дополнительный управленческий план счетов, по которому формируются проводки в типовых операциях, по аналогии с налоговыми (технически).
Там где не требуется развернутого аналитического анализа, все нормально.
Но вот в сложных случаях возникает немало вопросов. по штатному решению а.
Например, формирование проводок в модуле зарплата по логическому принципу не похожему на бух. и нал. учет.
В случае с Имуществом выручили доп. книги амортизации.
В зарплате так и напрашивается доп. измерение и механизм его использования.
Кто-нибудь уже касался этого а?
На текущий момент пока видим одно штатное решение:
в типовых операциях писать проводки с условиями на все случаи, но их может быть много.
Дело в том, что, как я понимаю, использование спецфункций из реестров пользователей, вызванных из плагинов - недокументированная возможность.
Если работает, ну и , но лучше использовать интерфейсные возможности программы.
Можно прекрасно обойтись кнопками и меню.
к примеру
не совсем так,
SET EXACT OFF сравнивает символы левой стороны по длине правой символьной строки . SET EXACT ON сравнивает символы правой стороны по длине левой символьной строки , а возможные символы пробела в конце не принимаются во . Если выражение справа содержит пустую строку (" "), оператор "не равно" возвратит значение .F.(ложь) при SET EXACT OFF, .T. (истина) с SET EXACT ON.
Все операторы сравнения - это бинарные операторы, которые сравнивают значения операндов друг с другом. В результате сравнения, если есть соответствие условию, операторы всегда приводят к логическому значению .T. (истина). Если условие не выполнено, то значение будет .F. (ложь).
! *) Сравнение символьных строк зависит от настроечных команд SET EXACT, SET COLLATION и SET LEXICAL.
Необходимо обратить на существование двух различных оператора равенства: простого "=" и точного "==".
Простой оператор равенства не может проверять все типы данных на равенство. Также, сравнение символьных строк, использующих этот оператор, зависит от установленных параметров настроечных команд SET EXACT ON|OFF и SET COLLATION. SET EXACT уточняет, рассматриваются ли пробелы в конце строк символов.
Оператор "==" может сравнивать значения любого типа данных. Переменные типов данных массива (A), блока кода (B) и объекта (O) проверяются, чтобы определить, ссылаются ли они на те же значения. Сравнивая символьные строки, оператор точного равенства возвращает значение .T. (истина), когда все символы обеих строк идентичны (бинарное сравнение). Когда сравниваются две переменные типа данных A, B или O, сравнение также приводит к истине только, когда обе переменных ссылаются на один и тот же массив, блок кода или объект.
Обычно оба операнда при сравнении должны иметь одинаковый тип данных. Однако, операторы равенства могут сравнивать все типы данных с NIL. Сравнение с NIL возвращает значение .T. (истина) только, когда значение обоих операндов равно NIL.
Оператор $ проверяет, содержится ли подстрока (левый операнд) в указанной символьной строке (правый операнд) (см. разделы для индивидуальных типов данных при обсуждении главы "Операции и операторы для простых типов данных").
"James" $ "James Bond's BMW" // результат: .T.
"james" $ "James Bond's BMW" // результат: .F.
"Bond's" $ "James Bond's BMW" // результат: .T.
"Bond s" $ "James Bond's BMW" // результат: .F.
По уникальности времени, на практике не проверял.
Но если сделать формат времени hh:mm:ss.cc
Наверняка для одной базы будет логично предположить что с одинаковыми долями секунд записей быть не должно.