объединение в единую базу конфигураций КА+УАТ
Добрый день.
Имеется заказчик с собственный крупным автопарком которому нужна комплексная автоматизация - управленческий учет, регламентированный учет, производство и т.п.
В качестве основной выбрана локализованная конфигурация КА. Вся отраслевая специфика деятельности предприятие заказчика хорошо покрывается возможностями отраслевой конфигурации "Управление автотранспортом Стандарт" (далее УАТ).
Ломаю голову надо глобальным вопросом. С одной стороны, очень хочется объединить эти две конфигурации в единую базу. Плюсов объединения очень много. Минус один - огромная трудоёмкость. Дело в том, что УАТ разрабатывалась как отдельное решение с дальнейшей выгрузкой данных в конфигурацию Бухгалтерия для отражения в регл. учете. Но возможности УАТ по упр. учету и вообще как средство управления бизнесом просто ничтожны по сравнению с ERP или КА. Поэтому клиенту нужна и КА (которая содержит в себе и регл.учет и ЗУП и многое другое) и УАТ, которая содержит отраслевую специфику - ГСМ, запчасти, шины, пробеги, путевые листы.
Специфика работы заказчика в том, что он производит работы/продукцию (в терминах КА), которые доставляются клиенту силами собственного и наёмного автотранспорта. Поэтому от клиента сразу принимается документ "Заказ покупателя" (КА) и "Заказ на ТС" (УАТ) (указывается только вид транспорта, но не конкретное ТС). Дальше происходит отгрузка части работ/продукции. При этом диспетчер подбирает по заданному виду ТС конкретный автомобиль и производит отгрузку. И тут возникают документ "Реализация товаров и услуг" (КА) и "Путевой лист" (УАТ).
По возвращению на базу по путевому листу списывается ГСМ и начисляется ЗП водителя (это если кратко).
Как видите без полной интеграции работа через обмены будет очень неудобной. Тем более что сейчас клиент работает в самописной базе 1С77, в которой вся описанная специфика реализована в одной базе. Пусть примитивно, но в одной базе, без обменов.
Вопрос к тем, кто хорошо знает УАТ и кто возможно сталкивался с подобной задачей. Какие есть подводные камни? На сколько трудоёмко в человека-часах хотя бы приблизительно. Есть ли другие способы достижения поставленных задач?
Основная сложность еще в том, что в УАТ есть документы, регистры, справочники которые так же есть и в КА, но в КА они гораздо более глубоко проработаны. И в этой ситуации придется отказываться от дублирующих документа УАТ в пользу аналогичных документов КА.
Имеется заказчик с собственный крупным автопарком которому нужна комплексная автоматизация - управленческий учет, регламентированный учет, производство и т.п.
В качестве основной выбрана локализованная конфигурация КА. Вся отраслевая специфика деятельности предприятие заказчика хорошо покрывается возможностями отраслевой конфигурации "Управление автотранспортом Стандарт" (далее УАТ).
Ломаю голову надо глобальным вопросом. С одной стороны, очень хочется объединить эти две конфигурации в единую базу. Плюсов объединения очень много. Минус один - огромная трудоёмкость. Дело в том, что УАТ разрабатывалась как отдельное решение с дальнейшей выгрузкой данных в конфигурацию Бухгалтерия для отражения в регл. учете. Но возможности УАТ по упр. учету и вообще как средство управления бизнесом просто ничтожны по сравнению с ERP или КА. Поэтому клиенту нужна и КА (которая содержит в себе и регл.учет и ЗУП и многое другое) и УАТ, которая содержит отраслевую специфику - ГСМ, запчасти, шины, пробеги, путевые листы.
Специфика работы заказчика в том, что он производит работы/продукцию (в терминах КА), которые доставляются клиенту силами собственного и наёмного автотранспорта. Поэтому от клиента сразу принимается документ "Заказ покупателя" (КА) и "Заказ на ТС" (УАТ) (указывается только вид транспорта, но не конкретное ТС). Дальше происходит отгрузка части работ/продукции. При этом диспетчер подбирает по заданному виду ТС конкретный автомобиль и производит отгрузку. И тут возникают документ "Реализация товаров и услуг" (КА) и "Путевой лист" (УАТ).
По возвращению на базу по путевому листу списывается ГСМ и начисляется ЗП водителя (это если кратко).
Как видите без полной интеграции работа через обмены будет очень неудобной. Тем более что сейчас клиент работает в самописной базе 1С77, в которой вся описанная специфика реализована в одной базе. Пусть примитивно, но в одной базе, без обменов.
Вопрос к тем, кто хорошо знает УАТ и кто возможно сталкивался с подобной задачей. Какие есть подводные камни? На сколько трудоёмко в человека-часах хотя бы приблизительно. Есть ли другие способы достижения поставленных задач?
Основная сложность еще в том, что в УАТ есть документы, регистры, справочники которые так же есть и в КА, но в КА они гораздо более глубоко проработаны. И в этой ситуации придется отказываться от дублирующих документа УАТ в пользу аналогичных документов КА.
По теме из базы знаний
Ответы
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Я бы пошел бы несколько по другому пути, вернее не так, а сделал бы объединение КА 2.4 и УАТ, а данные по регламентированному учету выгружал бы в БП 3.0 и ЗУП.3.1.
Затраты на поддержку КА + УАТ были бы минимизированы.
Вопрос к тем, кто хорошо знает УАТ и кто возможно сталкивался с подобной задачей. Какие есть подводные камни? На сколько трудоёмко в человека-часах хотя бы приблизительно. Есть ли другие способы достижения поставленных задач?
Я бы пошел бы несколько по другому пути, вернее не так, а сделал бы объединение КА 2.4 и УАТ, а данные по регламентированному учету выгружал бы в БП 3.0 и ЗУП.3.1.
Затраты на поддержку КА + УАТ были бы минимизированы.
(2) а какой смысл пользователей заставлять всё время переключаться между двумя базами? Лучше уж один раз вложиться в объединение и всю оставшуюся жизнь получать удовольствием.
Что значит "непонятно как поддерживать"? Так же как и доработанные КА и УАТ снятые с поддержки люди поддерживают - руками. Дело в том, что версии локализованных типовых еще не известно как часто будут выходить. КА последний раз в конце июля была. Т.е. хорошо если 2-3 раза в год хотя бы.
Просто критически важные документы - заявка на ТС и отгрузка. Получается чтобы принять заказ от покупателя нужно сначала в КА создать "Заказ покупателя", после чего в УАТ создать заявку на ТС, а затем их связать логически еще где-то. Тоже самое с отгрузкой: в КА диспетчер делает отгрузку, а затем идёт в УАТ привязывать конкретное ТС с водителем к отгрузке. А логически связывать их между собой где?
Что значит "непонятно как поддерживать"? Так же как и доработанные КА и УАТ снятые с поддержки люди поддерживают - руками. Дело в том, что версии локализованных типовых еще не известно как часто будут выходить. КА последний раз в конце июля была. Т.е. хорошо если 2-3 раза в год хотя бы.
Просто критически важные документы - заявка на ТС и отгрузка. Получается чтобы принять заказ от покупателя нужно сначала в КА создать "Заказ покупателя", после чего в УАТ создать заявку на ТС, а затем их связать логически еще где-то. Тоже самое с отгрузкой: в КА диспетчер делает отгрузку, а затем идёт в УАТ привязывать конкретное ТС с водителем к отгрузке. А логически связывать их между собой где?
(7) примерно по этому пути и идем
в ERP (по сравнению с КА) есть 2 модуля которые вероятнее всего не понадобятся - МСФО и диспетчеризация производства
Если я не прав - поправьте меня пожалуйста.
Плюс ERP существенно дороже по лицензиям, а КА им как раз то, что нужно - и регл. учет и упр.
в ERP (по сравнению с КА) есть 2 модуля которые вероятнее всего не понадобятся - МСФО и диспетчеризация производства
Если я не прав - поправьте меня пожалуйста.
Плюс ERP существенно дороже по лицензиям, а КА им как раз то, что нужно - и регл. учет и упр.
(10)Да, дороже.
Цитата из статьи с кодерлайнов:
В комплексной автоматизации не будет: блока МСФО (Международная Стандартная Финансовая Отчетность), блока производства, а именно:
• отсутствует планирование производства
• отсутствуют заказы на производство
• нет возможности распределять затраты на выпуск по заказам на производство
Ну и по модулю УАТ, он заявлен для ЕРП только, но различий между ЕРП и КА2 минимальны, при наличии модуля в теории можно срастить (глобальных проблем не предвижу).
Цитата из статьи с кодерлайнов:
В комплексной автоматизации не будет: блока МСФО (Международная Стандартная Финансовая Отчетность), блока производства, а именно:
• отсутствует планирование производства
• отсутствуют заказы на производство
• нет возможности распределять затраты на выпуск по заказам на производство
Ну и по модулю УАТ, он заявлен для ЕРП только, но различий между ЕРП и КА2 минимальны, при наличии модуля в теории можно срастить (глобальных проблем не предвижу).
Я бы сделал отдельно БУХ, отдельно транспорт и отдельно торговлю.
КА это проблема навсегда, вкорячить в нее еще транспорт это очень большая (я бы сказал немереная совершенно) проблема навсегда. Представляю ежемесячные обновления этой штуки, ух красота.
Обмен это проблема на неделю, настроить, правила прописать, выгрузку-загрузку можно онлайн сделать, и дальше только с обновлениями БУХ раз в полгода что-то поправить.
Все заказы записывать только в одну базу (где работает манагер, который их получает от клиентов), дальше онлайн выгрузить во вторую. В начале месяца выгружать в БП. В УТ или УАТ (смотря куда будет записываться исходная информация) добавить реквизит для связи документов двух баз.
Но! Если клиент хочет заплатить, а исполнитель хочет заработать, то объединение баз в одну это отличный путь для расходования бюджетов на автоматизацию. Это не один месяц напряженного труда и потом постоянная поддержка этого нетленного монстра.
КА это проблема навсегда, вкорячить в нее еще транспорт это очень большая (я бы сказал немереная совершенно) проблема навсегда. Представляю ежемесячные обновления этой штуки, ух красота.
Обмен это проблема на неделю, настроить, правила прописать, выгрузку-загрузку можно онлайн сделать, и дальше только с обновлениями БУХ раз в полгода что-то поправить.
Все заказы записывать только в одну базу (где работает манагер, который их получает от клиентов), дальше онлайн выгрузить во вторую. В начале месяца выгружать в БП. В УТ или УАТ (смотря куда будет записываться исходная информация) добавить реквизит для связи документов двух баз.
Но! Если клиент хочет заплатить, а исполнитель хочет заработать, то объединение баз в одну это отличный путь для расходования бюджетов на автоматизацию. Это не один месяц напряженного труда и потом постоянная поддержка этого нетленного монстра.
(4) а зачем ежемесячные обновления?? У нас локализованная версия КА - последнее обновление типовой было в июле и еще неизвестно сколько ждать следующего.
А зачем гонять туда-сюда по базам документы если можно просто отметить какие из документов должны быть отражены в регл. учете, а какие нет и всё? Прятать базу от проверяющих? Так прятать нужно любую от всех)
Обмены - это всегда есть вероятность коллизий. Это нужно полностью разграничивать справочники - в какой базе в какой справочник можно добавлять элементы, а в какой нет. Иначе разбираться постоянно с дублями.
И т.д. и т.п. Проблемы распределенок знаю не понаслышке. Считаю что если нет обоснованных противопоказаний, то должна быть единая база.
А зачем гонять туда-сюда по базам документы если можно просто отметить какие из документов должны быть отражены в регл. учете, а какие нет и всё? Прятать базу от проверяющих? Так прятать нужно любую от всех)
Обмены - это всегда есть вероятность коллизий. Это нужно полностью разграничивать справочники - в какой базе в какой справочник можно добавлять элементы, а в какой нет. Иначе разбираться постоянно с дублями.
И т.д. и т.п. Проблемы распределенок знаю не понаслышке. Считаю что если нет обоснованных противопоказаний, то должна быть единая база.
(14) если ее нет ,то это самопальная нетленка, для бухучета это локальная катастрофа для заказчика. Если ему пришла светлая идея так сделать и удалось найти исполнителя, который согласился - ну можно только посочувствовать. Это постоянные немалые расходы, постоянный риск попадалова на проблемы с налоговой и постоянная зависимость от разработчика нетленки и в конце катастрофа, когда этот разработчик в начале февраля скажет - до свидания, мой ласковый мишка, я нашел того, кто заплатит мне больше.
Имхо, объединение конфигураций зависит от того, какие данные и где находятся. Задача ведения учета в независимой базе уат выполнима с большей вероятностью, чем в единой базе.
Обслуживание обмена программистом может вообще не понадобится.
Обслуживание обмена программистом может вообще не понадобится.
(5) ну вот - можно заценить)
1. Прием заявки покупателя.
Клиент заказывает производство и доставку продукции по адресу доставки. Может заказать сразу несколько машин которые должны приезжать с интервалом и подвозить продукцию постепенно. Заказывает тип ТС.
2. Отгрузка.
Доставка выполняется как силами собственного автопарка, так и силами привлеченных перевозчиков.
Диспетчер привязывает конкретные заказы покупателей, которые нужно выполнить в данный момент по времени доставки к свободным ТС заданного в заказе вида ТС. Диспетчер печатает пакет документов, отдает водителю, ТС идет на погрузку.
3. Непосредственно перед загрузкой выполняется производство продукции и её загрузка в назначенное ТС.
Производство простое одно-передельное позаказное.
4. Оплата заказ клиентом на месте при доставке.
При доставке продукции водитель может принимать деньги от покупателей в качестве оплаты за заказ и сдает в кассу диспетчера (в подотчет с дальнейшим перемещением между кассами/подотчетниками).
5. Учет заправка на собственной АЗС.
Загрузка топлива на АЗС. Учет заправок собственных ТС и ТС перевозчиков. Взаиморасчеты с перевозчиками по ГСМ, по выполненным работам, по различным начислениям и удержаниям (штрафы, доп. работы и т.п.).
6. Ремонт ТС на собственном СТО.
Оприходование, списание запчастей, установленных шин, агрегатов, учет выполненных работ.
7. Учет выработки водителей – начисления сдельной и повременной ЗП, сверхурочные, доп. начисления и т.п.
8. Полноценный управленческий, регламентированный учет всех аспектов деятельности предприятия.
9. Полноценный кадровый учет. Начисление ЗП – регламентированное и управленческое.
Это где-то 70% самого востребованного функционала. Есть еще много чего по мелочи, но с нюансами. Если основные требования архитектура будет покрывать, то её примут.
1. Прием заявки покупателя.
Клиент заказывает производство и доставку продукции по адресу доставки. Может заказать сразу несколько машин которые должны приезжать с интервалом и подвозить продукцию постепенно. Заказывает тип ТС.
2. Отгрузка.
Доставка выполняется как силами собственного автопарка, так и силами привлеченных перевозчиков.
Диспетчер привязывает конкретные заказы покупателей, которые нужно выполнить в данный момент по времени доставки к свободным ТС заданного в заказе вида ТС. Диспетчер печатает пакет документов, отдает водителю, ТС идет на погрузку.
3. Непосредственно перед загрузкой выполняется производство продукции и её загрузка в назначенное ТС.
Производство простое одно-передельное позаказное.
4. Оплата заказ клиентом на месте при доставке.
При доставке продукции водитель может принимать деньги от покупателей в качестве оплаты за заказ и сдает в кассу диспетчера (в подотчет с дальнейшим перемещением между кассами/подотчетниками).
5. Учет заправка на собственной АЗС.
Загрузка топлива на АЗС. Учет заправок собственных ТС и ТС перевозчиков. Взаиморасчеты с перевозчиками по ГСМ, по выполненным работам, по различным начислениям и удержаниям (штрафы, доп. работы и т.п.).
6. Ремонт ТС на собственном СТО.
Оприходование, списание запчастей, установленных шин, агрегатов, учет выполненных работ.
7. Учет выработки водителей – начисления сдельной и повременной ЗП, сверхурочные, доп. начисления и т.п.
8. Полноценный управленческий, регламентированный учет всех аспектов деятельности предприятия.
9. Полноценный кадровый учет. Начисление ЗП – регламентированное и управленческое.
Это где-то 70% самого востребованного функционала. Есть еще много чего по мелочи, но с нюансами. Если основные требования архитектура будет покрывать, то её примут.
однозначно не объединение
------------------------------
еще может быть фокус , что понадобятся функции,
которые в старшей версии УАТ
-----------------------
другой вопрос в том, что нужнее :
управленческий учет, регламентированный учет, производство и т.п.
---------------------------
можете уточнить конкретные требования заказчика и поинтересоваться у соответствующего франча - покрывает ли УАТ эти требования
и только тогда решать - а так - никто не знает,
что нужно заказчику ( кроме него и вас)
----------------------------------
надеюсь вы уже посмотрели, как ведется учет в семерке
и какие подводники уже есть там ( кто главный, кто как хочет - так и воротит )
я бы с этого начал и возможно закончил,
потому что сладкий пирог может оказаться совсем не таким....
------------------------------
еще может быть фокус , что понадобятся функции,
которые в старшей версии УАТ
-----------------------
другой вопрос в том, что нужнее :
управленческий учет, регламентированный учет, производство и т.п.
---------------------------
можете уточнить конкретные требования заказчика и поинтересоваться у соответствующего франча - покрывает ли УАТ эти требования
и только тогда решать - а так - никто не знает,
что нужно заказчику ( кроме него и вас)
----------------------------------
надеюсь вы уже посмотрели, как ведется учет в семерке
и какие подводники уже есть там ( кто главный, кто как хочет - так и воротит )
я бы с этого начал и возможно закончил,
потому что сладкий пирог может оказаться совсем не таким....
там есть вопросы и ответы
------------------------
если вы с заказчиком говорите на одном языке
т.е. - НЕ на в общих фразах - автоматизация, управление, что-бы работала
то лучше конкретно посмотреть в старую базу , по ней задавать вопросы
и только тогда искать, возможно и две ( максимум ) устанавливать, но не франкенштейна......и вы не огласили список количества пользователей, айфоны и т.д
-----------
сегодня захотят одно,
а завтра - всем на смартфоны давай задачи
и контроль вплоть до пути домой.
(15)
Хотелось бы услышать более конкретные обоснования разделения/объединения баз по озвученным требованиям.
По озвученным требованиям на ум приходит разве что вот это произведение:
Если взрослого мыша
взять, и бережно держа,
напихать в него иголок, -
Вы получите ежа.
Если этого ежа,
нос заткнув, чтоб не дышал,
Где поглубже, сбросить в речку –
Вы получите ерша.
Если этого ерша,
головой в тисках зажав,
посильней тянуть за хвост, то –
Вы получите ужа.
Это неполная цитата, конечный результат данного эксперимента интересующимся предлагаю найти самостоятельно. :)
взять, и бережно держа,
напихать в него иголок, -
Вы получите ежа.
Если этого ежа,
нос заткнув, чтоб не дышал,
Где поглубже, сбросить в речку –
Вы получите ерша.
Если этого ерша,
головой в тисках зажав,
посильней тянуть за хвост, то –
Вы получите ужа.
Не так давно пришлось решать очень похожую задачу у одного клиента.
Напишу как было дело.
Клиент когда-то и как-то приобрел "КА-2" и "УАТ Стандарт". Заказал их подружить.
Долго думали и провели несколько экспериментов и такие выводы получились:
1. Слить в одну конфигурацию - не дело. Словарь идентификаторов и структура объектов метаданных у УАТ старый, приближен к программам УТ-10, КА-1, УПП и БП 2.0-3.0, но не к КА-2/ERP.
2. Есть в УАТ обмен c КА/ERP через EnterpriseData. Но работает он безобразно. Лучше бы его совсем не было.
Сливать деревья и делать "франкенштейна", нам показалось, не вариант по первой причине.
Допиливать встроенный обмен через EnterpriseData нам показалось на столько трудоёмко, что не уложиться в бюджет и сроки.
Предложили клиенту "1С:Управление автотранспортом. Модуль для 1С:ERP", цена 92000,00 руб. (артикул 4601546121936 в прайсе 1С), он закапризничал, де деньги уже потрачены.
Поскольку у нас в команде есть чел, кто в "Конвертации-2", как рыба в воде, то написали классический двусторонний обмен по правилам.
Не без проблем, конечно, но запустили, обкатали с помощью такой-то матери. Красота. Все довольны. 5-й месяц полёт нормальный.
В результате - набор правил и 2 расширеньица для транспорта данных (одно для КА-2, второе для УАТ). Как тиражный продукт предлагать это чудо пока не представляю, т.к. из КА в УАТ более менее понятно и почти у всех одинаково. А вот из УАТ в КА - этот учет у все по-разному ведется: сводно, подробно, с 23-м, без 23-го, ТС->АналитикаЗатрат, ТС->Подразделение и т.д. Вариантов масса. У нас пока реализован только один из множества имеющих право на существование вариантов.
Напишу как было дело.
Клиент когда-то и как-то приобрел "КА-2" и "УАТ Стандарт". Заказал их подружить.
Долго думали и провели несколько экспериментов и такие выводы получились:
1. Слить в одну конфигурацию - не дело. Словарь идентификаторов и структура объектов метаданных у УАТ старый, приближен к программам УТ-10, КА-1, УПП и БП 2.0-3.0, но не к КА-2/ERP.
2. Есть в УАТ обмен c КА/ERP через EnterpriseData. Но работает он безобразно. Лучше бы его совсем не было.
Сливать деревья и делать "франкенштейна", нам показалось, не вариант по первой причине.
Допиливать встроенный обмен через EnterpriseData нам показалось на столько трудоёмко, что не уложиться в бюджет и сроки.
Предложили клиенту "1С:Управление автотранспортом. Модуль для 1С:ERP", цена 92000,00 руб. (артикул 4601546121936 в прайсе 1С), он закапризничал, де деньги уже потрачены.
Поскольку у нас в команде есть чел, кто в "Конвертации-2", как рыба в воде, то написали классический двусторонний обмен по правилам.
Не без проблем, конечно, но запустили, обкатали с помощью такой-то матери. Красота. Все довольны. 5-й месяц полёт нормальный.
В результате - набор правил и 2 расширеньица для транспорта данных (одно для КА-2, второе для УАТ). Как тиражный продукт предлагать это чудо пока не представляю, т.к. из КА в УАТ более менее понятно и почти у всех одинаково. А вот из УАТ в КА - этот учет у все по-разному ведется: сводно, подробно, с 23-м, без 23-го, ТС->АналитикаЗатрат, ТС->Подразделение и т.д. Вариантов масса. У нас пока реализован только один из множества имеющих право на существование вариантов.
(19) спасибо, очень полезная информация
вот думаю - может взять локализованную ERP и этом модуль УАТ для неё. Общался с представителями Раруса у нас тут, которые локализовывали УАТ. Так они как-то расплывчато сказали что с этим модулем "не все так гладкой и просто".
А в вашем варианте как выглядел бизнес-процесс клиента в двух словах? Потому что у моих основной камень преткновения это как раз принятие заказа покупателя и последующая отгрузка с назначением автомобиля в АРМ Диспетчера.
Получается что пользователь должен:
1) в КА создать отгрузку и напечатать РН
2) перейти в другую базу УАТ и, закрепив автомобиль распечатать ТТН.
Это, мягко говоря, не очень удобно. Не думаю что клиент, который привык в 1С7 работать в одной базе согласится на такое.
вот думаю - может взять локализованную ERP и этом модуль УАТ для неё. Общался с представителями Раруса у нас тут, которые локализовывали УАТ. Так они как-то расплывчато сказали что с этим модулем "не все так гладкой и просто".
А в вашем варианте как выглядел бизнес-процесс клиента в двух словах? Потому что у моих основной камень преткновения это как раз принятие заказа покупателя и последующая отгрузка с назначением автомобиля в АРМ Диспетчера.
Получается что пользователь должен:
1) в КА создать отгрузку и напечатать РН
2) перейти в другую базу УАТ и, закрепив автомобиль распечатать ТТН.
Это, мягко говоря, не очень удобно. Не думаю что клиент, который привык в 1С7 работать в одной базе согласится на такое.
(21)
В нашем случае было несколько проще.
Свою продукцию отправляют только наёмным транспортом. Весь свой транспорт только доставляет сырьё (регулярные рейсы 5 грузовиков расписаны на месяц вперед, возят одно и то же), занят в технологии (кары, тракторы) и легковых несколько на побегушках.
В Вашем случае (если я правильно понял) нужно как-то в онлайн-режиме КА-шный "Заказ клиента" с видом доставки "Наша транспортная служба до клиента" при проведении конвертить в УАТ в документ "Заказ на ТС". Можно сделать классический транспорт обменных сообщений между КА и УАТ по расписанию с маленьким интервалом. Можно сделать что-то в онлайне через КОМ при проведении или почти в онлайне -- с очередью...
А на стороне УАТ есть функционал, который позволяет делать разнарядку по заказам на ТС.
Можно и обратную сторону обмена сделать из УАТ в КА, чтоб обозначить, что на КА-шныйй "Заказ клиента" ТС закреплено и менять заказ уже некошерно..
Подход можно распространить в общем случае и на "Заказ поставщику" и на "Внутренний заказ" - это всё тоже может ездить своим транспортом...
Сложного в общем-то ничего нет. Простая, конкретная и понятная работа, но довольно муторная и объёмненькая.
В нашем случае было несколько проще.
Свою продукцию отправляют только наёмным транспортом. Весь свой транспорт только доставляет сырьё (регулярные рейсы 5 грузовиков расписаны на месяц вперед, возят одно и то же), занят в технологии (кары, тракторы) и легковых несколько на побегушках.
В Вашем случае (если я правильно понял) нужно как-то в онлайн-режиме КА-шный "Заказ клиента" с видом доставки "Наша транспортная служба до клиента" при проведении конвертить в УАТ в документ "Заказ на ТС". Можно сделать классический транспорт обменных сообщений между КА и УАТ по расписанию с маленьким интервалом. Можно сделать что-то в онлайне через КОМ при проведении или почти в онлайне -- с очередью...
А на стороне УАТ есть функционал, который позволяет делать разнарядку по заказам на ТС.
Можно и обратную сторону обмена сделать из УАТ в КА, чтоб обозначить, что на КА-шныйй "Заказ клиента" ТС закреплено и менять заказ уже некошерно..
Подход можно распространить в общем случае и на "Заказ поставщику" и на "Внутренний заказ" - это всё тоже может ездить своим транспортом...
Сложного в общем-то ничего нет. Простая, конкретная и понятная работа, но довольно муторная и объёмненькая.
(22) В целом да, всё верно описали.
С документом "Заказ ТС" относительно просто - он регистратор регистра сведений "Заказы транспорта" (точное название немного другое, но не важно) - то есть к заказу покупателя прикручиваем движения по этому РС и с заказом вопрос закрыт.
А вот с отгрузкой всё гораздо сложнее. Нужно через АРМ диспетчера по виду требуемого ТС назначить ТС на конкретный заказ. По итогу назначения создаётся путевой лист, который и фиксирует что ТС занято. То есть нужно переносить и путевой лист со всеми движениям и АРМ диспетчера. А если всё это перенести. то что там уже остаётся?
Пока смотрим в сторону локализации модуля и интеграции его с локализованной ERP. Разработчик рассказывает что это очень трудоёмко и дорого, но по-моему "лучше ужасный конец, чем ужас без конца")
С документом "Заказ ТС" относительно просто - он регистратор регистра сведений "Заказы транспорта" (точное название немного другое, но не важно) - то есть к заказу покупателя прикручиваем движения по этому РС и с заказом вопрос закрыт.
А вот с отгрузкой всё гораздо сложнее. Нужно через АРМ диспетчера по виду требуемого ТС назначить ТС на конкретный заказ. По итогу назначения создаётся путевой лист, который и фиксирует что ТС занято. То есть нужно переносить и путевой лист со всеми движениям и АРМ диспетчера. А если всё это перенести. то что там уже остаётся?
Пока смотрим в сторону локализации модуля и интеграции его с локализованной ERP. Разработчик рассказывает что это очень трудоёмко и дорого, но по-моему "лучше ужасный конец, чем ужас без конца")
Оказалось что в ERP есть неплохой блок доставки, который нам почти полностью подходит. В связи с этим было принято решение - всё в ERP, транспорт начиная с заявки на ТС или путевого листа, а так же все затраты по автопарку и расчет ЗП водителей - в отдельной базе УАТ. Обе конфигурации локализованные, так что с этим проблем быть не должно.
В связи с этим вопрос к тем, кто настраивал обмены с помощью Конвертации 2.0 - сколько примерно человеко-часов потянет реализация вот таких требований? И какие там есть подводные камни.
Файл во вложении (укрупнённое описание).
Общая схема такая:
1. Доставка - вплоть до выполненного документа "Задание на перевозку" - в ERP
2. Выполненная доставка загружается в УАТ как документ "Путевой лист".
3. Закупка и перемещение запчастей, материалов, ГСМ и агрегатов - в ERP с выгрузкой в УАТ.
4. Ремонты, заправки, списания и прочие затраты - в УАТ с миграцией в ERP
5. ЗП сдельные, табеля водителей и расчет ЗП - в УАТ с последующей миграцией начисленной ЗП для отражения в затратах в ERP
В связи с этим вопрос к тем, кто настраивал обмены с помощью Конвертации 2.0 - сколько примерно человеко-часов потянет реализация вот таких требований? И какие там есть подводные камни.
Файл во вложении (укрупнённое описание).
Общая схема такая:
1. Доставка - вплоть до выполненного документа "Задание на перевозку" - в ERP
2. Выполненная доставка загружается в УАТ как документ "Путевой лист".
3. Закупка и перемещение запчастей, материалов, ГСМ и агрегатов - в ERP с выгрузкой в УАТ.
4. Ремонты, заправки, списания и прочие затраты - в УАТ с миграцией в ERP
5. ЗП сдельные, табеля водителей и расчет ЗП - в УАТ с последующей миграцией начисленной ЗП для отражения в затратах в ERP
Прикрепленные файлы:
Правила обменов ERP - УАТ.docx
(26)
Не глядя на структуру данных, оценить трудозатраты очень сложно. Можно только предположить, плюс заложить 75% процентов времени про запас, на непредвиденные работы.
кто настраивал обмены с помощью Конвертации 2.0 - сколько примерно человеко-часов потянет реализация вот таких требований? И какие там есть подводные камни.
Не глядя на структуру данных, оценить трудозатраты очень сложно. Можно только предположить, плюс заложить 75% процентов времени про запас, на непредвиденные работы.
(30)
Ну если эти базы у вас в наличии, можно и проанализировать и выдать примерную раскладку, е если их нет, то можно только предполагать.
А что и для кого тут может быть непредвиденно? Обе конфы совершенно конкретные и предвиденные. КД-2 тоже старая и понятная программа, к тому же прекрасно документирована.
Ну если эти базы у вас в наличии, можно и проанализировать и выдать примерную раскладку, е если их нет, то можно только предполагать.
(26)
(26) Отличная задача.
40 часов на правила обмена формата КД-2.
16 часов на транспорт (его нет ни в УАТ, ни в ERP, нет старых добрых планов обмена с загрузкой файлов правил, есть только Enterprise Data, но здесь она негодная).
В связи с этим вопрос к тем, кто настраивал обмены с помощью Конвертации 2.0 - сколько примерно человеко-часов потянет реализация вот таких требований? И какие там есть подводные камни.
(26) Отличная задача.
40 часов на правила обмена формата КД-2.
16 часов на транспорт (его нет ни в УАТ, ни в ERP, нет старых добрых планов обмена с загрузкой файлов правил, есть только Enterprise Data, но здесь она негодная).
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот