Разработка 1С «под ключ» в Москве от Трисофт это:

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

  1. Определяем: необходима индивидуальная разработка или есть подходящие типовые решения 1С с минимальным «допиливанием» — это и есть анализ требований.
  2. Запуск разработки, доуточнение требований, добавление функционала, встречи/обсуждения/созвоны. По итогу реализуем первый вариант, согласно MVP.
  3. Тестирование проходит и во время разработки, но именно рабочий вариант сборки и тестирование нашими силами позволяет найти слабые места, которые так не любят разработчики, но именно этот этап предоставляет в итоге ВАМ качественный продукт.
  4. Далее идут внедрение, обучение сотрудников, иногда мелкие доработки и сопровождение. Сопровождение может быть и в формате аутстафф в Москве.
Из чего состоят услуги компании по профессиональной разработке 1С
Анализ 18%
Разработка 35%
Тестирование 25%
Внедрение 22%

Ответы на частые вопросы разработки 1С на заказ

Дадим человеческие ответы на технические вопросы и бизнес-запросы

Потому что 1С:Предприятие позволяет реализовывать бизнес-решения с нуля. Но ещё важнее то, что за счёт гибкости системы 1С можно модифицировать/кастомизировать уже существующие решения, которые себя зарекомендовали в бизнесе заказчика, но требующие изменения из-за нововведений в законодательстве, бухгалтерии или под требования конкретных отделов внутри компании. 

  • Выяснить все требования, заглянуть в «серые зоны», выявить неучтённое, формализовать.
  • Описать бизнес-процессы с привязкой к возможностям платформы 1С.
  • Простым языком донести требования заказчика до разработчиков.
  • Протестировать разработанное и обучить пользователей.
Обойтись можно, но может выйти дороже. Неучтённая логистика перемещения товара между складами, пропущенная функциональность или отсутствие рекомендации перехода на ЭДО (электронный документооборот) – всё это реальные примеры экономии на анализе. Если нет штатного аналитика, можно нанять стороннего или воспользоваться опытом внутри компании разработки. 
У нас есть не только аналитик, но и архитектор автоматизации и бизнес-решений. Да, дорого, но цена ошибки может стоить кратно больше.

Давайте немного в техническую часть заглянем:

С нуля проще создавать: во-первых, не нужно искать варианты внедрения через прослойки доступа к данным, разбираться с текущим пользовательским интерфейсом, искать компромиссы и вставлять костыли в старый код.

Базовые библиотеки 1С имеют все необходимые объекты под любой размер и вид бизнеса. Несколько примеров: регистры накопления для товарного и суммового учётов, методы периодических расчётов (зарплаты, счета, договоры и т.д.), наличие иерархических справочников, регистр бухгалтерии для бухгалтерского и международного финансового учётов.

Решения из коробки дают набор паттернов (те же документы, справочники, счета, регистры сведений, разграничение ролей пользователей, и т.д.), что позволяет меньше программировать, а больше использовать уже давно написанные работающие модули и компоненты как самой платформы 1С, так и реализованных на ней конфигураций, например, «1С:ERP Управление предприятием», «1С:Управление торговлей». Экономим на разработке и тестировании новых блоков для решения бизнес-задач. Индивидуальные потребности бизнеса стараемся закрыть минимальными доработками.

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

Наверное, самая частая причина проблем обновления платформы. Хуже всего то, что практически невозможно спрогнозировать: упадёт часть функционала или пройдёт всё гладко и незаметно. 

Пример из практики: десятки магазинов по всей стране завязаны на кассовое обслуживание, выдачу чеков, проведение платежей от покупателей. Что будет, если мы внепланово решим установить обновление платформы… Кассы зависли, чеки не выдаются, продажи встали. И если для небольшого магазинчика проблема решается подручными средствами, то для крупного бизнеса такие ошибки приводят к миллионным убыткам.

