Доброго дня!

Есть задумка реализовать в БП3 КОРП функционал заказов клиента, аналогично заказам клиента в УТ11.4.
Есть ли у кого практический опыт подобного и на сколько это решаемо?

Цель данной задумки уйти от использования УТ и оставить только конфу БП.
Сейчас используем две конфы: УТ и БП с обменом в обе стороны (Проплаты приходят в БП)

(0) какой функционал ты хочешь от "заказов" в БП?

(0) Херовая, на мой взгляд, задумка.

(0) решаемо, на базе БП 3.0 до фига отраслевых решений, построенных аналогично

Расширение. Т.е. как бы отраслевая подсистема построенная в расширении.

Относительно конкретного предложения, что это Заказы клиента : поскольку в типовой БП этого нет, то не будет проблем с пересечением существующего в типовой с дополняемой функциональностью (( или расширяемой :-) ))

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

А вот какие именно - списывать их по образу и подобию из существующих в УТ или придумавать свои, заимствовав только саму идею Заказ - смотрите по себе.

Я понимаю, когда есть только БП и нет желания вести учет в УТ. Но когда есть работающая связка УТ - БП, я честно не понимаю смысла отказа от нее и приделывание своих костылей в БП аналогичных типовым механизмам в УТ.

(5) любой обмен зло
одна система всегда надежнее двух

(5) Причина проста в УТ по большому счету не дублируются только заказы клиентов. все остальное дублируется в БП. (в нашем случае это склад и снабжение). а еще УТ переписали для разного рода схем учета производства (давальческое сырье, давальческая переработка на стороне, возвраты с ответхранением и т.п.) что обменом летает туда-сюда и только портит данные. Но самое главное приходится ждать когда доки пройдут по обмену. Не говорю уже про заведение НСИ. Одни только контрагенты с договорами, типовыми и индивидуальными соглашениями (а их в БП нет) и расчетными счетами дают гору гемора так как заводятся в разных местах.
Нужно единое информационное пространство, но разделенное на сегменты (модули) для каждого подразделения свое. Вот и выдвинули идею проработать создание подсистемы заказов клиента в БП, но с возможностями как в УТ, а там взаиморасчеты за собой столько всего тянут...

(6) любой обмен - ЗЛО!!!
Поддерживаю всем чем можно.

(6) Если обмен простой, прозрачный и однонаправленный - не зло. Скажем, обмен ЗУП с БП вполне годный.

Зло, когда кривой обмен. Где голосовалка?  )

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

(7) Ну если по существу темы что-то дальше обсуждать, то нужны новые уточняющие вопросы, т.к. по общей формулировке все уже высказано.

(11) Спорный вопрос. Что мешает реализовать оперативный учет средствами бухгалтерского? У них просто разные цели.

(7) у тебя непонимание налицо

(7) В БП по сути должно выгружаться только чтобы в фискальные органы отчитаться, как правильно написали в (11) - учет "посмертный". А в УТ отражается настоящая деятельность организации. А (6) не слушай - он адепт ЕРП, где все в одном. :)

(7) ну прорабатывай

(15) одна система надежнее 2х,3х и т.д.

(15) В подавляющем большинстве случаев без УТ спокойно можно обойтись легкой доработкой БП. И не нужны тогда никакие обмены. Пару регистров и документов в расширении, пара обработок - и всё.

(0) у самих так. Всё нормально.

(17) Скажем так, каждая система из связки 2х,3х надежнее чем вся связка. Но на счет того, что вести учет в условной КА или ЕРП надежнее чем в связке УТ-БП - вот вообще не очевидно. Особенно когда надо оперативно обновлять блок БП и контролировать чтобы менеджеры не влияли своими шаловливыми руками на данные сданных периодов.
(18) Он то хочет функционал заказов как в УТ.

(18) Я свой учет вел в БП, мне функционала хватало. Но я хотя бы знаю как чего посмотреть, ибо знаю бух.учет и план счетов. А вот как он будет заставлять манагеров смотреть нужные отчетики по данным ОСВ и Анализа счетов? манагеры вообще в курсе с чем им придется столкнуться или (0) все нужные отчеты на плане счетов напишет?

(21) Какие проблемы написать отчет на СКД с выборкой первичных данных по бухитогам. А потом менеджеры пусть крутят как хотят.

(20) А если критически отнестись - что там такого можно накрутить в функционале Заказов клиентов из УТ, что может затем мешать работать в базе с обновлением типового БП ?

(0) такое работает в нескольких конторах, в принципе нормально. Но пускать манагеров в бп такое себе. Минусы - придется городить отдельные интерфейсы и отдельные роли и профили. А это проблемы после каждого планового обновления бп. Что-то обязательно отваливается как ни крути

(22) На словах никаких, особенно когда не тебе это делать. :) Там сразу выяснится, что не хватает кучи аналитик, ибо на счетах всего по три субконто и те не те что нужны. :) Или например получить себестоимость продаж в разрезе покупателей вдруг не получится простым запросом потому что в проводке Дт 90.02 - Кт 41 нет такой аналитики.

(21) если уж писать именно на документах из Заказов клиента, то естественно будет видеть РН и РС внутри процедур проведения.
Но если данные типовых документов в бух-регистре уже есть, то все равно они там есть и отчет на СКД дописывается в любом случае.

Т.е. (22) вполне работоспособный подход.

(23) Взаиморасчеты, например.

Не, я не против, пусть лабает, только три письма пусть не забудет написать. :)

(27) возражение нормальное. Только откуда уверенность, что у такого предложения как в (0) этим всем функционалом пользуются именно в УТ и пользоваться этой функциональностью доверено манагерам УТ, а не бухам БП ?

(24) упп как то жило, ерп же живет

(25) Ну выдерни данные из документов движений, какие проблемы?

(31) это же работать надо будет

Из разряда впилить в разработку тысысячу ч/ч чтобы сэкономить 50 ежегодно

(31) У меня вообще нет никаких проблем. Это у (0) проблемы. :)

(0) Плохая идея.Функционал УТ похоронить и писать свой.А не получится, УТ11 - очень богатая конфа.
Обмены надо настроить!И все будет летать.

(0) Доброго дня, уважаемый коллега. Делал такое. С учетом опыта могу заметить следующее:

1. Механизм заказа обычно связывают с механизмом резервирования. Т.е. если я в заказе укажу стол, то я подразумеваю, что стол не может быть отгружен вне рамок этого заказа. Если такое утверждение верно, тогда с заказом нужно делать и механизм резервирования, с которым в свою очередь нужно делать и механизм снятия с резерва. Т.е. в общем случае, видятся документы Заказ, Резерв, Снятие с резерва. Это минимум.

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

3. Если 1 заказ всегда закрывается 1 счетом и 1 отгрузкой (актом). В этом случае, можно не добавлять новый учетный документы "Заказ", а использовать для него типовой счет клиенту. Естественно, механизмы п.1 требуют отдельного уточнения и описания, но это возможно.

4. Если связь заказ-"счет" много ко многим, то это самый печальный случай, тогда все документы отгрузки будут требовать механизма выбора конкретного заказа. По практике просят тумблер "Заказ в шапке/ТЧ".

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

В целом, как я лично делал. У меня был п.4. Я посмотрел реализации УТ, посмотрел отчетность. Посмотрел реализации в УНФ, посмотрел отчетность. Описал концепт для конкретного клиента со всеми методическими ограничениям, т.к. ясно-понятно универсальное решение аля типовые, в одно лицо не сделать. Следующей итерацией была интеграция заказа с доставкой в БП. Сразу стало ясно, что ее возможности уже лимитируют заказы, поэтому я забрал данный функционал из УТ, адаптировав его под конкретную реализацию. С учетом пройденного опыта, сейчас многие вещи я сделал бы по другому.

скажу например так: в моей оптовой конторе для работы менеджеров вполне хватило бы БП + резервирование по заказам, как написал в (36). Ценовая политика - простая. Отчеты, которыми пользуются менеджеры - две-три штуки - остатки, акты сверок, шахматка по долгам. так что я бы вполне так сделал. Единственное что останавливало - мутность бухгалтерии как подразделения. Поэтому в итоге - развели на два контура. БП + УНФ.

(23) (29) Что можно сделать с заказом - например по одному заказу несколько отгрузок с частичной проплатой (или предоплатой) не равными суммами относительно товарных накладных, либо проплаты головной организацией за свои филиалы, либо отгрузка произведенного товара по отдельной спецификации или собственному опросному листу (кстати задача учета опросных листов - одна из обязательных требований в заказах) Так что тащить придется много. Резервирования как токового нет, ибо производство позаказное, и конечное изделие предназначено только заказавшему его клиенту по своим параметрам. И хотелось бы каждый заказ увязывать с выпуском готовой продукции (отчетом производства за смену) который есть в БП и чего нет в УТ. А так же важны расшифровки платежей клиента, так как сейчас клиент-банк выгружается в БП, а потом поступления на РасСч тянутся обратным обменом из БП в УТ и там их менеджер привязывает к заказам как ему нужно. Плюс акты сверок и ведомость расчетов (долги, просрочки и т.п.). На данный момент в УТ сперва делается коммерческое предложение или заказ, который рождается после отработки опросного листа и обменом в БП передается как счет покупателю (переписанный обмен).
Проблем с обменами на самом деле много. Так как много объектов и УТ передается не в аналогичные объекты в БП и наоборот. А пытаться там. что-то изменить, это по сути заново их написать. Основная трудность в том, то УТ не обновляется от слова совсем (тек. релиз 11.4.7.150) (это и не предполагалось внедрением) т.е. версии протоколов обмена с БП постоянно разъезжаются.

(36) Доброго дня! А чтобы вы сейчас сделали по другому?

(38) В таком изложении получается, при условном выделении в УТ подсистем CRM и оптовых продаж (отдельно от розничной реализации), у вас мечтают о написании своей версии КА2, но не прикручиванием к условному ядру подсистемы "регламентированный учет" (которая содержит регистр бухгалтерии), а наоборот - к БП прикрутить почти всю УТ (как минимум, CRM+Продажи)

Может быть проще будет посмотреть в сторону проекта внедрения КА 2 ? Будет у вас и CRM какая-то, и казначейство с платежным календарем, и бюджетирование можно будет применять
Т.е. в иотоге допиливания БП до уровня УТ родится некий мутант, с отдельными кусочками, уже разработанными внутри КА2

(40) Речь не о том, что хорошего заявлено в КА2, по сравнению с допиленной БП. Речь о том, что даже допиленную БП сопровождать проще, чем КА2 или тем более ЕРП, где без консультанта-методиста не обойтись.

(41) Это сильно зависит от сложности схем учета и заюзанного функционала КА.
Ну и дисциплины пользователей. Если задним числом при интеркампани любят то сами понимаете.

(41) А речь вообще не о том, что в КА2 есть что-то хорошее.

Если бы, к примеру, у ТС была УНФ и он заявил, а давайте куски из УНФ будем встраивать в БП каким-либо образом...
И мы бы тогда пытались сравнивать, что же там эдакого сумели придумать в УНФ, чего прямо хочется встраивать в БП? Ну и не известно, что там можно предполагать, с какой аргументацией.

А тут есть уже результат готового сращивания УТ+БП в виде КА2, а надо заявить, что пользоваться этим не нужно, а нужно заново все соединить, но самостоятельно!

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

(45) такой спор не имеет отношения к тому, что там у ТС происходит

если что, то мой ответ на вопрос топика озвучен в (4)

(38) (39) То что видно уже сейчас по вашей постановке:

1. >>например по одному заказу несколько отгрузок с частичной проплатой...Резервирования как токового нет, ибо производство позаказное, и конечное изделие предназначено только заказавшему его клиенту по своим параметрам.

У вас простой случай, когда 1 клиент имеет 1 заказ и все взаиморасчеты ведутся в разрезе счета. Вам вполне подойдет типовой документ счет клиенту для этого. Этим самым вы автоматом получаете все фишки "управленческого" счета в БП, а именно: контролируемый ввод со счета рту (система будет грузить в рту то, что еще не было отгружено), дебиторку по договора счета по сроку, привязку оплаты ко счету (т.к. для вас важны расшифровки платежей клиента,) авто-фиксации факта оплаты/отгрузки в форме списка счетов. Т.е. вы все это получаете бесплатно из коробки, просто введя у себя в организации правило, что в качестве заказа выступает документ счет. Тем более вы сами пишите "На данный момент в УТ сперва делается коммерческое предложение или заказ, который рождается после отработки опросного листа и обменом в БП передается как счет покупателю (переписанный обмен)." - т.е. у вас и так сейчас, также буквально.

2. >>И хотелось бы каждый заказ увязывать с выпуском готовой продукции (отчетом производства за смену) который есть в БП и чего нет в УТ.
Здесь пара ремарок:
2.1. Если вы хотите считать себестоимость в разрезе заказов в БП, то в эту сторону лучше не идти, а ограничиться уникальной готовой продукцией, на с.с. выпуска которой вы будете распределять ваши расходы.
2.2. Связь заказа и ОПзС, конечно придется доработать. Чтобы из счета можно было такой документ ввести.

Вы еще упомянали про коммерческое предложение. Конечно, если вы хотите полностью отказаться от УТ и перейти в БП, вам нужно создать его в БП в виде отдельного документа. Здесь, к сожалению аналога нет, которого можно было бы использовать.

В принципе, у вас не такая сложная задача, как показалось вначале. Доработки у вас, действительно будут минимальными.

(47),(48) Только для начала нужно бы получить уверенность в том, что все доработки реализуемы в расширениях. Типовая БП сейчас идет на уровне 17 релиза и по прежнему кое-что в расширении сделать ещё нельзя, и можно столкнуться со сложностями обновлений в будущем.

(49) >>все доработки реализуемы в расширениях.

Чьи это требования?

(0) все зависит от используемого функционала УТ11. Если вы используете обеспечение заказов, скидочную систему, учет по партнерам, логистический блок, функционал по ограничению отгрузок и т.д. то это будет не простая задача.

(50) Это не требования, это просто совет, который ТС очень лего может проигнорировать.
А так я встречал несколько конфигураций написанных на основе БП, которые потихоньку обрастали функционалом и превращались в самописки со всеми вытекающими по дальнейшему сопровождению. Но это абсолютно не значит, что так делать запрещено. Лично мне на сегодняшний день больше нравится разделение функционала, но ТС сам примет решение, зная свои процессы. Он в предыдущей ветке рассматривал переход на КА или ERP и советов ему уже надавали. Там где я работал одна БП не тянула и не большими изменениями все не заканчивалось.

(51) Это будет задача перехода на КА со связки УТ11+БП

(53) Тоже интересно насколько производство в БП отвечает их требованиям работать по заказам...

Хотя как он писал бухгалтерия все делает ручными операциями...И их это устраивает...Если собственника устраивать, то и пусть.

(54) как бы рассматривая Производство с позиций того, как это сделано хотя бы в КА - в БП это просто заглушка в виде документ для ввода Операции.

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

(55) Бухи там старой закалки, вероятно.

(56) "в БП это просто заглушка в виде документ для ввода Операции."
Нет конечно. В БП ОПЗС может вообще не делать бухпроводок, при соответствующих настройках. Там как раз главное это регистры оперативного учета, отражающие выпуск продукции. А себестоимость появится в конце месяца только.

(57) Только с заказами они никак не связаны, а как я понял ТС нужна связь с заказом.

(41) Вот именно, что во всех новых конфигурациях нужен именно консультант-методист, которому бухи будут выносить мозг, на тему как что сделать в программе, сами они разбираться точно не будут, ведь просчет спросить чем прочитать и вникнуть, и в большинстве случаев эти функции перекладывают на 1с-программиста, ведь брать еще одного сотрудника это не выгодно.

(41) (42) (43) Дисциплина пользователей? О чем вы? Когда уходили с КА1 то как раз и одной из причин отказа от КА2 был другой методологический подход к ведению БП.

(48) Если использовать счет покупателю БП как заказ клиенту, то таким образом просто счет на оплату (без движений) у же не выставишь, он автоматически станет заказом и соответственно уйдет в производство, нужен будет триггер на разделение смысла документа "Счет на оплату" как счет и как заказа. Типовой функционал гробить не хочется. То, что заказы из УТ обменом сваливаются в Счет в БП, это способ сообщить клиенту сумму к оплате по данному заказу. Полностью подменить понятия счета на заказ не выйдет - заказ намного шире по функционалу.
Про себестоимость пока не заморачиваюсь, ибо док. "РеализацияТиУ" из УТ падает в док. "реализация.." в БП и все считается по этим докам, как готовая продукция.
Сейчас больше интересует именно АРМ менеджера по продажам, что бы он мог полностью контролировать заказы, опр.листы, отгрузки, транспортные накладные (кстати в БП они тоже урезаны по сравнению с УТ, но это другая тема), оплаты и дебиторку (Ведомость расчетов с клиентами в разрезе заказов, с поступлениями на расч.счет и расшифровками платежей списками как в УТ).
Вот и мучают сомнения дописывать все это самому и все-таки как советуют на форуме рассмотреть переход на КА2. Хочется понять насколько это трудозатратно, ибо с меня в итоге спросят количество времени, и трудозатраты на тот или иной вариант.

(61) дописывать самому ИЛИ рассмотреть переход ...

(0) В УТ есть куча всякого функционала который в БП вообще нет.
Простой пример ценообразвание и скидки!
Этого вы что не юзаете в УТ?

(61) угу
все началось с того, что [Бухгалтерия привыкла работать с проводками напрямую]
если потратить пару дней на объяснение ГБ всех плюсов отражения в РСБУ в ERP/КА, то будет снята необходимость вести учет в 2-х системах или допиливать единственную

(0) ключевое слово - без доработки т.к. следствие доработки
отказ от привычного обновления и переход на танцы глазами сверять.
Т.е. есть же документ Операция. Можно сделать  забалансовый счет Заказ.
Количественный , суммовой , акт.пасс. Аналитика из доступных ( контрагент, номенклатура и тд)
В комментарии операции - заказ

В осв заказы смотреть ….

(62)
// Хочется понять насколько это трудозатратно
// дописывать самому ИЛИ рассмотреть переход ...

Если есть в наличии доступ к скачиванию КА2 - он по идее у вас там должен быть, т.к. КА1 была же куплена и внедрена
То можно просто для себя лично, в качестве тестирования самой возможности, посмотреть типовой способ перехода на КА2 с текущей базы УТ
Я не думаю, что это будет прямо много-много времени в техническом исполнении, но нужно будет посмотреть на результат.
В КА2 структурно УТ11 повторяется практически полностью. Если саму УТ никто не переписывал, то перенос данных трудностей вызывать не должен.


Понятно, что основной трудностью внедрения КА2, при переходе с УТ+БП - запустить пользователей БП, чтоб просто выполняли свои действия из БП по КА2 и не истерили.
Технических трудностей с этим в основном нет. В основном.

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

Тут можно просто повторить важные моменты для внедрения и саппорта КА2
- исходно УТ11 должна быть в наличии и в ней работают, ведут учет
- перенос работы из УТ11 в КА2 не вызовет трудностей (как уже сказал только что - структурно УТ и КА совпадают)
- перенос работы из БП в КА2 потребует некоторых разъяснений
- можно использовать точно также обмен КА2-БП, как сейчас используется обмен УТ-БП

Дописывать какие-то вещи для удобства работы бухгалтеров в КА будет проще, быстрее и по итогу качественней, чем городить внутри БП куски УТ
Но это я уже повторяться начал.

з.ы. И самое вкусное будет, что есть в КА2 подсистемы, которых в БП никогда не будет или для аналогов которых надо очень сильно постараться.
Из-за наличия этих подсистем, даже при наличии технических возможностей замены связок, со связки КА2+БП+ЗУП на связку УТ+БП+ЗУП никогда не уходят (ну почти никогда)

(63) Ценообразование и скидки не используем - цена фиксированная, определяется еще на этапе заказа и опросного листа. Мы не торговая организация (применительно к широкому понятию УТ. Все вкусняшки УТ для розницы нам без надобности). в основном УТ это склад и реализация, и то только из-за заказов.

(64) Ваши слова да бухам в уши. Но увы... Сорри.

(67) УТ переломали настолько, что диву даешься, как этот инвалид еще шевелится. второй год обновиться не можем, еще на релизе 7.150 работаем, хотя уже 15 релиз вышел

(65) Если и прилаживать свой функционал сбоку, то НЕ на регистрах бухгалтерии со своими счетами забалансовыми.

(64) Тут даже дело не столько в работе с проводками напрямую, а в привычке работать задним числом. Что вообще никак не накладывается на модель оперативного учета с текущей точкой актуальности итогов. В БП при работе задним числом всё более-менее выравнивается при закрытии месяца. А в более продвинутых системах, основанных на оперучете, при этом регулярно что-то рассыпается. Слишком там уж всё завязано на синтетические справочники, объекты которых генерятся при проведении.

(70) Тогда очень простой вывод:
любые предполагаемые доработки БП (или чего угодно) будет у вас просто повторным внедрением, когда работу с текущей базой нужно начать с "чистого листа".

(70) "хотя уже 15 релиз вышел" - вы не представляется как его перелопатили по сравнению со старыми релизами, будете сильно удивлены)

(72)[А в более продвинутых системах, основанных на оперучете, при этом регулярно что-то рассыпается]
ты просто не умеешь их готовить (с)

(69)[Но увы]
закрывай топик и иди кодировать
на перенос в БП заказа покупателя+Рг+общие модули нужна неделя

(76) Сдается мне, что сам по себе ему заказ клиента не нужен. Чтобы счет клиенту распечатать и потом реализацию на основании выписать - это уже и так есть в БП. А если надо что-то более полное, то там надо чтобы с этим всем и другие документы типовые работали и отчеты были соответствующие и контроли и резервы и взаиморасчеты и все такое прочее. Не думаю что за неделю такое можно налабать.

(77) ТС раз двадцать расписал, что ему резервы не нужны и дебиторка годиться по данным актов сверки, т.е. 62 счет
так что недели достаточно

(75) Возможно. Но БП интуитивно понятнее, а для ЕРП уже нужно специально учиться. И не все работодатели готовы на это тратиться. Думают, раз купили такое дорогое ЕРП, то оно и работать будет сразу же)

(78) Нафиг ему тогда заказ вообще? В БП есть счет покупателю, вполне себе достаточно.

(78) ты хотел сказать что завтра должно быть

(0) Начните с простого, создайте документ "Заказ" без проводок. На основании документа можно делать счет для заказчика. Бухгалтерия примет! ( если заказ будет делать не она).

(73) Вот тут вы правы. Слишком правы. Поэтому и возникают вопросы подобно этой теме, ибо заморачиваться каждый раз с новым внедрением уже никому ни хочется. Все ждут "волшебную кнопку", что бы открыл коробку и все работало. Причем не так как заложили разработчики, а как надо конечному пользователю. Ну или кто-нибудь это внедрение сделал (быстро и незаметно).

Возникает вопрос - а зачем столько вы в УТ наворотили,если вам простого заказа ,для ввода счета ,как (82) предлагает достаточно?Имхается, что пошлют вас с этой поделкой куда подальше, ибо будет постоянное нытьё «а там...»)))

(83) Если Заказчик готов платить за постоянные "улучшения и внедрения" аля как в УТ, то вперёд. При этом надо пожелать здоровья как Исполнителю, так и Заказчику. Вся система будет работоспособна до тех пор, пока они рядом и всегда что-то подправляют, и пока не изменятся задумки))

(84) Вот и мне уже четвертый год интересно, зачем УТ выбрали для производства, затем изуродовали до подмены понятий (например, в карточке склада в УТ галку "Ответственное хранение" задействовали как признак, что это склад давальческого сырья), искорежили обмен из УТ в БП, а в итоге используем УТ на 1% и с постоянными нареканиями, что все не работает, и с постоянными правками косяков. И вы правы - "а вот там... все работало". Достало все хуже редьки. Про ЕРП только разговоры, слишком все это дорого, вот и приходится искать альтернативы, как пришить рукава к брюкам.