• Пример настройки Торговой системы и Почтового модуля для сетевого режима работы.

 

- актуальная версия СуперМаг Плюс начиная с 30.10.2022г., определена как 1.049.1 сп1.

Работа с Честным знаком из Супермаг Плюс построена по принципу «работа из одного окна», т.е. сотрудникам, которые работают в Торговой системе и должны взаимодействовать с государственными системами (ЕГАИС, Честный знак) не нужно заходить в несколько программ. Все необходимые документы загружаются в Супермаг Плюс и появляется возможность создавать учетные документы на основании документов ФГИС. Дополнительная возможность сопоставлять номенклатуру ФГИС и учетную номенклатуру позволяет минимизировать ошибки, связанные с человеческим фактором.

Общие принципы работы с маркированными товарами:
1. Факт перехода прав собственности на товар фиксируется через электронный документ, полученный по ЭДО.
2. Факты выбытия маркированной продукцией из оборота фиксируется на кассовом ПО при продаже конечному покупателю

В решении Супермаг Плюс есть возможность подключить электронный документооборот через сервис ПО СБИС (от компании Тензор).

Из практики: 
клиент настроил обмен с документами УПД по двум каналам. Первый канал принимал УПД в центральную БД и распространял их по магазинам группы А. Второй канал принимал УПД в починенную БД и распространял их по магазинам группы Б.
Ошибочно идентификатор участника был указан для двух потоков как "1". Т.е. не был уникален в пределах сети магазинов.
В итоге документы УПД, и приходные накладные потока 2, согласно правилам рассылки "поднимались" в старшую БД. Где для этих документов срабатывала процедура сверки. Формировался ответ REPLY, который система отправляла через первый канал. 
Т.е. через канал Центральной БД. Таким образом наблюдалась ситуация, при которой документ был получен по каналу 2, а ответ отправлен по каналу 1. Если бы идентификаторы обмена для каналов обмена были бы указаны разные, например 1, и 2. 
Такая бы ситуация не произошла. Ответ который бы попыталась сформировать Центральная базы для документов полученных по каналу 2, не нашел бы необходимый почтовый ящик и отправлен бы не был. 

Здесь и далее, предлагается общая инструкция по настройке обмена электронными документами через провайдера Тензор (решение СБИС).

1. Схемы объектов используемые в процессе обмена (будут актуализироваться, изменяться, предлагаться варианты).

     2. Устарела.....бедует удалена...Схемы объектов используемые в процессе обмена (будут актуализироваться, изменяться, предлагаться варианты).

Перечень готовых QR кодов для самопроверки, на основании UPD_Natur_Prod.xml → QR коды.docx

2. Требования для клиентов для подключения Интеграции СМ+

• 1. Наличие версии Супермаг Плюс 1.49 или выше.
• Наличие специальной расширенной лицензии для ПО Супермаг плюс. Дополнительный модуль УПД EDI (ОДИН на ВСЁ ) в котором открыты модули их функции (список будет расширяться):
  - №121 УПД на отгрузку (функции - 12001, 12002, 12100, 12104, 12002, 12100, 12104, 12109, 12110, 12111, 12116, 12121, 12150).
  - №56 УПД на приход (функции - 5600, 5603, 5606, 5607, 5609, 5610, 5611, 5616, 5621).
