1с внутренняя ошибка подсистемы контроля несогласованных изменений 1с

	Я
LivingStar 06.06.19 — 07:37	Вношу изменения в документ ЗаказПоставщику. Стала выходить ошибка в режиме предприятия. Из за чего она? {ОбщийМодуль.ОбщегоНазначенияУТКлиент.Модуль(856)}: Внутренняя ошибка подсистемы контроля несогласованных изменений.     ВызватьИсключение НСтр(«ru = ‘Внутренняя ошибка подсистемы контроля несогласованных изменений.'»);
ДенисЧ 1 — 06.06.19 — 07:48	Посмотри в конфигурации, что приводит к этой строке.
Mankubus 2 — 06.06.19 — 07:58	(0) поиск рулит ‘Внутренняя ошибка подсистемы контроля несогласованных изменений.
LivingStar 3 — 06.06.19 — 07:59	(1) А как это определить. Просто срывается на эту процедуру и все. // Служебная процедура. // Процедура КонтрольНеСогласованныхИзмененийВызватьИсключение(Форма, Элемент) Экспорт     ВызватьИсключение НСтр(«ru = ‘Внутренняя ошибка подсистемы контроля несогласованных изменений.'»); КонецПроцедуры
LivingStar 4 — 06.06.19 — 08:00	(1) Я добавил новый реквизит в табличную часть, и возникает при вводе в него значения эта ошибка. Как от неё избавиться то?
LivingStar 5 — 06.06.19 — 08:05	Как избавиться от этого? Что нужно сделать?
Dmitrith 6 — 06.06.19 — 08:43	(5) где-то есть процедура, куда надо дописать твой новый реквизит. Где — не помню, отладчиком без проблем находится
LivingStar 7 — 06.06.19 — 09:32	Можете подсказать где это прописать?
LivingStar 8 — 06.06.19 — 09:32	(6) Подскажите пожалуйста как отловить это отладчиком.
ДенисЧ 9 — 06.06.19 — 09:34	(3) ТОчку останов на этой строчке и потом стек вызовов смотреть

Здесь во втором сообщении вам дадут решение, а в двадцатом дадут правильное решение. Ymryn

Я наверное совсем старый стал, или мозги пропил.. Конфигурация «Управление Торговлей 11» Заказчику понадобилось реализовать «хитрую» форму подбора товаров в документ реализации, с добавлением дополнительных реквизитов табличной части товаров. Форму подбора сделали, реквизиты добавили, на форму документа добавили поля реквизитов, назначили подписку на события при изменении…. Тест… «Внутренняя ошибка подсистемы контроля несогласованных изменений.» Отладчик «в зубы», после ТРЕХ часов поиска получили следующую цепочку. ПриЧтенииНаСервере -> ПриЧтенииСозданииНаСервере -> УстановитьДоступностьЭлементовПоСтатусуСервер -> ОбщегоНазначенияУТ.УстановитьПодпискуНаСобытияИзмененияЭлементовФормы И вот тут, очень хитро… цикл ПО ВСЕМ элементам формы, проверка наличия обработчика события «При изменении», и еще некоторых, и переназначение их??????? Далее еще интереснее, новый обработчик события, проверяет имя элемента формы, из которого он вызван, причем проверка производится простым «Если Тогда ИначеЕсли Тогда и т.д.» по именам элементов формы, и вызывает ПРОГРАММНО, процедуру обработчика события, назначенную в конфигураторе в свойствах элемента. А вот если имени элемента в «Если Тогда ИначеНсли Тогда», то вызывается генерация ошибки и выдается сообщение «Внутренняя ошибка подсистемы контроля несогласованных изменений.» Т.е. добавив ДОПОЛНИТЕЛЬНЫЙ реквизит документа, или табличной части, и выведя его в элементы формы, и при необходимости обработки его изменения, нужно кроме указания обработчика события, обязательно докопаться до процедуры проверки имени элемента формы, и уже там, добавивив свое «ИначеЕсли Тогда», вызывать обработчик события. ЗАЧЕМ?????? Не, я конечно все могу понять, и кому надо он докопается до сути. Но я не могу понять от кого этот велосипед, а главное ЗАЧЕМ.

Давайте разберем пример использования аннотации &ИзменениеИКонтроль (изменение и контроль). Для начала работы Вам потребуется создать расширение конфигурации. Для этого откройте список расширений и добавьте в него новое расширение. При этом обратите внимание на правильный выбор варианта назначения расширения конфигурации .

Возможность использования аннотации ИзменениеИКонтроль появилась начиная с версии платформы 8.3.15. В отличии от аннотаций &Перед, &После, &Вместо ​с помощью аннотации &ИзменениеИКонтроль ​Вы сможете делать точечные вставки в код типовой конфигурации. Основная проблема при изменении кода в больших процедурах и функциях с помощью расширений конфигурации — это постоянный контроль за постоянством этого кода. А в случае, если часть кода изменилась — необходимо сразу обновлять расширение. Использование аннотации &ИзменениеИКонтроль​ частично упрощает обновление расширений — теперь платформа будет контролировать неизменность кода в вынесенной в расширение процедуры.

Давайте разберем основные вставки, которые Вы можете выполнять в процедурах с аннотацией &ИзменениеИКонтроль.

1. Для удаления кода типовой конфигурации Вы используете вставки #Удаление и #КонецУдаления . Таким образом, весь код, который будет обрамлен этими вставками будет игнорироваться при компиляции модуля.
2. Для добавления своего кода Вы используете вставки #Вставка и #КонецВставки .

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

Ошибка подсистемы контроля целостности Secret Net

При включении компьютера при инициализации системных сервисов Secret Net на Windows не проходит инициализацию подсистема контроля целостности: зависает в ожидании старта.

Через какое-то время система всё-таки загружается, но на экране входа в Windows появляется надпись: «Произошла ошибка функционального контроля. Вход разрешен только администраторам.»

Администратор входит в систему, и она работает. Под обычным пользователем нет.

Проблема решилась сбросом настроек подсистемы контроля целостности:

! Сделайте резервные копии удаляемых файлов !

1) В папке C:Program FilesSecret NetClientetalons удаляем всё, кроме файла SnIcEtlDB.sdb

2) В папке C:Program FilesSecret NetClienticheck удаляем всё, кроме файла snicdb.sdb

3) Перезагружаем компьютер.

После этого Secret Net заново запустит подсистему контроля целостности с настройками по-умолчанию.

Проблема была в том, что Secret Net не мог прочитать log-файл, находящийся в папке etalons

Для отправки комментария необходимо авторизоваться.

Любые инновации, совершенствования деятельности фармацевтической компании, результаты мониторинга процессов и контроля качества продуктов, а также корректирующие и предупреждающие действия неизбежно! ведут к изменениям. Нет смысла бежать от изменений, и если Вы заявляете, что у Вас нет изменений, на практике это означает только одно – Вы просто ими не управляете.

Для надлежащей оценки, одобрения и внедрения любых изменений требуется иметь эффективную систему управления изменениями. В отечественной практике, где к изменениям принято относиться достаточно просто, внедрение такой системы становится еще более актуальным. Ведь каждый местный «Кулибин» действует только из лучших побуждений: «Ну, ведь стало намного лучше!?», или обратная история: «Ну и что тут такого. Ну поменяли смазку, ну заменили режимы эксплуатации системы, работает же!?» При этом даже не задумываясь о том, что, как минимум, это может повлечь за собой реквалификацию (IQ, OQ или даже PQ), ревалидацию очистки или валидацию технологического процесса, что все усилия предприятия могут быть сведены на нет одним необдуманным «улучшением». Сегодня система управления изменениями больше известна под термином «контроль изменений (change control)», заявленным в 15_ом Приложении «Квалификация и Валидация» к Руководству GMP, согласно которому требуется наличие документированной процедуры на внесение изменений, влияющих на качество препаратов или воспроизводимость процесса. При этом все изменения должны быть обоснованы, документально оформлены и утверждены, включая оценку необходимости проведения ревалидации. С появлением документа ICH Q10 система управления изменениями отнесена к ключевым элементам фармацевтической системы качества. Эта система обеспечивает своевременность и эффективность непрерывного совершенствования деятельности, в то же время давая высокую степень уверенности в отсутствии незапланированных последствий изменений. На протяжении 2008 года нашей команде удалось создать и даже автоматизировать систему управления изменениями на нескольких фармацевтических компаниях Украины и России. В такой работе очень важно не перегнуть с формализацией системы, она должна быть гибкой, оперативной и понятной персоналу. В противном случае, система будет, но совсем неэффективной и вряд ли оправдает затраты на ее поддержание.

