Бюджет: 1700 UAH Термін: 2 дні
Выполню отчет по вашему шаблону с отборами по техническому заданию
Создание внешнего отчета (отчет по закупкам)
1С:Підприємство 8.3 (8.3.14.1694)
"Управление торговым предприятием для Украины", редакция 1.2. (1.2.56.2)
Postgresql
Бюджет: 1700 UAH Термін: 2 дні
Выполню отчет по вашему шаблону с отборами по техническому заданию
Бюджет: 30000 UAH Термін: 10 днів
Доброго дня, Андрію.
Зроблю Вашу задачу так, як і вирішили в її обговоренні:
- В регістр Закупки додам два ресурси СтоимостьРегл та НДСРегл.
- В усіх місцях використання цього регістру врахую появу цих ресурсів.
Особливу увагу приділю проведенню документів:
+ АвансовыйОтчет
+ ВозвратТоваровПоставщику
+ ВозвратТоваровПоставщикуИзНТТ
+ ГТДИмпорт
+ КорректировкаЗаписейРегистров
+ ОтчетКомиссионераОПродажах
+ ПоступлениеДопРасходов
+ ПоступлениеИзПереработки
+ ПоступлениеТоваровУслуг
+ ПоступлениеТоваровУслугВНТТ
- Створю зовнішній звіт на СКД, який буде відображати данні регістру Закупки за вказаний період часу кожного дня з вказаного періоду дат. У вигляді, як у прикладених файлах.
- Створю зовнішню обробку, за допомогою якої можна буде заповнити нові ресурси регістра для вже існуючих рухів документів.
- Перенесу зміни на конфігурацію Вашої Живої бази (і виконаю на ній свою обробку).
Оцінюю задачу в 30 000 грн. На роботу мені потрібно 5-10 днів, але так як я навряд чи зможу почати раніше 6-го вересня, то кінцевий срок закриття задачі взяв би на 20 вересня.
Я зареєстрований ФОПом (ЄП, 3 група, без ПДВ).
Приймаю оплату виключно на розрахунковий рахунок ФОПа. При цьому саму задачу можна провести через Сайт з вказанням, що оплата буде здійснена поза Сайтом. Це може бути корисно для можливості залишити один-одному відгуки.
Можу прийняти оплату, як від юридичної особи, так і від фізичної особи.
Якщо Вам потрібен договір, то можемо підписати договір, і тоді оплата буде по актам виконаних робіт.
Якщо договір не потрібен, тоді оплата по рахункам-офертам.
Я демонструю результат віддалено, і після надходження від Вас грошей, віддаю його Вам.
На мої роботи даю гарантію:
Якщо після отримання результата Ви знайдете якісь помилки в тому, що я робив, то виправляю їх безкоштовно (цей ризик включено у вартість і мотивує мене робити все якісно з першого разу).
Більш детально про мене та взаємодію зі мною можна у мене на сайті почитати: http://hj.net.ua/synergies.html
Бюджет: 1420 UAH Термін: 3 дні
Добрый день. Готов выполнить заказ. Необходимо обсудить нюансы и можно приступать к работе.
Бюджет: 3000 UAH Термін: 2 дні
День добрый,
готов выполнить вашу задачу, опыт работы в написании отчетов есть и в работе с УТП тоже.
Бюджет: 1800 UAH Термін: 1 день
Добрый день. Обращайтесь - сделаем с использованием СКД со всеми настройками и отборами.
Опыт работы 17 лет.
Сертификаты 1С.
Контакты в профиле.
PS: Всем своим клиентам дарим модуль загрузки курсов валют с интернета.
Бюджет: 2000 UAH Термін: 2 дні
Добрый день! Буду рад сотрудничеству. Обращайтесь в ЛС для обсуждения.
Бюджет: 2999 UAH Термін: 2 дні
Доброго дня. Напишу вам такий звіт, можемо додатково поспілкуватися і уточнити всі нюанси. Дякую
Здравствуйте, Андрей.
Так в УТП закупки по регламентированному учету не ведутся в разрезе номенклатуры (если смотреть на регистр накопления ПриобретенияНалоговыйУчет). В регистре накопления Закупки - только данные управленческого учета.
Или Вам нужно объединить регистр накопления Закупки с регистром бухгалтерии Хозрасчетный (проводки Дт 2х Кт 63)?
Добрий вечір, так знаю що в регл. обліку не ведуться, показує лише управ. обліку. В нас валюта управ. обліку долар, а регл. обліку грн. Інвестор хоче ще бачити закупки і в грн.
То Вам потрібно просто перерахувати суми в доларах у гривню по поточному курсу (на яку дату)?
Чи потрібно організувати облік закупівель у гривні? Наприклад, додати ще один регістр і зробити, щоб документи робили по ньому рухи одночасно з рухами по регістру Закупівлі?
Алгоритм роботи наступний (в налаштуваннях валюта регламентованого обліку гривня, валюта управлінського обліку долар, курси валют щодн обновляються з фінанс.юа
1) закуповується сировина (продукція) - в 1с вводиться накладна, номенклатура з характеристиками, ціна зазначаєть в грн
2) щодня необхідно робити звіт по прийнятій продукції за зміну, тому у відборі вказувати ще й години окрім дати. наприклад звіт за період з 01.08 по 27.08 або з 27.08 8:00:00 год по 27.08 18:59:59 год., має відображатись кількість прийнятої продукції, вартість і сума як в грн так і доларах. в розрізі номенклатури скільки кожний контрагент поставив, або навпаки контрагент яку продукцію поставив, скільки і по якій ціні. Якщо заданий діапазон дат більше ніж один день то має будуватись по кожній даті. Це все приблизно описано наочно в файлах до завдання
По перше, потрібно зрозуміти, що хоч в документах і вказана гривня, але у регістр (по якому будується звіт) потрапляють долари.
Отже є два найочевидніших варіанти вирішення Вашої задачі (насправді їх значно більше, але то все варіації на тему цих двох).
1. Можна розраховувати суми в гривні при побудові звіту (курс брати з регістру з курсами валют на дату документа надходження, або прямо з документа надходження - в ньому фіксується той курс, по якому взаєморозрахунки з постачальником відображаємо).
В цьому випадку істотних змін в конфігурацію вносити не потрібно. Задача вирішується відносно швидко і не дорого.
Але формуватись цей звіт може годинами (може й швидше, але не настільки швидко, як користувачам зазвичай хочеться).
2. Можна в той же регістр Закупівлі додати ще один ресурс СумаРегл і при проведенні документів заповнювати його вказаною в документі суммою гривень, або перерахованою сумою документа з іншої валюти (якщо документ надходження валютний) у гривню.
Ну і потрібно буде або перепровести всі документи, або (що краще, хоч і витратніше) - написати ще обробку, яка в рухах всіх існуючих документів розрахує цей ресурс.
Цей варіант більш правильний з точки зору архітектури і методології розробки.
І в цьому випадку звіт буде формуватись "миттєво" (так як він формується зараз).
Вам який варіант більше до вподоби? На який бюджет Ви розраховуєте?
Якщо будемо все-одно вносити зміни у конфігурацію (варіант 2 без цього неможливий), то звіт все-одно робимо зовнішнім? Чи краще вже в конфігурацію його вставити?
Ще питання.
1.У звіт мають потрапляти ТІЛЬКИ прибуткові накладні?
Чи повернення, коригування, авансові звіти, звіти комісіонерів про продажі, надходження доп. витрат, надходження з переробки - теж?
2.
Я правильно розумію, що Вартість - це Ціна?
І вона розраховується як Сума / Кількість?
Чи має якось витягуватись вказана в документі Ціна?
1) на даний момент це поки тільки прибуткові. зараз в базі лише близько 500 документів
2) так вартість це ціна (ціна*к-ст=сума)
бажано щоб ціну відображало
на даний момент це поки тільки прибуткові. зараз в базі лише близько 500 документів
Тобто на даний момент обмежуємо задачу?
Варіант 1.
- В регістрі Закупки СумаРегл та НДСРегл будуть заповнюватись ТІЛЬКИ для прибуткових накладних (для інших документів там будуть нулі).
- У звіті потрібно реалізувати додатковий фіксований відбір, щоб у звіт потрапляли тільки рухи прибуткових накладних (доречі, в цьому випадку звіт буде трохи повільніше формуватись).
Так?
Варіант 2.
Чи бажано все ж таки зробити корректно (щоб всі документи рухали регістр правильно)?
Просто доробити це пізніше буде значно дорожче, ніж зробити це зараз вкупі з прибутковою накладною.
Варіант 3.Чи інші документи (крім прибуткової) не чіпаємо (вони будуть по регістру робити рухи з нульовими регламентними сумами), але і в звіті обмежень не вносимо (просто для не прибуткових накладних регламентні сума і вартість будуть нульові)?
Підкажіть, будь ласка, а що сталось з цією задачею? Її ж наче взялись виконувати. А тепер вона закрита без виконання.
Шукаємо досвідченого спеціаліста з 1СBAS КУП, який допоможе інтегрувати роботу з мобільним додаткомпід ключ.Наразі ми ще не визначилися з програмним забезпеченням та мобільним додатком для ТЗД, тому шукаємо фахівця, який має практичний досвід, орієнтується в сучасних рішеннях на ринку та зможе не лише порекомендувати оптимальний варіант, а й повністю його впровадити. Що потрібно зробити:встановити та налаштувати мобільний додаток і інтегрувати його з BAS КУП;підібрати та запропонувати ТЗД;налаштувати коректний обмін даними між BAS і мобільним додатком;протестувати роботу системи та, за потреби, усунути помилки або виконати необхідні доопрацювання.провести навчання для користувачів Bas Куп та ТЗДПроєкт потрібно реалізувати терміново, тому для нас важливо знайти спеціаліста, який готовий оперативно розпочати роботу та довести впровадження до повноцінного працездатного стану. Вимоги до кандидата:досвід роботи з BAS КУП та інтеграцією мобільног додатку;знання сучасних рішень для автоматизації складу;досвід реалізації аналогічних проєктів "під ключ";можливість розпочати роботу найближчим часом. У відгуку, будь ласка, коротко опишіть свій досвід, вкажіть, яке рішення ви рекомендуєте для нашого випадку, наведіть приклади схожих проєктів та повідомте, коли готові приступити до роботи.
Увага Виробництво шукає фахівця для довгої співпраці!!! Шукаю розробника або команду, яка допоможе створити недорогу, надійну та просту у використанні систему автоматизації виробництва для цеху обвалки курятини. Основна мета – максимально автоматизувати процес зважування, маркування продукції, ведення складського обліку та забезпечити повну простежуваність кожної партії продукції від приймання сировини до відвантаження покупцю. Основний функціонал 1. Інтеграція з ваговим обладнанням Підключення електронних ваг до персонального комп’ютера. Автоматичне отримання ваги без ручного введення. Підтримка одного або декількох робочих місць. 2. Автоматичний друк термоетикеток Після зважування система автоматично друкує етикетку, яка містить: найменування продукції; вагу; номер партії; дату виробництва; термін придатності; код або ПІБ працівників, які виконували операцію; штрих-код або QR-код; іншу необхідну інформацію відповідно до вимог підприємства. 3. Автоматичний складський облік Система повинна забезпечувати: приймання тушок на виробництво; автоматичне списання сировини; оприбуткування готової продукції; облік залишків у режимі реального часу; контроль втрат та виходу продукції. 4. Відвантаження продукції Формування замовлень покупців. Комплектація замовлень. Автоматичне списання продукції зі складу. Контроль залишків після відвантаження. 5. Простежуваність (Traceability) Це один із найважливіших модулів системи. Необхідно забезпечити можливість у будь-який момент визначити: з якої партії тушок виготовлена кожна одиниця продукції; коли вона була вироблена; хто саме виконував її обробку; на яких вагах була зважена; які вагові показники були зафіксовані; коли та кому була відвантажена. Також система повинна дозволяти швидко знайти всі одиниці продукції, виготовлені з конкретної партії сировини, що особливо важливо у разі перевірок або відкликання продукції. 6. Звіти Бажано реалізувати: залишки на складі; рух продукції; виробіток працівників; вихід продукції з кожної партії; втрати при обвалці; історію всіх операцій; статистику виробництва за будь-який період. Побажання Простий та інтуїтивно зрозумілий інтерфейс. Мінімальна кількість ручного введення інформації. Робота без дорогих ліцензій. Локальна база даних із можливістю резервного копіювання. Можливість подальшого розширення функціоналу. Підтримка інтеграції з вагами та термопринтерами (Zebra, Godex, TSC, Xprinter або аналогічними). У відповіді прошу зазначити Приклади аналогічних проєктів. Запропоновану технологію розробки. Орієнтовну вартість та строки виконання. Підтримувані моделі ваг і термопринтерів. Пропозиції щодо покращення системи. Перспектива співпраці У майбутньому планується розширення системи до повноцінної виробничої ERP із автоматизацією всіх процесів підприємства: закупівель, складу, виробництва, контролю якості, логістики, продажів та фінансового обліку. Тому шукаю спеціаліста або команду для довгострокової співпраці. Я б також одразу додав ще одну вимогу, яка суттєво підвищить практичну цінність системи:розрахунок виходу продукції та втрат. Наприклад, якщо прийняли 1 000 кг тушок, система автоматично показує: скільки отримано філе, стегна, крил, гомілки тощо; загальний відсоток виходу; технологічні втрати; виробіток кожного працівника або бригади; собівартість кожної позиції.
Комунікаційна/рекрутингова агенція. CRM — NetHunt (тариф Business, 2 користувачі). Дві воронки — кандидати і клієнти — уже створені самостійно. Це внутрішній робочий інструмент для команди з 2 осіб, не публічний продукт. Мета — коректно налаштувати систему, автоматизувати рутину і звʼязати з CRM зовнішні інструменти (Google-форма, Notion, Telegram). Що потрібно зробити Ревізія й оптимізація структури бази та двох воронок (поля, етапи) під рекрутингові процеси. Автоматичні листи кандидатам при переході між етапами воронки (нативний workflow NetHunt + шаблони). Автостворення картки кандидата із заявки — оцінити два варіанти: (а) нативна форма NetHunt; (б) з наявної Google-форми через вебхук/Make. Notion → NetHunt: при створенні запису в базі [ВКАЖИ, ЯКІЙ] автоматично створюється картка в CRM (через Make/Zapier, мапінг полів, захист від дублів). Підключення Telegram — оцінити два варіанти: (а) двостороння інтеграція (чати кандидатів стають картками, відповідь із CRM); (б) односторонні автоповідомлення. Тестування всіх сценаріїв + навчання 2 осіб + коротка інструкція. Критерії успішного результату Усі автоматизації працюють стабільно, без дублів і втрати даних. Команда розуміє, як користуватись системою і вносити прості правки самостійно. Є коротка зрозуміла документація по налаштованому. Прошу вказати у відгуку Фіксовану ціну окремо по кожному пункту + разом. Термін виконання. Чи входить підтримка після запуску (напр., виправлення багів 1–2 тижні). Схожі кейси: впровадження NetHunt та/або інтеграції через Make.
Шукаємо спеціаліста з Google Sheets для підтримки існуючої таблиці обліку виконаних робіт та розрахунку заробітної плати. Таблиця вже створена та містить багато формул і взаємозв'язків між аркушами. Наразі виникли помилки, які потрібно знайти та виправити. Потрібно: проаналізувати структуру таблиці; знайти та усунути помилки у формулах; за потреби відновити коректну роботу таблиці; пояснити принцип роботи, щоб ми могли самостійно виконувати прості зміни в майбутньому; за можливості здійснювати подальшу підтримку таблиці. Буде перевагою досвід роботи з Google Apps Script, якщо таблиця використовує автоматизацію. Перед початком роботи надам доступ до таблиці та поясню, у чому полягає проблема.
Додавання фото документів через телеграм бот. Підключення до BAS має виконатись як розширення - без зміни конфігурації. Налаштування: 1. Журнал, для встановлення налаштування для яких обʼєктів працюватиме. Обʼєктом може бути документ або довідник. 2. Журнал користувачів бота. В журналі підтвердження користувачів бота, привʼязка до користувача BAS (користувач бота може не бути користувачем BAS), підрозділ по замовчуванню 3. Налаштування доступу для зебереження на FTP 4. Налаштування підрозділів та директорій на FTP для підрозділів Реєстрація 1. по номеру телефону 2. Підтвердження реєстрації в BAS (проставити галочку активний) Режим роботи. Режим 1. 1. З документу натискається клавіша "додати фото". (клавіша для користувача натискається тільки раз, і до завершення операції в боті для користувача не активною для цього чи інших документів) 2. Бот відправляє користувачу повідомлення "додайте фото або документ". 3. Користувач прикріпляє фото (одне або декілька) і натискає в боті клавішу "відправити" (або скасувати) 4. Повідомлення в телеграм про успішність відправлення. 5. Фото прикріпляється до документу в BAS. Режим 2. 1. В бот додаються фото 1 або декілька 2. Появляється кнопка "відправити" (або скасувати) 3. Повідомлення в телеграм про успішність відправлення 4. Загрузка файлу в директорію підрозділа. Назва файлу формується як: 2026_06_24_Документ_Телеграмuser