Решение: установка на тестовый и далее на предпродуктовый контуры, оперативная связь с разработчиками 24/7, прямые контакты без call-центров и, как было выше сказано, работа аналитика при разработке должны подсветить возможные проблемы и заложить комплексное решение на случай форс-мажора.

Почему нам стоит выбрать вас?

Как сказал один известный дизайнер: «Я всегда выбираю гостиницу с четырьмя звёздами. Почему? Потому что они работают над тем, чтобы выбрали их. А переплачивать за бренд — не в моих правилах». Качественно сделанная работа наше кредо.

Если нужны сразу голые цены, то можно перейти по ссылке. Подробно расписали стоимость каждого программиста в Трисофт.

С нуля 1С разработка в Москве стоит от 1 380 руб./час работы программиста. Почему такая чёткая градация? Потому что ценообразование прозрачное, нет скрытых услуг, планирование даёт совсем небольшую погрешность от прогнозируемых до фактических затрат.

Итоговая стоимость зависит от конкретного количества часов, необходимых на реализацию вашего технического задания. Договорные отношения подразумевают прогнозируемость затрат и результата.

Как и всегда, конечная стоимость под ваши требования лучше обсуждать с нашими менеджерами или напрямую с руководителем Михаилом.

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

Наш девиз: три шага от потребности к готовому софту. Контакт, анализ, разработка. Для тех, кто читает всё, что написано — скидка 🙂 Сообщите по телефону про первый шаг и получите особые условия ценообразования.

1С разработка. Примеры выполненных задач.

Конечно, мы разработали значительно больше расширений, интерфейсов и модулей, чем представлено ниже. Но наш специалист по рекламе сказал, что обязательно нужно показать примеры выполненных работ на данной странице. Так как мы ему доверяем, то будем рады, если вы ознакомитесь с приведёнными примерами ниже 🙂

Описание

Обмен информацией между закупщиком и продажником осуществлялся с низкой эффективностью и система взаимодействия нуждалась в оптимизации. Кроме того, в экстремальных случаях невозможно было определить слабое звено, являющееся причиной срыва сделки, поскольку причиной отмены сделки могло стать как долгое оформление заказа менеджером по продажам, так и неоперативная работа закупщика. Используемая информационная система не позволяла повлиять на данную ситуацию. Такое положение дел могло привести компанию к возможным потерям клиентов и части выручки. Поэтому было принято решение разработать модуль для управления взаимодействием между менеджером по закупкам и менеджером по продажам.

Сокращения

  1. ЗСНН - запрос на создание новой номенклатуры.
  2. ЗУЦ - запрос на уточнение закупочных цен.
  3. Закупщик - менеджер по закупкам
  4. Продажник - менеджер по продажам

Вводные данные

Создание новой номенклатуры по запросу

  1. Автор заказа клиента (продажник) на основании заказа формирует запрос на создание новой номенклатуры исполнителю (закупщику).
  2. Исполнителю автоматически формируется задача.
  3. Исполнитель обрабатывает запрос: создает и указывает в запросе номенклатуру, подбирает аналоги или отказывает, и передает запрос автору для проверки.
  4. Автору автоматически формируется задача на проверку.
  5. Если причина отказа удовлетворительная и остальная часть запроса выполнена без нареканий, продажник помечает запрос закрытым и данные из запроса переносятся в заказ клиента. Если нет - продажник отправляет запрос на доработку и цикл повторяется.

Уточнение закупочных цен

  1. Автор заказа клиента (продажник) на основании заказа формирует запрос на уточнение закупочных цен исполнителю (закупщику).
  2. При формировании запроса продажник должен указать список товаров для уточнения цен, приоритет по срокам, приоритет по качеству, возможность использования аналога.
  3. Закупщику автоматически формируется задача.
  4. Закупщик обрабатывает запрос: уточняет у поставщиков цену и срок поставки, и указывает их в запросе.
  5. Продажнику автоматически формируется задача на проверку.
  6. Продажник проверяет обработанный закупщиком запрос. Если у него имеются замечания, то он отправляет запрос на доработку с указанием замечаний и цикл повторяется. Если замечаний нет, то по уточненным закупочным ценам закупщик обновляет прайс-лист.

