Как мне правильно расширить CustomerPaymentMethod?

#extension-methods #acumatica

#методы расширения #acumatica

Вопрос:

У меня есть кое-что, что запускается, но, конечно, не кажется правильным

Желание: Добавить одно поле в качестве расширения к коду метода CustomerPaymentMethod / Таблица приведена ниже

Проблема: Зачем мне нужно поле PaymentMethod ID и как мне заполнить его, если это необходимо?

Запускался без этого в таблице DB или Dac. Это загружает / работает при прямом доступе к AR303010 (способ оплаты клиента), но завершается ошибкой при SQL Join из AR303000 (AR Customer)

Если я просто добавляю в таблицу, то получаю «Невозможно вставить null в поле»

Если я добавляю в DAC, то продолжаю получать Null в базе данных (только в таблице расширений)

Итак, это выполняется, но, конечно, кажется неправильным. Я бы ожидал, что идентификатор PaymentMethod в таблице расширений не понадобится, поскольку в DAC из «CustomerPaymentMethod.cs» он НЕ отмечен «IsKey = true». Если мне это действительно нужно, то я надеюсь, что он заполняется автоматически как часть ключа

Таблица:

 Create Table XPMCustomerPaymentMethodExt (
    [CompanyID] [int] NOT NULL DEFAULT ((0)),
    [PMInstanceID] [int] NOT NULL,
    [BAccountID] [int] NOT NULL,
    [PaymentMethodID] [nvarchar](10) NULL,  /* Problem Child, if not here, fails to load customer screen (AR303000) */
    [CanConsolidate] [bit] NULL,
    [DeletedDatabaseRecord] [bit] NOT NULL DEFAULT ((0)),
 CONSTRAINT [PK_XPMCustomerPaymentMethodExt] PRIMARY KEY CLUSTERED 
(
    [CompanyID] ASC,
    [PMInstanceID] ASC
    )
    )
  

DAC:

 [PXTable(IsOptional = true)]
public class XPMCustomerPaymentMethodExt : PXCacheExtension<PX.Objects.AR.CustomerPaymentMethod>
{
    #region CanConsolidate
    public abstract class canConsolidate : PX.Data.IBqlField
    {
    }
    protected bool? _CanConsolidate = false;
    [PXDBBool]
    [PXDefault(false, PersistingCheck = PXPersistingCheck.Nothing)]
    [PXUIField(DisplayName = "Payments may be consolidated")]
    public virtual bool? CanConsolidate
    {
        get
        {
            return _CanConsolidate;
        }
        set
        {
            _CanConsolidate = value;
        }
    }
    #endregion

    #region PaymentMethodID
    public abstract class paymentMethodID : PX.Data.IBqlField
    {
    }
    protected string _PaymentMethodID; // = Base.PaymentMethodID;
    [PXMergeAttributes(Method = MergeMethod.Merge)]
    [PXDBString(10, IsUnicode = true)]
    //[PXDefault(typeof(CustomerPaymentMethod.paymentMethodID), PersistingCheck = PXPersistingCheck.Nothing)]
    //[PXFormula(typeof(Selector<CustomerPaymentMethod.pMInstanceID, CustomerPaymentMethod.paymentMethodID>))]
    public virtual String PaymentMethodID
    {
        get
        {
            //return Base.PaymentMethodID;
            return _PaymentMethodID;
        }
        set
        {
            // Base.PaymentMethodID = value;
            _PaymentMethodID = value;
        }
    }
    #endregion
}
  

Комментарии:

1. «Не удается вставить null в поле» — это именно то сообщение об ошибке, которое отображается? Я нахожу формулировку довольно странной и подозреваю, что сообщение об ошибке и трассировки отличаются.

2. SQL (Да, чисто тестовое окно, и да, известно о нарушениях целостности): Удалите xpmcustomerpaymentmethod, удалите CustomerPaymentMethod, закомментировал все поле PaymentMethod из расширения, удалены как PaymentMethod, так и PaymentMethod, Откройте AR303010 (способ оплаты клиента), введите данные напрямую, попробуйте сохранить данные, из набора данных SalesDemo: Клиент: Способ оплаты ABARTENDE: Процессор VISA по умолчанию, на Номер карты AUTDOTNET (ТЕСТ): 411111111111111111 Дата выхода: 21.12 Название: abc CVV: 123 Сохранение работает нормально. В таблице указано значение NULL для поля PaymentMethod id

