Pa’s Oracle based Utilities suites

PA’s ORACLE BASED UTILITIES SUITES

ORACLE «PA» базированный на портфеле энергоснабжения

Введение

Эволюция, так как это делает рынок

 

 

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

 

Несмотря на все происходящие нарушения в настоящее время, есть одна константа: это заказчик. Продолжать удовлетворять и совершенствовать качество обслуживания клиентов, напрямую влияет на вашу возможность сократить циклы оплат, конкурировать на нерегулируемых рынках, и максимизировать денежные потоки. Опыт «Pa» в понимании функционировании инженерных сетей и быть частью обеспечения энергоснабжения осуществляя обслуживания клиентов Oracle и биллинга систем комплексного энергоснабжения, чтобы быть успешным и без тревожным. Мы обеспечиваем энергоснабжения путем предоставления всесторонней поддержки системы для всех клиентов и выставления счетов ориентированных операций. Интегрированные архитектуры «Pa» (IA) в связке с EDM, CRM и биллинговой системой в одной платформе обеспечивает наиболее экономическую эффективность, полный модульный измеритель денежных средств, биллинга и CRM-система для удобного управления.

 

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

 

Многие процессы от поддержки измерения установки, обслуживания и биллинга, должны развиваться по улучшению и поддержке новых процессов от должности биллинга для предоплаченных вариантов или измерителя на денежные процессы. Мы привели в соответствие нашего биллинга и CRM систем для работы с нашими MDMS / системы EDM в интегрированный процесс для достижения модульности и софистики, необходимых для удовлетворения изменений в течение следующих 20 лет. Следующие архитектуры показывает различные системы интеграций для формирования общей Oracle энергоснабжений платформы приложений.

 

 

Список серверов и приложений в рамках наших предложений

 

Подстанция/ измерение уровня- измерения, коммуникационные модули и концентраторы данных

 

Сетевой уровень - AMI слой, там где он состоит

• Сбор данных слоев или AMI головных устройств

• Уровень управления сетью по Wasion

 

Application Layer – The System application layer that consists of

· The Meter Data Management System (MDMS) consisting of our

o Transaction Server/Rsview Manager

o Vantage Point EMI that consists of the The Meter Depository, The Pricing Servers, the Meter rules engine, the Reporting Engine and the Enterprise Database Storage Solutions based on Oracle Database.

· The Oracle Billing Systems fully integrated to our payment collection systems

· The Oracle Customer Care Systems or The Customer Relationship Management (CRM) System

· Заявительный уровень - слой системы приложений, состоящих из

· • управление данными измерительных приборов системы (MDMS), состоящий из наших:

· Протокольный сервер/ RSView менеджер

· Наблюдательный пункт EMI, который состоит из измерения коэффициента, цены Сервера, правил измерения двигателя, формирования отчетов, инициативных Решений хранения данных в основе базы данных Oracle.

· • Oracle билинг, полностью интегрированный в наший системе сбора платежей

· • Система Oracle обслуживания клиентов или управление взаимоотношениями с клиентами (CRM) системы

 

 

Система строения

 

 

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

Payment Systems

Системы оплат

С помощью нашей системы, она будет вести к

 

· • Повышение удовлетворенности клиентов

· • Повышение производительности

· • Снижение операционных расходов

· • Улучшить движения денежных средств

· • Создать новые источники дохода

· • соблюдение нормативных требований

· • Полное тестирование, разработка и производство тестирования всех сценариев

 

In short, we offer a fully compliant bid where some of the key drivers, as listed in the RFP will be fully met, they are:

Короче говоря, мы предлагаем полностью совместимые предложения где одним из ключевых факторов, будут полное выполнение предложений указанных в запросе, они таковы:

1. Мониторинг в режиме реального времени системы электроснабжения предприятия, связанные с 
 быстрым реагированием на сбои

2. Разрешить использование гибких тарифов, основываясь с категориями клиентов, объем 
 потребляемой электроэнергии, времени потребления в различные сезоны / времени суток и т.д.

3. Поощрение потребителей к энергосбережению через ответственное использование 
 электроэнергии и реализации энергосберегающих технологий

1. Управление энергией и потреблением энергии потребителям через 
 постоянный мониторинг их потребление, чтобы держаться в рамках своего
 утвержденного кредитного рейтинга

2. Повышение качества электроэнергии за счет снижения перегрузки системы способом 
 активного управления мощности и потребления энергии потребителями

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

10.Обеспечить точное выставление счетов, снижение времени сбора, повышения ликвидности 
 предсказуемости продаж

11 Улучшить систему поддержки коэффициента загрузки системы и снижение системный пиков, по способы сдвига загрузки с час пика на свободный час пик.

12.Обеспечить быстрый доступ к счетчику и устранения субъективного человеческого фактора 
 (фальсификации со счётчиком и мошенничества)

Это позволит значительно улучшить эффективность работы, сократить количество краж, улучшить безопасность и надежность, а также расширить выбор и обслуживание клиентов. Мы должны объяснить в деталях о том, как система может быть использована для достижения этой цели.

 

Обзор системы

Реализация строения энергоснабжения Oracle «PA» обеспечивает гибкость и точность необходимой для обработки сложных измерений и учета сценариев, в условиях постоянно меняющегося рынка в одной модульной и полностью компетентной платформы. Это настраивается к практическому любому использования рынка - газа, воды, электричества, розничном или оптовом рынке.

· • Управление интервалом данных

· • Контрольные списки для точных подсчетов

· • Автоматизированные подсчеты счета

· • Тестовые расчеты счетов

· • Обработка счета с начало до оконца

· • Счетчик на денежные процессы

Услуги на базе строения

 

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

торговая система CIS / CRM / может быть подключена через ядро базы данных для своих конкретных требований. Система имеет модульную структуру и поддерживает любые приложения, которые могут быть разработаны в течение стандартного ODBC соединения с базой данных с помощью менеджера транзакций. Некоторые процессы показаны ниже нашего решения

Broad-Based Pricing Support

Широкий ценообразования на основе поддержки

 

Our Utilities Billing Component allows you to easily adapt to the pricing structures and models required to win and retain customers. The application supports almost any pricing structure, including multiple account and contract hierarchies, currencies, commodities, collars, caps, and custom incentives and discounts. You can price your products any way necessary, including Standard Market Design (SMD), Locational Marginal Pricing (LMP), wholesale transmission billing, Open Access Transmission Tariffs (OATT), full ancillary services, Real-Time Pricing (RTP), and many more.

Наши билинг Компоненты энергоснабжения позволяет легко адаптироваться в соответствии с Тарифной структурой и моделью, необходимых для победы и удержания клиентов. Приложение поддерживает практически любую структуру ценообразования, в том числе несколько счетов и иерархии контрактов, валют, товаров, воротники, шапки, а также индивидуальных стимулов и скидок. Вы можете назначить цену на вашу продукцию любым необходимым способом, в том числе стандартным способом дизайна рынка(SMD), географическим предельным ценообразованием (LMP), оптовым биллингом передач, открытым доступом Тарифом на передачу (OATT), полная комплексом вспомогательных услуг, ценообразованием в реальном времени (RTP), и многим больше.

 

Low Total Cost of Ownership

Общие низкие цены на собственность

Ever-changing market conditions and regulations require frequent updates to billing applications. Oracle Utilities Billing Component separates the business rules from the application logic so changes can be made without costly, time-consuming modification of the source code.

 

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

PA’s implementation of Oracle based Utilities Billing Component provides all billing data in a single environment and allows users to correct, adjust, or reissue a bill.

Реализации PА компонентов Oracle энергоснабжения предоставляет все данные биллинга в единую среду и позволяет пользователям исправлять, корректировать или переиздавать счета.

 

Key Application Features

Data Manager

Data Manager is the tool you use to view, edit, and update records in the Oracle Utilities Meter Data Repository.

2.1.1 Администратор данных

Администратор данных является инструментом, используемого для просмотра, редактирования и обновления записей в депозитарии Oracle измерения Данные энергоснабжения.

Overview обзор

The Oracle Utilities Receivables Component performs a number of financial management and accounts receivable functions, allowing users to process billing, remittance, adjustments, transfers, writeoffs, refunds, and collections transactions. At the core of Oracle Utilities Receivables Component is the Financial Engine, which is primarily responsible for credit application and journaling. Transactions processed by the Financial Engine come from a number of modules, each specific to a financial management area. These modules are described in more detail in The Financial Engine and the Financial Management Modules below.

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

The system shall fully comply with all current legal requirements in the Republic of Uzbekistan, like, but not limited to, the following:

Система должна полностью соответствовать всем требований действующего законодательства Республики Узбекистан, но, не ограничиваясь, следующим:

 law on accounting Законом о бухгалтерском учете

 auditing law закон об аудиторской деятельности

 enterprise code код предприятия

 taxation code налоговый кодекс

 national accounting standards (NAS)

Национальных стандартов бухгалтерского учета (НСБУ)

 production cost regulations (PCR).


Правил себестоимости (ПЦР).

The Oracle Utilities Receivables Component also provides interfaces for other systems, including the Oracle Utilities Receivables Component User Interface, batch processes, an Event Management System (EMS)/Enterprise Application Integration (EAI) systems, a Web Server for all users, and other Oracle Utilities products, such as Oracle Utilities Billing Component or the Oracle Utilities Load Profiling and Settlement. These can trigger functions in one or more of the financial management modules, which in turn trigger the Financial Engine. Some of the key modulesa are

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

Invoicing выставление счета

· Invoicing processes will enable the grouping of bills by different criteria or companies to provide an invoice. This process will contain sending of invoices for services and service agreements, as well as invoices on behalf of other market roles comprising third-party services.

· Процессы Счетов позволят группировать счета по различным критериям или компаниям для предоставления счета-фактуры. Этот процесс будет содержать отправку счетов за услуги и сервисные соглашения, а также счета от имени других ролей рынка содержащие сторонних услуг.

· t not limited to, street lights (unmetered), insurances, consulting, energy management, energy-saving services, billing, auditing, load profiling, metering, fire protection, security services, and technical grid or service connection services shall be billable as well.

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

·

Account Data

Данные счета

 

In the following chapters, we attempt to demonstrate the features within the modules and how the system handle various information and the account data.

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

 

Account data is data that defines specific accounts and how transactions related to specific accounts are processed by Oracle Utilities Receivables Component and the Financial Engine. In this chapter, we shall attempt to demonstrate the handling of the data and hence the ability of our proposed platform in meeting the requirements of the specifications.

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

Account Table Счет таблице

The Account Table stores information about individual accounts. An account is the smallest billable entity in the system. Account entities typically are the root of virtually all activity in the system. An account receives a single bill statement from its billing operating company per billing period. Specific information relating to the Oracle Utilities Receivables Component stored in the

Таблица Счета хранит информацию индивидуальных счетов. Счетом является самым мало оплачиваемым объектом в системе. Счет лица обычно являются причиной практически все активности в системе. Пользователь может принимать в одном операторе счет от своего биллинга компании, работающей в расчетном периоде. Конкретная информация, относящаяся к дебиторской задолженности Компонент Oracle Utilities хранятся в

Account Table includes:

Таблица Счета включает в себя:

The Account’s Billing Address (from the Address Table), and Region (the region associated with the account, from the Region Table).Currency (the currency associated with the account, from the LS Currency table).

Платежные Счета адресов (из адресной таблицы) и регион (область, связанного с учетной записью, из региона таблицу). (Валюта связанна с учетной записью, из таблицы валют Ls).

Auto Payment Plan Table

2.2.7 Автоматическая оплата Таблица плана

 

Records in the Auto Payment Plan Table represent automatic payment plans for a given account for a specified time period. The existence of a current automatic payment plan for an account triggers an automatic draft of the specified automatic payment vendor account when the account is billed.

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

 

Write-Off Reason Table

Списание Причина таблице

The Write-Off Reason Table stores reasons for writing off an account, such as “Sold”, “Deceased”, “Bankrupt”, or “Bad Debt”. This is a lookup table used by the Account Table. If the “Write-Off Reason” column in the Account Table is populated, the Account’s Receivable Status should be “UNCOLLECTIBLE” or “UNREFUNDABLE”.