Объекты изменений

Важно понимать, что система управления изменениями распространяется, как минимум, на следующие объекты изменений:

• сырье и материалы;

• технические средства (помещения, оборудование, инженерные и компьютеризированные системы);

• технологические среды (вода, сжатый воздух, чистый пар, воздух производственных помещений и т.п.);

• методы очистки;

• методики контроля качества;

• ход и/или параметры технологических процессов;

• непосредственно сам лекарственный препарат (состав, размер серии, спецификация);

• ход и показатели процессов системы качества;

• компетентность персонала.

• объекты изменения;

• классификационный код изменения (АВСDЕ);

• инициаторов изменения (предполагаемые, существующие);

• кто информируется, в какой форме информируется?

• стандартный план внедрения изменения, включая расчетный срок на полное внедрение;

• условия принятия решений, а также уровень такого решения и т.д.

• выявленные:

• — скрытые (при проверках, самоинспекциях, внешних аудитах и т.п.);

• — оперативно задокументированные (например, при отклонениях);

• предложенные:

• — по устранению причин несоответствий (включая корректирующие и предупреждающие действия (САРА));

• — для улучшений

• критические;

• умеренные;

• незначительные.

• внутренние;

• требующие официального уведомления регулирующих органов;

• — типа I (IA, IB);

• — типа II;

• — требующие новой регистрации.

• постоянные;

• временные.

• программируемые (наличие согласованного плана внедрения);

• непрограммируемые.

• сопротивление персонала, в особенности персонала инженерной службы;

• отсутствие документированного опыта работы с оборудованием, инженерными системами, лекарственными препаратами и т.п.;

• непонимание руководителями, да и чиновниками, сущности системы, ее назначения, серьезности и возможностей. Честное слово, иногда легче головой пробить каменную стену, чем упереться в мягкий и упругий живот управленца, который выступает против перемен. Этот живот пробить намного сложнее;

• постоянные поиски одной и той же информации, никто не знает «кто что знает», прошлый опыт компании никак не учитывается, поэтому все наступают на одни и те же грабли;

• работники плохо ориентируются в системе, не понимают и поэтому не хотят ее использовать;

• стремление службы качества к чрезмерному формализму и «заорганизованности», что создает общее негативное впечатление у других служб предприятия.

• изменение механизма принятия управленческих решений в компании с позиции оценки целесообразности, потенциальных рисков и наличия ресурсов;

• значительное упрощение работ при подготовке Обзора качества препаратов;

• накопление знаний в отношении процессов и продукции, предотвращение «утечки» опыта;

• повышение мобильности компании, ее способности к переменам: быстро передать, чтобы быстро применить;

• получение гарантии поддержания качества процессов и продукции.

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

Классификация изменений

В ходе работы мы пришли к классификации изменений в компании по следующим принципам:

По степени воздействия [B]:

По официальному статусу [C]:

По временному фактору [D]:

По согласованности действий [E]:

Классификация изменений может изменяться в зависимости от накопленного опыта, степени детализации и основана на величине потенциального риска, который количественно оценивается с помощью инструментов управления рисками по качеству (см. Приложение 20 к Руководству GMP)(см. таблицу 1).

При этом обращаем внимание, что временные изменения не могут быть незначительными.

Схема кодирования изменений

Для обеспечения четкой прослеживаемости и возможности оперативного управления предложена следующая схема кодирования изменений (см. таблицу 2). Кодирование всех изменений целесообразно передать Отделу обеспечения качества (ООК). На первом этапе важно обеспечить, чтобы инициатор изменения оказывал помощь ООК в классификации изменений. Иногда, в ситуации когда невозможно присвоить четкий код изменению, целесообразно проводить совещания экспертов (рабочих групп).

Элементы системы управления изменениями

Схематично структура системы управления изменениями представлена на рис. 1.

Условно в системе управления изменениями мы рекомендуем выделять 9 основных элементов. При этом, если внимательно посмотреть на эти элементы, они в целом совпадают с элементами системы управления корректирующими и предупреждающими действиями (САРА). Всю систему необходимо детально описать в документе системы качества (СТП, СОП и т.п.).

Степень формализации работ, связанных с изменением, зависит от классификации изменения и величины риска, связанного с таким изменением.

Критические и умеренные изменения требуют четкой формализации в виде согласованных форм протоколов (бланков). Что касается незначительных изменений, на наш взгляд, строгая формализация, наоборот, здесь может навредить, и в результате привести к увеличению количества скрытых изменений. И основная проблема в том, что очень важно четко прописать, какие изменения относят к незначительным, чтобы исключить соблазн «умельцев» к классификации изменений как незначительных по принципу «Я чего, я же только как лучше хотел?!»

При этом ООК необходимо обеспечить регистрацию любых изменений в едином каталоге регистрации изменений.

Таблица 1: Пример классификации изменений

Изменения, которые имеют

или могут иметь существенное влияние на критические свойства* системы, процессов, материалов, процедур и продуктов

Изменения, которые имеют

или могут иметь незначительное влияние на критические свойства* системы, процессов, материалов, процедур и продуктов

Изменения, которые с низкой

долей вероятности могут

отразиться на критических

свойствах* системы, процессов, материалов и процедур

Требуют уведомления регуляторных органов в форме внесения изменений в регистрационное досье или лицензионную документацию

Как правило, не требуют уведомления государственных

Не требуют уведомления государственных органов

Требуют ревалидации процессов или реквалификации

Могут требовать ревалидации

процессов или реквалификации оборудования, систем

Не требуют ревалидации

процессов или реквалификации оборудования, систем

замена производителя активных фармацевтических ингредиентов (АФИ), введение дополнительных компонентов в лекарственную

форму, изменения критических параметров технологического процесса

замена узлов (элементов)

основного оборудования, замена поставщиков вспомогательных материалов, появление нового продукта на

изменение форм записей,

протоколов качества, введение нового смазочного материала

Ответственность за принятие

решений – Высшее руководство и/или Уполномоченное

Ответственность за принятие

Лицо и Директор по качеству

Ответственность за принятие

решений – Руководители подразделений и/или владельцы

процессов системы качества

Примечание: * Критическими свойствами является совокупность показателей, которые

влияют на качество, безопасность и эффективность лекарственного средства

Таблица 2: Схема кодирования изменений

аббревиатура изменения (Change Control)

принадлежность к объекту/процессу, к которому относится изменение

код структурного подразделения – инициатора изменения

классификационный код изменения

сквозной порядковый номер по каталогу регистрации изменений

Первичная оценка ситуации

При первичной оценке целесообразно оценить необходимость оперативных действий и механизма прохождения изменения. На характер рассмотрения изменений влияет степень детализации затрагиваемых работ (процессов) в документах системы качества. Как правило, первичная оценка проводится ООК, но для незначительных изменений целесообразно передать это право владельцам процессов системы качества и даже непосредственно руководителям структурных подразделений, обменяв такое делегирование на четкую и структурированную отчетность. При первичной оценке необходимо определить, имеет ли изменение стандартную схему решения, т.е. существует ли подготовленный план внедрения. Если «да», это значительно ускоряет процедуру согласования изменений. Экспертной команде достаточно один раз сформулировать ход внедрения таких изменений (с учетом оцененных рисков), и в дальнейшем они будут строго выполняться. При поддержании системы управления изменениями, одной из основных задач ООК как раз и будет отработка как можно большего числа стандартных решений по вероятным изменениям, наполнение «портфеля изменений» с учетом накопленного опыта. Куда проще иметь стандартный план внедрения и оперативно принимать решения о целесообразности и сроках внедрения изменения, исходя из текущего финансового состояния.

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

