Загрузка документов в программу Альта ГТД

[Oleg_vl]

Кажется понял причину такого поведения: если загружать документ, то программа каждый раз генерирует свой новый код в поле DOCUMENTID таблицы dbo_Docs. Но нам это поле не нужно, код GUID, указанный в загружаемом файле, ложится в поле GID указанной таблицы (как я писал раньше, надо учитывать, чтобы GUID не повторялся, а то и в этом поле автоматически сгенерируется).

Если во внутреннем формате используются два поля, то к чему тогда первоначальный посыл:

В начале декабря в программе Альта-ГТД была добавлена функция, благодаря которой при загрузке XML-документов уникальный номер DocumentID присваивается из самого документа, а не генерируется программой как раньше. Это позволяет формировать опись уже с указанием этих GUID-номеров. Очень удобно и большое спасибо за реализацию этой возможности.

Поля никак не связаны и при выгрузке во внешнем файле отсутствует GUID, есть только DOCUMENTID
Как указать GUID во внешнем файле для загрузки в Альту?

И выгружается документ не с новым GUID, а просто с номером из поля GID, которое отличается от поля DOCUMENTID. И если несколько раз выгружать, он всегда будет один и тот же.

В общем надо экспериментировать и анализировать, тогда можно добиться желаемого результата.

Это как раз и подтверждает наличие двух разных полей в документах

[Synt]

Если во внутреннем формате используются два поля, то к чему тогда первоначальный посыл:

В начале декабря в программе Альта-ГТД была добавлена функция, благодаря которой при загрузке XML-документов уникальный номер DocumentID присваивается из самого документа, а не генерируется программой как раньше. Это позволяет формировать опись уже с указанием этих GUID-номеров. Очень удобно и большое спасибо за реализацию этой возможности.

Поля никак не связаны и при выгрузке во внешнем файле отсутствует GUID, есть только DOCUMENTID
Как указать GUID во внешнем файле для загрузки в Альту?

Два поля GID и DOCUMENTID используются в базе SQL (в таблице dbo_Docs). А в загружаемом/выгружаемом XML-документе только один код, который располагается в XML-тэге <cat_ru:DocumentID> и заполняется он из поля GID базы данных. Вот его то мы и указываем при загрузке файла. Потом в описи вставляем этот же самый код, как я указывал ранее, и при загрузке пакета документов сразу все документы уже привязаны к описи.

[Tradeon]

хотелось бы , чтобы документы в ЭД версии соответствовали документам бумажных носителей, а не выдумывать свои..

а мне бы хотелось, что бы Заполнитель брал из скана и раскидывал по графам в формализованный документ. Или штрихкод на всех документах. [/quote]


Иронизируете?
А меня вот лично задолбали такие тупости:
-при создании ЭД-2 паспорта сделки переносится номер приложения,а не номер договора в соответствующее поле ПСИ;
- неспособность программы перенести номер счет-фактуры за транспорт в ЭД-2 альбом (понятно,что нужно подключать Билла Гейтса на добровольных началах,ибо данная операция труднопрограммируемая);
- неспособность инспектора увидеть в коносаменте описание груза. Как выясняется,описание груза нужно помещать в графу "Описание грузовых мест";
- невозможность инспектором увидеть в 44 графе письмо ЦБ 117-и. Отображается чушь;

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

Борьба с ветряными мельницами.

[Nick]

Обращайтесь, обязательно! Обычно "методом итерраций" в конце концов любая проблема домучивается до окончательного решения.

-при создании ЭД-2 паспорта сделки переносится номер приложения,а не номер договора в соответствующее поле ПСИ;

У меня перенеслось из гр.44 03011, то есть как раз номер договора. Пришлите пример ГТД в которой не так, посмотрим.

- неспособность программы перенести номер счет-фактуры за транспорт в ЭД-2 альбом (понятно,что нужно подключать Билла Гейтса на добровольных началах,ибо данная операция труднопрограммируемая);

В какой именно ЭД-2 документ, альбомы большие...
Дело в том что до этого года "счет фактуры за транспорт" в ГТД не указывался, не было такого кода в гр.44
Поэтому может быть и до сих пор ничего с ним не делается, расскажите поподробнее, куда его надо переносить? Тут же сделаем.