• Расширенная лицензия выдается по договоренности между клиентом и его курирующим менеджером (со стороны компании Ритейл Софт) на коммерческой основе.
• Лицензированию подлежит каждый экземпляр БД, в случае если клиентом используется вариант «распределительных баз».
• В случае, если у клиента имеется одна единая БД которая используется для работы всех пользователей предприятия (склады, магазины, офис) – расширенная лицензия понадобится только одна.
• Лицензия открывает доступ к необходимым разделам ПО, и выдает разрешение на их использование всем пользователям СМ+ без ограничений.
• Допускается вариант работы, когда расширенная лицензия приобретается только для центральной базы данных. В этом случае, функционал работы с ЭДО в подчинённых базах сохранятся, но попадает под действие некоторых ограничений. Сократить количество ограничений, которые могут возникнуть у операторов в магазинах, позволит использование мобильного рабочего места СММобайл. Отсутствие лицензии, не даст возможности использовать раздел УПД на приход, УП на отгрузку, но несмотря на это, процессы связанные приемкой товаров \ отгрузкой товаров на основании УПД – будут доступны (доступны с ограничением).
• Допускаются различные комбинированные варианты, при которых, модули ЭДО приобретаются не на всю сеть. Например, расширенная лицензия не устанавливается в «маленькие» магазины.
• Для окончательного принятия решения со стороны клиента о необходимости приобретения модуля ЭДО и его количеств. Компания разработчик ПО – предлагает получить временную лицензию на модуль ЭДО для старшей БД. И при наличии, для 1-й (любой) подчиненной сроком на 2 месяца.
• Для осуществления обмена данными на стороне СМ+ необходимо:
  - Запустить и настроить Почтовый модуль Супермаг Плюс.
  - В параметры настроек добавить две «Доверительные базы», например TENSOR1, TENSOR2 (или как на рисунках - SBIS_IN_УПД, SBIS_OUT).
  - Каждая из БД должна производить обмен по протоколу FTP.
  - Каждая из БД должна иметь свои уникальные каталоги обмена (IN, OUT).
  - БД TENSOR1 – должна использовать фильтр «Стандартный фильтр XML»
  - БД TENSOR2 – должна использовать фильтр «УПД XML»