Причины аннулирования - такие, как, "Продано", "Усохло", "Банкрот", или "плохая кафедра". Это поисковые таблицы используется учетной записью, если колонка "причины аннулирования" акаунта заполнен. При аннулировании статус дебитный задолженности Счета должен быть "безнадежные" или "без возвратным".

 

Location Tables

Расположение таблиц

Location tables store information about the physical location of accounts and services. These include the Address, Premise, and Region tables.

Расположение таблиц хранящие данные о физическом расположении счетов и услуг. Они включают в себя адрес, помещения и регион таблиц.

 

Address Table

Таблица адресов

The Address Table stores physical address information. Records in this table are used in the Premise Table.

Таблица Адресов хранит информацию о физических адресах. Записи в этой таблице используются в таблице предпосылок.

 

Premise Table

Таблица предпосылок

The Premise Table stores the physical location of service. This is typically a building, or a location within a building.

Таблица предпосылок - хранит физическое местоположение службы. Как правило, это здания, или место внутри здания.

 

Region Table

Таблица регионов

 

The Region Table stores additional geographical attributes that are optionally used by accounts.

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

Service Tables

Таблицы сервисов

The Service tables describe the types of services provided to accounts, and the relationships among accounts, services, and locations.

Таблицы служб описывают виды услуг, предоставляемых для акаунтов, и отношения между счетами, услугами и местонахождениями.

Service Type Table

Типы таблиц сервиса

 

The Service Type Table is used to define all service-oriented businesses or commodities provided by the client operating company. Typical service types might include “Electric”, “Gas”, or “Cable”.

Типы Таблиц сервиса используется для определения всех сервис-ориентированных предприятий или товаров, предоставленных клиентом управляющей компании. Типичные виды обслуживания могут включать "Электричество", "Газ", или "Кабель".

 

Service Plan Table

Таблица План обслуживания

 

The Service Plan Table associates an account with a service type. An account may have several services active at any one time.

Служба сторонники планируют таблице запись с помощью услуги типа.Счет может иметь несколько активных услуг в любой момент времени.

 

Budget Tables

Таблицы Бюджетов

 

The Budget tables store data related to budget types and budget plans used by accounts.

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

 

Budget Type

Тип бюджета

 

Records in the Budget Type Table represent specific types of budget plans recognized by the application. The application uses budget types to determine how true-ups should be handled.

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

 

Budget Plan

Планирование бюджета

Records in the Budget Plan Table indicate that a given account is on a particular budget plan for a specific time period. Account Data

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

 

Meter Tables

Таблицы измерения

 

The Meter tables store usage data for scalar meters and the relationships between meters and accounts.

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

 

Meter Table

Таблица счетчика

 

Records in the Meter Table represent scalar meters in the system.

Записи в таблице счетчика, представляют измерения скалярного счетчика в системе.

 

Meter Read Table

Таблица измерения счетчика

 

Records in the Meter Read Table represent readings for a meter.

Записи в таблице измерения счетчика представляют показания для счетчика.

 

Meter History Table

Таблица историй измерений

 

Records in the Meter History Table represent snapshots of a meter’s use and related information. The Meter History Table associates meters with accounts.

Записи в таблице историй измерений представляют снимки использование счетчика и соответствующей информации. Таблица Истории измерений также помогает счетчикам акаунтов.

 

Transaction Data

Данные сделки

 

Transaction data is at the heart of the functionality of the Oracle Utilities Receivables Component and the Financial Engine. The following tables contain data concerning transactions and how those transactions are processed by the Financial Engine.

Данные транзакции в основе функциональности компонента Дебиторской задолженность «Oracle Utilities» и финансовой системы. В следующих таблицах приведены данные о сделках и как эти операции выполняются сотрудниками финансового двигателя.

 

Note: Records in the Transaction and Credit Application Tables should be created only by the Financial Engine.

Примечание: Запись в таблицах транзакций и Кредит Заявка должна быть создана только путем финансового двигателя.

 

Transaction ID Table

Таблица ID транзакции

 

The Transaction ID Table is used to configure different adjustment transaction types, refund transaction types, etc. This table is configurable and can accommodate various financial transaction IDs based on specific requirements. At least one Transaction ID is required for each Transaction Type (see Transaction Type Table, below).

Таблица ID транзакции используется для настройки различных типов операций регулировки, типы возврата сделки и т.д. Эта таблица настраивается и может использоваться для различных финансовых идентификаторы транзакций на основе конкретных требований. По меньшой мере нужна хоты бы одна транзакции ID для каждого типа операции (см. таблицу типа операции, ниже).

 

Transaction Type Table

Таблица Видов операций

 

Records in the Transaction Type Table represent different types of financial transactions recognized by the application, including the following

Записи в таблице Видов операций представляют собой различные виды финансовых операций, отраженных в заявке, в том числе следующие

 

 

Transaction Type code

Charge or Credit CHRGCRDT

Tax TAX

Installment INST

Statement STMT

Bill BILL

Payment PAYMENT

Deposit DEPOSIT

Deposit Interest DEPINT

Deposit Application DEPAPP

Adjustment ADJ

Refund RFND

Write-Off WRTOFF

Blance Transfer BALTXFR

 

Вид операции code

Расходы или кредит CHRGCRDT

Налог TAX

взнос INST

заявление STMT

счет BILL

оплата PAYMENT

депозит DEPOSIT

Проценты по вкладу DEPINT

Вклад DEPAPP

регулировка ADJ

возврат RFND

аннулирование WRTOFF

Передача Баланса BALTXFR

 

The following transaction have been effectively replaced by the Charge or Cridit(CHRGCRDT) transaction type, but are still available for user of previous versions of Oracle Utilities Rcceivables Component.

Следующие сделки были эффективно заменены расходным или кредитным (CHRGCRDT) типом сделки, но по-прежнему доступны для пользователей предыдущих версий компонентов Дебиторской задолженности. Oracle Utilities

 

Note:While additional Transaction Type can be added to the Transaction Type Table,types on the list provided should NOT deleted.

Примечание: В то время как дополнительный типы сделок могут быть добавлены в таблицу Типов действий, перечень видов то, она НЕ должна быть удалена.

 

LSTransaction Table

Таблица операций LS

 

Records in the LSTransaction Table represent financial transactions for an account. Each transaction represents a single unit of work that occurs at a point in time and that may be cancelled as a whole.

Записи в таблице, представляют финансовые операции по счету. Каждая операция представляет собой одну единицу работы, которая происходит в определенный момент времени, и что может быть отменена в целом.

 

Some of the specific data stored in the LSTransaction Table includes:

Некоторые конкретные данные, хранящиеся в Таблице операций, включает в себя:

 

· •Unique ID for the transaction,

· Уникальный идентификатор для сделки,

· Account ID (the parent account of the transaction),

· Номер счета (родительский счет сделки),

· Transaction Number (unique number for the transaction within the account),

· Сделка (уникальный номер для сделки в счет),

· Transaction ID and Type, and Time,

· ID транзакции и тип, и время,

· Revenue Month (the month to which any revenue associated with the transaction applies),

· Выручка за месяц (месяц, к которому применяется любой доход, связанный с транзакцией),

· User ID (user identification associated with the transaction),

· User ID (идентификатор пользователя, связанные с операцией),

· Application Method (indicates the credit application method)

· Применение метода (указывает метод кредитной заявки)

· Debit and Credit Account ID (optional debit and credit journal account IDs associated with this transaction),

· дебетовых и кредитных счета ID (дополнительно дебетовых и кредитных журнала идентификаторов учетных записей, связанных с этой сделки),

· Cost Center ID (optional cost center ID associated with this transaction),

· МВЗ ID (опция ID центром затрат, связанных с этой сделкой),

· Cancel Time, Cancel Revenue Month, Cancel User ID, Cancel Reason, Cancel Note, Cancel

· Время отмен, отмените Выручки месяца, отмена пользовательских ID, отмена причины, Примечание отмены,

· Debit Account ID, Cancel Credit Account ID, and Cancel Cost Center ID (time, revenue month, user ID, reason for the cancellation of the transaction, an optional note, optional debit/credit accounts, and cost center associated with the cancellation of the transaction),

· Дебетовые счета ID, Отменить Кредит ID счета и Отмена МВЗ ID (время, доходы месяца, идентификатор пользователя, причиной отмены сделки, дополнительные сведения, дополнительный дебетовых / кредитных счетов и затрат, связанных с отменой сделки),