Да, кстати, 99% операций по копированию полей "из ГТД в ЭД-2" не зашиты в пресловутом "ядре" (которое действительно лучше лишний раз не трогать, ибо чревато непредсказуемыми побочными эффектами), а вынесены скриптами во внешний файл wgtdinfo.dat. Так что никаких проблем нет их "доработать напильником", только пишите.

- неспособность инспектора увидеть в коносаменте описание груза. Как выясняется,описание груза нужно помещать в графу "Описание грузовых мест";

То есть название графы "Описание грузовых мест" надо поменять на "Описание груза" для большей доходчивости? Скорее всего так поле называется в *.XSD файле от таможни...

- невозможность инспектором увидеть в 44 графе письмо ЦБ 117-и. Отображается чушь;

Опять таки присылайте ГТД с примером заполнения гр.44. Такого что бы "10023 Письмо ЦБ 117-и от 15.06.2004" превратилось при выгрузке в "10023 ЧУШЬ" явно не бывает...

[Tradeon]

44 графу с письмом ЦБ таможня видит так (и я так вижу переданную ТД в формате HTML):
02024 XT66180770 02.05.2011 КНИЖКА МДП
03011 14-6/04 26.04.2011 ВОЗМЕЗДНЫЙ ДОГОВОР
04021 62667968 27.04.2011 ИНВОЙС (СЧЕТ-ФАКТУРА) К ДОГОВОРУ
04031 3119 29.04.2011 ИНВОЙС (СЧЕТ-ФАКТУРА) ЗА ПЕРЕВОЗКУ/ПОГРУЗКУ
07011 16-ФЗ 10.01.2006 ДОКУМЕНТЫ ПО ЛЬГОТАМ НА ПЛАТЕЖИ, ПОШЛИНЫ, НАЛОГИ 5010
07011 16-ФЗ 10.01.2006 ДОКУМЕНТЫ ПО ЛЬГОТАМ НА ПЛАТЕЖИ, ПОШЛИНЫ, НАЛОГИ 2010
10023 ИНЫЕ СВЕДЕНИЯ - РФ по 15.06.2004

и у них там "все ругается" на отсутствие даты выдачи документа и проч.
При этом заполнено :10023 117-И ОТ 15.06.2004 (как,собственно и положено)

В счет-фактуре на транспортные услуги существуют поля для указания кода валюты,но на деле приходится указывать валюту счета в графе "Наименование товара (описание выполненных работ, оказанных услуг) ". И выглядит это так :"ТРАНСПОРТНО-ЭКСПЕДИТОРСКИЕ УСЛУГИ ПО МАРШРУТУ ОСНАБРЮК ГЕРМАНИЯ-КАЛИНИНГРАД РОССИЯ, А/М О665/РВ/АВ9465. СЧЕТ ВЫСТАВЛЕН В ЕВРО."
Кстати,если в описи вы уже забили номер и дату выдачи счет-фактуры,то этот номер не перенесется в ЭД-2 документ.

Что касается Ваших экспериментов с номером договора и ПСИ.Номер договора в паспорт сделки ЭД-2 у Вас перенесся потому,что в 44-й графе не было дополнений. Забейте в 44-у любой номер под 03012 и Вы убедитесь,что в ПСИ снесется именно он,но не номер договора.

По поводу коносамента Вы неправы. Дело в том,что поле "Наименование груза" инспектор видит пустым,чтобы Вы туда не написали. Описание груза приходится заносить в поле "Описание грузовых мест,данные о внешнем виде,состоянии упаковки и особых свойствах груза".
Полагаю я не обладаю особой доходчивостью и по несправедливости предъявляю претензии? Но мне логика подсказывает,что графа "Наименование груза" должна иметь какое-то отношение именно к наименованию. И уж выгружаться в любом случае.
Да,а зачем нужно заполнять раздел "Подпись капитана". Приходится ставить дату коносамента в поле "Дата" раздела "Подпись капитана" иначе документ не проходит формально-логический контроль. Это фишка такая,да?

А создание контракта? Скажите,зачем программа автоматом создает нам спецификацию к договору,висящую прицепом внизу документа? Для того,чтобы мы ее регулярно и методично удаляли? Я полагаю,кому нужно - сам создаст. К тому же спецификацию программа ваяет слепком с ТД (за минусом оборотки). Т.е. такая "спецификация" даром не нужна.

