Microsoft Dynamics

Предисловие

Я однажды уже писал об архитектуре модуля логистики в DAX. Думаю что рассказ был бы не полным, если бы я не привел конкретный пример того, как можно дополнять логистический модуль новыми типами складских документов.  Пример, который я буду рассматривать в этой статье, сделан по мотивам доработки, реализованной для конкретного проекта. Эта доработка успешно эксплуатируется почти два года и я уверен в принципиальной работоспособности предложенного подхода. Тем не менее, хочу предупредить что:

1. Я разрабатывал этот пример с ноля и особо глубоко не тестировал. В нем могут быть достаточно глупые ошибки
2. Исходный вариант был реализован на версии 3.0,  при переходе на 4ку я мог чего-то упустить
3. Не следует считать мой стиль программирования образцовым. Метками я не пользуюсь и best practice не всегда соблюдаю.
4. Я не уверен в том,  что предложенная модификация хорошо укладывается в идеологию MRP. С другой стороны - для торговых организаций такая доработка может быть очень полезна.

Короче говоря  - прощу относится к прилагающемуся примеру не как к готовому модулю, а как к действующему макету.

Бизнес-проблема

Внедрение в крупной торговой организации. За любой ходовой товар идет непрерывная борьба между сейлами. Поскольку неходовой товар стараются не закупать, сейлы борются вообще почти за любой товар. Использование стандартной функциональности DAX по работе с резервами не устраивает пользователей. Регулярно возникает необходимость перенести резерв с одного заказа на другой (более срочный). Если просто снять резерв с одного заказа и потом поставить резерв на другой заказ, есть большие шансы что в процессе переноса, снятый резерв будет поставлен на свой заказ каким-то другим сейлом.

Кроме того, выяснилось что в условиях конкуренции за товар, сейлы приноровились создавать фиктивные заказы. По таким заказам никогда не происходит реальная отгрузка. Единственная цель существования подобных заказов - это использовать их для хранения заначки из резервов. Таким образом, реально резерв в системе бывает двух типов: нормальный резерв, привязанный к обычному заказу и глобальный резерв сейла, который привязан к некому фиктивному заказу (хотя по смыслу, скорее должен быть привязан к сейлу, а не заказу). Руководство коммерческих департаментов в принципе не возражает против существования подобных заначек продавцов, но хотело бы как-то цивилизовать работу с ними. По крайней мере необходимо разделять в системе информацию об обычных резервах и подобных стратегических резервах продавца.

Общий дизайн

Предлагается реализовать новую сущность - клипборд резервов. В системе может существовать любое количество именованных клипбордов резервов. Доступ к клипборду настраивается с точностью до пользователей или групп пользователей. Во всех складских документах, кроме обычной функции резервирования становятся доступными два специальных пункта меню “Резервировать из клипборда”,”Снять резерв в клипборд”. Перевод резерва с обычного складского документа в клипборд или наоборот, происходит как одна целостная операция в одной транзакции.

Для того чтобы отделить нормальные резервы, от резервов лежащих в клипборде необходимо в форме “Запасы в наличии” и других аналогичных формах, добавить после колонки “Физически зарезервировано” колонку “В том числе - клипборды”.

Путеводитель по классам логистики

В первом приближении - понятно как с точки зрения системы должен выглядеть клипборд резервов. Это должно быть некое подобие заказа, c шапкой и строками. Шапка должна соответствовать самому клипборду, а строки - строкам лежащего в клипборде товара. Исходя из этой идеи, можно конечно было бы попытать реализовать клипборд резервов, совершив жестокое и противоестественное насилие над обычными заказами, но это не наш метод.

 Предлагается внести в систему логистики Dynamics AX совершенно новый, отдельный тип складского документа - строка клипборда резервов.

Напомню о подходе, который используется в DAX для организации связи исходных складских документов (таких как строки заказов, закупок, складских журналов, клипборда резервов), с общими таблицами логистического модуля (то есть - складскими проводками, остатками и тп). Созданием и обновлением складских проводок занимаются наследники класса InventUpdate. Каждой операции над складскими проводками (соответственно - и над складскими документами) соответствует один из классов наследников:

При этом, каждый из этих классов НИЧЕГО не знает о специфике, связанной с конкретным исходным складским документом. Когда этим классам требуется получить какую-то информацию из исходного складского документа (например - код номенклатуры или складской аналитики) или выполнить какое-то действие, специфичное для данного складского документа (например - создать проводку в ГК по финансовым складским движениям), они обращаются к классам семейства InventMov*, которые и предоставляют подобный сервис. В каждом из наследников класса InventMovement есть внутренняя переменная, в которой хранится экземпляр записи  складского документа, на основании которой и создается складская проводка. При создании класса inventMovement, система использует constructor controlled inheritance. Строка складского документа передается в метод InventMovement::construct, который на основании информации из tableId этой строки, создает тот или иной наследник класса InventMovement. Классы inventMovement - это не просто дополнение к классам inventUpdate; На самом деле - это просто набор неких сервисов, связанных со складскими документами, которые вызываются не только из классов inventUpdate, но и из других мест системы.

Поскольку ниже я буду описывать ключевые методы класса inventMovement, надо сразу же ввести некоторую условную классификацию методов:

1. Методы чтения. Так я буду называть методы, которые возвращают информацию из строки складского документа. Они конечно могут ее трансформировать или как-то подменять, но глубокой переработки возвращаемой информации эти методы не предполагают
2. Методы параметризации. Эти методы также возвращают некий параметр, от которого зависит способ работы вызывающего класса. В отличие от методов чтения, эти методы либо возвращают константу, определяемую спецификой самого класса (например - поддерживает ли этот класс отслеживание недоотгруженного/недопоставленного остатка), либо значение некой настроечной таблицы, достаточно косвенно зависящее от складского документа.
3. Методы обновления. Эти методы обновляют данные в исходном документе.
4. Методы действия. Методы выполняют какие-то обновления данных, не связанные с обновлением складского документа. Например - создание проводок ГК, создание карантинного журнала и тп.
5. Методы проверки. Вызываются системой перед выполнением каких-то действий. Должны не только вернуть true/false, но и выдать какое-то сообщение об ошибке, если таковая случилась.
6. Сервисные методы. Фактически - все прочие методы.

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

По моему правильный подход к переопределению методов в своем наследнике inventMovement такой: Сначала сделать маленький прототип, в котором переопределены только минимальный набор методов чтения и записи. В ходе тестирования мы неоднократно наткнемся на ошибку, связанную с отсутствием переопределения метода. После того как наша доработка перестала вылетать с выдачей сообщения об отсутствии определения метода, мы уже можем посмотреть на смысловую часть работы нашей модификации. Если что-то работает не так как нам хотелось бы, есть большие шансы что ситуацию можно будет исправить, переопределив в нашем классе некоторые из методов. Кроме того - некоторые методы вызываются параметрически. То есть - если у нас метод mustBeRemainControlled возвращает true, то нам придется реализовывать методы addRemainXXX, потому что первый параметрический метод, собственно и включил их вызов.

Ниже я привожу список основных методов класса inventMovement:

Если просмотреть иерархию классов-наследников InventMovement, можно обнаружить там классы, которые не создаются в inventMovement::cnstructNoThrow(). Это классы inventMov_Vir_Transfer, inventMov_Vir_Counting, inventMov_Vir_QuarantineLoss и их суперкласс inventMov_Virtuel, которые используются для создания складских движений полностью программным путем - без создания соответствующего складского документа. Ниже я привожу табличку с описанием того, зачем эти классы используются в системе.

В заключение, надо сказать о том как обычно строится взаимодействие классов inventMovement и inventUpdate. В любом классе inventUpd имеется стандартный метод-конструктор с именем типа newParameters. Кроме того, для всех (или почти всех) складских документов, которые могут порождать подобный вид складских операций, заводится специальный метод newXXX (например -  newPurchInvoice,newSalesInvoice,newInventJournal и тп). После того как объект inventUpdate создан, само действие выполняется вызовом inventUpdate.updateNow().

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

После того как теоретическая часть закончена, можно приступить к практическим занятиям Код примера приложен к статье. Он был реализован на DAX 4.0SP2

Для начала создаем собственно таблицы, в которых у нас будут хранится строки клипборда резервов - reserveClipBoardLine. Строка эта, само собой, должна содержать код номенклатуры, код складской аналитики,количество и номер лота. Кроме того, в нашем случае она будет содержать код клипборда резервов. Номер лота будем генерировать и присваивать в методах update и insert. Обратите внимание на шаблонный кусок кода, вызывающий inventUpd_estimated.updateNow(), чтобы создавать складские проводки в статусе Заказанно.   

Сам список клипбордов резервов лежит в таблице reserveClipboard.

Предполагается, что пользователи не будут часто работать с таблицей строк клипборда резервов напрямую (то есть - не через функции “Резервировать из клипборда”/”Снять резерв из клипборда”). Тем не менее, из соображений хорошего тона нам придется реализовать форму редактирования строк клипборда резервов. Сама по себе форма особого интереса не представляет. Любопытным, однако, будет посмотреть на доработки, которые понадобилось сделать для того чтобы заинтегрировать ее с системой управления доступностью/недоступностью складской аналитики для редактирования.

Для начала стоит посмотреть на то, как эта форма работает с классом inventDimCtrl_Frm_mov. Этот класс является наследником класса inventDimCtrl_Frm, который и отвечает за работу с отображением складской аналитики на форме. Я не буду разбирать работу этих классов в целом. Ниже описаны доработки, которые  пришлось сделать для того чтобы поддержать интеграцию новой формы со стандартным механизмом работы со складской аналитикой.

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

Для того чтобы завершить интеграцию вновь созданного класса в систему логистики, нам осталось доработать метод InventMovement::constructNoThrow() таким образом чтобы он создавал объект типа inventMov_reserveClipboardLine. Кроме того, нам надо аналогичным образом доработать метод inventTrans.inventMovement().

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

