Бюджет: 1000 PLN Термін: 10 днів
Доброго вечора. Маю досвід реалізації складного парсера анкет зі структуруванням. Звертайтеся.
Замовляю виконання стабільного конвертера рахунків PDF у файл JPK V7M (2) в XML, відповідного актуальній схемі MF.
Програма має:
Завантажувати папку з рахунками PDF (пакетно, багато файлів одночасно)
Парсити дані з рахунку, мінімум:
номер рахунку
дата виставлення
дата продажу (резервний варіант, якщо відсутня)
ІПН покупця
назва покупця
сума нетто
сума ПДВ
валюта (PLN / EUR)
Обробляти рахунки в EUR
автоматично отримувати середній курс НБП (таблиця A)
курс з останніх робочих днів перед датою продажу
відсутність ручного введення курсу
Перерахунок валют відповідно до ПДВ:
NETTO × курс НБП
ПДВ розраховується вже від суми в PLN
Генерувати коректний файл JPK V7M (2):
Програма повинна:
бути стійкою до різних макетів PDF (резервні варіанти, regex)
не аварійно завершуватися при нетиповому рахунку
явно фейлити, а не генерувати помилковий JPK
бути готовою до перевірки ДПІ (відсутність «вгадування» даних)
Що надаю я
приклади рахунків PDF
приклад коректного JPK V7M (2) як зразок структури
вимоги щодо бухгалтерії (ПДВ)
Бюджет: 1000 PLN Термін: 10 днів
Доброго вечора. Маю досвід реалізації складного парсера анкет зі структуруванням. Звертайтеся.
Бюджет: 2000 PLN Термін: 9 днів
Антоні, створення автоматичного конвертера PDF до JPK V7M - це завдання, яке я розумію досконало. Важливість обробки різних макетів рахунків-фактур і обслуговування валют відповідно до ПДВ - це ключові аспекти, які я можу ефективно реалізувати завдяки моєму досвіду в проектуванні систем автоматизації бізнесу.
Я використаю надійне парсинг і підберу алгоритми до змінного формату PDF, що забезпечить надійність роботи і відповідність вимогам США. Мої реалізації вже допомогли багатьом компаніям оптимізувати обіг документів, тому я з радістю впроваджу найкращі практики та рішення також у твоєму проекті.
Бюджет: 1200 PLN Термін: 10 днів
Доброго дня, у мене великий досвід у парсерах та автоматизації, тому я можу виконати це замовлення.
Python/Node.js для парсингу, те саме для генерації. Планую налаштувати базу даних для курсів НБУ, яка використовуватиметься лише з метою мінімізації навантаження (DDOS) серверів НБУ. Помилки будуть записуватись у файл.
Виконання буде використовувати виключно дані з рахунків – без жодного «вгадування» даних.
Час виконання може варіюватися в залежності від кількості прикладів рахунків.
Бюджет: 1000 PLN Термін: 30 днів
Доброго дня! Я ознайомився з вашим завданням і вважаю, що зможу успішно його виконати. Буду радий співпраці, будь ласка, напишіть мені особисто для подальших деталей.
Бюджет: 3000 PLN Термін: 14 днів
Шановний пане,
з зацікавленням ознайомився з вашим замовленням щодо створення стабільного конвертера рахунків PDF у формат JPK V7M (2) в XML, відповідного актуальній схемі Міністерства фінансів. Як досвідчений програміст, що спеціалізується на автоматизації бухгалтерських процесів і обробці документів PDF, я впевнений, що можу надати рішення, яке відповідатиме всім зазначеним вимогам.
Мій досвід:
- Маю понад 5 років досвіду роботи з Python, включаючи бібліотеки для парсингу PDF (наприклад, PyMuPDF, pdfplumber, PyPDF2) та генерації XML (xml.etree.ElementTree, lxml).
- Реалізовував подібні проекти, такі як екстракція даних з рахунків для систем ERP, обробка курсів валют з API.
Пропоноване рішення:
- Пакетне завантаження: Програма буде сканувати папку з PDF-файлами та обробляти їх пакетно, з можливістю ведення журналу прогресу.
- Парсинг даних: Використаю комбінацію OCR (якщо потрібно, наприклад, Tesseract) з регулярними виразами та запасними варіантами, щоб обробити різні макети рахунків. Мінімальні дані (номер, дати, ІПН, назва, суми нетто/ПДВ, валюта) будуть екстраговані з стійкістю до помилок – у разі нетипових рахунків програма повідомить про явну помилку.
- Обробка EUR: Автоматичне отримання курсу НБУ з останнього робочого дня перед датою продажу (або виставлення як запасний варіант). Перерахунок: нетто × курс, а ПДВ від суми в PLN, відповідно до вимог ПДВ.
- Генерація JPK V7M (2): Файл XML буде створено на основі схеми МФ, з валідацією структури. Використаю ваш приклад JPK як зразок.
- Стійкість і безпека: Програма буде "fail-safe" – не вгадує дані, а у разі проблем перериває процес з повідомленням. Готова до аудиту ДПС, з повною документацією коду та тестами на прикладних рахунках.
План реалізації:
1. Аналіз прикладних PDF та JPK (1-2 дні).
2. Прототип парсингу та перерахунку (3-5 днів).
3. Інтеграція з генерацією XML та тести (3-4 дні).
4. Оптимізація та обробка крайових випадків (2-3 дні).
Всього оцінюю на 10-14 робочих днів, залежно від кількості прикладів.
Бюджет: 1200 PLN Термін: 3 дні
Доброго дня. Робив проект, де потрібно було перевіряти pdf рахунки на підробку/не підробку. Можу переробити під Ваше завдання.
Бюджет: 1000 PLN Термін: 5 днів
Я зроблю стабільний конвертер PDF рахунків -> JPK V7M (2) XML (пакет), відповідно до схеми MF. У мене є досвід в автоматизаціях/парсингах файлів та валідації даних, тому я підійду до цього «без здогадок» — якщо щось не можна впевнено витягнути з PDF, інструмент чітко це покаже.
На старт мені потрібен пакет прикладів PDF + цей правильний JPK як зразок.
Бюджет: 6000 PLN Термін: 14 днів
Доброго дня,
я зацікавлений у виконанні замовлення щодо автоматичного конвертера рахунків PDF → JPK V7M (2) в XML.
Я маю практичний досвід у:
- парсингу документів (PDF) та витягуванні з них бухгалтерських даних,
- роботі з даними ПДВ, валютами (PLN/EUR) та курсами НБУ,
- генерації файлів XML, що відповідають схемам Мінфіну (в тому числі контроль правильності структури).
На основі опису я бачу наступний обсяг робіт:
- Завантаження папки з рахунками PDF (пакет, багато файлів одночасно).
- Парсинг ключових даних з рахунків (номер рахунку, дати, НІП/назва покупця, суми нетто/ПДВ, валюта).
- Обробка рахунків в EUR з автоматичним отриманням курсу НБУ (таблиця А):
- курс з останнього робочого дня, що передує даті продажу,
- без ручного введення курсу.
- Перерахунок НЕТТО × курс НБУ, а потім правильний розрахунок ПДВ вже від суми в PLN, відповідно до правил ПДВ.
- Генерація файлу JPK V7M (2) в XML, що відповідає актуальній схемі Мінфіну:
- валідація структури відносно схеми,
- явне звітування про помилки (програма має «падати» у разі проблеми, а не вгадувати дані).
- Стійкість до різних макетів PDF:
- підхід, заснований на фолбэках/регексах та правилах,
- без тихого пропуску або домислювання значень — рішення «готове до контролю ДФС».
З Вашого боку (прикладні PDF, правильний JPK V7M (2), бухгалтерські вимоги) дозволять добре відтворити бухгалтерську логіку та впевнитися, що конвертер не «вгадує» дані, а працює повністю детерміністично.
Пропоновані терміни:
- Аналіз прикладних рахунків та зразкового JPK, проектування мапування та архітектури рішення: 2–3 робочі дні.
- Реалізація конвертера (парсинг PDF, валютна логіка, інтеграція з НБУ, генерація JPK, обробка помилок): близько 7–10 робочих днів.
- Тестування на наданих рахунках, виправлення та зміцнення рішення: 2–3 робочі дні.
Всього: орієнтовно 2–3 календарних тижні, залежно від кількості варіантів макетів рахунків та можливих додаткових вимог з боку бухгалтерії.
Бюджет: 1000 PLN Термін: 12 днів
Доброго дня! Ознайомився із завданням, маю практичний досвід у розробці фінансових конвертерів. Готовий швидко реалізувати надійне рішення для роботи з PDF та формування валідного XML, результат покажу на ваших прикладах.
Добрый день! Хотелось бы уточнить несколько нюансов:
Какие именно макеты? Сколько существует разных видов счетов? Это 3-5 постоянных шаблонов или каждый раз новые?
Формат PDF, это текстовые PDF (где можно выделить текст мышкой) или сканы/фотографии?
Потрібен досвідчений 1С програміст для одноразової міграції даних із 1С у нову CRM систему. Необхідно виконати експорт даних з 1С із збереженням усіх зв'язків між сутностями: товари, клієнти, приходи, накладні, залишки, історія руху товарів та інші довідники. Формат вивантаження може бути JSON, SQL або інший зручний для подальшого імпорту формат. Основна вимога — зберегти структуру даних та всі взаємозв'язки між документами й об'єктами, щоб дані можна було коректно перенести в іншу CRM без втрати інформації. Буде перевагою досвід міграції даних між 1С та сторонніми системами. непотрібно мігрувати в іншу СРМ а просто дати файл або зробити фнкціонал шоб на клік зберігався локально файл дампу . В мене все ведеться локально так шо прийдеть працювати через ені деск , або шось інше. Цін на таку роботу незнаю тому пропонуйте
Щукаємо для підтримки проекта на базі Yii , треба вносити правки та доопрацювання бази , частково є звязок з попереднім виконавцем .....................
Потрібно зробити міграцію бази з CRM G-PLUS на MyChatBot Обєм бази - 26 тис. лідів 2 воронки - Кол центр та Відділ продажу зі своїми вирвами Картки лідів (крім імені та номеру) мають багато різних полів Ліди також мають голосові записи дзвінків. Їх також потрібно перенести Від кандидата очікую орієнтовну суму та терміни реалізації
Створити дашборд для моніторингу та аналізу ефективності мережі локацій (філій) компанії у Google Business Profile (GBP). через офіційний Google Business Profile API. Обробкачерез Скрипт на базі Google Apps Script (підв'язати до Google Таблиці). Запис даних у Google Таблиця (яка виступає як база даних для Looker Studio). Оновлення: Щодня (з індикацією дати останнього оновлення).Створити сервісний акаунт Google Cloud Скрипт раз на добу (тригер о 03:00 ночі) надсилає запит до GBP API. Отримує метрики за вчорашній день по кожній локації (locationId). Записує дані в таблицю в плоскому форматі (рядок = унікальне поєднанняДата + ID Філії + Метрики). Картки ключових показниківНазва карткиМетрика GBPФормат динамікиПерегляди профілюImpressions (Search + Maps)Відсоток %, Sparkline (синій)ДзвінкиLocal Services Phone CallsВідсоток %, Sparkline (зелений)Переходи на сайтWebsite ClicksВідсоток %, Sparkline (фіолетовий)Побудова маршрутівDirection RequestsВідсоток %, Sparkline (помаранчевий)Середній рейтингAverage Review RatingАбсолютна зміна (наприклад, +0.1), Sparkline (жовтий)Нові відгукиNew Reviews CountВідсоток %, Sparkline (бірюзовий)
Всім привіт! Шукаю Backend-розробника (NestJS) для роботи над новим проектом. Що потрібно зробити Розробити REST API на NestJS. Підготувати і підтримувати документацію через Swagger (OpenAPI), щоб фронтенд-розробник міг автоматично генерувати клієнт через Orval і завжди працювати з актуальною специфікацією. Спроектувати чисту, масштабовану архітектуру, яку буде легко підтримувати і розвивати. Вимоги Упевнене знання NestJS та TypeScript. Досвід роботи з PostgreSQL. Досвід інтеграції з Supabase: автентифікація та авторизація; робота з базою даних; використання готових можливостей платформи. Досвід інтеграції Stripe (через можливості Supabase). Розуміння принципів безпеки API, авторизації, валідації даних і захисту додатку. Вміння писати чистий, структурований і розширюваний код. Якщо у вас є релевантний досвід, будь ласка, надішліть: приклади проектів або GitHub; бажану ставку (за екрани, які я надав, щоб я розумів ваш рейт, погодинна не зручна, оскільки не зрозуміло, який обсяг роботи буде виконано, у всіх різний темп);