Требования

  1. Реализовать формирование задания (бизнес-процесс) по ЗСНН и ЗУЦ, и задачи закупщику (на выполнение) и продажнику (на проверку) на основе задания.
  2. У Продажника должна быть возможность отправить ЗСНН/ЗУЦ на доработку исполнителю с указанием комментария к доработке.
  3. У Продажника в табличной части ЗСНН/ЗУЦ должна быть колонка “Комментарий к доработке”. Построчные комментарии к доработке автоматически переносятся в комментарий к доработке в шапке документа с указанием тегов в начале и конце автоматической вставки.
  4. Если форма заказа клиента открыта и другой пользователь пытается из ЗСНН/ЗУЦ инициировать изменение заказа (обновление его комментария), то у него должно появляться предупреждение о том, что в заказе клиента работает другой пользователь (и указать какой) и изменения в заказе не должны быть выполнены.
  5. Исполнитель ЗСНН или ЗУЦ может быть не указан, тогда задача должна формироваться на роль исполнителей “Исполнитель уточнения цен”. Данная роль будет настроена следующим образом:
    Объект адресации - подразделение
    Исполнители роли - закупщики
  6. При отказе заполнения номенклатуры в ЗСНН обязательно заполнение комментария исполнителя.
  7. В заказе клиента должна быть команда “Догрузить созданную номенклатуру” , при которой в таблицу товаров автоматически будут добавляться товары, созданные или подобранные по запросу на создание новой номенклатуры. При повторном нажатии на кнопку добавленные ранее товары не дублируются, нажатие на кнопку добавляет в список товары, которых в нем еще нет.
  8. ЗСНН должен формироваться как на основании заказа клиента, так и простым созданием нового документа.
  9. ЗУЦ должен формироваться только на основании заказа клиента.
  10. В форме ЗУЦ при регистрации цен должен создаваться документ “Регистрация цен поставщика” для тех строк, в которых указана цена, включен НДС и поставщик. Ссылка на созданные документы должны отображаться в отдельной колонке “Регистратор цен”.
  11. В форме ЗУЦ должна быть возможность открыть “Прайс-лист” для тех строк, которые выделены в табличной части и в которых заполнен регистратор цены.
  12. При исполнении запроса на уточнение цен в поле “Менеджер по закупкам” должен подставляться фактический исполнитель запроса. Если было несколько исполнителей, то должен подставляться последний.
  13. У продажника должна быть возможность в отдельной форме перед формированием ЗУЦ выбрать определенные товары из заказа клиента для переноса в новый документ ЗУЦ. В этом окне вверху должны быть варианты массовой простановки флагов построчно для товаров: отсутствие цены, отсутствие необходимого количества на складе или по умолчанию (или отсутствие цены, или отсутствие на складе).
  14. В ЗУЦ должна быть возможность массово (для выделенных строк) установить/снять флаг «можно аналог», указать приоритеты по срокам, по качеству и комментарий.
  15. ЗУЦ должен содержать документ-основание (заказ клиента), автора (менеджер, который создал запрос), исполнителя (фактический менеджер по закупкам, который уточнил цены), склад заказа, подразделение заказа, статус документа, список номенклатуры с редактируемыми либо нередактируемыми колонками (т.е. часть колонок должна быть недоступна для редактирования Продажнику).
  16. Продажник не может изменять созданные документы ЗУЦ (даже если создал он), только просматривать. У него нет прав на регистрацию цен поставщиков, у закупщика это право есть.
  17. В ЗУЦ в случае, если не указан поставщик или цена, цена не может быть зарегистрирована и должно быть выдано соответствующее сообщение.
  18. Цены товаров, поставщик, “Включает НДС” должны браться из последней закупки.
  19. В ЗУЦ если поставщик поставил флаг “Включен НДС” или ячейка “Цена” не изменяется закупщиком в сравнении со значением, заполненным по умолчанию, то ячейка в соответствующей колонке должна подсвечиваться желтым. Если изменяется - то зеленым.