Оценка целесообразности внедрения

Оценку целесообразности рекомендуется проводить в составе экспертной группы, например, валидационной комиссии. При необходимости ООК определяет состав группы из числа заранее одобренных экспертов из различных структурных подразделений, или же сразу выносит на анализ со стороны высшего руководства. Задача экспертной группы – провести всестороннюю оценку предложенного изменения, а также (при необходимости) согласовать изменение с различными структурными подразделениями.

Данный этап целесообразно проводить дважды, – после первичной оценки, т.е. перспективно, и уже после оценки рисков и/или согласования бюджета (ретроспективно). Нужно понять, есть ли возможность, подходящий ли сейчас момент для изменения, насколько необходимы эти изменения. На этом этапе возможен запрос дополнительных данных. Другой стороной является наличие достаточных ресурсов. Совет дать легко. Сказать и даже красиво обосновать свое предложение абсолютно не трудно, но деньги в случае чего теряет не работник, а собственник, на которого он работает. Особенно это характерно для инженерной службы. Например, главный механик вносит предложение о заказе фильтров для установки псевдоожиженного слоя не у производителя оборудования, а пошив фильтры самостоятельно. Перспектива налицо, значительная экономия финансовых ресурсов, генеральный директор просто в восторге. Но, если посмотреть на это с позиции GMP, необходимо, как минимум, обеспечить подбор идентичной ткани (учитывая размер частиц смеси по продуктам), доказать ее идентичность, подтвердить компетентность швеи, доказать идентичность сшитого фильтра, возможно, провести реквалификацию функционирования (PQ) и даже ревалидацию технологических процессов. Нет, это не означает, что от такой идеи необходимо отказаться, это означает, что необходимо детально сопоставить варианты.

Оценка рисков, связанных с изменением

Может проводиться той же экспертной группой, которая определяет целесообразность, но иногда может потребоваться и другой состав экспертов. Опять же, исходя из характера незначительных изменений при оценке рисков и принятии решения о целесообразности его внедрения, допускается единоличное решение ответственного руководителя о необходимых действиях. Подготовка плана внедрения Подготовка плана внедрения изменения осуществляется по результатам предыдущих этапов – оценки рисков и оценки целесообразности. При этом учитываются все необходимые требования GMP.

Возьмем ту же инженерную службу: при установке новой единицы оборудования потребовалось передвинуть упаковочную линию на 45 см, как минимум план внедрения изменения должен включать обучение персонала, который будет проводить работы, а также этапы реквалификации IQ, OQ и при необходимости PQ.

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

Согласование бюджета на внедрение

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

Реализация плана внедрения

На данном этапе реализуются все запланированные мероприятия по внедрению изменения и осуществляется оперативный контроль за ходом внедрения изменения. При необходимости осуществляются требуемые коррективы.

Мониторинг обратной связи

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

Документальное закрытие изменения

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

Проблемы при внедрении системы управления изменениями

Основные проблемы, с которыми мы сталкиваемся при внедрении системы, можно выразить следующим образом:

Полученный результат

В первую очередь к результатам внедрения системы управления изменениями можно отнести:

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

Статья опубликована в журнале «Промышленное обозрение. Фармацевтическая отрасль» №1 (12) 2009, стр. 24-27

Внутренняя ошибка.

Автор Zloydog, 06 ноя 2012, 13:09

0 Пользователей и 1 гость просматривают эту тему.

---

---

---

---

<?php // Полная загрузка сервисных книжек, создан 2023-01-05 12:44:55
global $wpdb2;

global $failure;

global $file_hist;



/////  echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;

//подключаемся к базе

$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL

// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке

if (!empty($wpdb2->error))

{

/////   echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';

$failure=TRUE;

wp_die( $wpdb2->error );

}
$m_size_file=0;

$m_mtime_file=0;

$m_comment='';

/////проверка существования файлов выгрузки из 1С

////файл выгрузки сервисных книжек

$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';

if (!file_exists($file_hist))

{

/////   echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';

$m_comment='Файл обмена с сервисными книжками не существует';

$failure=TRUE;

}
/////инициируем таблицу лога

