Мои комментарии

Спасибо!

Спасибо!
Ну если так, то так и оставлю.
Ошибки имелись ввиду такие: что, пока еще запись сохранена в базе, есть возможность получить тот же номер MNUMINDATE. А это приведет к смешению проводок при отображении в журнале вместе с проводками. По крайне мере, в ранних версиях мы с этим сталкивались, если я правильно помню.
Чем еще опасно наличие у двух операций одинакового значения NUMINDATE?
И если удалить такую операцию, надо ли перестраивать номера по порядку или пропуски номеров допустимы?

Спасибо, попробую!
Только точно узнать, помогло или нет, можно будет со временем - ошибка плавающая и появляется иногда, просто в последнее время стала появляться все чаще, а пользователей программы ИБ у нас достаточно много.

Заинтересовал вопрос про управление ИБ через DDE.
Есть какие-то примеры, или хотя бы направление к действию.
Одна из мыслей - это заменить стандартную форму ввода операции в ИБ на свою и работать через ИС.
В этом случае возникает 2 проблемы, как узнать запись которую будут редактировать (OPER_NUMB).
и как встать на нужную запись в журнале после вставки, т.е. если мы будем создавать операции напрямую через инфо-сервер, то операции будут вставляться куда-то в журнале, и курсор необходимо перемещать на новую запись.
Возможно ли сделать это средствами ИБ, DDE или еще какими-то?

О. спасибо. Это уже лучше.

Спасибо, буду пробовать.

Как я понял, Инфо-Сервер смотрит сквозной номер в таблицах операций, проводок, плана счетов и остатков и держит данный номер у себя и передает клиенту по запросу.
Клиент должен сформировать правильный текст запроса и передать серверу.
Сервер его выполнит. Т.е. на момент записи операции в ИБ, сам ИБ уже знает номер операции, но не возвращает его во внутренний язык.
Дело в том, что одновременно вводить проводки могут несколько человек.
Поэтому просто считывать последнюю запись из HOZOP не корректно.

Т.е. из внутреннего языка никак не узнать реальный ключ хозяйственной операции, хотя он есть?

Возможно из-за того что у нас Инфо-сервер, почему-то в таблице EVENTNET.DB пусто.
Это действительно так или в момент ввода там будут появляться записи?

Дело в том, что связь уже есть (с 2009 года) и работает. Экспорт-импорт не производим (именно из-за того, что номер в этом случае меняется). все манипуляции с базой (проверки, лечение) производим на сетевой базе (с копированием ее в локальную папку)с отключением пользователей.

С недавнего времени работает инфо-сервер.

Планируем создавать проводки из сторонних систем в базу, при помощи API данного сервера, но некоторые вещи могут быть добавлены и в ИБ, в этом случае хотелось налету переносить операции-проводки (и счета) в нашу систему. Сейчас импорт происходит ночью - раз в сутки.

К сожалению поле номер документа занято номером документа реального документа. писать какой-то номер в текст операции тоже не представляется возможным (его могут просто уничтожить или изменить).

Мысль была при добавлении, изменении и удалении производить импорт в нашу систему сразу же.
Если невозможно получить код операций и проводок, вижу единственный вариант - находить запись в таблице HOZOP по атрибутам (дата, номер содержание, полная сумма, и т.д.) как вариант, конечно, не очень нравится. было бы на порядок проще передавать в функцию импорта текущий OPER_NUMB.

Идея в том, чтобы 2 журнала наш и ИБ в любой момент времени соответствовали. С какой бы стороны не происходил ввод данных.

Странно, что штатными средствами не получается вводить пользователей.

Да инфо-сервер планируем запустить. Но пусть медленно и в обычной сети должно работать.
Думал, может, есть какие-то хитрости в настройке при большом количестве пользователей.

Сложности с запуском ИС в том, что нельзя чтобы даже случайно было подключение к базе ИС обычным порядком. (по крайне мере так написано в инструкции)
Или если не писать то не так критично?
Просто возникает проблема с установкой настроек ИС на все компьютеры пользователей одномоментно.

1. Если мы сейчас обновимся до 8.716, нам потом ключ не надо будет снова обновлять?
2. Когда ждать 8.717?

Мы не дообрабатываем, у нас около 40 человек работает одновременно, во первых необходимо вести логи: кто, что, когда сделал, во вторых надо как-то закрыть предыдущий месяц. Мы делаем это через обработчики. Когда просто вводят операцию - работает, когда программно - нет.
А т.к. не хочется все вводить в журнал руками, мы лишены данных об операциях полученных программным путем, ну и если забыли при копировании (мы делаем это скриптом который выше, т.к. без инфо-сервера проводки при копировании рушатся, а его пока не внедрили) поменять дату, то проводка уходит в прошлый период.

А чтобы перейти с версии 8.702 необходимо будет перерегистрировать ключ?

А как вызвать событие после вызова функции ЗАП_ОПЕР?
Просто вызвать как функцию?
и система сама поймет что это событие для для последней операции?
И передаст туда номер?

А как это можно сделать?
Мы сами каким-то образом можем привязать события к вызову этих функций?
Или имеется ввиду, что выполнение данных функций способствует вызову обработчиков?
Но вот данная функция не вызывает обработчики? Есть ли возможность что-то изменить?

ФУНКЦИЯ CopyOp(ТИП_ЧИСЛО: Ном)
СОЗДАТЬ(ОП, ТИП_ОПЕРАЦИЯ)
ОП=ОПЕР_СЧИТАТЬ(Ном)
н1=ОП.НАЗВ1
н2=ОП.НАЗВ2
н3=ОП.НАЗВ3
Док=ОП.документ
д1=ДАТА_ТЕК
ЦИКЛ ДЛЯ (пр=1, ОПЕР_ПРОВ(Ном))
пров=ОП.ПРОВ(пр)
Д=пров.дебет
К=пров.кредит
Кол=пров.количество
Сум=пров.сумма
ПРОВОДКА(Д,К,Сум, Кол, Док,д1, РАБ_МЕСТО, н1)//, н2, н3)
КОНЕЦ_ЦИКЛА
ЗАП_ОПЕР
CopyOp=ДА
КОНЕЦ_ФУНКЦИИ

Спасибо, буду ждать.

Все еще актуально.
Сотрудники Инфо-бухгалтера могут прокомментировать данную проблему?
Или мы что-то неправильно делаем?
Или события толком не работают и не имеет смысла на них надеяться?

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

Да архив большой, это архив платежек примерно за год.

версия программы 8.7

Раньше работали в версии 8.4. Архив перенесли оттуда, но насколько я понимаю формат его не поменялся, т.к. я переконвертировал через DBF и все равно проблема осталась (утлита BARCONV.EXE вообще с 2000 года не менялась)

Бланк работает через интерпретатор, также перенесен с 8.4.

Может в это дело, но что можно посмотреть.

Архив очищать не разрешают, т.к. пользуются им постоянно, чтобы делать похожие платежи.

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

Хотелось бы еще узнать про возможность объединения архивов. как это можно сделать? про такую функцию мне ничего не известно.

Спасибо.