Над разработкой работали: аналитик, руководитель проекта, стажёр, старший инженер-программист.

Описание

Требуется перенести логистику в 1С (сейчас ведётся Excel), чтобы ускорить получение информации менеджерами по продажам о статусах товаров по ним.

  1. Отчет по заказам поставщикам, в который можно вносить комментарии о текущем статусе заказа. И чтобы потом эти комментарии сохранялись в самом заказе поставщику.
  2. В отчете, при отображении заказов и позиций, присутствуют следующие колонки:
    1. Наименование поставщика (только в строке заказа поставщика)
    2. Номер заказа (только в строке заказа поставщика)
    3. Страна (только в строке заказа поставщика)
    4. Номенклатура (только по позициям заказа поставщика)
    5. Цена (только по позициям заказа поставщика)
    6. Количество (только по позициям заказа поставщика)
    7. Сумма заказа (в позициях сумма по самим позициям, в заказе поставщика - общая сумма заказа)
    8. Валюта заказа (только в строке заказа поставщика)
    9. ETD – ориентировочная дата отгрузки которую дает поставщик при подтверждении заказа (в строке заказа поставщика отображается ближайшая дата из позиций заказа, отгруженные позиции не учитываются)
    10. Факт. дата отгрузки – фактическая дата отгрузки (в строке заказа поставщика отображается ближайшая дата из позиций заказа, отгруженные позиции не учитываются)
    11. ETA - ориентировочная дата поступления на склад
    12. Статус - статус позиций и статус заказа
    13. Вид транспорта – ЖД, авиа, море, авто (только по позициям заказа поставщика)
    14. Комментарий - указывается только по строке заказа в формате "Дата/Автор комментария/Комментарий"
    15. Ответственный продавец
  3. При установке галочки "Только заказы", колонки "Номенклатура", "Цена" и "Количество" не должны отображаться в отчёте.
  4. В отчете по каждому заказу должны отображаться статус позиций в заказе, статусы следующие.
    1. Размещено поставщику - заказ размещен поставщику (Документ заказ поставщику проведен)
    2. В производстве - заказ подтвержден поставщиком, выставлена проформа(PI) (статус меняется на "В производстве" при проведении проформы PI)
    3. Готово к отгрузке – наступила дата отгрузки, заказ готов к отгрузке. Статус меняется после наступления фактической даты отгрузки.
    4. Отгружено - сформирована заявка на перевозку (Документ "Заявка на перевозку" проведен)
  5. Также должны отображаться статусы заказов. В дополнение к перечисленным, требуется добавить еще три статуса.
    1. Частично готов к отгрузке - если в заказе есть позиции "В производстве" и "Готов к отгрузке"
    2. Частично отгружено - если в заказе есть позиции "Готов к отгрузке" и "Отгружено"
    3. Частично готов к отгрузке и частично отгружен - если в заказе есть позиции "В производстве", "Готов к отгрузке" и "Отгружено"
  6. Возможность разбиения строки в заказе поставщику в случае частичной отгрузки позиции (например, есть позиция в количестве 100 штук. Необходимо отгрузить 50. Нужно разбить строку на 2 позиции, чтобы можно было сформировать заявку на перевозку только по одной из них). .
  7. В отчете должна быть возможность ставить Факт. дата отгрузки на заказ и эта фактическая дата отгрузки должна транслироваться на каждую позицию в этом заказе (кроме позиций со статусом "Отгружено"). Даты должны автоматически изменяться в заказе поставщику.
  8. В отчете должна быть возможность изменять фактическую дату отгрузки по отдельной позиции (кроме позиций со статусом "Отгружено"). Дата должна автоматически изменяться в заказе поставщику.
  9. В отчете должна быть возможность ставить ETD и эта ETD должна транслироваться на каждую позицию в этом заказе.
  10. В отчете должна быть возможность изменять ETD по отдельной позиции. Дата должна автоматически изменяться в заказе поставщику.
  11. В отчете должна быть возможность задавать временной интервал.
  12. В отчете должны быть 2 уровня группировок.
    1. Когда отображаются только заказы без отображений позиций
    2. Когда отображаются и заказы и позиции
  13. В отчете должна быть возможность фильтров.
    1. По поставщику
    2. По статусу заказа
    3. По статусу позиции
    4. По виду транспорта
    5. Страна
  14. В отчете должна быть кнопка формирования заявки на перевозку, при нажатии на которую, по всем выделенным позициям со статусом "Готов к отгрузке" формируется заявка на перевозку. Позиции могут выделяться попозиционно так и групповым выделением.
  15. При формировании заявки, она должна открываться поверх окна отчета.
  16. В отчете должна быть кнопка изменения фактической даты отгрузки у всех выделенных строк, кроме строк со статусом "Отгружено"
  17. В отчете должна быть кнопка изменения ETA у всех выделенных строк
  18. В отчете должна быть возможность открыть заказ поставщику нажатием на номер заказа
  19. В отчете должна быть строка, в которую выводится комментарий из выделенной строки (для удобства чтения комментария)
  20. В отчете должна быть возможность добавить новый комментарий по заказу поставщика, путём изменения комментария в нужном заказе
  21. В заказе поставщику в колонке статус, должны отображаться статусы позиций
  22. В заказе поставщику добавить колонки:
    1. ETD
    2. Факт. дата отгрузки
    3. ETA
    4. Транспорт
  23. Создать в заказе поставщику вкладку "Логистика", в которой будет отображаться список комментариев по заказу в виде таблицы:
    1. Номер комментария.
    2. Комментарий.
    3. Автор комментария.
    4. Дата комментария.
  24. При открытии вкладки логистика должен выделяться последний комментарий.
  25. В проформе PI должны быть:
    1. Кнопка добавления документа, при нажатии на которую открывается проводник windows, где выбирается нужный файл
    2. Кнопка удаления загруженного документа
    3. Поле, в котором отображается путь к добавленному документу в виде ссылки. При нажатии на эту ссылку, документ должен открываться
  26. В документе "Заявка на перевозку" должны быть: кнопка добавления, кнопка удаления, и поле с ссылкой на выбранный файл по аналогии с проформой PI. Такой функционал должен быть для:
    1. Документа "Инвойс".
    2. Документа "Упаковочный лист".
    3. Документа "Коносамент".
  27. Должна быть возможность сохранить заявку в файле Excel (нажать кнопку "Печать" и выбрать "Печать Excel").