3. Проблема от Customer, join включает ссылку на PaymentMethod ID (слишком длинный для комментария, получен из SQL Profiler): customerpaymentmethod info_customerpaymentmethod_xpmcustomerpaymentmethod text -> длинное имя СЛЕВА JOIN [xpmcustomerpaymentmethod text] [длинное имя] ON ( [длинное имя]. [CompanyID] = 2) И [длинное имя]. [DeletedDatabaseRecord] = 0 И [customerpaymentmethod info_customerpaymentmethod_customerpaymentmethod]. [PMInstanceID] = [длинное имя]. [PMInstanceID] И [CUSTOMERPAYMENTMETHOD info_customerpaymentmethod_customerpaymentmethod]. [PaymentMethod ID] = [длинное имя]. [PaymentMethod id] )

Ответ №1:

Это не типично для поиска PXMergeAttributes в расширении кэша. Самая близкая вещь к сообщению об ошибке "Unable to insert null into field" — это PXDefault PXPersistingCheck проверка.

Если у вас есть этот атрибут в поле, попытка сохранить null значение для этого поля приведет к ошибке, подобной той, о которой вы упомянули:

 [PXDefault(PersistingCheck = PXPersistingCheck.Nothing)]
  

Похоже, вы прокомментировали это, но я думаю, что это все еще там из-за PXMergeAttributes :

 [PXMergeAttributes(Method = MergeMethod.Merge)]
[PXDBString(10, IsUnicode = true)]
//[PXDefault(typeof(CustomerPaymentMethod.paymentMethodID), PersistingCheck = PXPersistingCheck.Nothing)]
//[PXFormula(typeof(Selector<CustomerPaymentMethod.pMInstanceID, CustomerPaymentMethod.paymentMethodID>))]
  

Если в Base DAC поле есть PXDefault атрибут, и вы добавляете его PXMergeAttributes , то это приводит к слиянию Base DAC и Extension DAC атрибутов, тем самым сохраняя PXDefault из Base DAC и обеспечивая, чтобы значение этого поля никогда не было нулевым, выдавая ошибки проверки.

Комментарии:

1. Пробовал без PXMerge, а только с PDBString. Желательно, чтобы поле было заполнено действительными данными, если они должны быть на расширении. Итак, работает ТОЛЬКО с PXDBString: Save, но null в поле DB

2. Какой смысл настраивать это поле? Поскольку ваша настройка не опубликована, сохраняются ли какие-либо проблемы с методом оплаты клиента?

3. Я думаю, что ваша проблема может быть связана с созданием случайных таблиц в базе данных. Вы создали новую таблицу XPMCUSTOMERPAYMENTMETHOD text, но объявили ее как расширение. При расширении DAC вы никогда не должны создавать новые таблицы с расширением, указывающим на него. Либо вы расширяете DAC и не создаете таблицу, либо вы создаете новую таблицу, и вместо того, чтобы наследовать DAC от PXCacheExtension, вы наследуете от PXCache, который используется для новых таблиц. Несоответствие обоих приводит к путанице в ORM и приводит к ошибке в SQL Join.

4. Таким образом, правильным решением было бы удалить таблицу XPMCUSTOMERPAYMENTMETHOD TEXT и удалить поле PaymentMethod id из расширения DAC. Если вы создали расширение с помощью редактора проекта настройки, оно автоматически сгенерирует скрипт базы данных (db script) для добавления столбца CanConsolidate. Если вы вручную создали расширение DAC, что, похоже, может иметь место, вам придется создать / сгенерировать соответствующий скрипт DB, чтобы добавить столбец CanConsolidate в таблицу CustomerPaymentMethod. Сценарии базы данных хранятся в проекте настройки.

5. «Какой смысл настраивать это поле?» VAR — это решение, и, насколько я понимаю, базовые таблицы не должны изменяться, чтобы предотвратить конфликты использования одного и того же имени среди разных переменных. Казалось бы, это не позволяет просто добавить его в качестве пользовательского поля. Да, я создал таблицу вручную в базе данных. Ссылка: «Acumatica-ISV-Solution-Test-Suite-November-2016.pdf», из этого «4) Любая устаревшая реализация скриптов таблиц, ЦАП и BLCS с использованием механизма настройки Acumatica, найденная в сборках расширений и / или project.xml в пакете настройки должны быть преобразованы классы расширения.»