Sagrer » Сб апр 28, 2012 13:09
Подниму опять тему загрузки из открытого таможенного формата в xml и обращусь к сообществу форума за советом.
Ситуация следующая:
1) Имеется организация (брокер), около 30 специалистов по Т.О. Уже много лет плотно работает на программах СТМ.
2) Имеется настоятельная рекомендация (отказаться нельзя) из вышестоящей организации (головное предприятие, мы филиал) - полностью отказаться от программного обеспечения СТМ и перейти на Альту.
4) Имеется база данных со всеми выпущенными за время работы декларациями (а их без шуток >9000 штук) в виде файлика DCL.mdb, т.е. база Access-а со структурами во внутреннем формате СТМ - все эти декларации нужно каким-то образом перетянуть в формат Альты на SQL-сервер (чтобы с ними можно было работать из ГТД-про). Понятно что бОльшая часть этих деклараций если когда-то и потребуется то только для статистики и отчётов, но, тем не менее, нужна возможность взять любую из этих деклараций, создать по образцу новую, что-то там исправитьпеределать и запустить по ЭД. Заново создавать опись и привязывать туда документы специалисты по Т.О. не будут ибо во-первых они уже были привязаны в СТМ (оно логично, на самом деле) и второй раз им это делать некогда, во-вторых "мы не программисты и это вы нам должны...", а в третьих не царское это вообще дело. В общем, надо чтобы все декларации были в базе в максимально сохранном после миграции виде, с описью и всеми уже привязанными документами. Начал смотреть как это сделать...
5) СТМ-овский ВЭД-декларант умеет выгружать в своём внутреннем формате (в дистрибутиве документация на него есть но _очень_ старая), в старом открытом dbf-формате (для моей задачи он не подходит ибо доисторический, не говоря уж об ЭД2) и, естественно, в современном открытом таможенном xml.
6) Альта умеет загружать из своего внутреннего и недокументированного бинарного формата, из своего внутреннего и документированного xml-формата, и из таможенного xml-формата. При этом нормально, с сохранением связей между документами загрузка возможна только из внутреннего xml-формата (судя по форуму тоже есть ньюансы) и, возможно (не проверял) из внутреннего бинарного формата. При загрузке из таможенного формата теряются номера деклараций, связи нет ни между декларацией и описью, ни между описью и ЭД2-документами.
7) Проблему с потерей номеров деклараций и привязке описи к декларации можно решить с помощью найденного на форуме
шаманства - несмотря на то что в самой декларации в таможенном xml-формате регистрационного номера нет, он есть в описи, а опись в контейнере есть всегда, достаточно написать программку которая будет смотреть номер в описи и переименовывать или копировать с новым именем xml-файлики - при загрузке в альту такого xml-я номер ГТД остаётся а опись получается прикреплённой. Документы однако остаются не прикреплены к описи - поковырял hex-редактором выгруженные после загрузки бинарные файлики с описью и прочими документами, судя по всему при загрузке генерируются новые DocumentID всем ЭД2-документам, а в описи ссылки вообще не проставляются (для пробы руками привязал 1 документ чтобы посмотреть как это в бинарнике выглядит).
Что со всем этим в принципе можно сделать? Я вижу пока 2 возможных варианта:
1) Тщательно изучить таможенный и внутренний xml-формат альты и попытаться написать конвертер из таможенного формата в формат альты, из которого документы насколько понимаю загружаются номально, с сохранением DocumentID и связей. Вариант плох объёмом работы по строительству двух велосипедов - ведь надо уметь прочитать любой документ в таможенном формате и записать любой документ в формате альты, + по многим типам документов возможно потребуются какие-то нетривиальные действия по конвертации собственно содержимого.
2) Пытаться загружать из таможенного xml, с помощью самописной программки подправив ссылки в базе на SQL-сервере. Поскольку DocumentID после загрузки меняется - если сразу загрузить все декларации - идентифицировать потом где какой документ будет невозможно. Однако, в принципе, сразу после загрузки одной единственной декларации - идентифицировать документы по названию, типу и номеру посмотрев на последние внесённые в базу записи вполне возможно, в т.ч. программно без участия человека. В альте есть функция автозагрузки из настроенной на наблюдение папки, причём на форуме вычитал что если положить в эту папку файлик eoj.txt - альта автоматом загрузит подсунутый xml-файл и удалит оба файла из наблюдаемой папки. Т.е. по исчезновению этих файлов можно со своей программы лезть в базу, сопоставлять новые DocumentID старым и проставлять ссылки в опись, а когда всё готово - скармливать альте очерезной xml-файл - всё это в принципе можно оформить в виде программки например на delphilazarus. Но и тут имеется подводный камень - в полях баз на SQL информации почти нет, всё хранится в BLOB-ах во всё том же бинарном формате. В принципе, полностью разбирать формат нужно только для описи, а опись - штука не такая уж и сложная, по всем остальным типам надо уметь только вынимать DocumentID и, как я понимаю, заголовки файлов практически одинаковые и какой-то идентификатор похоже вообще идёт стабильно на 0x28h(40) байте, второй обычно на 0x78h(120) байте хотя для бинарного формата ГТД там примерно в том же месте но по другому смещению идёт информация о номере и типе процедуры... но в любом случае разобрать формат описи и заголовки других типов документов + реализовать чтениезапись бинарной описи и чтение идентификаторов документов из других форматов должно быть значительно проще и быстрее чем писать полноценный конвертер [таможенныйXML]-->[AltaXML].
Есть ещё третий вариант - попытаться "наехать" на техподдержку и убедить их убедить в свою очередь программистов что-то сделать с импортом из таможенного xml-формата, но судя по тому сколько лет на форуме поднимаются такие вопросы - вероятность благоприятного развития событий в этом направлении крайне мала %).
Собственно, кто что посоветует? Я скорее всего попытаюсь перекинуть декларации через таможенный формат и привязывающую документы программку, но может кто-то знает вариант попроще?
Подниму опять тему загрузки из открытого таможенного формата в xml и обращусь к сообществу форума за советом.
Ситуация следующая:
1) Имеется организация (брокер), около 30 специалистов по Т.О. Уже много лет плотно работает на программах СТМ.
2) Имеется настоятельная рекомендация (отказаться нельзя) из вышестоящей организации (головное предприятие, мы филиал) - полностью отказаться от программного обеспечения СТМ и перейти на Альту.
4) Имеется база данных со всеми выпущенными за время работы декларациями (а их без шуток >9000 штук) в виде файлика DCL.mdb, т.е. база Access-а со структурами во внутреннем формате СТМ - все эти декларации нужно каким-то образом перетянуть в формат Альты на SQL-сервер (чтобы с ними можно было работать из ГТД-про). Понятно что бОльшая часть этих деклараций если когда-то и потребуется то только для статистики и отчётов, но, тем не менее, нужна возможность взять любую из этих деклараций, создать по образцу новую, что-то там исправитьпеределать и запустить по ЭД. Заново создавать опись и привязывать туда документы специалисты по Т.О. не будут ибо во-первых они уже были привязаны в СТМ (оно логично, на самом деле) и второй раз им это делать некогда, во-вторых "мы не программисты и это вы нам должны...", а в третьих не царское это вообще дело. В общем, надо чтобы все декларации были в базе в максимально сохранном после миграции виде, с описью и всеми уже привязанными документами. Начал смотреть как это сделать...
5) СТМ-овский ВЭД-декларант умеет выгружать в своём внутреннем формате (в дистрибутиве документация на него есть но _очень_ старая), в старом открытом dbf-формате (для моей задачи он не подходит ибо доисторический, не говоря уж об ЭД2) и, естественно, в современном открытом таможенном xml.
6) Альта умеет загружать из своего внутреннего и недокументированного бинарного формата, из своего внутреннего и документированного xml-формата, и из таможенного xml-формата. При этом нормально, с сохранением связей между документами загрузка возможна только из внутреннего xml-формата (судя по форуму тоже есть ньюансы) и, возможно (не проверял) из внутреннего бинарного формата. При загрузке из таможенного формата теряются номера деклараций, связи нет ни между декларацией и описью, ни между описью и ЭД2-документами.
7) Проблему с потерей номеров деклараций и привязке описи к декларации можно решить с помощью найденного на форуме [url=https://www.alta.ru/forum/viewtopic.php?f=23&t=14916&p=118653&hilit=xml#p118653]шаманства[/url] - несмотря на то что в самой декларации в таможенном xml-формате регистрационного номера нет, он есть в описи, а опись в контейнере есть всегда, достаточно написать программку которая будет смотреть номер в описи и переименовывать или копировать с новым именем xml-файлики - при загрузке в альту такого xml-я номер ГТД остаётся а опись получается прикреплённой. Документы однако остаются не прикреплены к описи - поковырял hex-редактором выгруженные после загрузки бинарные файлики с описью и прочими документами, судя по всему при загрузке генерируются новые DocumentID всем ЭД2-документам, а в описи ссылки вообще не проставляются (для пробы руками привязал 1 документ чтобы посмотреть как это в бинарнике выглядит).
Что со всем этим в принципе можно сделать? Я вижу пока 2 возможных варианта:
1) Тщательно изучить таможенный и внутренний xml-формат альты и попытаться написать конвертер из таможенного формата в формат альты, из которого документы насколько понимаю загружаются номально, с сохранением DocumentID и связей. Вариант плох объёмом работы по строительству двух велосипедов - ведь надо уметь прочитать любой документ в таможенном формате и записать любой документ в формате альты, + по многим типам документов возможно потребуются какие-то нетривиальные действия по конвертации собственно содержимого.
2) Пытаться загружать из таможенного xml, с помощью самописной программки подправив ссылки в базе на SQL-сервере. Поскольку DocumentID после загрузки меняется - если сразу загрузить все декларации - идентифицировать потом где какой документ будет невозможно. Однако, в принципе, сразу после загрузки одной единственной декларации - идентифицировать документы по названию, типу и номеру посмотрев на последние внесённые в базу записи вполне возможно, в т.ч. программно без участия человека. В альте есть функция автозагрузки из настроенной на наблюдение папки, причём на форуме вычитал что если положить в эту папку файлик eoj.txt - альта автоматом загрузит подсунутый xml-файл и удалит оба файла из наблюдаемой папки. Т.е. по исчезновению этих файлов можно со своей программы лезть в базу, сопоставлять новые DocumentID старым и проставлять ссылки в опись, а когда всё готово - скармливать альте очерезной xml-файл - всё это в принципе можно оформить в виде программки например на delphilazarus. Но и тут имеется подводный камень - в полях баз на SQL информации почти нет, всё хранится в BLOB-ах во всё том же бинарном формате. В принципе, полностью разбирать формат нужно только для описи, а опись - штука не такая уж и сложная, по всем остальным типам надо уметь только вынимать DocumentID и, как я понимаю, заголовки файлов практически одинаковые и какой-то идентификатор похоже вообще идёт стабильно на 0x28h(40) байте, второй обычно на 0x78h(120) байте хотя для бинарного формата ГТД там примерно в том же месте но по другому смещению идёт информация о номере и типе процедуры... но в любом случае разобрать формат описи и заголовки других типов документов + реализовать чтениезапись бинарной описи и чтение идентификаторов документов из других форматов должно быть значительно проще и быстрее чем писать полноценный конвертер [таможенныйXML]-->[AltaXML].
Есть ещё третий вариант - попытаться "наехать" на техподдержку и убедить их убедить в свою очередь программистов что-то сделать с импортом из таможенного xml-формата, но судя по тому сколько лет на форуме поднимаются такие вопросы - вероятность благоприятного развития событий в этом направлении крайне мала %).
Собственно, кто что посоветует? Я скорее всего попытаюсь перекинуть декларации через таможенный формат и привязывающую документы программку, но может кто-то знает вариант попроще?