Інтеграція (потокове вивантаження податкових накладних)

[Kreont]

Дуже цікавить питання інтеграції медок+1С (чи інша система обліку) щодо вивантаження податкових накладних (ПН).

Що цікавить, чи можна зробити так:
1. Система обліку (місце де створюються ПН) створює файл xml.
2. Викликаючи через ОЛЕ (чи навіть через командну стрічку в крайньому випадку) бібліотеку медка, здійснюється підпис xml файлу
і його завантаження (імпорт в медок). Без завантаження візуальної оболонки медка і без внесення паролів на кожне підписування,
тому що кількість накладних дуже велика.
3. Можливість підключення до бази медка (Який буде постійно включений в режимі перечитування квитанцій/підтверджень з пошти) щоб з "іншої" програми
можна було взнати чи конкретна вивантажена ПН пройшла успішно/неуспішно реєстрацію.

П.С. Ще цікавить де є інструкція до криптографічної бібліотеки: QuickLib і чи я її можу сам використовувати для підпису і відправлення?

П.С.С. медок база даних бачу працює на firebird, можуть розробники опублікувати структуру бази даних + звязки + хоч якийсь мінімум опису полів.
Можливо це і буде одним із способів як для вивантаження файлів xml, так і для перевірки статусу ПН.

[Родин Евгений]

1. Вопрос к той системе, в которой будете формировать ХМЛ.
Любая система учета, настроенная на формирование ХМЛ на основании схемы XSD.
2.Навряд ли будет. Оболочка создается именно для того, чтобы запретить пользователю делать то, что нненужно. Это один из принципов программирования пользовательского интерфейса.
3. Есть один нюанс (заодно отвечу на последний вопрос П.С.С): используется Embedded версия (СУБД FireBird, верно), а это значит, что подключаться можно только одним клиентом. Т.е. и Медок, и Ваша самописная программа работать одновременно небудут, только одна из них. Т.е. в режиме реального времени этого сделать неудастся. Вышли из Медка - включили программу проверки, выключили программу - включили Медок (для отправки). Технически подключение к базе данных и проверку ответа реализовать можно. Насчет структуры БД --- ее можно запросто просмотреть, используя стандартные средства FireBird Maestro, IBExpert (это из рекомендуемых). Все настройки подключения и прочую информайцию можно найти в Гугле. Публиковать такую информацию разработчик навряд ли будет, т.к. это всеравно что "Самоучитель по трепанации черепа".... может плохо закончиться, и виноват конечно будет, разработчик (как иначе.... всегда и во всем разработчик виноват...). Вцелом названия таблиц соответствуют общепринятой "венгерской нотации".
П.С. методика работы QuickLib неразглашается.

[Kreont]

Спасибо за ответ.

Я в первом посте имеел ввиду по пунктах скорее не отдельные задачи, а последовательность работы.
Задача стоит в том чтоб оптимально (именно оптимально а не выделять отдельного человека "шифровальщика" для отправки налоговых накладных) сделать обмен между учётной системой и программой подписи и обмена електронными сообщениями с порталом ДПИ.

Перефразирую вопрос.
Есть для примера 10000 налоговых накладных.
1. Программа учётная 100% умеет создавать правильные xml-файлы, умеет их сохранять, и передать научу (через файл, или записать в БД), это не проблема. Причем все это из учетной программы можно сделать одним пакетом а не по отдельности. (В результате получим 10000 xml-файлов). На это у меня уйдет времени компьютерного допустим 10 мин.
2. Если у медка будет интерфес обмена для импорта сразу 10000 и подписывания тоже сразу всех накладных + отправка (и все вложится в 10 мин.- вообще супер) тогда хорошо. Если такого механизма не будет, а надо будет вручную импортировать по одной с выбором каалога или подписывать по одной и на каждый ключ вносить пароль тогда речи об "пользовательского интерфейса" не будет, оно затмится попросту производительностью и рутинной работой. Вот для таких процедур мне и надо будет иметь возможность из "своей" программы автоматом передать+подписать 10000 документов. Причем желательно что б пользователь "случайно" не выбрал ненужный каталог и не скинул например налоговые накладные из демо базы. В режиме обмена через файл я такую ситуацию могу предвидеть, а вот когда через обмен напрямую (ОЛЕ, или файлом не двая возможности изменить сам файл) между учетной базой и програмой медка, такую возможность я смогу исключить.
3. Учетная система должна в автоматическом режиме отслеживать состояние (квитанции полученны от ДПИ) переданных налоговых накладных используя модули медка (поскольки все 10000 * к-во получено/1-й уровень/2- уровень = 30000 квитанций) для расшифровки и получения ответа о возможности отпуска товара. Если все будет скрыто от пользователя тогда нормально, если он будет вводить пароль на каждую полученную квитанцию , то думаю тут любой GUI интерфес не справится, в таких случая важна скорость а не красота И если 3-й пункт (не считая время на обработку сообщений порталом ДПА) тоже будет исполнятся до 10 мин. то нормально.

Или предложите кто нибудь Ваше видение обмена накладными через Медок если есть 10000 накладных (в день, "на уже"), будет очень интересно услышать...

[Родин Евгений]

В 044 будет система, удовлетворяющая этим требованиям. По крайней мере надеемся, что она вам понравится

[Kreont]

В 044 будет система, удовлетворяющая этим требованиям. По крайней мере надеемся, что она вам понравится

Вже версія 10.00.049, а оптимізації і швидкодії не наблюдається.

Вихідні дані: 900 податкових накладних (ПН).
Компютер: i7, 6GB памяті.

Час вивантаження xml файлів з 1С: 1хв.
Час завантаження в медок всіх цих ПН: 10хв.
Після того як виділили всі ПН і натиснули кнопку відправити в ДПА: система медок "думала" 20 хв. (перевіряючи структуру xml на коректність я так розумію,
хоча для чого ця операція не зрозуміло, я тому і писав в попередніх постах: що в даному випадку з 1С вивантажують "ідеальні" xml файли податкових, які вже перевіряти не потрібно). Чи можна модифікувати, чи зробити в медку опціонально перевірку струтури хмл при вивантаженні, щоб виключити ці затримки?

І після цього пішла ще відправка на пошту, десь біля 10хв.

....тут чекаєм коли портал згенерував повідомлення... (Що радує що сайт ДПА відповів на протязі 10-15хв. на всі повідомлення).

І натиснули в медку отримати пошту (закачка квитанцій), система спочатку качала повідомлення з пошти: приблизно 3-5хв.
плюс я так розумію після цього почалось внесення в базу медка і співставлення отриманих квитанцій, ще 10-15хв.

Як на мене вся ця процедура тривала задовго, враховуючи що були скинуті тільки ПН за один день
і цю операцію бухгалтер відтепер буде повинен виконувати кожен день.

А ну і головне забув добавити, в момент першого експорту на сайт програма медок видала повідомлення про System.OutOfMemoryException (Це на компі з 6ГБ).
Видаючи вікно з помилкою на "випадкові відправки ПН" і так в результаті на 250 накладних, добре що під рукаю був степлер, яким притиснув кнопку ESC і це повідомлення з помилкою "з допомогою степлера і мат..." пройшло. Звичайно що після цього прийнято рішення ще раз імпортувати всі накладні і ще раз повторно вивантажити їх (другий раз як не дивно помилка про брак памяті не зявилась:). Так що наведений час можна сміло множити на 2 якщо виникають будь-які помилки

[Гресь Светлана]

А Вы пробовали использовать автоматическую обработку НН в модуле Реєстр первинних документів?

[Kreont]

А Вы пробовали использовать автоматическую обработку НН в модуле Реєстр первинних документів?

Знаю за цей модуль, наразі ні, але я думаю що він мало що допоможе, зайву перевірку структури медок і так буде робити.

Сьогодні відтестуєм через модуль авт.обробки, звіт про час виконання напишу завтра обовязково

[Kreont]

Протестував аналогічно через модуль "автоматичної обробки".
Тільки заміри маю вже для 700 шт. ПН:

Авто імпорт з каталога: 8 хв. (зовсім не швидше, навіть трохи повільніше ніж звичайно)

Автомат відправка на пошту: (Перше що хотілося б, це бачити "прогрес бар" відправки)
А то почекавши 2.5хв, я натиснув зупинити, зявилось вікно:
"Зачекайте триває зупинка автом.обробки", яке висіло 7хв. що зробило невідомо. Змін в реєстрах відправлених/отриманих документів не побачив,
таке враження що просто підвисло на моменті не відправки а перевірки пошти.

Після цього ще раз попробував автоматом відправити пошту:))
Знову нічого не видно і нічого не зрозуміло, почекавши тепер 7хв., знову зупинив непобачивши ніякого руху...
П.С. Інструкцію з файлу про "Автоматичну обробку перечитав"

І тоді перейшовши в модуль податкові накладні відправили все звичайним способом:
Файл-Відправити в ДПА (час 8 хв поки не зявилось вікно вибору е-мейлу куда відправляти)
І тоді ще 4 хв. сама відправка.

Аналогічно маємо проблеми з часом отримання і оброблення квитанцій. Ну дуже довго, йде отримання і обробка.
Поштовий сервер власний, налаштовано зберігати листи на сервері на протязі 3-днів. Якщо зараз натиснути доставити пошту медок підвисає на 10-15хв.
Через це я догадуюсь і автомат.відправка і не працює, хоча...

Що хто порадить як прискорити процес?

І чи можна відключити в медку перевірку структури файлу хмл перед відправкою чи імпортом?

[Kreont]

І чи не поможе таке рішення: поставити медок в демо режимі і відправляти і підписувати податкові без імпорту хмл, а тільки як звичайні файли?

>>> Хоча це повний парадокс тоді буде, для чого тоді купляли програму невідомо?

[pumbaE]

Парадокс? Нет! http://www.me-doc.com.ua/forum/viewtopi ... 0&start=10 пример.

[Kreont]

Я можу отримати логін + пароль до firebird: щоб самому читати дані напряму з ZVIT.FDB ?

[Родин Евгений]

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

[Kreont]

А если медок серверная установка?

[skirillov]

Как я понимаю, в серверной тоже монопольно база открываеться, но уже службой zvitgrp, кот. выступает как контролер доступа пользователей.
Тогда нужен протокол работы со службой, кот. скорей всего не дадут.

[VovaRivne]

Ще цікавить, чи можна реалізувати прогресс бар процесу імпотрту под. накладних, бо незрозуміло скільки ще чекати. В день завантажуються 2500 ПН