Заметка «Снова о разных подходах к внедрению iScala» была опубликована 08.02.2019. А ранее эта тема обсуждалась на форуме.
Ниже я хочу поделиться своими соображениями немного в ином ключе.
Буквально на днях я обсуждал с сотрудницей моего клиента возможность автоматически обработать УПД, накладную или счёт-фактуру, поступившие от поставщика через систему электронного документооборота (ЭДО). И выяснилось, что существующая схема закупок исключает этот (такой желаемый) вариант. Всё дело в том, что для ввода заявок используется некая «внешняя» система с красивым веб интерфейсом и продвинутым функционалом, интегрированная с iScala через Epicor Service Connect. Вот только функционал собственно заявок находится в этой системе, а не в iScala. В веб интерфейсе вводится заявка на закупку, утверждается, а позднее, при получении счёта от поставщика в этой же системе делается соотнесение запланированного количества и суммы (например, заявка на целый год, счета поступают на кратные части от общего согласованного объёма закупок), делается это через ввод поставки, и уже после этого бухгалтер может создать счет-фактуру на поставку, который через систему Epicor Service Connect автоматически создаёт аналогичный счёт-фактуру и проводку по поставщику в iScala. При такой схеме поступающий через ЭДО файл акта, накладной или счёта-фактуры должен быть обработан во «внешней» по отношению к iScala системе размещения заявок на закупку. Но для этого её разработчики должны доработать систему и добавить в неё отсутствующий функционал. Возможно ли это, сколько займёт времени, сколько будет стоить? — эти вопросы не слишком очевидны, да и не могут быть решены «на стороне клиента», если только вы не практикуете такой подход, как прямую запись в таблицы.
Если бы та же система не пыталась подменить собой модуль «Требования» iScala, а служила лишь более удобным интерфейсом ввода заявок, загружаемых затем через Epicor Service Connect в iScala, тогда и поступивший через систему ЭДО файл мог бы быть обработанным непосредственно в iScala через тот же Epicor Service Connect. А ведь организовать ввод заявок (требований) в iScala можно даже с помощью Excel и небольшой надстройки, которая создаст XML файл нужной структуры, который, в свою очередь, обработает Service Connect. Но через веб интерфейс, скорее всего, удобнее, ну, как минимум, красивее 🙂
Разумеется, я не против подобных систем. Но при этом за то, чтобы по максимуму использовать функциональность iScala без попыток её полностью переписать «на стороне». Разумное взаимодействие, помогающее пользователю работать, это благо. Пока оно «разумное» 🙂
В любом случае это решает «заказчик». Но я за то, чтобы ему до принятия решения предоставили несколько альтернативных вариантов и объяснили плюсы и минусы каждого подхода.