/////если не существует файла то возврат и ничего не делаем

if ($failure){

///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']

/////   echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));

wp_die();

/////    echo '<H2><b>Возврат в начало.</b></H2><br>';

return $failure;

}

/////проверка лога загрузки, что бы не загружать тоже самое

$masiv_data_file=stat($file_hist);   ////передаем в массив свойство файла

$m_size_file=$masiv_data_file[7];    ////получаем размер файла

$m_mtime_file=$masiv_data_file[9];   ////получаем дату модификации файла

////создаем запрос на получение последней удачной загрузки

////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
/////   echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';

/////   echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';

/////   echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';

////препарируем запрос

$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);

$results=$wpdb2->get_results($text_zaprosa);
if ($results)

{   foreach ( $results as $r)

{

////если штамп времени и размер файла совпадают, возврат

if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))

{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));

wp_die();

return $failure;

}

}

}

////если данные новые, пишем в лог запись о начале загрузки

/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));



////очищаем таблицу

$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');

$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);

$results=$wpdb2->query($clear_tbl_zap_repl);

/////   echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';

if (empty($results))

{

/////   echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';

//// если очистка не удалась, возврат

$failure=TRUE;

wp_die();

return $failure;

}
////загружаем данные

$table='vin_history';         // Имя таблицы для импорта

//$file_hist Имя CSV файла, откуда берется информация     // (путь от корня web-сервера)

$delim=';';          // Разделитель полей в CSV файле

$enclosed='"';      // Кавычки для содержимого полей

$escaped='


      
Related Posts
  
      
      
        

	       
Получение логина и пароля техподдержки 1С из базы
	       
Класс для вывода отчета в Excel
	       
Счет-фактура для УПП
	       
Библиотека классов для создания внешней компоненты 1С на C#
	       
Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
	       
Прайс-лист с артикулом в отдельной колонке
        
      







	    
9 Comments

		

				

		

				
Расширения — хороший инструмент…



  


                       
  




Но вот почему у 1с без костылей никак ?…
			 
Reply ↓			
			   			
	
	

		

				
Не могли бы вы подсказать , что сделать если после переопределения ошибка все равно воспроизводится , но только после записи документа ?

в не записанном или в вновь открытом нет ошибки.

Вопрос решился добавлением переопределения в процедуру «после записи»
			 
Reply ↓			
			   			
	
	

		

				
Спасибо мил человек!
			 
Reply ↓			
			   			
	
	

		

				
Подробно, спасибо!

p.s. Аналогично допиливаю доп. ед. измерения для УТ 11, писал в тех. поддержку 1с, они не понимают для чего нужны доп. ед. изм., просили ПОЛНОСТЬЮ описать бизнес процесс предприятия, по мне быстрее допилить УТ чем вести бесполезную переписку и доказывать для чего необходим данный функционал.



  


                       
  




			 
Reply ↓			
			   			
	
	

		

				
Спасибо за отличный материал! Очень помогло, только пришлось команду УстановитьВыполнениеПослеОбработчиковСобытия заменить на саму процедуру Расш1_ПереопределитьОбработчикиПриИзменении — ругается что можно только из самой формы такое делать, а не из расширения
			 
Reply ↓			
			   			
	
	

		

				
Спасибо за статью, кое что прояснилось.

Но подобные проблемы могут возникать не только при работе с расширениями.
Я правда по другому сделал, дописал КонтрольНеСогласованныхИзмененийОбработатьСобытиеПриИзменени­и()
			 
Reply ↓			
			   			
	
	

		
	
	

		

				
(7) теперь да, можно проще, данный функционал появился кажется начиная с 8.3.10 или выше, раньше не было.
			 
Reply ↓			
			   			
	
	

		

				
Зачем вообще нужен данный функционал Контроль несогласованных изменений? Ну например у нас отключено использование статусов в настройках.. какой смысл в этом всем? Выпилил этот бред вообще из нужных форм.



  


                       
  




			 
Reply ↓			
			   			
	
		

		
		
	
		

		
Leave a Comment 
Ваш адрес email не будет опубликован. Обязательные поля помечены *