• Настройка отмеченная в п.7 обеспечивает обмен разными типами документов по разным каналам связи. (например, База TENSOR1 предназначена для обмена EDI объектами. База TENSOR2 предназначена для обмена УПД и УКД документами (в дальнейшем);
• Каждая из БД использует свои почтовые схемы объектов (XSD).
• Схемы объектов будут предоставляться службой Технической поддержки СМ+, но вариант разработки новых (других) схем самостоятельно клиентом– не исключён (если такая необходимость возникнет).

3. Общие принципы и условия обмена.

• Обмен подразумевает ситуацию при которой справочники (товары и их атрибуты, поставщики, клиенты и т.п.) не имеют полной синхронизации между отправителем и получателем.
• Поэтому идентификация объектов на принимающей стороне происходит по заранее определенным и назначенным признакам.
• Например: идентификация карточки, происходит на основании закрепленного за товаром Штрихового кода.
• Например: идентификация поставщика, происходит на основании GLN (GLN (Global Location Number) – глобальный номер места нахождения – уникальный номер в системе GS1 для идентификации участников цепи поставки и их материальных, функциональных или юридических объектов (подразделений) (филиалы/офисы/склады/рампы и т.д.). Используется главным образом в EDI для эффективной идентификации всех объектов, касающихся поставок).
• Торговая система Супермаг Плюс при формировании пакета на отправку или при осуществлении приема имеет возможность указания в схеме объекта XSD определенных функций, в задачу которых будет входить предобразование одной сущности в другую. Например: При приеме объекта со ШК, функция ArticleByBarcode* произведет преобразование ШК в артикул карточки товара в Супермаг Плюс. * - описание функций смотрите в бюллетенях изменений - Бюллетень изменений СуперМаг
• В качестве транспорта для передачи объектов со стороны Супермаг Плюс используется Почтовый модуль СуперМага работающий по протоколу FTP.

4. Необходимая информация для справочников Супермаг Плюс, которая требует обязательного указания и согласования с Тензор.

• Контрагент (Поставщик, Покупатель, Собственный контрагент). Указывается: ИНН, КПП, GLN.

• Контрагент (Поставщик). Указывается (опционально): на закладке "Артикулы контрагента" - спецификация поставляемой продукции, Арт. контрагента (внутренний код поставщика), Штриховой код товара (Штриховой код товара который зафиксирован в справочниках поставщика, для идентификации товара).

• Места хранения. Указывается: КПП, GLN

• Карточка товара. Указывается: На закладке "Штрихкоды", для одного ШК - атрибут "Обмен с EDI", именно этот ШК будет участвовать в отсылке поставщику. Алгоритм выбора ШК для отправки поставщику работает по следующему правилу: По умолчанию передается ШК поставщика, заранее заявленный в системе СМ+ (раздел контрагенты, закладка артикулы поставщика), если список артикулов и ШК у поставщика пуст. То передается ШК из раздела - карточка товара, который имеет признак - "Использовать при с EDI обмене". Если ни один штриховой код не отмечен, штриховой код будет подобран по правилу "первый попавшийся".

5. Настройки обмена.

• Для обеспечения полноценного обмена как EDI объектами, так и УПД и УКД объектами. Используются разные точки отправки и приемка.
• Пример настроек Почтового модуля для обмена EDI объектами:

• Пример настроек Почтового модуля для обмена УПД и УКД объектами:

Обратите внимание, что в рамках версии 1.49 сп2. 

УПД фильтр. Опция «Сохранять копию (.bak) при отсылке».
В настройки почтового модуля для УПД фильтра добавлена опция «Сохранять копию (.bak) при отсылке». По умолчанию флаг не отмечен.
Если флаг отметить, то при отсылке пакетов по протоколу «УПД фильтр» копии отсылаемых файлов будут сохраняться в подкаталоге LOG каталога исходящих сообщений с расширением .bak.
Опция может быть полезна в тех случаях, когда провайдер забирает файлы пакетов в автоматическом режиме, но требуется знать точное содержание переданных файлов, например, в случаях разногласий с провайдером или контрагентом в интерпретации содержания отосланных пакетов. При использовании опции необходимо следить за размером дискового пространства и периодически удалять ненужные файлы.

5. Правила рассылки почтовых объектов.

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

• возможные настройки №1 (централизованная схема БД Супермаг (одна база данных)).

• возможные настройки №2 (распределенная схема БД Супермаг (одна старшая и множество подчиненных БД)).

Обмен с ЭДО и EDI (со всеми провайдерами) настроен в базе ЦО.

ЦО получает Накладную поставщика из магазина и отсылает ответ.

Справка:

Отличия между EDI и ЭДО
Теперь мы располагаем всей полнотой информации, чтобы уверенно ответить: EDI и ЭДО — разные системы. Доступен и ответ на вопрос о том, в чём заключаются отличия между ними. Главное из них — в следующем:

сообщения и документы в системе EDI имеют форму, не утверждённую законодательством — она определяется самими участниками обмена данными;
документация, передаваемая с помощью системы ЭДО, имеет форму, предусмотренную нормативными актами, и заверяется электронной цифровой подписью. Это придаёт ей юридическую силу и позволяет подавать в налоговые инспекции, суды, другие государственные и муниципальные органы.

Примечание:

№1 - В рамках версии 1.045 сп2. Была сделана доработка

Почтовый модуль. Функция импорта артикула XML файла.

В почтовый модуль добавлена функция ArticleByBarcodeUI для определения артикула при импорте XML файла по содержанию поля, предназначенного для хранения EAN штрихового кода артикула и/или таблицы с КИЗ.

Функция исследует значение поля для хранения штрихового кода. если поле содержит данные, то определяет артикул по штриховому коду, также как функция ArticleByBarcode. В противном случае функция исследует содержание таблицы с КИЗ и определяет артикул по содержанию первого попавшегося кода КИЗ (КИЗ содержит 14 символов GTIN товара после кода применения 01, из которого, в свою очередь, можно получить EAN товара отбрасыванием лидирующего нуля).

XSD схема должна содержать, как поле «BARCODE» (название может быть произвольным), так и таблицу с полем «MARCCODE», тогда как XML файл может содержать как оба поля, так и какое либо одно из них.

Функция ArticleByBarcodeUI предназначена, в первую очередь для обработки УПД на приход при приеме УПД от разных поставщиков, которые по разному формируют содержание документа.

--- Задача функции сводится к определению артикула из двух возможных источников.

Но, как показала практика, есть случаи, когда на товаре нет ШК, и еще нет КИЗ (не маркированный), чаще всего такой товар - является весовым.

В этом случае, "добыть" артикул нам не из чего. Конечно, можно исправить схему (убрать функцию: "ArticleByBarcode(BARCODE)" или "ArticleByBarcodeUI"). И передавать Артикул в явном виде в файле УПД (UI). 

Но тогда сломается определение артикула для случаев, когда нужно опираться на ШК или КиЗ (т.е. для штучных товаров и маркированных товаров, а их порядка 90% в общем справочнике).

Предложение следующее (или \ или):

• Назначить на товар ШК = текущему артикулу.
• Назначить на товар любой короткий ШК, можно вообще любой.
• Назначить на товар ШК = артикулу поставщика.

Определить этот код, как "Используется при EDI обмене". Передавать его для поставщика и получать его обратно. На основании функций "ArticleByBarcode(BARCODE)" или "ArticleByBarcodeUI" - определять артикул товарной карточки. (т.е. не менять установленную логику работы).

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

№2 - Провайдер присылает документ с заполненной "меткой", необходимо было видеть значение этой же метки, но в другом документе.

Во вложении скрипт, который нужно пропустить по базе oracle от имени supermag.
Если по почте приходит документ «Подтверждение заказа поставщику» с изменившимся значением метки «EDIReceivedStatus»,
то это значение будет проставлено в ту же метку для заказа поставщику, находящегося в общих основаниях подтверждения заказа.
Ограничение: если после получения метки ее удалить из заказа поставщику и получить повторно документ
«Подтверждение заказа поставщику» с прежним значением метки, она в заказ поставщику не проставится,
т.к. в подтверждении заказа ее значение не изменится.

CentrTorg_DocPropsOE_Trigger.sql

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

№3 - В рамках версии 1.048. Была сделана доработка, касающаяся работы с УКД на приход.

.... 

- Почтовый модуль принимает УКД в документ «УПД на приход» с операцией «Коррекция при приемке». При приеме УКД создается новый документ УПД на приход, спецификация которого формируется, как спецификация первичного УПД с коррекцией по данным УКД.

- Содержание вновь созданного документа УПД на приход сверяется с содержанием приходной накладной. В случае расхождения, УКД на приход блокируется "Заблокирован", в случае совпадения - получает статус «Закрыт».

- Поставщику отсылается уведомление о подтверждении приема.

- Если приходная накладная имела статус «Принят на складе», то ее статус автоматически меняется на «Принят полностью».

....В случае расхождения, УКД на приход блокируется...

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

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

№4 - Почему УПД блокируется?

Нужно более детально смотреть состав документов, проверяется совпадение.
- МХ поставки.
- поставщик
- собственный контрагент
- вхождение в спецификацию
- количество
- цена полная (допускается расхождение в пределах не более +- копейка)
- цена без НДС (допускается расхождение в пределах не более +- копейка)
- сумма НДС (допускается расхождение в пределах не более +- копейка)
- ставка НДС
- полная сумма (допускается расхождение в пределах не более +- копейка)
- сумма без НДС (допускается расхождение в пределах не более +- копейка)
- сумма документа (допускается расхождение в пределах не более +- копейка)
- марки (при наличии)

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

№5 - Почему УПД блокируется?

Исследовав накладную поставщика (УПД на приход) с внутренним документом Приходная накладная. Допустим, Вы сделали вывод, что СуперМаг Плюс неверно формирует документ.

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

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

Рассмотрим пример формирования УПД от поставщика А.

На первый взгляд. вполне корректная накладная.

Но.....

13*10.83= 140.79 (Количество * Цена без налога = Сумма без налога )

13*13=169 (Количество * Цена  = Сумма)

Можно и другой вариант рассмотреть:

13*10.83= 140.79 (Количество * Цена без налога = Сумма без налога )

13*13=169 (Количество * Цена  = Сумма)

Можно ли считать, что какой-то из документов оформлен не верно? Да. Но попробуйте это объявить поставщику, т.е. указать ему на нарушение существующих правил формирования докментов, регламенты и пр.

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

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

ВСЁ, халява закончилась.

Теперь, такой документ проверку в Супермаг Плюс - не пройдет. Не сможем мы согласиться с документом поставщика, который пренебрёг элементарными правилами математики.

Наверное, уже большинство поняли в чем проблема (если не поняли, дальше можете не читать (до свидания! ).

Большинство думают, что формат электронной накладной такой, что "циферки" в ней помещаются не полностью, приходится "бедному" поставщику все округлять.

Но, как бы не так:

https://www.consultant.ru/document/cons_doc_LAW_388349/

Формат, например, поля, ЦенаТов = N(26.11)

Формат числового значения указывается в виде N(m.k), где: m - максимальное количество знаков в числе, включая знак (для отрицательного числа), целую и дробную часть числа без разделяющей десятичной точки, k - максимальное число знаков дробной части числа. Если число знаков дробной части числа равно 0 (то есть число целое), то формат числового значения имеет вид N(m).

Т.е. 11! знаков после запятой. 

Спросите у поставщика-  зачем его "программист", наокруглял значения цен и сумм и из "кареты сделал тыкву"?

Вот так выглядят эти документы в Торговой системе Супермаг Плюс.

И кто теперь, по вашему мнению, слабое звено?

Выдохнули.... и поняли, поставщика "переделать" не выйдет, придется искать решение у себя в системе.

1. В документе Приходная накладная, есть закладка "Финансовые атрибуты" - там параметр "Округление". Меняем пробуем подгоняем. Помним, что погрешность в +- 1 копейка, для строки спецификации - СуперМаг Плюс умеет игнорировать. 
2. В документе Приходная накладная, есть функция "Заполнить ценами из УПД". Заполняем, пробуем в разных режимах округления.

Кто-то спросит, а нельзя ли заполнять Приходную накладную с теми же ошибками, что допустил поставщик? - НЕТ НЕЛЬЗЯ.

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

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

--------------------------------------------------------------------------

№6 - Почему при приеме УПД не находится товарная карточка?

Ошибка возникает из-за невозможности определить артикул по данным входящего пакета. Во входном пакете есть значение кода ОСУ: <OSUCODE>020481022303313837120</OSUCODE>. Этот код является штрихкодом формата GS1 в котором зашита информация о коде EAN13 – «4810223033138» и количестве «120». По коду EAN можно получить артикул. Но Супермаг не распознал последовательность символов 020481022303313837120 как корректный штрихкод и не получил из него код EAN13. Дело в том, что форматы штрихкодов очень разнообразны и по внешнему виду штрихкода не всегда можно определить его тип и, соответственно, выделить данные из штрихкода. Возможно неоднозначное определение типа. Поэтому в Супермаге имеется справочник «Штрихкоды» в котором должны быть описаны типы штрихкодов, используемых данным клиентом.

UI.XSD

UPD_c4a6a73a-c3e1-4e68-9e36-94084c53120d.BAK

В данной БД не был разрешен штрихкод типа GS1. Я добавил в справочник «Штрихкоды» такой штрихкод (ид. 41, «секционный GS1»). После этого приём УПД в БД BELPROD заработал.

Ошибка:

--------------------------------------------------------
2023.02.07 (вторник) 10:56:59 1.49.1.0 sp3 Sm.Post.Server
----- Прерывание работы программы -----
сообщение: "Ошибка приёма объекта «UI 0000000037», виртуальный пакет «UPD_c4a6a73a-c3e1-4e68-9e36-94084c53120d.SVP»"
исключение: Sm.Core.BaseException
источник: Sm.Post.DbLoader
----- Причина исключения, уровень вложения 1 -----
сообщение: "Невозможно записать в БД объект «UI, 0000000037», таблица «SMSPECWE»"
исключение: Sm.Core.BaseException
источник: Sm.Post.DbLoader
метод: Void WriteNewObject(Sm.Server.Database.OracleTransConn)
в Sm.Post.PostObjectAdapter.WriteNewObject(OracleTransConn transaction)
в Sm.Post.PostObjectDocumentAdapter.WriteNewObject(OracleTransConn transaction)
в Sm.Post.PostObjectAdapter.WriteObject(OracleTransConn connection, PostObject originalByType)
в Sm.Post.PostUploader.UploadObject(IVirtualPackageReader reader, PostObjectInfo postData, PostObject originalByType)
в Sm.Post.PostUploader.UploadObjects(IVirtualPackageReader reader, ICollection objs, LockMultiObjects locker, Dictionary`2 original, IUploadExceptionHandler xHandler, IPostReplyClient postReply, Progress progress, Boolean postReplySuccess)
----- Причина исключения, уровень вложения 2 -----
сообщение: "ORA-01400: невозможно вставить NULL в ("SUPERMAG"."SMSPECWE"."ARTICLE")"
исключение: Oracle.ManagedDataAccess.Client.OracleException
источник: Oracle Data Provider for .NET, Managed Driver
данные:
соединено с: База данных=BELPROD; Пользователь=Supermag
текст команды: Insert into Supermag.SMSPECWE(DOCID,DOCTYPE,SPECITEM,ARTICLE,COUNTRY,DISPLAYITEM,DISPLAYITEMUI,ITEMPRICE,ITEMPRICECUR,ITEMPRICENOTAX,QUANTITY,QUANTITYUI,SPECITEMUI,TOTALPRICE,TOTALPRICECUR,TOTALPRICENOTAX,VATRATE,VATSUM) values(:pDOCID,:pDOCTYPE,:pSPECITEM,:pARTICLE,:pCOUNTRY,:pDISPLAYITEM,:pDISPLAYITEMUI,:pITEMPRICE,:pITEMPRICECUR,:pITEMPRICENOTAX,:pQUANTITY,:pQUANTITYUI,:pSPECITEMUI,:pTOTALPRICE,:pTOTALPRICECUR,:pTOTALPRICENOTAX,:pVATRATE,:pVATSUM)
тип команды: Text
параметры: pDOCID=«0000000037»; pDOCTYPE=«UI»; pSPECITEM=«1»; pARTICLE=«»; pCOUNTRY=«Россия»; pDISPLAYITEM=«1»; pDISPLAYITEMUI=«»; pITEMPRICE=«501,00»; pITEMPRICECUR=«0»; pITEMPRICENOTAX=«455,45»; pQUANTITY=«736,710»; pQUANTITYUI=«»; pSPECITEMUI=«»; pTOTALPRICE=«369091,71»; pTOTALPRICECUR=«0»; pTOTALPRICENOTAX=«335537,92»; pVATRATE=«10»; pVATSUM=«33553,79»
метод: Int32 UpdatedRowStatusErrors(System.Data.Common.RowUpdatedEventArgs, BatchCommandInfo[], Int32)
в System.Data.Common.DbDataAdapter.UpdatedRowStatusErrors(RowUpdatedEventArgs rowUpdatedEvent, BatchCommandInfo[] batchCommands, Int32 commandCount)
в System.Data.Common.DbDataAdapter.UpdatedRowStatus(RowUpdatedEventArgs rowUpdatedEvent, BatchCommandInfo[] batchCommands, Int32 commandCount)
в System.Data.Common.DbDataAdapter.Update(DataRow[] dataRows, DataTableMapping tableMapping)
в Oracle.ManagedDataAccess.Client.OracleDataAdapter.Update(DataRow[] dataRows, DataTableMapping tableMapping)
в System.Data.Common.DbDataAdapter.UpdateFromDataTable(DataTable dataTable, DataTableMapping tableMapping)
в System.Data.Common.DbDataAdapter.Update(DataTable dataTable)
в Sm.Server.Database.OracleRunner.Update(OracleSafeAdapter dataAdapter, DataTable dataTable)
в Sm.Post.PostObjectAdapter.WriteNewObject(OracleTransConn transaction)