Односторонний обмен данными (справочниками) из 1С:Бухгалтерия 8 в самописную конфигурацию
Добрый день.
Есть рабочая база на сервере 1С:Бухгалтерия 8 (8.19.10.01.4) обычные формы, необходимо выгружать справочник номенклатура в самописную конфигурацию на управляемых формах. Подскажите пожалуйста как это можно реализовать? Через выгрузку xml пробовал выгружать справочник, но при загрузке пишет ошибку "неверный формат файла выгрузки" Подскажите пожалуйста как это можно сделать? Новичок в 1С буду благодарен за помощь.
Технологическая платформа 1С:Предприятие 8.3 (8.3.9.2309).
Есть рабочая база на сервере 1С:Бухгалтерия 8 (8.19.10.01.4) обычные формы, необходимо выгружать справочник номенклатура в самописную конфигурацию на управляемых формах. Подскажите пожалуйста как это можно реализовать? Через выгрузку xml пробовал выгружать справочник, но при загрузке пишет ошибку "неверный формат файла выгрузки" Подскажите пожалуйста как это можно сделать? Новичок в 1С буду благодарен за помощь.
Технологическая платформа 1С:Предприятие 8.3 (8.3.9.2309).
По теме из базы знаний
Ответы
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Если форматы справочников не совпадают, а скорее всего так и есть, то как один формат можно загрузить в другой?
Нужны соответствующие правила. Что на что меняется или не меняется.
Если нужен xml, то нужно копать в сторону xdto. Это технология работы с xml в 1с.
Либо ставит конвертацию, создавать правила и пользоваться универсальной обработкой.
Через выгрузку xml пробовал выгружать справочник, но при загрузке пишет ошибку "неверный формат файла выгрузки
Если форматы справочников не совпадают, а скорее всего так и есть, то как один формат можно загрузить в другой?
Нужны соответствующие правила. Что на что меняется или не меняется.
Если нужен xml, то нужно копать в сторону xdto. Это технология работы с xml в 1с.
Либо ставит конвертацию, создавать правила и пользоваться универсальной обработкой.
(5) от формата справочника в данной конфигурации. как называются реквизиты, какого типа и размера.
если у одного справочника есть реквизит ЕдИзм справочник ЕдиницыИзм а у другого ЕдиницыИзмерения то как загрузить без исправления ? Будет ругатся на несоответствие форматов.
Ставится конвертация, загружаются обе конфигурации, сопоставляются объекты, сохраняются правила....
если у одного справочника есть реквизит ЕдИзм справочник ЕдиницыИзм а у другого ЕдиницыИзмерения то как загрузить без исправления ? Будет ругатся на несоответствие форматов.
Ставится конвертация, загружаются обе конфигурации, сопоставляются объекты, сохраняются правила....
Если необходимо выгружать небольшое количество реквизитов ,то проще и быстрее написать свою обработку по выгрузке в txt, xml. Можно использовать COM, ТекстовыйДокумент, ЧтениеТекста, ЗаписьXML, фабрику XDTO, Конвертация данных. Все зависит от сути, сложности задачи, объема данных, архитектуры и т.п. Считаю каждый метод имеет место быть и нужно знать как они работают. Также хочу напомнить и про планы обмена, которые позволяют регистрировать изменения и кстати с их помощью можно тоже писать в xml быстро и не сложно - пример есть в желтой книге.
(7) В идеале конечно чтобы все работало как : пользователь зашел в базу(самописная) и у него уже были данные обновленные по справочникам или хотя бы открывал обработку которая новые записи номенклатуры вытаскивала из 1С:Бухгалтерии и записывала в текущую. Лучше это реализовать каким методом?
(10)Регламент обновления может быть абсолютно любой, может конечно зависеть от объема данных. Можно настроить с помощью регламентного задания (если БД не файловая) и назначить расписание, например обмен ночью или обмен каждые 5 мин. Можно при входе пользователя, но не рекомендую, т.к. это не очень универсально. Давайте так БД Файловые или серверные? Сколько и какие реквизиты нужно обновлять (наименования, полное наименование и т.п.)? Какое количество номенклатур в БД? как часто номенклатуры могут изменяться? Есть ли потенциальный рост объема обновляемых данных? Обмен однонаправленный? Есть вероятность что появится третья БД для обмена номенклатурой?
Вот перечень важных вопросов которые возникли сразу.
Вот перечень важных вопросов которые возникли сразу.
(13)
1. БД серверные.
2. 6 реквизитов(Код, Артикул, Наименование, Полное наименование, Класс ТМЦ, Базовая ед. изм.)
3. около 6000 номенклатур.
4. Добавляется каждый день около 3-5 номенклатур.
5. Обмен однонаправленный.
6. Есть вероятность что появится третья БД.
1. БД серверные.
2. 6 реквизитов(Код, Артикул, Наименование, Полное наименование, Класс ТМЦ, Базовая ед. изм.)
3. около 6000 номенклатур.
4. Добавляется каждый день около 3-5 номенклатур.
5. Обмен однонаправленный.
6. Есть вероятность что появится третья БД.
(16) 1. БД серверные значит лучше использовать регламентные задания
Нужно определиться по каким критериям осуществлять поиск номенклатуры. Сейчас можно в самописной создавать номенклатуру с УИД как в бухгалтерии и определять номенклатуру по УИД. Можно завести реквизит в самописной БД "УИДБухгалтерии" и делать поиск по УИД. НО! если появится третья БД надо определяться как сапоставлять номенклатуру из разных БД, что делать при добавлении, изменении, удалении номенклатуры В БД, как разрешать коллизии, какая БД будет главной. Может придется делать поиск по артикулу, тогда рекомендую добавить реквизит "Бренд", чтобы артикулы не повторялись. Ой, много можно писать....
2. 6 реквизитов это тоже хорошо, только нужно определиться как синхронизировать ссылочные типы "Класс ТМЦ" и "Базовая ед. изм". Базовую ед. изм. по ОКЭД. Класс ТМЦ можно по наименованию (я полагаю их будет немного). Соответственно не забываем про вероятность появления третьей БД.
3. 6000 номенклатур это немного, можно выбрать любой способ.
4. 3-5 номенклатур это круто! обмены будут занимать секунды)
5. Пока однонаправленный это упрощает жизнь
6. третья БД даст большое усложнение алгоритма, если о ней не думать все просто
Я бы наверное сделал так :
Создал объект конфигурации "План обмена" и настроил на регистрацию изменений справочника номенклатура.
Провел первоначальную выгрузку данных из источника в приемник (написал обработку или зарегистрировал изменения по плану обмена).
В БД источник создал регламентное задание, которое дергает процедуру, которая сначала проверяет есть ли ответ по загруженным сообщениям от БД приемника. Если ответ есть, то снимаем регистрацию измениний для сообщений с соответствующим номером. Далее проверяет, есть ли изменения по номенклатуре, если есть, то формирует xml-файл для обмена , допустим в 7 утра или каждые 5 мин, как угодно.
В БД приемник создал регламентное задание, которое дергает процедуру, которая проверяет, есть ли файл для обмена, если есть, то выполняется обмен. После обмена файл удаляется и приемник шлет ответ, что сообщения с таким-тло номером загружены.
В общем как-то так, почитайте про планы обмена, я думаю они вам лучше подойдут. Зато получите новые знания и четко будете понимать что у вас просходит. Да и задачи Вам в дальнейшем могут поставить очень нетривиальные, раз есть самописная конфигурация
Нужно определиться по каким критериям осуществлять поиск номенклатуры. Сейчас можно в самописной создавать номенклатуру с УИД как в бухгалтерии и определять номенклатуру по УИД. Можно завести реквизит в самописной БД "УИДБухгалтерии" и делать поиск по УИД. НО! если появится третья БД надо определяться как сапоставлять номенклатуру из разных БД, что делать при добавлении, изменении, удалении номенклатуры В БД, как разрешать коллизии, какая БД будет главной. Может придется делать поиск по артикулу, тогда рекомендую добавить реквизит "Бренд", чтобы артикулы не повторялись. Ой, много можно писать....
2. 6 реквизитов это тоже хорошо, только нужно определиться как синхронизировать ссылочные типы "Класс ТМЦ" и "Базовая ед. изм". Базовую ед. изм. по ОКЭД. Класс ТМЦ можно по наименованию (я полагаю их будет немного). Соответственно не забываем про вероятность появления третьей БД.
3. 6000 номенклатур это немного, можно выбрать любой способ.
4. 3-5 номенклатур это круто! обмены будут занимать секунды)
5. Пока однонаправленный это упрощает жизнь
6. третья БД даст большое усложнение алгоритма, если о ней не думать все просто
Я бы наверное сделал так :
Создал объект конфигурации "План обмена" и настроил на регистрацию изменений справочника номенклатура.
Провел первоначальную выгрузку данных из источника в приемник (написал обработку или зарегистрировал изменения по плану обмена).
В БД источник создал регламентное задание, которое дергает процедуру, которая сначала проверяет есть ли ответ по загруженным сообщениям от БД приемника. Если ответ есть, то снимаем регистрацию измениний для сообщений с соответствующим номером. Далее проверяет, есть ли изменения по номенклатуре, если есть, то формирует xml-файл для обмена , допустим в 7 утра или каждые 5 мин, как угодно.
В БД приемник создал регламентное задание, которое дергает процедуру, которая проверяет, есть ли файл для обмена, если есть, то выполняется обмен. После обмена файл удаляется и приемник шлет ответ, что сообщения с таким-тло номером загружены.
В общем как-то так, почитайте про планы обмена, я думаю они вам лучше подойдут. Зато получите новые знания и четко будете понимать что у вас просходит. Да и задачи Вам в дальнейшем могут поставить очень нетривиальные, раз есть самописная конфигурация
(32) Так выгружать надо из бухгалтерии а загружать в самописную. Я смотрю делаете через обработку "Универсальный обмен данными". Я ей пользовался очень давно, не совсем помню как она работает. Вам быстрее самому написать выгрузку загрузку. План обмена создали? пришлите скрины объекта конфигурации. Я попробую вам скинуть код выгрузки, загрузки.
(35) а, я понял, Вы пошли другим путем, хотите каждый раз выгружать всю номенклатуру из базы источника в приемник. Я не сильно помню как работает универсальный обмен данными. Вроде нужно запускать обработку в базе источнике ,чтобы данные выгрузились в файл, а потом загрузить этот файл в базе приемнике. Нужно открыть файл и посмотреть глазами, выгружена ли хотя бы одна номенклатура. если загрузка не проходит, то нужно включать возможность отладки, чтобы разобраться что происходит
1. Определиться, какие реквизиты есть в базе-приемнике (на управляемых формах) в справочнике "Номенклатура".
2. Отделить простые реквизиты от ссылок.
3. Разобраться, откуда из базы-источника (обычные формы) взять каждый из реквизитов.
4. Создать структуру со списком полей базы источника, которые будут потом загружены в базу-приемник.
5. Написать запрос, который из базы источника получить все нудные поля.
6. Выполнить запрос и для каждого вернувшегося значения заполнить созданную структуру и положить ее в массив. Для простых типов (число, булево, строка, дата) в запросе должны быть взяты значения как есть. Для ссылочных типов нужно взять только те реквизиты ссылки, которые имеют место быть в базе-приемнике (код, наименование, иные существенные реквизиты).
7. Выгрузить массив структур в XML или JSON.
8. В базе-приемнике загрузить массив структур из XML или JSON.
9. Для каждого элемента массива произвести поиск всех имеющихся в нем сущностей (элементов ссылочного типа и элемента самой номенклатуры).
10. Создать все объекты ссылочных типов, если они не найдены.
11. Создать номенклатуру, если не найдена.
12. Заполнить данными.
13. Записать.
14. Профит.
15. Грустно посмотреть на вышний список и разобраться с конвертацией, где придется сделать ровно то же самое.
2. Отделить простые реквизиты от ссылок.
3. Разобраться, откуда из базы-источника (обычные формы) взять каждый из реквизитов.
4. Создать структуру со списком полей базы источника, которые будут потом загружены в базу-приемник.
5. Написать запрос, который из базы источника получить все нудные поля.
6. Выполнить запрос и для каждого вернувшегося значения заполнить созданную структуру и положить ее в массив. Для простых типов (число, булево, строка, дата) в запросе должны быть взяты значения как есть. Для ссылочных типов нужно взять только те реквизиты ссылки, которые имеют место быть в базе-приемнике (код, наименование, иные существенные реквизиты).
7. Выгрузить массив структур в XML или JSON.
8. В базе-приемнике загрузить массив структур из XML или JSON.
9. Для каждого элемента массива произвести поиск всех имеющихся в нем сущностей (элементов ссылочного типа и элемента самой номенклатуры).
10. Создать все объекты ссылочных типов, если они не найдены.
11. Создать номенклатуру, если не найдена.
12. Заполнить данными.
13. Записать.
14. Профит.
15. Грустно посмотреть на вышний список и разобраться с конвертацией, где придется сделать ровно то же самое.
(15) Согласен с предыдущим постом, связываться с конвертацией не стал бы.
В целом идея следующая: из базы источника выгружаем объекты в "Стандартный" XML
В базе приемнике: читаем XML - файл с помощью DOM обрабатываем только нужные поля - так как нам надо, со всеми проверками и нюансами.
В целом идея следующая: из базы источника выгружаем объекты в "Стандартный" XML
В базе приемнике: читаем XML - файл с помощью DOM обрабатываем только нужные поля - так как нам надо, со всеми проверками и нюансами.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот