| Главная |
| Свяжитесь с нами |
|
Как найти ошибку при переносе данных Известно, что программы фирмы 1С - удобный и многофункциональный инструмент для автоматизации учета, подходящий для предприятий самых разных отраслей и направлений деятельности. Однако инструмент это сложный и в работе с ним, к сожалению, не редко возникают разного рода ошибки. В этой статье мы расскажем, как найти и устранить ошибку, возникшую при переносе данных с использованием правил, созданных по Технологии конвертации данных 2.0. Что делать, если выгрузка завершается ошибкой или не получается загрузить данные в базу-приемник? Наша статья призвана ответить на эти вопросы. Итак, если Вы приобрели правила конвертации данных, открыли обработку для переноса, выставили все настройки, но выгрузка прерывается и в служебных сообщениях появляется запись об ошибке, вот несколько приемов, которые могут помочь Вам найти и устранить ошибку. В самую первую очередь, сверьте версии релизов Вашей программы с теми, что указаны в правилах. При небольшом расхождении версий источника проблем не возникает, но если Ваш релиз существенно отстает от свежих версий правила работать не будут. Версия конфигурации приемника должна быть идентична указанной в правилах. Как посмотреть, для каких релизов предназначены правила? Просто откройте файл правил любым редактором (по умолчанию это может быть Internet Explorer или Блокнот) и посмотрите на первые строчки - в них записаны версии источника и приемника.
Рис.1. Просмотр правил Что делать? Если у Вас есть такая возможность - обновите программу-источник до релиза, указанного в правилах конвертации. Если Вы не можете обновить программу, значит и с этими правилами работать не сможете. Но, возможно, Вы уже все это сделали, а выгрузка все равно происходит с ошибками? Тогда попробуйте найти проблемный элемент, мешающий программе выполнять выгрузку корректно. Алгоритм действий при поиске ошибок мы продемонстрируем на примере переноса данных из КА 1.1 в БП 3.0. Действуйте следующим образом: отключите все правила переноса и поочередно выгружайте отдельные группы правил. Т.е. сперва попробуйте выгрузить только Учетную политику, затем только Входящие остатки, только Справочники и т.д. (рис.2). Чаще всего проблемы возникают при выгрузке документов, тогда как остальные виды объектов выгружаются нормально, так что на их примере и рассмотрим дальнейшие действия. Теперь Вам нужно повторить процесс с поочередной выгрузкой с каждым правилом конвертации документов. Т.е. по очереди выгружать только авансовые отчеты, только аккредитив переданный и т.д. по списку, как показано на рис.3.
Рис.2. Поочередная выгрузка групп объектов
Рис.3. Поочередная выгрузка видов объектов Итак, предположим, что выгрузка прерывается при выборе всех правил выгрузки Документы. Вы по очереди выгрузили все виды документов, прошли все позиции по одной и вычислили, что ошибка возникает только при выгрузке, например, документов Операция (бухгалтерский и налоговый учет). Далее следует постепенно сужать период выгрузки, чтобы найти проблемный документ. Сначала выгружайте по кварталам, месяцам, неделям, пока не найдете день, в котором выгрузка обрывается ошибкой. Что делать? Если Вам удалось найти конкретный документ, вызывающий ошибку и Вы видите, в чем, вероятнее всего, заключается проблема - отлично. Исправьте документ, если это возможно, или просто не переносите его - гораздо проще восстановить один документ, чем выполнять весь перенос вручную. Чтобы выполнить перенос, исключив только один документ, воспользуйтесь отбором в соседнем окне. В колонке "Тип сравнения" установите "Не равно", в "Значение" выберите проблемный документ, и продолжайте выгрузку как обычно.
Рис.4. Отбор документа при выгрузке Хорошо, но что если выгрузка проходит корректно, а вот загрузить данные в другую базу не получается? Для начала не торопитесь и еще раз проверьте все ли Вы выполнили правильно и совпадают ли версии программы. В отличие от источника, версия релиза приемника должна строго совпадать с указанной в правилах, в противном случае у Вас всегда будет возникать ошибка. Что делать? Ошибки на этапе загрузки чаще всего можно исправить только на этапе выгрузки, так что порядок действий при поиске проблемы будет тем же, что описан выше, с одним лишь исключением - после каждой выгрузки необходимо будет повторять загрузку, чтобы найти элемент, который в базу-приемник не загружается. Выполняйте ту же самую последовательность - сначала перенесите группу видов объектов, затем определенные виды, за определенные даты и наконец исключите проблемный элемент, мешающий успешной загрузке. Как правильно читать служебные сообщения об ошибках? Когда типовая обработка не может выполнить выгрузку корректно и процесс останавливается, в служебных сообщениях всегда появляется запись об ошибке. В некоторых случаях, найти место возникновения и причину этой ошибки действительно возможно только поочередно выгружая разные типы объектов. Однако это не единственный способ. Зачастую причина ошибки уже раскрыта в служебном сообщении, нужно только правильно его прочесть. Рассмотрим на примере выгрузки из КА 1.1. Пользователь выгружает из базы-источника Входящие остатки на начало 2018 года. Процесс выгрузки прерывается и программа выдает несколько служебных сообщений, среди которых имеется следующее:
Можно было бы пойти сложным путем и поочередно выгружать разные виды остатков (остатки основных средств, остатки нематериальных активов и т.д.) и найти, что ошибка возникает при выгрузке по правилу Остатки_Материалы. А можно сразу посмотреть имя правила в сообщении об ошибке. Посмотрите, в самой первой строчке в расшифровке ошибки в сообщении говорится именно об этом. ПВД - правило выгрузки данных. Правило выгрузки данных равняется Остатки_Материалы. Нам не нужно ничего искать, программа сама сообщает место возникновения ошибки.
Рис. 5.1. Служебное сообщение об ошибке Так же легко мы можем найти и причину. В строке ОписаниеОшибки написано Ошибка получения значения свойства объекта (по имени свойства источника). Не очень понятное сообщение для пользователя. Однако мы можем понять что ошибка заключается в каком-то свойстве объекта. Какого объекта? Того, который указан в строке Объект в этом сообщении. В данном случае этим объектом является Сварочный аппарат инвертор ВДИ 160Р (Основные средства). Уже в данный момент можно заметить расхождение. Правило выгрузки данных называется Остатки Материалы, в строке Правило конвертации объекта (ПКО) написано Номенклатура, почему же тип объекта записан как Основные средства? Давайте заглянем в базу-источник и проверим, действительно ли мы нашли правильный объект. В остатках по счету 10.09 "Инвентарь и хозяйственные принадлежности" находим наш проблемный объект - субконто Сварочный аппарат инвертор ВДИ 160Р (см. рис. 5.2)
Рис. 5.2. Оборотно-сальдовая ведомость по счету 10.09 за 2018 г. Если открыть это субконто, то можно сразу увидеть, что Сварочный аппарат инвертор ВДИ 160Р действительно является основным средством, а не номенклатурой (см. рис. 5.3). То, что остатки по Сварочному аппарату инвертор ВДИ 160Р оказались на счете 10.09 совершенно очевидная ошибка, которую необходимо исправить.
Рис. 5.3. Карточка основного средства Сварочный аппарат инвертор ВДИ 160Р Ошибка при выгрузке в данном случае возникает из-за неверного типа объекта. По правилу выгрузки остатков материалов должна выгружаться именно Номенклатура - материалы, топливо, инвентарь и т.д.. У таких объектов есть определенный набор свойств, который переносится в другую базу по правилу конвертации. У объектов с типом Основное средство набор свойств будет совсем другим. Такой объект никак не получится выгрузить по правилу для выгрузки материалов. Программа идентифицирует объект как Номенклатуру но не находит у него необходимых свойств и соответственно не может конвертировать его для записи в файл. Об этом и говорило сообщение Ошибка получения значения свойства объекта (по имени свойства источника). В данном примере решить проблему можно достаточно легко - в наших правилах существует параметр Не выгружать остаток, если нулевое количество. При его установке остатки с нулевым количеством просто не будут выгружаться. Как Вы могли видеть в оборотно-сальдовой ведомости, представленной на рисунке 5.2, у остатков данного субконто нет количества, т.е. этот проблемный остаток легко исключить с помощью указанного параметра. В других случаях, когда нет возможности исключить объект с помощью отбора или параметра, пользователю пришлось бы исправлять ошибку в базе-источнике, прежде чем выполнять перенос данных. Примеры ошибок. Рассмотрим пример еще одной ошибки, обнаруженной при переносе данных. При попытке проведения документа Ввод начальных остатков в БП 3.0 (раздел учета НДС по авансам) появляется сообщение "Не удалось сформировать документ "Счет-фактура" № СН/301118/0015 от 30.11.2018 0:00:00. Вероятно счет-фактура с таким номером уже записан в информационной базе". Эта ошибка возникла из-за того, что в источнике (КА 1.1) - длинные номера (см. рис 5.4), первые 12 символов двух разных номеров совпадают, а в БП номер 12-тизначный, следовательно в приемнике номера и даты двух разных документов совпадут, что невозможно. Понятно, что в типовой конфигурации КА, такого быть не может, там номера также 12-тизначные, но в практике, как видим такое случается, а пользователи не понимают причину.
Рис. 5.4 Пример совпадения номеров счетов-фактур И самое главное, почему этот пример здесь размещен. Есть еще одна особенность. Это уже специфика работы типовой БП. Проведение документа происходит в транзакции, поэтому если возникла одна ошибка такого рода, то на всех последующих строках в документе тоже будет появляться аналогичное сообщение, хотя ошибки там уже никакой нет. Т.е. имеет смысл обращать внимание только на первое сообщение. После исправления первой ошибки других ошибок может и не быть. Рассмотрим пример еще одной ошибки. При первой попытке выгрузки документов пользователь увидел в системных сообщениях вот такой текст. Сообщение об ошибке позволяет нам пропустить механизм поиска момента возникновения ошибки и перейти к ее устранению. Подобные сообщения появляются не всегда и иногда искать ошибку методом поочередной выгрузки все же приходится. А как прочитать такое сообщение мы уже говорили выше.
Рис.6.1. Сообщение об ошибке Итак, проблемный документ нам сообщает сама программа - это Счет покупателю ИПБП-000008, значит мы сразу переходим к документу и пытаемся выяснить, в чем заключается ошибка. Как Вы можете видеть на рисунке 6.2, в этом документе в табличной части "Товары и услуги" в одной из строк установлена группа номенклатуры, а не сама номенклатура, что само по себе является ошибкой. Разумеется, в правилах конвертации для этого документа не прописано как из этой табличной части конвертировать объект группа номенклатуры, это элемент совсем другого типа, нежели сама номенклатура, и у программы нет сведений о том, как перенести другой элемент, отличный от указанного в правилах. Следовательно, процесс конвертации не распознает его, не может его конвертировать и выдает ошибку.
Рис.6.2. Документ с ошибкой Как и зачем это было установлено нас, в данный момент, не интересует. Мы решаем не переносить документ, а значит, исключаем его из списка переносимых объектов. Находим правило выгрузки документа Счет на оплату покупателю, выбираем его, переходим к отбору, устанавливаем Поле - Ссылка, Вид сравнения - Не равно, Значение - наш проблемный документ. Таким образом мы исключим данный документ из списка переносимых объектов и выгрузка должна пройти нормально.
Рис.6.3. Установка настроек для исключения документа После этого можно продолжать выгрузку удобным для Вас способом - перенести все документы сразу, или перенести только Счета на оплату, за исключением найденного документа, и затем перенести остальные - порядок переноса данных может быть любым. Здесь необходимо отметить, что возможности отбора объектов существуют в обработках УниверсальныйОбменДаннымиXML не во всех типовых конфигурациях. Точнее такой функционал отсутствует в режиме управляемого приложения. В частности, в типовой конфигурации Комплексная автоматизация ред.1.1 можно работать как в режиме обычного приложения, так и в режиме управляемого приложения, или, как еще говорят, в режиме управляемых форм. В первом случае отборы в типовой обработке возможны (см. рис.4), во втором - нет. Тогда нужно воспользоваться доработанным версиями обработки (см. рис. 6.3). Если конфигурация используется в режиме совместимости с платформой 8.2 (это в частности КА 1.1 и УПП 1.3), то необходима обработка УниверсальныйОбменДаннымиXML версии 2.1.7. Если же режим совместимости не используется, как например в конфигурации Бухгалтерия предприятия редакции 3.0, то нужно работать с обработкой версии 2.1.8. Эти обработки обладают также дополнительными возможностями по заполнению отборов из журнала регистрации (подробнее здесь), поэтому входят не во все варианты поставок, но их всегда можно приобрести либо в составе пакетов, помеченных как с отбором по ЖР, либо отдельно. Еще одна ситуация, которая воспринимается пользователями как ошибка переноса, связана с переносом различных счетов учета из программ ERP 2.5 (КА 2.5) в другие программы, например в БП 3.0 или БП 2.0. В ERP 2.5 есть такое понятие как Вид запасов, в состав которого может входить группа финансового учета ГФУ. Это зависит от состояния соответствующей константы (см. рис.7), которая по умолчанию включена, а значит включена у большинства пользователей.
Рис. 7 Настройка видов запасов с учетом ГФУ При такой настройке программы в виды запасов записывается ГФУ. Проблема в том, что вид запасов формируется в документе в момент создания, ГФУ в него записывается на момент создания и сохраняется в неизменном виде навсегда. Если ГФУ номенклатуры изменили уже после создания документа (н-р на момент создания ГФУ была пустой), то ГФУ в виде запасов не будет соответствовать новому значению. Повторное проведение документа ничего не изменит. Исправить ситуацию можно только перевыбрав номенклатуру или, если не помогло, создав заново строку документа. До тех пор, пока ГФУ вида запасов не соответствует ГФУ номенклатуры, возможно несовпадение счета учета в проводках документа счету учета ГФУ, указанному в настройках отражения в регламентированном учете. В наших правилах переноса мы определяем счет учета по текущим настройкам ГФУ номенклатуры. Еще одна ситуация, которая воспринимается пользователями как ошибка переноса, это ошибки ведения учета, которые пользователи не видят. Чаще всего, это происходит при загрузке остатков. Различных примеров пересортицы в остатках (назовем это так) великое множество. Проиллюстрируем сказанное примером из БП 3.0 КОРП (см. рис.8). Видно существование отрицательных остатков в разрезе подразделений, это явная ошибка. Если свернуть остатки только по банковским счетам, все выглядит хорошо, остаток положительный. Но при конвертации базы в другую, н-р в ERP 2, КА 2, УХ 3.1 или другую БП 3.0, сформируются остатки по всем подразделениям, отрицательные остатки "превратятся" в нули, т.к. в базе-приемнике суммы в документах ввода остатков могут быть только положительными.
Рис. 8 Пример отрицательных остатков Еще один случай ошибок в учете, часто встречающийся на практике, приводящий к проблемам при формировании остатков на счете 76.АВ, рассмотрим на примере переноса данных из БП 2.0 в БП 3.0 (см. рис.9.1), понятно, что аналогичные ошибки встречаются и в других переносах. Здесь хорошо видны две ошибки одинакового рода: наличие положительного и отрицательного остатка по одному и тому же счету-фактуре. Важно подчеркнуть, что и документ Поступление на расчетный счет и документ Счет-фактура выданный связаны именно с одним и тем же счетом-фактурой.
Рис. 9.1 При формировании документа Ввод начальных остатков будут созданы строки с одинаковыми номерами и датами счетов-фактур (см. рис.9.2), что приведет к ошибке записи с сообщением такого рода: "Не удалось сформировать документ "Счет-фактура" № 000000000078 от 01.12.2017 0:00:00. Вероятно счет-фактура с таким номером уже записан в информационной базе". Это требует ручного исправления после загрузки остатков в базу-приемник. Конкретно в данном случае нужно просто удалить ненужные четыре строки. Заметим, что существует параметр Исправлять пересортицу по расчетам с контрагентами, при установке которого часть подобных ошибок будет исправлена автоматически в процессе выгрузки, но только для тех контрагентов, у которых результирующее сальдо равно нулю.
Рис.9.2 Подобных примеров пересортицы очень много. Часто остатки "разбегаются" по третьему субконто на счетах расчетов с контрагентами или на счетах учета ТМЦ, при том, что суммарное сальдо по контрагенту или ТМЦ равно нулю. В наших правилах обмена, как правило, есть специальные алгоритмы, позволяющие исправить такие ошибки. Для включения таких алгоритмов служат соответствующие параметры. Подробнее о примерах пересортицы и о параметрах читайте здесь. Вот так, в общем виде, выглядит процесс поиска и устранения ошибки, возникшей при переносе данных 1С. Наши правила переноса данных:
Ознакомиться с другими полезными материалами можно в разделе Статьи на этом или основном нашем сайте. © Группа компаний Профи-центр, последние изменения август 2023г. |