· Charge or Credit (whether the transaction is a charge or credit),

· Расход или кредит (является ли сделка расходной или кредитной),

· Amount (the amount of the transaction, including the currency code for the transaction. In the case of a consumption charge, the amount is the amount of consumption),

· Сумма (сумма сделки, включая текущей код валютный сделки, В случае потребления расхода, суммы объема потребления),

· Balance (outstanding balance of charge or credit, including the currency code for the balance. The Balance is NULL if the amount does not affect the balance of the account, such as in the case of consumption charges, and deferred or budget service charges),

· Баланс (непогашенный остаток расхода или кредита, в том числе код валютного баланса, если сумма не влияет на баланс счета, Баланс будет, является NULL, например, в случае потребления расходов, и отложенные или бюджет плата за обслуживание),

· Billed Or Paid Date (date the charge was billed or credit paid),

· Представления счета или платных данных (дата расхода начисления или плата кредитом),

· Due Date (data that payment for a charge is due),

· Срок оплаты (данные, что оплата за расходы обезательно),

· Receivable Type (from the Receivable Type Table; see below),

· Тип задолженность (задолженность от типа таблицы, см. ниже),

· Charge Type (from the Charge Type Table; see below),

· Типы расходов (по данным таблицы Типов расходов, см. ниже),

· Rate Form, Rate Code, Operating Company, and Jurisdiction,

· Оцените форму, скорость кодирования, операционная компания, и юрисдикция,

· Statement Date (optional date of statement associated with the transaction),

· Дата выписки (опциональная дата заявления, связанные с операцией),

· Invoice ID and Date (optional ID and date of invoice associated with the transaction),

· • Счет ID и даты (необязательна ID и дата счета-фактуры, связанные с операцией),

· Cancel Statement Date (optional date of statement associated with cancelling the transaction),

· Отмена Даты выписки (опциональная дата заявления, связанная с отменой сделки),

· Cancel Invoice ID and Cancel Invoice Date (optional ID and date of invoice associated with cancelling the transaction),Bill Cycle Date (optional date of bill cycle associated with the transaction),

· Отменить Счет ID и Отмена Дата счета (опционально ID и дата счета-фактуры, связанные с отменой сделки), Цикл Биллинга даты (факультативно даты проекта цикла, связанная с операцией),

· Budget Bill True-up BDGTTRP

· Бюджет корректировочного BDGTTRP

· Installment Charge INSTCHG

· Рассрочка Charge INSTCHG

· Transaction Type CodeTransaction Data

· Типы кодов сделок

· Unique ID of associated Bill History Record (from the Bill History Table),

· Уникальный идентификатор связанного Историей счетов торговли (по данным таблицы История Билла),

· Unique ID of the subaccount from which the transaction originated (from the Account Table),

· Уникальный идентификатор субсчета, из которого была начата транзакция (со счета таблицу),

· Transferred To Transaction/Transferred From Transaction (for transactions that have been transferred from one account to another),

· Переведен в Сделку / перемещен из сделки (для сделок, которые были переданы с одного счета на другой),

· Payment, Service Plan, Budget Plan (associated Payment, Service/Budget Plan records),

· оплаты, тарифного плана, бюджетный план (вспомогательные оплаты, сервис / бюджетного учета плана),

· Installment Plan (installment plan associated with deferred charge or installment transactions),

· рассрочку (рассрочка, связанные с отложенным заряда или рассрочки сделок),

· Deposit (unique ID of deposit associated with Deposit, Deposit Interest, Deposit

· Депозит (уникальный идентификатор месторождения связи с депозитом, Проценты по вкладу, депозит

· Application, or Installment transactions),

· Применение или рассрочка сделок),

· Unique ID of batch in which the transaction was posted (from Batch Transaction table), and Unique ID of the batch in which the transaction was cancelled (from the Batch Transaction table).

· Уникальный идентификатор пакета, в котором была размещена сделки (от партии таблице проводок), а Уникальный идентификатор пакета, в котором сделка была отменена (из таблицы Смайлы).

 

Batch Transaction Table

Пакетная таблице транзакций

 

Records in this table represent a batch of transactions, each of which contains one or more transactions on multiple accounts. Data stored in the Batch Payment Table includes:

Записи в этой таблице, представляют партию операций, каждая из которых содержит одну или более операций на несколько учетных записей. Данные, хранящиеся в таблице оплаты пакетного включает в себя:

 

· A unique ID for the batch transaction,

· уникальный идентификатор для пакетной сделки,

 

· Transaction File (a unique pathname of the transaction file that includes this batch),

 

· Сделка файла (уникальный путь к сделке файл, который включает в себя эта партия),

 

· Batch No (unique number that identifies the batch within the transaction file),

 

· Нет Пакетный (уникальный номер, идентифицирующий партии в рамках транзакции файл),

 

· Date (the date on which the batch was received),

 

· дата (дата, на которую был получен партии),

 

· Number of Transactions (the total number of transactions in the batch),

 

· количество сделок (общее количество сделок в партии),

 

· Amount (the total amount of the batch transaction, including the currency code for the transactions), and

 

· Сумма (общая сумма сделки партии, в том числе код валюты для сделок), а

 

· Cancel Time (the date/time at which the batch was cancelled).

 

· Отмена времени (дата / время, в которое пакет был отменен).

 

Cancel Reason Table

Таблица причин Отмен

 

· Records in the Cancel Reason Table represent types of reasons for which a transaction might be cancelled.

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

Receivable Type Table

Таблица Типов Задолженности

 

Records in the Receivable Type Table represent types of receivables to which a financial transaction amount might apply. Typical receivable types might include “Disco Electric” or “State Tax”. Payments on an account are applied to receivable types based on the application priority of the receivable type (see the description of the Application Priority Table below). Each charge type (see below) is associated with one receivable type, but a given receivable type might be associated with more than one charge type.

Записи в таблице типа задолженности представляют виды дебиторской задолженности, к которым финансовая сумма сделки может применяться. Типичные виды задолженности может включать “Disco Electric” или "государственной пошлины". Платежи по счету применяются к получению типов основанных на применении приоритетов задолженность типа (см. описание таблицы приоритетной заявки ниже). Каждый тип расхода (см. ниже) связан с одним типом задолженность, но данный тип задолженности может быть связан с более чем одним типом расхода.

 

Charge Type Table

Таблица Типов расхода

 

Records in the Charge Type Table represent types of detailed charges generated during bill calculation. Charge types are defined to roll up to a receivable type when charges are posted as financial transactions.

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

 

Though most charge types are financial charges, records in the Charge Type Table can also represent consumption charges; that is, charges that are based on consumption rather than dollars.

Хотя большинство типов расходов - финансовые расходы, записи в таблице Типов расходов также может представлять потребления расходов, то есть расходы, которые основаны на потребление, а не долларе.

 

This is handled through the “Consumption?” and “Unit of Measure (UOM)” columns on the Charge Type Table. If the “Consumption?” value is “Yes”, the UOM column indicates the specific unit of measure for the consumption charge.

Это обрабатывается через "потребления?" И "Единица измерения (UOM)" столбцов на поле Типов расходов. Если "Потребление?" Значение "Да", колонка UOM указывает конкретную единицу измерения расхода заряда.

 

Credit Application Table

Таблица кредитной заявки

 

Each record in the Credit Application Table represents an application of a credit. The rules for how credits are applied to charges in the Financial Engine.

Каждая запись в таблице заявок на кредит представляет собой заявку прошению на кредит. Правила, по которым составляется заявки на кредит к издержкам в финансовом двигателе.

 

Application Priority Table

Таблица приоритетных заявок

Records in the Application Priority Table indicate the application priority of the associated receivable type. When credits are applied to charges with the same bill date, they will be applied in order of the application priority of the receivable type of any outstanding charges. The highest priority is 1. Receivable types with the same priority will be applied in the order in which they are retrieved from the database (by age, and then by transaction number). The Ignore Age field is used to specify whether age should be factored first in the application of credits. The default for this field is NULL, which means that all charges are ordered by age. Any receivable types without a corresponding application priority record will be applied last. More information concerning how the Application Priority Table interacts with the Financial Engine

 

 

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

Journaling Data

Ведение журнала данных

 

Journaling data defines how transactions are journaled both at the sub-ledger level and the general led