Эти функции выполняются классами reserveFromClipboard и unreserveFromClipboard. Эти классы делают достаточно трививальную вещь - открывают транзакцию, снимают резерв в одном месте и ставят резерв в другом месте. Я думаю - несложно будет разобраться по исходному коду примера. Хочу обратить внимание на использование методов addTrans() и updateBuffer() для того чтобы увеличить количество в строке клипборда резервов перед резервированием в клипборде или уменьшения количества - после снятия резерва из клипборда. Также надо обратить внимание на использование метода transIdSum() для подсчета количества в разных статусах в складских проводках по данному лоту. Даже после обновления статусов проводок в методе inventUpdate.writeInventTrans(), этот метод возвращает объект inventTransIdSum(), возвращающий правильные количества. Пункты меню, связанные с новыми классами, добавлены только в форму заказов. В реальных условиях они, само собой, были добавлены во все складские документы, порождающие списания.

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

Добавление полей в таблицу “Запасы в наличии”

В первом приближении - добавление новых количественных полей в таблицу inventSum (Запасы в наличии) - это достаточно простой процесс. Обновление этой таблицы производится вызовами ее методов addInventTransOnSum и subInventTransOnSum, которые вызываются в момент обновления записей в таблице inventTrans. В этих методах имеется оператор switch, который, в зависимости от статусов прихода и расхода, добавляет (или вычитает) количество в складской проводке к количеству в одном из количественных полей inventSum. Так что в первом приближении, все что нам надо сделать - это добавить в эти методы маленькую веточку в оператор case, которая в зависимости от типа проводки добавляла бы количество из складской проводки не только в обычное поле, но и в наше новое поле “физически зарезервировано в клипборде”.

Остальные доработки связаны с появившимся в версии DAX 4.0 механизмом отложенного обновления остатков. В связи с этим, нам приходится добавлять поля и обновлять методы таблицы inventSumDelta. Особенно важно, не забыть включить новое поле в группы полей deltaFields и deltaFieldsQty в таблицах inventSum и inventSumDelta. Как я уже писал в одной из своих предыдущих статей, система для быстрого обновления таблицы InventSum использует native SQL, который перегоняет накопленные обновления из таблицы inventSumDelta в таблицу inventSum. Именно для генерации корректного списка обновляемых полей и необходимы эти группы полей. Более того, поскольку при использовании Oracle, это обновление делается с помощью хранимой процедуры, нам после установки этой доработки необходимо будет выполнить метод SQLOracleInitStoredProcs::initOracleSPIMTS(), чтобы пересоздать эту хранимую процедуру на сервере.

Необходимо также, добавить новое поле в макрос inventSumFields, перекомпилировав после этого все классы и таблицы. Кроме того - я добавил новые методы в класса inventTransidSum и inventOnHand. Я этими новыми методами не пользуюсь, но из соображений хорошего тона в программировании эти методы добавить надо.

Наконец, надо изменить класс InventSumRecalcItem. Этот класс используется для пересчета таблицы InventSum. Поскольку он, перед вызовом методом inventSum.addInventTransOnSum и inventSum.subInventTransOnSum() группирует строки таблицы inventTrans по статусу, разнообразным датам, складской аналитике и номенклатуре, нам для правильной работы доработки придется добавить туда еще и тип проводки.

Хотя в данной доработке я создаю новые поля в inventSum на основании стандартных полей inventTrans, но в целом этот механизм достаточно удобно применять и для всяких дополнительных статусных полей. Например, на одном из проектов, мы добавили в шапку закупки новое перечислимое поле “Статус доставки”, в котором указывалась стадия доставки товара от производственных площадок производителя (зарубежного кстати) до локальных складов организации, в которой шло внедрение. Далее, мы растиражировали это поле в складские проводки, а затем добавили в таблицу запасов в наличии новые поля, в которых было указано количество в каждой из стадий доставки. После этого пользователям в форме “В наличии” стала доступна информация не только о том сколько товара уже заказано, но и о том где этот заказанный товар находится.

Вместо завершения

В приложенном проекте имеется группа объектов inventTransCreateDemo и вложенный в нее класс InvVirDemo, которые не имеют никакого отношения к рассматриваемому примеру с клипбордами резервов. Просто я решил, что раз уж я рассказал в этой статье о классах виртуальных складских движений (inventMov_virtual и наследники), то имеет смысл привести пример их использования. Класс invVirDemo запрашивает у пользователя номенклатуру, количество, себестоимость, два склада и два коррсчета. После этого система создает приход номенклатуры на один из складов с первого коррсчета, делает перенос номенклатуры на второй склад и списывает со второго склада на второй коррсчет. Я думаю в классе достаточно подробные комментарии чтобы разобраться с ним самостоятельно.

Также хочу заметить, что на мой взгляд, не стоит слишком увлекаться использованием класса inventMov_Virtuel для создания складских движений. На мой взгляд, этот класс придуман для тех случаев, когда какой-то кусок функциональности ИНОГДА должен создавать складские проводки. Если вы пишете какое-то полноценное расширение логистики, то правильнее создавать новый тип складского движения и нового наследника класса inventMovement.