Вы там хоть поглядывайте иногда,что у вас на выходе получается.

С 18-й вообще хохма. С недавних для 1-го транспортного средства с прицепом мы ставит 2.
И выглядит графа так: 2 А179СМ,АЕ1696 . Иначе никак. (через запятую,как Вы догадались,приходится указывать прицеп).

Далее: попробуйте забить товар со страной происхождения "Гонконг" и Вы приятно удивитесь тому,как программа начнет сама себе противоречить в части определения ставки пошлины

Про процедуру "ИМ60" по процедуре 6078111 (вот тафтология стала получаться ) можно уже и не говорить. Ни ЭД-2 альбомов,ни понятия у программы нет. Столько ошибок выдает при проверке - туши свет. Причем все "левые". Видимо сами создатели не представляют себе,как должна заполняться ТД при заявлении этой таможенной процедуры.

[Fioletovo]

44 графу с письмом ЦБ таможня видит так (и я так вижу переданную ТД в формате HTML):
02024 XT66180770 02.05.2011 КНИЖКА МДП
03011 14-6/04 26.04.2011 ВОЗМЕЗДНЫЙ ДОГОВОР
04021 62667968 27.04.2011 ИНВОЙС (СЧЕТ-ФАКТУРА) К ДОГОВОРУ
04031 3119 29.04.2011 ИНВОЙС (СЧЕТ-ФАКТУРА) ЗА ПЕРЕВОЗКУ/ПОГРУЗКУ
07011 16-ФЗ 10.01.2006 ДОКУМЕНТЫ ПО ЛЬГОТАМ НА ПЛАТЕЖИ, ПОШЛИНЫ, НАЛОГИ 5010
07011 16-ФЗ 10.01.2006 ДОКУМЕНТЫ ПО ЛЬГОТАМ НА ПЛАТЕЖИ, ПОШЛИНЫ, НАЛОГИ 2010
10023 ИНЫЕ СВЕДЕНИЯ - РФ по 15.06.2004

и у них там "все ругается" на отсутствие даты выдачи документа и проч.
При этом заполнено :10023 117-И ОТ 15.06.2004 (как,собственно и положено)

Позвольте узнать, а зачем Вы указываете эту центробанковскую инструкцию?

По поводу коносамента Вы неправы. Дело в том,что поле "Наименование груза" инспектор видит пустым,чтобы Вы туда не написали. Описание груза приходится заносить в поле "Описание грузовых мест,данные о внешнем виде,состоянии упаковки и особых свойствах груза".
Полагаю я не обладаю особой доходчивостью и по несправедливости предъявляю претензии? Но мне логика подсказывает,что графа "Наименование груза" должна иметь какое-то отношение именно к наименованию. И уж выгружаться в любом случае.

Есть вероятность, что инспектор не видит описание товара в поле "Наименование груза" лишь потому, что в КПС "Инспектор ОТО" криво реализовано отображение значения узла "Наименование груза" в экранной форме коносамента.

С 18-й вообще хохма. С недавних для 1-го транспортного средства с прицепом мы ставит 2.
И выглядит графа так: 2 А179СМ,АЕ1696 . Иначе никак. (через запятую,как Вы догадались,приходится указывать прицеп).

Это не хохма. Читайте пп.39 п.1 ст. 4 ТК ТС. Там ясно сказано, что к категории транспортных средств относятся и автомобильное транспортное средство, и прицеп, и полуприцеп. Следовательно, тягач с прицепом представляют собой 2 транспортных средства. Соответственно, внимательно прочтите порядок заполнения графы 18 ДТ (в решении КТС № 379 от 20.09.2010).

Про процедуру "ИМ60" по процедуре 6078111 (вот тафтология стала получаться ) можно уже и не говорить. Ни ЭД-2 альбомов,ни понятия у программы нет.
Столько ошибок выдает при проверке - туши свет. Причем все "левые". Видимо сами создатели не представляют себе,как должна заполняться ТД при заявлении этой таможенной процедуры.

Во-первых, альбом форматов электронных документов на сегодняшний день весьма куцый. Во-вторых, Инструкция о порядке заполнения декларации на товары, утверждённая Решением КТС № 379 от 20.09.2010, практически не документирует особенности заполнения граф ДТ при разнообразных процедурах, отличных от ЭК10 и ИМ40.

[Tradeon]

И смех и грех: пока мы тут с Вами боремся за исправления косяков,возникают старые. К примеру перестал сносится номер контракта в инвойс при его создании.

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

[Tradeon]

Позвольте узнать, а зачем Вы указываете эту центробанковскую инструкцию?

А Вы в случае особенности сделки "06" не указываете?

[Fioletovo]

Позвольте узнать, а зачем Вы указываете эту центробанковскую инструкцию?

А Вы в случае особенности сделки "06" не указываете?

А зачем?
Прошу в студию Ваши доказательства обязательности указания пресловутой инструкции.

[splav]

Указывать 117-И в гр.44 - это дикость, программа проверки - бесплатная и соответственно и сервис такой же, покупайте тут же софт-лэндовскую.
автоматическая формализация так понимаю разработчиками не заявляется и соответственно нечего её критиковать.
не нравится - делайте чисто с нуля.

[Bubl-Gum]

Указывать 117-И в гр.44 - это дикость, программа проверки - бесплатная и соответственно и сервис такой же, покупайте тут же софт-лэндовскую.
автоматическая формализация так понимаю разработчиками не заявляется и соответственно нечего её критиковать.
не нравится - делайте чисто с нуля.

я Вас умоляю, про софтлэндовскую программу! две процедуры ИМ-4,ЭК-1, а если режим переработки запихнуть или транзитку....

Лучше подскажите, можно ли в универсальный документ вложить контракт с дополнениями ?
я не могу заполнить контракт и дополнения в формализованном виде(в альбомы), т.к.
информация обязательная для заполнения или вообще отсутствует или в допниках.

И еще вопрос по декларированию многооборотной тары, согласно конвенции! на бумаге это выглядит как письмо с данными по грузу. Декларировать в гтд тоже смысла нет, т.к. будут сборы браться... ЧТО ДЕЛАТЬ? Люди?

[splav]

Нельзя контракт в универсальный, тару по ДТ, не понял про сборы.

[Bubl-Gum]

контракты долгосрочные,в самом контракте не оговорены даты последнего платежа и т.д. как же быть с формализацией ?
многооборотная тара оформляется не по ДТ , а по письму(на письме ставится штамп "выпуск разрешен"), естественно сборы не платятся. И получается , что по конвенции я могу по упрощенке ввозить, а декларировать без взимания сборов не могу!

[Ranger_Z]

Вы это таможне объясните.

[Sagrer]

Подниму опять тему загрузки из открытого таможенного формата в 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-формата, но судя по тому сколько лет на форуме поднимаются такие вопросы - вероятность благоприятного развития событий в этом направлении крайне мала %).

Собственно, кто что посоветует? Я скорее всего попытаюсь перекинуть декларации через таможенный формат и привязывающую документы программку, но может кто-то знает вариант попроще?

[Nick]

Пришлите, пожалуйста, пример "пакета" из ГТД, Описи и ЭД-2 документов в таможенном XML-формате от СТМ. Если в Описи для каждой строчки заполнено поле InventDocumentID и оно соответствует полю DocumentID привязанного ЭД-2 документа - тогда мы при загрузке в Альту будем эти взаимосвязи сохранять.

[100]

Добрый день. Нужен совет. При загрузке из таможенного*.dbf (операционка Windows 7) начинается процесс загрузки массива деклараций, однако он подвисает на начальной стадии и в итоге загружается лишь маленькая доля деклараций. В Windows ХР подобного не наблюдалось - Альта висела со статусом ("Программа не отвечает"), однако все файлы загружались. Какой есть путь решения данной проблемы?
Спасибо.

[Nick]

От версии Windows понятное дело ничего не зависит. Просто какая-то конкретная ГТД в загружаемой базе вызывает зависание из-за особенностей заполнения. Значит просто зависает, никакого сообщения об ошибке? Достаточно долго пробовали ждать?

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

[100]

скинуть на support@alta.ru ?

[Nick]

Спасибо за пример! Разобрались, и правда не все декларации грузились из большого *.DBF

В версии 221 будет исправлено.