Над разработкой работали: аналитик, ведущий инженер-программист, младший инженер-программист.

Описание

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

Для этого требуется:

  1. Создать форму “Заказ покупателя” по аналогии со счётом:
    1. Строку с условиями размещения заказа:
      1. Строка должна выводиться в шапке ПФ и содержать следующий текст: “Условия размещения заказа действительны до [Дата актуальности] При неполучении поставщиком подписанного со стороны Покупателя данного заказа в течение вышеуказанного срока Поставщик имеет право не размещать данный заказ”, где [Дата актуальности] - дата, до которой актуален данный заказ.
    2. Строки, содержащую условия доставки (доставка или самовывоз):
      1. В первой строке находится следующий текст: “Условия доставки: [Способ доставки]”, где [Способ доставки] - один из двух способов доставки: “Самовывоз” или “До покупателя”;
      2. Во второй строке указывается следующий текст: “Адрес доставки: [АдресДоставки], где [АдресДоставки] - адрес, указанный в заказе.
    3. Добавить столбец “Срок поставки” в таблицу со списком товаров(работ, услуг):
      1. Данный столбец должен быть оформлен в том же стиле, что и остальные столбцы таблицы:
    4. В таблице “Этапы оплаты”, добавить между колонкой номера и колонкой %платежа колонку “Название этапа”:
    5. Сделать вывод таблицы “Этапы оплаты”, даже если в заказе всего 1 этап оплаты(в “Счет на оплату” выводится только при >1 строк);
    6. В подвале счета провести следующие изменения:
      1. Убрать строку с подписью бухгалтера;
      2. Строку с подписью руководителя изменить следующим образом:
        1. “Руководитель” заменить на “Продавец”;
        2. В строку должности продавца всегда выводить должность основного ответственного лица организации и его факсимиле.
      3. Добавить строку для подписи “Покупатель”;
      4. В каждой строке добавить место для отображения должности;
      5. Программно незаполненной должна быть только область подписи покупателя.
      6. Добавить строку о переходе права собственности со следующим текстом: “Право собственности на Товар...”
    7. В шапку ПФ вывести штрихкод заказа максимально возможного размера.
    8. В строке “ОбразецЗаполненияНазначениеПлатежа” изменить текст с “Оплата по заказу клиента” на “Оплата по заказу покупателя”
    9. Изменить область “Заголовок” следующим образом:
      1. Область должна содержать текст: “Заказ покупателя [НомерЗаказа] от [ДатаЗаказа], где [НомерЗаказа] - номер данного заказа, а [ДатаЗаказа] - дата создания данного заказа.
    10. Также добавить возможность выводить такую же ПФ без факсимиле (без заполнения колонки подписей).
      Примерный вид формы показан на рисунке:

Образец печатной формы в 1С

2. Ввести новое условие для размещения заказа: подкрепленный в базу подписанный заказ клиента. В том числе, контролировать наличие подкреплённого заказа клиента, когда выполняется согласование размещения без оплаты.

  1. В заказ клиента во вкладку “Дополнительно” добавить заполняемое поле “Подписанный файл клиента”;
  2. Не давать менеджеру “Подтвердить размещение и создать заказы поставщикам” или “Отправить на согласование на размещение без предоплаты”, если в поле “Подписанный файл клиента” отсутствует прикрепленный документ с подписанным заказом покупателя;
  3. Не давать менеджеру отправлять на согласование заказ если:
    1. Не заполнен адрес доставки;
    2. Не заполнены должность и ФИО у руководителя, у менеджера и у контактного лица(покупателя);
    3. ФИО менеджера, руководителя или контактного лица(покупателя) заполнено некорректно(указана только фамилия без имени).
  4. При согласовании заказа отправлять Директору по продажам письмо с адресом доставки (или адресом склада, с которого осуществляется самовывоз) и прикрепленным к письму “Заказом покупателя”. Примерный вид письма показан на рисунке:

Образец письма с прикреплёнными файлами из заказа клиента

3. При отправке производственного заказа отправлять также подписанный покупателем заказ клиента.

  • При нажатии кнопки “Подтвердить размещение и создать заказы поставщикам” или “Отправить на согласование на размещение без предоплаты” руководителю отдела закупок вместе с производственным заказом также должен отправляться подписанный заказ покупателя.

4. Создать рабочую инструкцию по использованию нового функционала.

Пара отзывов о нашей работе

Больше отзывов вы можете найти на следующих страницах сайта: главная, внедрение, сопровождение. Отзывам на сторонних ресурсах мы тоже уделяем внимание. В основном это Яндекс.Карты, так как они позволяют активно работать с обратной связью.

Мы заказывали небольшую доработку, оценённую в 16 часов разработки. Необходимо было при оформлении отгрузки товаров в килограммах, списывать фактическое количество метров с остатков.

Для разработки нам был выделен старший программист Максим, который за 2 дня завершил задачу. Работу с Трисофт могу рекомендовать, так как сроки и стоимость работ, согласованные “на берегу”, не отошли от заявленных.

GrigorievDI

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

В среду к нам добавили программиста. К пятнице всё было готово. Несомненно довольны работой сотрудников и Михаила, в частности.

Демчева Л.В.

Демчева Л.В.

Директор