Транзакций нет: Транзакции в .net — conspi.ru — Конспирология

Содержание

Руководство по SQL. Транзакции. – PROSELYTE

Транзакция является рабочей единицей работы с базой данных (далее – БД). Это последовательность операций, выполняемых в логическом порядке пользователем, либо программой, которая работает с БД.

Мы можем сказать, что транзакция – это распространение изменений в БД. Например, если мы создаём, изменяем или удаляем запись, то мы выполняем транзакцию. Крайне важно контролировать транзакции для гарантирования.

Основные концепции транзакции описываются аббревиатурой ACID – Atomicity, Consistency, Isolation, Durability (Атомарность, Согласованность, Изолированность, Долговечность).

Атомарность

Атомарность гарантирует, что любая транзакция будет зафиксирована только целиком (полностью). Если одна из операций в последовательности не будет выполнена, то вся транзакция будет отменена. Тут вводится понятие “отката” (rollback). Т.е. внутри последовательности будут происходить определённые изменения, но по итогу все они будут отменены (“откачены”) и по итогу пользователь не увидит никаких изменений.

Согласованность

Это означает, что любая завершённая транзакция (транзакция, которая достигла завершения транзакции – end of transaction) фиксирует только допустимые результаты. Например, при переводе денег с одного счёта на другой, в случае, если деньги ушли с одного счёта, они должны прийти на другой (это и есть согласованность системы). Списание и зачисление – это две разные транзакции, поэтому первая транзакция пройдёт без ошибок, а второй просто не будет. Именно поэтому крайне важно учитывать это свойство и поддерживать баланс системы.

Изолированность

Каждая транзакция должна быть изолирована от других, т.е. её результат не должен зависеть от выполнения других параллельных транзакций. На практике, изолированность крайне труднодостижимая вещь, поэтому здесь вводится понятие “уровни изолированности” (транзакция изолируется не полностью).

Долговечность

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

Управление транзакциями

Для управления транзакциями используются следующие команды:

COMMIT
Сохраняет изменения
ROLLBACK
Откатывает (отменяет) изменения
SAVEPOINT
Создаёт точку к которой группа транзакций может откатиться
SET TRANSACTION
Размещает имя транзакции.

Команды управление транзакциями используются только для DML команд: INSERT, UPDATE, DELETE. Они не могут быть использованы во время создания, изменения или удаления таблицы.

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


mysql> SET autocommit=0;

Предположим, что у нас есть таблица

developers, которая содержит следующие записи:


+----+-------------------+-----------+------------+--------+
| ID | NAME              | SPECIALTY | EXPERIENCE | SALARY |
+----+-------------------+-----------+------------+--------+
|  1 | Eugene Suleimanov | Java      |          2 |   2500 |
|  2 | Peter Romanenko   | Java      |          3 |   3500 |
|  3 | Andrei Komarov    | C++       |          3 |   2500 |
|  4 | Konstantin Geiko  | C#        |          2 |   2000 |
|  5 | Asya Suleimanova  | UI/UX     |          2 |   1800 |
|  7 | Ivan Ivanov       | C#        |          1 |    900 |
|  8 | Ludmila Geiko     | UI/UX     |          2 |   1800 |
+----+-------------------+-----------+------------+--------+

Удалим всех С++ разработчиков с помощью следующей команды:


mysql> DELETE FROM developers 
       WHERE SPECIALTY = 'C++';

mysql> COMMIT;

В результате выполнения данного запроса наша таблица будет содержать следующие записи:


+----+-------------------+-----------+------------+--------+
| ID | NAME              | SPECIALTY | EXPERIENCE | SALARY |
+----+-------------------+-----------+------------+--------+
|  1 | Eugene Suleimanov | Java      |          2 |   2500 |
|  2 | Peter Romanenko   | Java      |          3 |   3500 |
|  4 | Konstantin Geiko  | C#        |          2 |   2000 |
|  5 | Asya Suleimanova  | UI/UX     |          2 |   1800 |
|  7 | Ivan Ivanov       | C#        |          1 |    900 |
|  8 | Ludmila Geiko     | UI/UX     |          2 |   1800 |
+----+-------------------+-----------+------------+--------+

Теперь попробуем выполнить команду ROLLBACK:


mysql> ROLLBACK;

После выполнения данной команды наша таблица содержит следующие данные:


+----+-------------------+-----------+------------+--------+
| ID | NAME              | SPECIALTY | EXPERIENCE | SALARY |
+----+-------------------+-----------+------------+--------+
|  1 | Eugene Suleimanov | Java      |          2 |   2500 |
|  2 | Peter Romanenko   | Java      |          3 |   3500 |
|  3 | Andrei Komarov    | C++       |          3 |   2500 |
|  4 | Konstantin Geiko  | C#        |          2 |   2000 |
|  5 | Asya Suleimanova  | UI/UX     |          2 |   1800 |
|  6 | Ludmila Geiko     | UI/UX     |          2 |   1800 |
|  7 | Ivan Ivanov       | C#        |          1 |    900 |
+----+-------------------+-----------+------------+--------+

Как мы видим, запись С++ разработчика вновь в таблице.

Теперь постараемся разобраться с SAVEPOINT.
Для начала создадим точку сохранения, используя следующий запрос:


mysql> SAVEPOINT SP1;

Теперь выполним следующие запросы:


mysql> DELETE FROM developers WHERE ID = 7;
Query OK, 1 row affected (0.00 sec)

mysql> DELETE FROM developers WHERE ID = 6;
Query OK, 1 row affected (0.02 sec)

mysql> DELETE FROM developers WHERE ID = 5;
Query OK, 1 row affected (0.00 sec)

На данный момент наша таблица содержит следующие записи:


+----+-------------------+-----------+------------+--------+
| ID | NAME              | SPECIALTY | EXPERIENCE | SALARY |
+----+-------------------+-----------+------------+--------+
|  1 | Eugene Suleimanov | Java      |          2 |   2500 |
|  2 | Peter Romanenko   | Java      |          3 |   3500 |
|  3 | Andrei Komarov    | C++       |          3 |   2500 |
|  4 | Konstantin Geiko  | C#        |          2 |   2000 |
+----+-------------------+-----------+------------+--------+

Теперь мы вернёмся к точке сохранения SP1 с помощью команды:


mysql> ROLLBACK TO SP1;

После выполнения данного запроса, наша таблица будет хранить следующие записи:


+----+-------------------+-----------+------------+--------+
| ID | NAME              | SPECIALTY | EXPERIENCE | SALARY |
+----+-------------------+-----------+------------+--------+
|  1 | Eugene Suleimanov | Java      |          2 |   2500 |
|  2 | Peter Romanenko   | Java      |          3 |   3500 |
|  3 | Andrei Komarov    | C++       |          3 |   2500 |
|  4 | Konstantin Geiko  | C#        |          2 |   2000 |
|  5 | Asya Suleimanova  | UI/UX     |          2 |   1800 |
|  6 | Ludmila Geiko     | UI/UX     |          2 |   1800 |
|  7 | Ivan Ivanov       | C#        |          1 |    900 |
+----+-------------------+-----------+------------+--------+

Как мы видим, мы откатились к состоянию таблицы на момент создания точки сохранения SP1.

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


mysql> RELEASE SAVEPOINT SP1;

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


SET TRANSACTION READ ONLY;

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


SET TRANSACTION READ WRITE;

На этом мы заканчиваем изучение SQL транзакций.
В следующей статье мы рассмотрим функции даты.

Состояния транзакций, сборка мусора, интересующиеся и активные транзакции, sweep, примеры

Автор: Ann Harrison, Harbor

Перевод: Дмитрий Кузьменко
Оригинальный текст: oitoat.txt

Внимание!

Документ устарел, и хотя и содержит верные сведения, к прочтению не рекомендуется. Вместо него следует читать более современные и подробные статьи:

Пояснение для новичков – когда я говорю «транзакция», я имею в виду набор действий над базой данных, завершающихся Commit (подтверждением), Rollback (отменой), Prepare/Commit (подготовкой к подтверждению при two phase commit), и в том числе отсоединением от базы данных (обрыв связи, выключение клиентского компьютера и т. п.). Простое действие, как вставка, изменение или удаление записи, является оператором. Многие инструменты обеспечивают автоматическую поддержку транзакций, поэтому вам может быть неизвестно реальное количество транзакций, выполняемых при работе с данными. Но любой инструмент, производящий подтверждение (commit) на каждый оператор, не является лучшим выбором при импорте данных в БД.

Состояния транзакций

Транзакции могут находиться в четырех состояниях: активном, подтвержденном, limbo (подтвержденное но не зафиксированное по TPC) и отмененном.

Рассмотрим каждое состояние подробнее от самого сложного до самого простого:

Limbo: Транзакция, стартовавшая в режиме 2PC (two phase commit) вызовом процедуры Prepare. Эта транзакция может быть живой или нет. В любой момент такая транзакция может возобновиться и запросить подтверждение или отмену. Изменения, произведенные транзакцией, оставшейся в состоянии in limbo не могут быть приняты или игнорированы, соответственно они не могут быть удалены из БД.

Подтвержденное: Транзакция, которая завершила всю свою работу успешно

вызовом процедуры COMMIT
вызовом процедуры Rollback, но не произведя никаких изменений в БД.

В любом случае транзакция завершилась, и никогда не возобновится снова. Ее изменения теперь являются частью корректного состояния БД.

Отмененное: Транзакция, которая

завершилась процедурой ROLLBACK, т. е. запросила удалить все произведенные ею изменения из БД.
была помечена как Активная, но была обнаружена в неживом состоянии другой транзакцией, которая и помечает ее как отмененную.

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

Активное: Такое состояние имеет транзакция, которая

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

Как транзакции узнают о состояниях друг друга?

Состояние каждой транзакции хранится на Transaction Inventory Page (TIP). Единственным измененим БД при подтверждении транзакции является смена состояния этой транзакции с Активной на Подтвержденную. Когда транзакция вызывает процедуру отмены, она проверяет свой Update Flag – если он не установлен, то значит никаких изменений БД не было произведено, и нужно сделать Подтверждение (COMMIT) вместо Отмены (ROLLBACK).

Таким образом, отмена read-only транзакций не нагружает БД.

Каким образом транзакция переходит из Активного состояния в Отмененное если завершение происходит по сбою?

Это может произойти двумя путями.

Когда транзакция стартует, она делает блокировку собственного идентификатора транзакции. Если транзакция B пытается изменить или удалить запись, и обнаруживает что версия записи была создана транзакцией A, состояние в TIP которой Активное, транзакция B пытается вызвать конфликт блокировки идентификатора транзакции A. Если блокировка прошла, то транзакция B решает что A умерла, и меняет состояние A в TIP с Активного на Отмененное.
Когда транзакция стартует, она проверяет, можно ли установить полную блокировку на БД. Вообще транзакции при работе устанавливают разделяемые блокировки на БД. Следовательно, если транзакции удается поставить полную блокировку, то других транзакций нет, и она конвертирует все Активные состояни в TIP на Отмененные.

Мусор

Borland InterBase – СУБД с многоверсионностью данных. Когда запись изменяется, на страницу данных помещается ее копия с новыми значениями, однако старая запись остается. Старое значение называется «Back Version» (резервная версия), и является «историей отката» – если транзакця, изменившая запись, отменится, то старая версия записи тут как тут, на своем старом месте. Кроме этого, старые версии обеспечивают уровень изоляции Repeatable Read (воспроизводимое чтение) для длинных транзакций, которым на все время действия нужно видеть данные, существовавшие на момент начала такой транзакции.

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

Сборка мусора

Сборка мусора предотвращает наполнение интенсивно обновляемой БД ненужными старыми версиями записей.

Также уничтожаются версии записей, созданные отмененными транзакциями (Rolled Back). Каждая транзакция участвует в сборке мусора, в том числе и только читающие (read-only) транзакции.

Когда транзакция считывает запись, на самом верхнем уровне она получает эту запись (это относится к любой записи в БД). Двумя уровнями ниже, где-то в недрах сервера, Borland InterBase вытаскивает с диска набор версий. (Прим. пер.: поскольку версии записей хранятся на страницах данных, а механизм работы со страницами оптимизирован для работы с версиями, лишних операций кроме чтения страниц данных не происходит). Каждая версия имеет идентификатор создавшей ее транзакции. Первой в списке версий идет самая старая запись. В этот момент сервер имеет две задачи:

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

Существует и третий случай сборки мусора, который происходит в этот же момент. Кроме многоверсионных обновлений сервер использует и многоверсионные удаления. Когда транзакция удаляет запись, должна ли такая запись быть сразу удалена? Конечно нет! Удаление ведь может быть отменено. Поэтому вместо удаления записи, сервер выставляет метку удаления для старой версии записи. Если рано или поздно транзакция завершится, то вся запись вместе с меткой удаления и со своими предыдущими версиями станет мусором, и… (вы угадали!) когда-нибудь будет физически удалена.

Сборка мусора – итог

Сборка мусора является кооперативной. Это означает что все транзакции участвуют в ней (а не какая-то специально выделенная команда мусорщиков). Старые версии, удаленные записи, и отмененные изменения (и добавления) уничтожаются, когда транзакция пытается прочитать запись. (Прим. пер.: именно этим объясняются «странные» задержки в отработке запросов, например если вы выдали SELECT на таблице, из которой другой человек прямо перед вами удалил тысяч сто (100000) записей – вашей транзакции выпало «счастье» убирать мусор за предыдущей транзакцией).

Периодическое архивирование БД (backup) также производит сборку мусора, поскольку считывает абсолютно все записи из БД. (Прим. пер.: если в момент backup есть активные транзакции, то некоторый мусор после их завершени безусловно останется. если не хотите, чтобы backup собирал мусор, указывайте ключ -g в командной строке gbak).

Старейшая заинтересованная транзакция (OLDEST INTERESTING TRANSACTION)

Для того чтобы определить, какие версии записей могут быть удалены при сборке мусора, и какие изменения отменены и могут быть игнорированы, каждая транзакция имеет «маску» «заинтересованых» транзакций». Транзакция является «заинтересованной» по отношению к другой транзакции, если она конкурирует с ней – т. е. ее изменения не подтверждены, или она отменена (ее изменения должны игнорироваться или такая транзакция в состоянии limbo).

«Маска транзакций» – это снимок состояний всех транзакций от старейшей заинтересованной (OIT) до текущей. Размер снимка зависит от количества транзакций, стартовавших с момента старта старейшей заинтересованной транзакции. (Прим. пер.: собственно, здесь речь идет про TIP).

Старейшая активная транзакция (OLDEST ACTIVE TRANSACTION)

Примечание KDV. То, что Ann здесь именует как Oldest Active Transaction, на самом деле всегда было и есть Oldest Snapshot Transaction. См. www.ibase.ru/summary/, www.ibase.ru/ibtrans/. Звучит просто, но на самом деле не очень. Старейшая активная транзакция это не старейшая, живущая до настоящего момента. И не старайшая транзакция помеченная как Активная в TIP. Это старейшая транзакция, которая была активной, когда началась старейшая активная в текущий момент транзакция. Читать такие выражения довольно трудно, и я не помню как это было сделано, но это так, и это работает.

(Прим. пер.: следующий абзац переводите сами)

Any record version behind a committed version created by a transaction older than the oldest transaction active when the oldest transaction currently active started is garbage and will never be needed ever again. That’s pretty dense. Lets ignore the commit/rollback question briefly.

Простой случай: Я транзакция 20. Я нахожу запись созданную и подтвержденную транзакцией 15. Я изменяю ее и подтверждаю изменения. Вы – транзакция 25, и когда вы стартуете, вы являетесь единственной активной транзакцией. Вы читаете запись, и обнаруживаете что все активные транзакции (стартовавшие после вас) могут использовать версию записи, созданную мной, поэтому вы собираете мусор – оригинальную версию этой записи. В этом случае, право на сборку мусора (как старейшей активной транзакции) ваше.

Тяжелый случай: Вы продолжаете работу, изменяя данные тут и там. Другая транзакция, например 27, стартует. Вы являетесь старейшей заинтересованной. Та, 27-а транзакция, тоже может изменять данные тут и там, кроме тех записей, что вы модифицировали. 27-ая завершается и подтверждает изменения. Я стартую транзакцию 30. Вы также являетесь для меня старейшей заинтересованной транзакцией, и я не могу собирать мусор поскольку новые версии записей моложе вас. Я нахожу запись, созданную транзакцией 15, измененную транзакцией 20, и затем опять измененную транзакцией 27. Все три этих транзакции завершены и подтверждены, но я могу собрать мусор только в виде оригинальной версии записи, созданной транзакцией 15. Т. к. версия, созданная транзакцией 27, для меня стара, но не стара для вас, я решаю, что вы можете быть заинтересованы в этой версии записи.

Тяжелейший случай: Я транзакция 87, и когда я стартую, все транзакции до 75-ой завершились подтверждением, и все после 75-ой в настоящее время активны. Транзакция 77 модифицирует запись, созданную транзакцией 56. Я продолжаю читать версию 56-ой транзакции. Все нормально. Транзакция 77 завершается подтверждением. Вы – транзакция 95. Когда вы стартуете, я (87-ая) являюсь старейшей активной. Вы читаете запись созданную 56-ой и модифицированную 77-ой. Вы не можете собирать мусор для этой записи, поскольку я не могу читать записи созданные транзакцией после 74-ой (они еще не все завершены).

Надеюсь что вы теперь поняли, что понятие «старейшей активной» транзакции не так просто, как кажется.

Чистка (SWEEPING)

Чистка – это НЕ только сборка мусора. Основная работа, которую делает чистка, это перемещение старейшей заинтересованной транзакции «вверх», и уменьшение размера маски транзакций. Это делается переводом Отмененных транзакцией в Подтвержденные транзакции.

Вы скажете – «Она сошла с ума!»

Но это, действительно, основная работа чистки. Она удаляет все изменения, сделанные отмененными транзакциями, затем меняет их состояние на Подтвержденное. (Помните, было сказано, что отмененные read-only транзакции получают состояние подтвержденных. Удалите изменения, и можно считать что транзакция завершилась подтверждением).

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

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

Транзакции «in limbo»

Транзакции in limbo не могут быть переведены в другое состояние автоматически, будут приводить к постоянному включению чистки, и будут блокировать попытки изменения или удаления созданных ими версий. В любом случае Borland InterBase предоставляет хорошую диагностику при возникновении сбоев при two phase commit (утилита Server Manager).

Несколько примеров

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

Случай 1. Поток неконкурирующих транзакций

Транзакция 1 вставляет запись 1 и завершается подтверждением. Транзакция 2 стартует и становится одновременно старейшей активной и старейшей заинтересованной. Она вставляет запись 2 и завершается подтверждением. Транзакция 3 стартует, также становится старейшей активной и заинтересованной, вставляет свою запись и завершается подтверждением. В конце концов транзакция 1000000 стартует, опять становится старейшей активной и заинтересованной. Чистки не происходит (в общем-то чистить и нечего).

Случай 2. Готовится засада

Транзакция 1 стартует, оглядывается, и идет покурить. Транзакция 2 стартует, обнаруживает что 1-ая является старейшей активной и
заинтересованной, вставляет запись 1 и завершается подтверждением. Транзакция 3 стартует, обнаруживает что 1-ая все еще старейшая активна и заинтересованная, вставляет запись 2 и завершается подтверждением. В конце концов транзакция 1000001 стартует, видит что 1-ая все еще старейша активная и заинтересованная, т. е. разница между OAT и OIT равна 0, и завершается. Опять чистка не возникает.

Случай 3. Кто попадет в засаду?

Транзакция 1 стартует, что-то делает и идет покурить. Транзакция 2 стартует, обнаруживает что 1-ая является старейшей активной и заинтересованной, вставляет запись 1 и завершается. Транзакция 3 стартует, обнаруживает что 1-ая является старейшей активной и заинтересованной, вставляет запись 2 и завершается. Вдруг транзакция 1 отравляется никотином и умирает прямо в курительной комнате (допустим, не так страшно, а просто происходит обрыв связи между клиентским компьютером и сервером). Транзакция 15034 стартует (к счастью), получает возможность установить монопольную блокировку на файл базы данных, и устанавливает состояние транзакции 1 в Отмененное. Теперь старейшая заинтересованная имеет номер 1, но старейшая активная уже имеет номер 15034. Разница составляет 15033, поэтому уборка (sweep) не начинается. Через 4967 транзакций происходит уборка. После того как она закончена, идентификаторы старейшей заинтересованной и активной становятся равными, и следущий процесс уборки может начаться только если возникнет заинтересованная транзакция, перешедшая в неактивное состояние.

Случай 4. Смертельные качели

Предположим, что в нашей системе происходят парные транзакции, одна из которых завершается подтверждением, а другая откатом. Проблема в том, что транзакция, завершенная откатом, становится старейшей заинтересованной (OIT), а транзакция завершенная подтверждением – соответственно старейшей активной (OAT). Если после транзакции, завершившейся откатом, произойдет еще одна откатываемая транзакция, то она не станет OIT, поскольку предыдуща является «старейшей». Таким образом после даже единственной завершенной откатом транзакции, каждая последующая подтверждаемая транзакция будет увеличивать разницу между OIT и OAT. И через 20001 завершенных подтверждением транзакций действительно произойдет ЧИСТКА (SWEEP).

Итог

Итак, мы с вами выяснили к чему может привести вставка 1000000 записей с транзакцией на каждую запись. Может быть стоит выключить forced write (параметр БД в Server Manager)? Или настала пора запустить дефрагментацию диска?

Смена источника данных о транзакциях – Справочный центр OWOX

По умолчанию, данные Google Analytics, сохраненные в таблицах Google BigQuery, являются источником данных и о поведении пользователей, и о транзакциях.

Если вы хотите атрибутировать ценность товаров, купленных не на сайте, или учитывать исполняемость заказов, измените источник данных о транзакциях на странице модели на такой, в котором учтены эти события. Например, на данные из вашей СRM-системы.

О том, как импортировать данные о транзакциях в Google BigQuery, читайте в этой статье.

Как добавить данные о транзакциях из CRM

1. На экране модели нажмите Добавить источник:

2. Выберите Транзакции из CRM:

3. Выберите нужные вам проект BigQuery, набор данных и таблицу или представление:

Обратите внимание: Вы можете подключить только те таблицы с данными, которые находятся в той же локации, что и остальные источники модели атрибуции. Если данные, которые уже подключены к модели атрибуции находятся в локации EU, то вы не сможете подключить источник данных из CRM с локацией US и наоборот. Как перенести данные между наборами в разных локациях читайте здесь.

4. Нажмите Сохранить и заново рассчитайте модель.

Структура таблицы с данными о транзакциях

Структура таблицы или представления в Google BigQuery обязательно должна соответствовать определению схемы данных в этой статье.

Во время расчета, данные таблицы с транзакциями заменят данные Google Analytics в полях transaction_id, user_id и product_id. Учитываться будут только транзакции в статусе completed.

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

Как соотносятся User ID из Google Analytics и таблицы-источника

Обратите внимание, что если нет информации о User ID, то в поле user_id можно записывать Client ID.

Google Analytics		Транзакции из CRM		Как соотносятся
userId 1	transaction 1	userId 1	transaction 1	И пользователь, и транзакция совпадают. Действия перед покупкой будут соотнесены по этому пользователю.
userId 2	transaction 2	userId 3	transaction 2	Транзакция совпадает, а пользователь нет. Действия перед покупкой будут соотнесены по пользователю из первой по времени строки.
userId 4	transaction 3	null	transaction 3	Транзакция совпадает, пользователя в одном источнике нет. Действия перед покупкой будут соотнесены по пользователю из первой по времени строки. Если это окажется источник, где нет пользователя, в воронке будет отображаться только шаг покупки.
null	transaction 4	userId 4	transaction 4

Информация берется из первой по времени записи о транзакции среди двух источников (GA и CRM).

Эти схемы работают только если последний шаг воронки — CRM-транзакция. Если последний шаг — кастомное событие, то информация о конверсиях и событиях будет взята из таблицы с кастомными событиями.

Как соотносятся данные о транзакциях из Google Analytics и таблицы-источника

Транзакции есть в Google Analytics, но их нет в таблице с транзакциями
Ценность товаров из этих транзакций не будет распределена.
Транзакций нет в Google Analytics, но они есть в таблице с транзакциями
— Для таких транзакций будут созданы сессии покупок, с каналом (medium) 'offline'.
— Если у посетителя до офлайн-покупки были онлайн-сессии, то они получат ценность. Ценность за прохождение остальных шагов воронки между онлайн- и офлайн-взаимодействием получит сессия офлайн-покупки.
— Если онлайн-сессий не было, то 100% ценности получит сессия офлайн-покупки.
Транзакции есть и в Google Analytics, и в таблице с транзакциями
Вся информация о таких транзакциях и о сессиях, которые к ним привели, будет соответствовать данным Google Analytics.

PostgreSQL : Документация: 9.6: 13.2. Изоляция транзакций : Компания Postgres Professional

13.2. Изоляция транзакций

Стандарт SQL определяет четыре уровня изоляции транзакций. Наиболее строгий из них — сериализуемый, определяется одним абзацем, говорящем, что при параллельном выполнении несколько сериализуемых транзакций должны гарантированно выдавать такой же результат, как если бы они запускались по очереди в некотором порядке. Остальные три уровня определяются через описания особых явлений, которые возможны при взаимодействии параллельных транзакций, но не допускаются на определённом уровне. Как отмечается в стандарте, из определения сериализуемого уровня вытекает, что на этом уровне ни одно из этих явлений не возможно. (В самом деле — если эффект транзакций должен быть тем же, что и при их выполнении по очереди, как можно было бы увидеть особые явления, связанные с другими транзакциями?)

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

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

Уровни изоляции транзакций, описанные в стандарте SQL и реализованные в PostgreSQL, описываются в Таблице 13.1.

Таблица 13.1. Уровни изоляции транзакций

Уровень изоляции	«Грязное» чтение	Неповторяемое чтение	Фантомное чтение	Аномалия сериализации
Read uncommited (Чтение незафиксированных данных)	Допускается, но не в PG	Возможно	Возможно	Возможно
Read committed (Чтение зафиксированных данных)	Невозможно	Возможно	Возможно	Возможно
Repeatable read (Повторяемое чтение)	Невозможно	Невозможно	Допускается, но не в PG	Возможно
Serializable (Сериализуемость)	Невозможно	Невозможно	Невозможно	Невозможно

В PostgreSQL вы можете запросить любой из четырёх уровней изоляции транзакций, однако внутри реализованы только три различных уровня, то есть режим Read Uncommitted в PostgreSQL действует как Read Committed. Причина этого в том, что только так можно сопоставить стандартные уровни изоляции с реализованной в PostgreSQL архитектурой многоверсионного управления конкурентным доступом.

В этой таблице также показано, что реализация Repeatable Read в PostgreSQL не допускает фантомное чтение. Стандарт SQL допускает возможность более строгого поведения: четыре уровня изоляции определяют только, какие особые условия не должны наблюдаться, но не какие обязательно должны. Поведение имеющихся уровней изоляции подробно описывается в следующих подразделах.

Для выбора нужного уровня изоляции транзакций используется команда SET TRANSACTION.

Важно

Поведение некоторых функций и типов данных PostgreSQL в транзакциях подчиняется особым правилам. В частности, изменения последовательностей (и следовательно, счётчика в столбце, объявленному как serial) немедленно видны во всех остальных транзакциях и не откатываются назад, если выполнившая их транзакция прерывается. См. Раздел 9.16 и Подраздел 8.1.4.

13.2.1. Уровень изоляции Read Committed

Read Committed — уровень изоляции транзакции, выбираемый в PostgreSQL по умолчанию. В транзакции, работающей на этом уровне, запрос SELECT (без предложения FOR UPDATE/SHARE) видит только те данные, которые были зафиксированы до начала запроса; он никогда не увидит незафиксированных данных или изменений, внесённых в процессе выполнения запроса параллельными транзакциями. По сути запрос SELECT видит снимок базы данных в момент начала выполнения запроса. Однако SELECT видит результаты изменений, внесённых ранее в этой же транзакции, даже если они ещё не зафиксированы. Также заметьте, что два последовательных оператора SELECT могут видеть разные данные даже в рамках одной транзакции, если какие-то другие транзакции зафиксируют изменения после запуска первого SELECT, но до запуска второго.

Команды UPDATE, DELETE, SELECT FOR UPDATE и SELECT FOR SHARE ведут себя подобно SELECT при поиске целевых строк: они найдут только те целевые строки, которые были зафиксированы на момент начала команды. Однако к моменту, когда они будут найдены, эти целевые строки могут быть уже изменены (а также удалены или заблокированы) другой параллельной транзакцией. В этом случае запланированное изменение будет отложено до фиксирования или отката первой изменяющей данные транзакции (если она ещё выполняется). Если первая изменяющая транзакция откатывается, её результат отбрасывается и вторая изменяющая транзакция может продолжить изменение изначально полученной строки. Если первая транзакция зафиксировалась, но в результате удалила эту строку, вторая будет игнорировать её, а в противном случае попытается выполнить свою операцию с изменённой версией строки. Условие поиска в команде (предложение WHERE) вычисляется повторно для выяснения, соответствует ли по-прежнему этому условию изменённая версия строки. Если да, вторая изменяющая транзакция продолжают свою работу с изменённой версией строки. Применительно к командам SELECT FOR UPDATE и SELECT FOR SHARE это означает, что изменённая версия строки блокируется и возвращается клиенту.

Похожим образом ведёт себя INSERT с предложением ON CONFLICT DO UPDATE. В режиме Read Committed каждая строка, предлагаемая для добавления, будет либо вставлена, либо изменена. Если не возникнет несвязанных ошибок, гарантируется один из этих двух исходов. Если конфликт будет вызван другой транзакцией, результат которой ещё не видим для INSERT, предложение UPDATE подействует на эту строку, даже несмотря на то, что эта команда обычным образом может не видеть никакую версию этой строки.

При выполнении INSERT с предложением ON CONFLICT DO NOTHING строка может не добавиться в результате действия другой транзакции, эффект которой не виден в снимке команды INSERT. Это опять же имеет место только в режиме Read Committed.

Вследствие описанных выше правил, изменяющая команда может увидеть несогласованное состояние: она может видеть результаты параллельных команд, изменяющих те же строки, что пытается изменить она, но при этом она не видит результаты этих команд в других строках таблиц. Из-за этого поведения уровень Read Committed не подходит для команд со сложными условиями поиска; однако он вполне пригоден для простых случаев. Например, рассмотрим изменение баланса счёта в таких транзакциях:

BEGIN;
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 7534;
COMMIT;

Если две такие транзакции пытаются параллельно изменить баланс счёта 12345, мы, естественно, хотим, чтобы вторая транзакция работала с изменённой версией строки счёта. Так как каждая команда влияет только на определённую строку, если она будет видеть изменённую версию строки, это не приведёт к проблемам несогласованности.

В более сложных ситуациях уровень Read Committed может приводить к нежелательным результатам. Например, рассмотрим команду DELETE, работающую со строками, которые параллельно добавляет и удаляет из множества, определённого её условием, другая команда. Например, предположим, что website — таблица из двух строк, в которых website.hits равны 9 и 10:

BEGIN;
UPDATE website SET hits = hits + 1;
-- выполняется параллельно:  DELETE FROM website WHERE hits = 10;
COMMIT;

Команда DELETE не сделает ничего, даже несмотря на то, что строка с website.hits = 10 была в таблице и до, и после выполнения UPDATE. Это происходит потому, что строка со значением 9 до изменения пропускается, а когда команда UPDATE завершается и DELETE получает освободившуюся блокировку, строка с 10 теперь содержит 11, а это значение уже не соответствует условию.

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

Частичная изоляция транзакций, обеспечиваемая в режиме Read Committed, приемлема для множества приложений. Этот режим быстр и прост в использовании, однако он подходит не для всех случаев. Приложениям, выполняющим сложные запросы и изменения, могут потребоваться более строго согласованное представление данных, чем то, что даёт Read Committed.

13.2.2. Уровень изоляции Repeatable Read

В режиме Repeatable Read видны только те данные, которые были зафиксированы до начала транзакции, но не видны незафиксированные данные и изменения, произведённые другими транзакциями в процессе выполнения данной транзакции. (Однако запрос будет видеть эффекты предыдущих изменений в своей транзакции, несмотря на то, что они не зафиксированы.) Это самое строгое требование, которое стандарт SQL вводит для этого уровня изоляции, и при его выполнении предотвращаются все явления, описанные в Таблице 13.1, за исключением аномалий сериализации. Как было сказано выше, это не противоречит стандарту, так как он определяет только минимальную защиту, которая должна обеспечиваться на каждом уровне изоляции.

Этот уровень отличается от Read Committed тем, что запрос в транзакции данного уровня видит снимок данных на момент начала первого оператора в транзакции (не считая команд управления транзакциями), а не начала текущего оператора. Таким образом, последовательные команды SELECT в одной транзакции видят одни и те же данные; они не видят изменений, внесённых и зафиксированных другими транзакциями после начала их текущей транзакции.

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

ОШИБКА: не удалось сериализовать доступ из-за параллельного изменения

так как транзакция уровня Repeatable Read не может изменять или блокировать строки, изменённые другими транзакциями с момента её начала.

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

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

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

Для реализации уровня изоляции Repeatable Read применяется подход, который называется в академической литературе по базам данных и в других СУБД Изоляция снимков (Snapshot Isolation). По сравнению с системами, использующими традиционный метод блокировок, затрудняющий параллельное выполнение, при этом подходе наблюдается другое поведение и другая производительность. В некоторых СУБД могут существовать даже два отдельных уровня Repeatable Read и Snapshot Isolation с различным поведением. Допускаемые особые условия, представляющие отличия двух этих подходов, не были формализованы разработчиками теории БД до развития стандарта SQL и их рассмотрение выходит за рамки данного руководства. В полном объёме эта тема освещается в [berenson95].

Примечание

До версии 9.1 в PostgreSQL при запросе режима Serializable поведение системы в точности соответствовало вышеописанному. Таким образом, чтобы сейчас получить старое поведение Serializable, нужно запрашивать режим Repeatable Read.

13.2.3. Уровень изоляции Serializable

Уровень Serializable обеспечивает самую строгую изоляцию транзакций. На этом уровне моделируется последовательное выполнение всех зафиксированных транзакций, как если бы транзакции выполнялись одна за другой, последовательно, а не параллельно. Однако, как и на уровне Repeatable Read, на этом уровне приложения должны быть готовы повторять транзакции из-за сбоев сериализации. Фактически этот режим изоляции работает так же, как и Repeatable Read, только он дополнительно отслеживает условия, при которых результат параллельно выполняемых сериализуемых транзакций может не согласовываться с результатом этих же транзакций, выполняемых по очереди. Это отслеживание не привносит дополнительных препятствий для выполнения, кроме тех, что присущи режиму Repeatable Read, но тем не менее создаёт некоторую добавочную нагрузку, а при выявлении исключительных условий регистрируется аномалия сериализации и происходит сбой сериализации.

Например, рассмотрим таблицу mytab, изначально содержащую:

 class | value
-------+-------
     1 |    10
     1 |    20
     2 |   100
     2 |   200

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

SELECT SUM(value) FROM mytab WHERE class = 1;

а затем вставляет результат (30) в поле value в новую строку со значением class = 2. В это же время сериализуемая транзакция B вычисляет:

SELECT SUM(value) FROM mytab WHERE class = 2;

получает результат 300 и вставляет его в новую строку со значением class = 1. Затем обе транзакции пытаются зафиксироваться. Если бы одна из этих транзакций работала в режиме Repeatable Read, зафиксироваться могли бы обе; но так как полученный результат не соответствовал бы последовательному порядку, в режиме Serializable будет зафиксирована только одна транзакция, а вторая закончится откатом с сообщением:

ОШИБКА: не удалось сериализовать доступ из-за зависимостей чтения/записи между
  транзакциями

Это объясняется тем, что при выполнении A перед B транзакция B вычислила бы сумму 330, а не 300, а при выполнении в обратном порядке A вычислила бы другую сумму.

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

Для полной гарантии сериализуемости в PostgreSQL применяются предикатные блокировки, то есть блокировки, позволяющие определить, когда запись могла бы повлиять на результат предыдущего чтения параллельной транзакции, если бы эта запись выполнялась сначала. В PostgreSQL эти блокировки не приводят к фактическим блокировкам данных и, следовательно, никоим образом не могут повлечь взаимоблокировки транзакций. Они помогают выявить и отметить зависимости между параллельными транзакциями уровня Serializable, которые в определённых сочетаниях могут приводить к аномалиям сериализации. Транзакции Read Committed или Repeatable Read для обеспечения целостности данных, напротив, должны либо блокировать таблицы целиком, что помешает пользователям обращаться к этим таблицам, либо применять SELECT FOR UPDATE или SELECT FOR SHARE, что не только заблокирует другие транзакции, но и создаст дополнительную нагрузку на диск.

Предикатные блокировки в PostgreSQL, как и в большинстве других СУБД, устанавливаются для данных, фактически используемых в транзакции. Они отображаются в системном представлении pg_locks со значением mode равным SIReadLock. Какие именно блокировки будут затребованы при выполнении запроса, зависит от плана запроса, при этом детализированные блокировки (например, блокировки строк) могут объединяться в более общие (например, в блокировки страниц) в процессе транзакции для экономии памяти, расходуемой для отслеживания блокировок. Транзакция READ ONLY может даже освободить свои блокировки SIRead до завершения, если обнаруживается, что конфликты, которые могли бы привести к аномалии сериализации, исключены. На самом деле для транзакций READ ONLY этот факт чаще всего устанавливается в самом начале, так что они обходятся без предикатных блокировок. Если же вы явно запросите транзакцию SERIALIZABLE READ ONLY DEFERRABLE, она будет заблокирована до тех пор, пока не сможет установить этот факт. (Это единственный случай, когда транзакции уровня Serializable блокируются, а транзакции Repeatable Read — нет.) С другой стороны, блокировки SIRead часто должны сохраняться и после фиксирования транзакции, пока не будут завершены другие, наложившиеся на неё транзакции.

При правильном использовании сериализуемые транзакции могут значительно упростить разработку приложений. Гарантия того, что любое сочетание успешно зафиксированных параллельных сериализуемых транзакций даст тот же результат, что и последовательность этих транзакций, выполненных по очереди, означает, что если вы уверены, что единственная транзакция определённого содержания работает правильно, когда она запускается отдельно, вы можете быть уверены, что она будет работать так же правильно в любом сочетании сериализуемых транзакций, вне зависимости от того, что они делают, либо же она не будет зафиксирована успешно. При этом важно, чтобы в среде, где применяется этот подход, была реализована общая обработка сбоев сериализации (которые можно определить по значению SQLSTATE ‘40001’), так как заведомо определить, какие именно транзакции могут стать жертвами зависимостей чтения/записи и не будут зафиксированы для предотвращения аномалий сериализации, обычно очень сложно. Отслеживание зависимостей чтения-записи неизбежно создаёт дополнительную нагрузку, как и перезапуск транзакций, не зафиксированных из-за сбоев сериализации, но если на другую чашу весов положить нагрузку и блокирование, связанные с применением явных блокировок и SELECT FOR UPDATE или SELECT FOR SHARE, использовать сериализуемые транзакции в ряде случаев окажется выгоднее.

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

Применяя сериализуемые транзакции для управления конкурентным доступом, примите к сведению следующие рекомендации:

Объявляйте транзакции как READ ONLY, если это отражает их суть.
Управляйте числом активных подключений, при необходимости используя пул соединений. Это всегда полезно для увеличения производительности, но особенно важно это в загруженной системе с сериализуемыми транзакциями.
Заключайте в одну транзакцию не больше команд, чем необходимо для обеспечения целостности.
Не оставляйте соединения «простаивающими в транзакции» дольше, чем необходимо. Для автоматического отключения затянувшихся транзакций можно применить параметр конфигурации idle_in_transaction_session_timeout.
Исключите явные блокировки, SELECT FOR UPDATE и SELECT FOR SHARE там, где они не нужны благодаря защите, автоматически предоставляемой сериализуемыми транзакциями.
Когда система вынуждена объединять предикатные блокировки уровня страницы в одну предикатную блокировку уровня таблицы из-за нехватки памяти, может возрасти частота сбоев сериализации. Избежать этого можно, увеличив параметр max_pred_locks_per_transaction.
Последовательное сканирование всегда влечёт за собой предикатную блокировку на уровне таблицы. Это приводит к увеличению сбоев сериализации. В таких ситуациях бывает полезно склонить систему к использованию индексов, уменьшая random_page_cost и/или увеличивая cpu_tuple_cost. Однако тут важно сопоставить выигрыш от уменьшения числа откатов и перезапусков транзакций с проигрышем от возможного менее эффективного выполнения запросов.

Для реализации уровня изоляции Serializable применяется подход, который называется в академической литературе по базам данных Изоляция снимков (Snapshot Isolation), с дополнительными проверками на предмет аномалий сериализации. По сравнению с другими системами, использующими традиционный метод блокировок, при этом подходе наблюдается другое поведение и другая производительность. Подробнее это освещается в [ports12].

Управление транзакциями базы данных — Документация Django 1.9

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

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

atomic может использоваться как decorator:

from django.db import transaction

@transaction.atomic
def viewfunc(request):
    # This code executes inside a transaction.
    do_stuff()

и как context manager:

from django.db import transaction

def viewfunc(request):
    # This code executes in autocommit mode (Django's default).
    do_stuff()

    with transaction.atomic():
        # This code executes inside a transaction.
        do_more_stuff()

Обернув atomic в блок try/except, можно выполнить обработку ошибок:

from django.db import IntegrityError, transaction

@transaction.atomic
def viewfunc(request):
    create_parent()

    try:
        with transaction.atomic():
            generate_relationships()
    except IntegrityError:
        handle_exception()

    add_children()

В этом примере, вы можете выполнить запросы в add_children(), даже если generate_relationships() вызывал ошибку, также никуда не денутся изменения, выполненные в create_parent(). Обратите внимание, любые операции из generate_relationships() уже будут отменены, и при обработке ошибки в handle_exception() можно безопасно выполнять запросы к базе данных.

Избегайте перехвата ошибок в atomic!

При выходе из блока atomic Django определяет произошла ли ошибка, чтобы понять фиксировать изменения или отменить их. Если вы перехватите исключение и обработаете его в блоке atomic, вы можете скрыть от Django наличие проблемы. Это может привести к непредвиденному поведению.

В основном это относится к DatabaseError и классам наследникам, например IntegrityError. При таких ошибках транзакция будет сломана и Django выполнит отмену изменений после завершения блока atomic. Если вы попытаетесь выполнить запросы перед отменой изменений, Django вызовет исключение TransactionManagementError. Подобное поведение может произойти, если обработчик сигналов ORM вызовет исключение.

Правильный способ обработать ошибки базы данных – перехватить их за блоком atomic, как в примере выше. Если необходимо, добавьте дополнительный блок atomic для этого. У такого подхода есть свои преимущества: он явно разделяет операции, которые должны быть отменены при ошибке.

Если вы перехватите исключение, вызванное чистым SQL запросом, поведение Django будет зависеть от вашей базы данных.

Чтобы гарантировать атомарность, atomic блокирует некоторые функции. При попытке явно зафиксировать или отменить изменения, или изменить статус “autocommit” подключения к базе данных внутри блока atomic, будет вызвано исключение.

atomic принимает аргумент using, который обозначает имя базы данных с которой производится работа. Если этот аргумент не указан, то все действия идут относительно стандартной ("default") базы данных.

Код обработки транзакций в Django выполняет следующие действия:

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

Вы можете отменить создание точки сохранения для внутренних блоков, указав в аргументе savepoint False. При исключении Django выполнит отмену изменений при выходе из первого попавшегося блока, который создает точку сохранения, или же самого последнего блока. Атомарность внешних транзакций все также гарантирована. Такой подход должен использоваться только для оптимизации создания точек сохранения, т.к. нарушает обработку ошибок, как было описано выше.

Вы можете использовать atomic при выключенном “autocommit”. Он использует только точки сохранения, даже для самого внешнего блока.

Изменено в Django 1.8.5:

В предыдущих версиях самый внешний блок нельзя было объявить с savepoint=False при выключенном “autocommit”.

Транзакции, ACID, CAP | GeekBrains

Краткое введение в тему.

https://d2xzmw6cctk25h.cloudfront.net/post/676/og_cover_image/b8801415ef8996f3e4f5b448255abf4e

Это тоже база данных, но ручная

Здравствуйте!

Поговорим об базах данных. Сегодня транзакции, ACID и CAP-теорема — теория, которая важна для следующих статей.

Транзакции

Транзакция — это набор действий с данными, объединенный в логическую единицу. Она либо выполняется целиком, либо нет. Классический пример с операцией перевода денег со счета на счет:


Начать транзакцию

прочесть баланс на счету номер 5

уменьшить баланс на 10 денежных единиц

сохранить новый баланс счёта номер 5

прочесть баланс на счету номер 7

увеличить баланс на 10 денежных единиц

сохранить новый баланс счёта номер 7

Окончить транзакцию

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

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

Вот что может случиться при параллельном выполнении неизолированных транзакций.

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

Грязное чтение
Когда читаются данные, которые в этот момент изменяются транзакцией, а потом транзакция откатывается и данные исчезают.

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

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

Изоляция транзакций

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

Чтение неподтверждённых данных (read uncommitted)
Самый низкий уровень изоляции. Можно свободно читать незафиксированные изменения других транзакций, но запись идет строго последовательно. Таким образом, исключается только проблема потерянных обновлений: гарантируется, что в итоге в ячейку запишут нужное значение все транзакции по очереди.

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

Чтение подтверждённых данных (read committed)
Можно свободно читать все изменения своей транзакции и зафиксированные изменения чужих транзакций. Исключаются потерянные обновления и грязное чтение, остаются проблемы неповторяемых чтений и фантомов.

Повторяемое чтение (repeatable read)
Можно читать все изменения только своей транзации. Данные, измененные другими транзакциями, недоступны. Остается только проблема фантомных чтений.

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

ACID

Это набор из четырех требований к транзакционной системе, обеспечивающих максимально надежную и предсказуемую работу. Не все базы данных полностью реализуют ACID.

Атомарность (atomicity)
Атомарность гарантирует, что каждая транзакция будет выполнена полностью или не будет выполнена совсем. Не допускаются промежуточные состояния.

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

Изолированность (isolation)
Гарантия того, что параллельные транзакции не будут оказывать влияния на результат других транзакций. Мы разобрались с изоляцией выше.

Долговечность (durability)
Изменения, получившиеся в результате транзакции, должны оставаться сохраненными вне зависимости от каких-либо сбоев. Иначе говоря, если пользователь получил сигнал о завершении транзакции, он может быть уверен, что данные сохранены.

CAP-теорема

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

Согласованность данных (consistency)
Когда во всех узлах в каждый момент времени данные согласованы друг с другом, то есть не противоречат друг другу. Если в одном из узлов в ячейке базы данных есть данные, такие же данные есть на всех остальных узлах.

Доступность (availability)
Когда любой запрос может быть обработан системой, вне зависимости от ее состояния.

Устойчивость к разделению (partition tolerance)
Когда расщепление системы на несколько изолированных секций не приводит к некорректному отклику от каждой из секций: отвалилась сеть между двумя узлами, но каждый из них может корректно отвечать своим клиентам.

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

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

Сапёр / Статьи / База знаний / SAPLand — Мир решений SAP

В статье рассмотрены инструменты решения проблем, возникающих из-за неполноты прав пользователя при выполнении транзакции. В статье описано использование в качестве таких инструментов транзакция SU53 и процедура трассировки полномочий пользователя. С помощью трассировки полномочий удаётся определить недостающие права пользователя для выполнения транзакций и отследить, какие объекты полномочий проверяются при выполнении пользователем той или иной операции в системе.

Использование транзакции SU53

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

Для демонстрационных примеров я создам двух пользователей в системе:

SAP_ADMIN– спрофилемSAP_ALL;
SAP_USER – с ролью ZZSAP_LO_EMPLOYEE, которая является копией стандартной роли SAP_LO_EMPLOYEEи дополнительно с правами на запуск транзакцийSU53 и ME2L.

В своих примерах я буду использовать функциональность GuiXT, где в файле rsession.txtсодержится скрипт, выводящий имя пользователя в заголовок окна SAP (Примечание. Вход в систему осуществляется на русском языке):

TitlePrefix»*** User: &V[_user]***»

Благодаря этому скрипту, несмотря на то, что будет запущено несколько окон SAPот имени разных пользователей, легко будет определить, окно какого пользователя активно в данный момент (без обращения к информационному табло системы в правом нижнем углу экрана). Более того, будет удобнее использовать сочетание клавиш Alt+Tab, так как в строке заголовка окна выводится имя пользователя – «владельца экрана», к окну которого планируется перейти (Рис.1).

Рис.1 Использование файла rsession.txt надстройки GuiXTдля обозначения пользователя – «владельца экрана»

Рассмотрим Пример 1.

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

Исходное состояние полномочий пользователя SAP_USER приведено в Таблице 1.

Таблица 1. Исходное Состояние полномочий пользователя SAP_USER

Имеющиеся полномочия

1) Объекты полномочий стандартной роли SAP_LO_EMPLOYEE

2) запуск транзакции SU53

3) запуск транзакции ME2L

Неполнота полномочий

Нет полномочий на просмотр всех видов заказов на поставку по всем закупочным организациям и группам закупок;
нет полномочий на GUI-операции (нет прав на объект S_GUI).

Запустим транзакцию ME2L от имени пользователя SAP_USER (Рис.2) (как указано выше, у пользователя есть права только на запуск этой транзакции)

Рис.2 Запуск транзакции ME2Lот имени пользователя SAP_USER

Система выдаст следующее сообщение «У вас нет полномочий на транзакцию ME2L» (Рис.3).

Рис.3 Сообщение об отсутствующих полномочиях на транзакцию ME2L

В подобных случаях следует использовать транзакцию SU53, которая показывает, для какого именно объекта у пользователя отсутствуют полномочия. Для запуска используем команду /nSU53 (Рис.4), тем самым мы закрываем текущее окно и переходим к просмотру данных полномочий пользователя.

Рис.4 Запуск /nSU53 для получения анализа последней проверки полномочий системой

Мы увидим, что ошибка вызвана отсутствием полномочий на объект M_BEST_EKO (закупочная организация в заказе на поставку), а если быть точнее, то отсутствуют права на операцию 03 (просмотр) для объекта полномочий M_BEST_EKO (Рис.5).

Рис.5 Отсутствуют права на объект полномочий M_BEST_EKO

Для обеспечения пользователя необходимым объёмом полномочий можно или отредактировать имеющуюся у пользователя роль, или добавить пользователю дополнительную роль, обладающую соответствующим объёмом прав. Решение принимает по ситуации консультант направления совместно с консультантом по базису. Технология добавления и исправления полномочий и ролей – отдельная тема.

Добавим пользователю SAP_USER недостающие права для работы с объектом M_BEST_EKO: укажем в его роли объект полномочий M_BEST_EKOна операцию 03 (просмотр)со значением 1000. Таким образом, после выполненного редактирования роли пользователь сможет просматривать заказы на поставку с закупочной организацией 1000, но не сможет просматривать заказы на поставку с любыми другими закупочными организациями.

Рассмотрим Пример 2.

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

Текущее состояние полномочий пользователя SAP_USER приведено в Таблице 2.

Таблица 2. Текущее состояние полномочий пользователя SAP_USER.

Имеющиеся полномочия

1) Объекты полномочий стандартной роли SAP_LO_EMPLOYEE

2) запуск транзакции SU53

3) запуск транзакции ME2L.

4) Имеются полномочия на просмотр заказов на поставку по закупочной организации с кодом 1000.

Неполнота полномочий

Нет полномочий на просмотр всех видов документа заказа на поставку по всем закупочным организациям, отличным от 1000, и всем группам закупок;
нет полномочий на GUI-операции (нет прав на объект S_GUI).

Ещё раз запустим транзакцию ME2L, указав в качестве параметра запуска отчета закупочную организацию 1000.. Транзакция отобразит селекционный экран отчёта ME2L. Однако при попытке запуска отчёта система снова выдаст неинформативное сообщение «Из-за отсутствия полномочий список неполный» (Рис.6).

Рис.6 Попытка запуска выполнения отчета ME2L

Запустим транзакцию /nSU53. Получим информацию об отсутствии прав на операцию 08 (Просмотр документов изменений) для объекта M_BEST_BSA (Вид документа в заказе на поставка).

Рис.7 Отсутствие полномочия на объект M_BEST_BSA (Вид документа в заказе на поставку)

Добавим пользователю SAP_USER отсутствующие полномочия на работу с объектом M_BEST_BSA Вид документа в заказе на поставку) (для упрощения примера, я добавил пользователю права на все виды заказов на закупку и все операции с ними; на практике, полномочия назначаются, исходя из бизнес — сценария).

Рассмотрим Пример 3.

Покажем, что отслеживания недостающих полномочий с помощью транзакции SU53 – трудоёмкий процесс.

Текущее состояние полномочий пользователя SAP_USER приведено в Таблице 3.

Таблица 3. Текущее состояние полномочий пользователя SAP_USER

Имеющиеся полномочия

1) Объекты полномочий стандартной роли SAP_LO_EMPLOYEE

2) запуск транзакции SU53

3) запуск транзакции ME2L.

4) Имеются полномочия на просмотр всех видов документа заказа на поставку.

5) Имеются полномочия на просмотр заказов на поставку по закупочной организации с кодом 1000.

Неполнота полномочий

Нет полномочий на просмотр заказов на поставку по всем закупочным организациям, отличным от 1000, и всем группам закупок;
нет полномочий на GUI-операции (нет прав на объект S_GUI).

Выполним транзакцию ME2L ещё раз. Мы получим такое же сообщение об отсутствующих полномочий как в примере 2 (Рис.6), и снова запустим транзакцию /nSU53 . Теперь мы получим информацию о неполноте полномочий, но уже для другого объекта (Рис.8): M_BEST_EKG(группа закупок в заказе на поставку).

Рис.8 Отсутствуют права на объект полномочий M_BEST_EKG

Добавим пользователю SAP_USER соответствующие полномочия на объект M_BEST_EKG и попробуем выполнить отчёт ME2L ещё раз.

Итерацию запуска транзакции SU53 и коррекцию прав приходится повторять до тех пор, пока транзакция выполнится без сообщения об ошибке (отчёт выполнится без ошибок).Как видно, это – может быть весьма трудоёмким процессом.

Рассмотрим Пример 4.

Покажем, что при отсутствии полномочий на несколько объектов полномочий (а именно: отсутствие авторизации на просмотр заказов на закупку по закупочным организациям, отличным от 1000; отсутствие полномочий на GUI-операции) в транзакции SU53 будут показываться различные результаты в зависимости от формата вывода отчета.

Текущее состояние полномочий пользователя SAP_USER приведено в Таблице 4.

Таблица 4. Текущее состояние полномочий пользователя SAP_USER

Имеющиеся полномочия

1) Объекты полномочий стандартной роли SAP_LO_EMPLOYEE

2) запуск транзакции SU53

3) запуск транзакции ME2L.

4) Имеются полномочия на просмотр всех видов заказа на поставку.

5) Имеются полномочии на просмотр заказов на поставку со всем группами закупок.

6) Имеются полномочия на просмотр заказов на поставку по закупочной организации с кодом 1000.

Неполнота полномочия

Нет полномочий на просмотр заказов на поставку по всем закупочным организациям, отличным от 1000;

нет

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

Зарегистрироваться

У вас уже есть учетная запись?

Войти

КБ 860314 — транзакции не отображаются при открытии окна «Выбор банковской операции» в Microsoft Dynamics GP

Признаки

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

Причина

Эта проблема может возникнуть по любой из следующих причин:

Bank Reconciliation не зарегистрирован и не отмечен в окне регистрации.
Столбец согласованного номера (RECONUM) в таблице CM20200 не соответствует столбцу согласованного номера (RECONUM) в таблице CM20500.
Сделки уже сверены. Указанные транзакции теперь будут иметь значение 1, что означает, что транзакция уже согласована в Microsoft Dynamics GP. Следовательно, он больше не будет отображаться в окне «Выбор банковских операций», когда вы выполняете согласование, щелкнув Транзакции , указав Финансовый , щелкнув Согласование банковских выписок , а затем щелкнув Транзакции .
Записи находились в поврежденной сверки.
Порядок сортировки / сопоставление SQL не поддерживается в Microsoft Dynamics GP.

Разрешение

Чтобы решить эту проблему, воспользуйтесь одним из следующих способов:

МЕТОД 1:

Убедитесь, что выверка банка зарегистрирована и отмечена в окне регистрации.Для этого нажмите «Инструменты» в Microsoft Dynamics GP, выберите «Настройка», «Система» и нажмите «Регистрация». Прокрутите вниз в окне «Регистрация» и убедитесь, что в списке «Выверка банковского счета» установлен флажок.
МЕТОД 2:
Убедитесь, что транзакции еще не согласованы. Для этого выполните следующие действия:
1. Щелкните Inquiry , щелкните Financial , а затем щелкните Checkbook Register .
2. Введите или выберите соответствующий идентификатор чековой книжки.
3. В меню Просмотр щелкните по дате , а затем щелкните поле Из .
4. Задайте в поле From нулевое значение, а затем введите дату, которая будет использоваться в качестве даты окончания или даты окончания выписки по счету, в окне «Согласование банковских выписок».
5. Щелкните Повторно отобразите .
6. Щелкните Показать подробности , чтобы развернуть предоставленную информацию и убедиться, что в столбце Выверенное значение установлено значение Да, . Если транзакции еще не согласованы, а вы согласовываете, поле RECONUM из таблицы CM20500 может быть причиной того, что вы не видите никаких транзакций в окне «Выбор банковских транзакций».
  В Microsoft Dynamics GP конкретное значение RECONUM присваивается чековой книжке, когда информация вводится в окне «Согласование банковских выписок». Когда транзакция отмечена в окне «Выбор банковских транзакций» для этой чековой книжки, столбец RECONUM для этой транзакции в таблице CM20200 заполняется тем же значением RECONUM, что и в таблице CM20500. Если значения RECONUM в таблице CM20200 и таблице CM20500 не совпадают, то во время процесса согласования транзакции в окне «Выбор банковских транзакций» генерироваться не будут.
МЕТОД 3:
Убедитесь, что значение номера согласования совпадает между таблицами. Для этого выполните следующие действия:
1. Откройте SQL. Для этого выполните одно из следующих действий:
  - Для SQL Server 2005 откройте SQL Server Management Studio, щелкните «Новый запрос» и выберите нужную базу данных компании.
  - Для SQL Server 2008 откройте SQL Server Management Studio, щелкните «Новый запрос» и выберите нужную базу данных компании.
2. Убедитесь, что поле RECONUM имеет одинаковое значение в таблице CM20200 и таблице CM20500, выполнив следующие операторы SQL.
  SELECT MAX (RECONUM) FROM CM20200, WHERE CHEKBKID = 'XXX' SELECT MAX (RECONUM) FROM CM20500 WHERE CHEKBKID = 'XXX' SELECT RECONUM FROM CM20500 WHERE CHEKBKID = 'XXX' and RECON RECONUM) из CM20200, где CHEKBKID = 'XXX')
  Примечание. В этих инструкциях заполнитель XXX представляет идентификатор чековой книжки.
  Также запустите этот сценарий, чтобы увидеть, есть ли поврежденная или застрявшая разведка для идентификатора чековой книжки:
  выберите отдельный (RECONUM) из CM20200, где RECONUM отсутствует (выберите RECONUM из CM20500) и RECONUM <> '0.00000' и CHEKBKID = 'xxx'
  — где xxx — идентификатор нужной вам чековой книжки
3. Обратите внимание на результаты, полученные из запроса SQL на шаге 2.
4. Убедитесь, что верно следующее утверждение:
  Максимальное значение поля RECONUM из таблицы CM20200, которое сгенерировано из первого оператора из шага 2, на одно число меньше максимального значения поля RECONUM из таблицы CM20500, которое создается из второго оператора, описанного в тот же шаг.
5. Результат, полученный из третьего оператора, описанного в шаге 3, вернул пустые результаты.Если утверждения из предыдущего шага подтверждены как истинные, выполните следующий запрос SQL для дальнейшего решения проблемы:
  обновить CM20500 установить RECONUM = (выбрать MAX (RECONUM) из CM20200, где CHEKBKID = 'XXX') , где RECONUM = (выбрать MAX (RECONUM) из CM20500, где CHEKBKID = 'XXX')
  Примечание. В этом запросе заполнитель XXX представляет идентификатор чековой книжки.
Войдите в Microsoft Dynamics GP.Щелкните Транзакции , щелкните Финансовый , а затем щелкните Согласование банковских выписок . Выберите идентификатор чековой книжки, а затем щелкните Транзакции . Убедитесь, что транзакции теперь правильно отображаются в окне «Выбор банковских транзакций».
МЕТОД 4: Выполните проверку ссылок:
Сделайте резервную копию или сначала сделайте это в тестовой компании. В Microsoft Dynamics GP наведите указатель на «Обслуживание» и нажмите «Проверить ссылки».Выберите финансовую серию. В списке «Логические таблицы» выберите «Транзакция CM» и нажмите «Вставить», чтобы она отобразилась в разделе «Выбранные таблицы». Щелкните ОК. Просмотрите отчет журнала ошибок, и, если вы согласны с тем, что он сделал, вы можете сделать это в реальной компании.
Теперь проверьте, отображаются ли транзакции в окне «Выверка банка».
МЕТОД 5: Сортировка SQL:
Запустите приведенный ниже сценарий в SQL Server Management Studio, чтобы проверить порядок сортировки SQL и сопоставление SQL.В результатах найдите строку для компании, с которой вы работаете, и перетащите поле «Статус», чтобы вы могли прочитать данные в этом поле. Убедитесь, что Collation и SQLSortOrder являются поддерживаемой версией. (Порядок сортировки SQL должен быть 50 или 52). Окно может не отображаться, если вы не используете поддерживаемую версию.
SP_Helpdb

Устранение неполадок связанных учетных записей — Справка YNAB

Решение проблем с импортом может быть, мягко говоря, нервным.Выберите свое собственное импортное приключение ниже, и мы сможем вам помочь!
Не могу подключиться.
Я не могу импортировать транзакции.
Мои транзакции неверны.
У меня неправильные учетные записи.
Мне все еще нужна помощь.
Мои учетные данные не работают.
Ваш супруг, сосед и троюродный брат — все были рядом, когда вы еще раз вводили свой пароль…и опять. Мы знаем, что вы (и вся ваша большая семья) знаете, что ваши учетные данные верны, но, увы, не всегда в этом виноваты бабы.
шагов, которые нужно предпринять
1
Проверить YNAB страницу статуса для текущих распространенных проблем — возможно, мы уже занимаемся этим делом!
2
Убедитесь, что веб-адрес, который вы используете для входа в свой онлайн-банкинг, совпадает с веб-адресом, который вы видите в списке поиска финансовых учреждений YNAB. Для каждого финансового учреждения может быть несколько вариантов, поэтому обязательно выберите ближайший совпадающий веб-адрес.
3
Если вы используете менеджер паролей или копируете / вставляете, попробуйте ввести свои учетные данные вручную. Оба могут незаметно добавить лишние пробелы к вашему имени пользователя или паролю.
4
Если вы используете какой-либо тип контента / блокировщика рекламы, убедитесь, что Google reCAPTCHA находится в белом списке. Точно так же, если вы используете какое-либо расширение конфиденциальности, попробуйте добавить YNAB в качестве надежного сайта. Если из-за этого у вас косились глаза, не волнуйтесь — вы, вероятно, не используете ни то, ни другое. 😉
5
Убедитесь, что вы используете те же заглавные буквы и пробелы, что и в онлайн-банке, при вводе имени пользователя и пароля в YNAB.
6
В настоящее время наши партнеры по импорту не могут поддерживать пароли, содержащие амперсанд «&», вертикальную черту «|», тильду «~» или угловую скобку «<или>». Если вы обновите свой пароль, чтобы удалить эти символы, вы сможете подключиться.
7
Удалите соединение и повторно установите связь между учетными записями. Это часто путают с кнопкой «Отменить связь». Не волнуйтесь, вам не нужно будет удалять учетную запись — просто соединение — и вы не потеряете свои данные!
Проблема по-прежнему не устранена?
Если вы попробовали все это, но по-прежнему получаете сообщение о том, что ваши учетные данные недействительны, отправьте нам сообщение со следующим кодом:
Название вашего финансового учреждения
Тип учетной записи, которую вы хотите подключить (чековая, кредитная карта, инвестиционная, ссудная и т. Д.)
Интернет-адрес домашней страницы вашего финансового учреждения
Веб-адрес фактической страницы входа (если он отличается от указанного выше)
Снимок экрана со сводной страницей вашей учетной записи в онлайн-банке — веб-адрес этой страницы отображается в браузере, а вся важная личная информация заблокирована. (Инструкции для Mac или ПК)
В начало
Мне нужно переподключаться каждый день.
Если вас снова и снова просят ответить на секретные вопросы или ввести одноразовый пароль, это не потому, что вы играете главную роль в римейке «Дня сурка».Хорошая новость заключается в том, что это также не означает, что ваша связь разорвана — она просто требует доказательств за доказательством того, что вы — вы, а не плохой актер.
Контрольные вопросы
При установке нового соединения с финансовым учреждением вам может быть предложено часто отвечать на контрольные вопросы, пока все ответы не будут сохранены. Эти запросы должны прекратиться после того, как вы ответите на все свои вопросы безопасности.
Одноразовый пароль (OTP)
Некоторые финансовые учреждения часто требуют авторизации из-за того, как наша интеграция работает с безопасностью их сайтов.Это может измениться (то есть появляться и исчезать, казалось бы, из ниоткуда) по мере того, как учреждения делают обновления сайтов и безопасности.
Мы не можем изменить это требование, но, к счастью, вам не нужно авторизовать соединение каждый раз, когда он запрашивает — просматривайте запросы только тогда, когда будете готовы импортировать новые транзакции.
* Некоторые финансовые учреждения требуют ввода ваших учетных данных, а также контрольных вопросов или OTP.
В начало
Мое соединение заблокировано.
Если ваше соединение заблокировано, это обычно означает, что на вашем счете в онлайн-банке есть предупреждение или сообщение, которое необходимо подтвердить. Это может быть что угодно, от небольших уведомлений (Привет! Мы скучаем по вам) до запросов на безбумажное выставление счетов (Как деревья? Мы тоже!).
шагов, которые нужно предпринять
1
Войдите в свое финансовое учреждение и посмотрите, есть ли любых действий, которые вы можете предпринять. Проверьте все, от начальных уведомлений до непрочитанных сообщений! Многие финансовые учреждения показывают предупреждения только на паутина версия их онлайн-банкинга, поэтому обычно лучше проверять с компьютера, а не с мобильного устройства.
2
Вернитесь в YNAB и попробуйте подключиться снова!
Проблема по-прежнему не устранена?
Если ваше соединение по-прежнему заблокировано, отправьте нам сообщение со следующим кодом:
Название вашего финансового учреждения
Тип учетной записи, которую вы хотите подключить (чековая, кредитная карта, инвестиционная, ссуда и т. Д.)
Вы входили в свой сайт онлайн-банкинга с компьютера, чтобы искать и подтверждать какие-либо предупреждения?
Снимок экрана со сводной страницей вашей учетной записи в онлайн-банке — веб-адрес этой страницы отображается в браузере, а вся важная личная информация заблокирована.(Инструкции для Mac или ПК)
В начало
Я не получаю свои пароли.
Когда ваше соединение запрашивает код, который вы никогда не получаете, это может показаться плохой шуткой. Настолько плохо, что это может быть так же просто, как обновление вашей контактной информации. Шутки над тобой, отправитель кода. 😏
шагов, которые нужно предпринять
1
Войдите на веб-сайт своего финансового учреждения и убедитесь, что вся ваша контактная информация указана и актуальна.
2
Попытайтесь снова подключиться к YNAB и убедитесь, что предоставленная нами контактная информация совпадает с информацией на веб-сайте учреждения.
3
Попробуйте удалить и заново добавить соединение (не учетную запись!) В YNAB.
4
Попробуйте каждый вариант (звонок, текст, голубь), чтобы понять, удастся ли вам лучше с одним из них.
4
Используете ли вы стороннее приложение для аутентификации (например, Authy или Google Authenticator) в своем финансовом учреждении? Мы не можем поддерживать их, поэтому вам придется переключать методы аутентификации для подключения.
Проблема по-прежнему не устранена?
Если вы по-прежнему не получаете коды доступа, отправьте нам сообщение со следующим кодом:
Название вашего финансового учреждения
Тип учетной записи, которую вы хотите подключить (чековая, кредитная карта, инвестиционная, ссуда и т. Д.)
Интернет-адрес домашней страницы вашего финансового учреждения
Дата и время (включая часовой пояс) вашей последней попытки
В начало
Мое финансовое учреждение обновило свой веб-сайт.
Наконец, у вашего финансового учреждения появился новый яркий веб-сайт, которым вы можете похвастаться своим друзьям. Но твоя связь в YNAB? Не ахти. Мы все любим хороший макияж, но это означает, что соответствующие изменения необходимо внести и с нашей стороны.
Если у вас возникли проблемы с подключением или импортом транзакций после того, как ваше финансовое учреждение изменило свой веб-адрес, обновило свой веб-сайт или изменило требования безопасности, отправьте нам сообщение со следующим кодом:
Название вашего финансового учреждения
Интернет-адрес домашней страницы вашего финансового учреждения
Веб-адрес фактической страницы входа (если он отличается от указанного выше)
Описание внесенных обновлений и возникшей у вас проблемы.
В начало
Моего финансового учреждения нет в списке.
Не все финансовые учреждения доступны для прямого импорта. (Извините, преданные кредитного союза Under-Your-Mattress!) Мы также не поддерживаем организации за пределами США и Канады. Тем не менее, мы надеемся, что вы найдете момент, чтобы предложить тот, который ищете, прямо в приложении.
Когда мы будем готовы расширить нашу поддержку на большее количество финансовых учреждений, мы будем знать, где искать.
Но …
Не останавливайтесь на достигнутом!
Мы предлагаем другие варианты ввода транзакции, чтобы помочь вам обновлять свой бюджет.И помните, лучше всего сразу вводить транзакции. Таким образом, ваш бюджет всегда актуален в режиме реального времени!
В начало
Мое финансовое учреждение поддерживает протокол OAuth.
Пользователи прямого импорта, радуйтесь! Некоторые финансовые учреждения поддерживают протокол OAuth, который позволяет вам войти в свой банк напрямую, а не через наших провайдеров. Вы будете знать, что ваш банк поддерживает OAuth, потому что вы будете перенаправлены непосредственно в свой банк для входа в систему, и как только вы выполните все инструкции, вы вернетесь в YNAB.Повышенная стабильность соединения и повышенная безопасность? Что может быть лучше!
Если у вас возникнут какие-либо проблемы с подключением OAuth, применимы все шаги по устранению неполадок, перечисленные на этой странице, поэтому попробуйте их и отправьте нам сообщение, если у вас все еще есть проблемы.
Импорт транзакций остановлен.
Ваша учетная запись работала нормально, и вы назначали и одобряли транзакции, как чемпион, как вдруг … все это резко остановилось.
Финансовые учреждения такие же, как и все мы — им нравится подтягивать ноги в выходные и праздничные дни. В некоторых случаях для импорта транзакции может потребоваться до трех дней , но если это было дольше, пора вникнуть.
шагов, которые нужно предпринять
1
Проверьте нашу страницу статуса — возможно, мы уже работаем над этим!
2
Попробуйте удалить соединение. Это часто путают с кнопкой «Отменить связь».Не волнуйтесь, вам не нужно будет удалять учетную запись — просто соединение — и вы не потеряете свои данные! При повторном добавлении подключения обязательно:
Проблема по-прежнему не устранена?
Если транзакции по-прежнему не импортируются, отправьте нам сообщение со следующим кодом:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.)
Ник аккаунта в YNAB
Дата последней импортированной транзакции
Дата, получатель и сумма нескольких транзакций, которые не были импортированы, но были очищены от вашего счета в онлайн-банке более 3 дней назад
В начало
Сделки ни разу не импортировали.
Новые транзакции обычно становятся доступными для импорта в течение 24 часов после их подтверждения вашим финансовым учреждением. Когда вы стремитесь к бюджету (как и все мы!), Это может показаться вечностью. ⏱
Выходные, праздничные дни и время могут повлиять на время ожидания транзакций, поэтому в некоторых случаях для импорта транзакции может потребоваться до трех дней . Если это было дольше, пора копать.
шагов, которые нужно предпринять
1
Убедитесь, что вы вошли в систему под учетными данными основного владельца учетной записи.Если вы не уверены, вы можете удалите соединение и создайте его снова.
2
Найдите галочку справа от имени учетной записи. Если вы его не видите, свяжите свой аккаунт с подключением. Просто наведите указатель мыши на имя учетной записи и щелкните значок «Изменить» слева от имени. Затем нажмите «Связать учетную запись» в появившемся окне.
3
Отметьте дату вашего начального баланса. Сделки, которые выполняются до этого, не будут импортированы.Если хотите, можете отредактируйте дату вашего начального баланса, но не забудьте также отрегулировать сам баланс.
4
Это инвестиционный или ссудный счет? Да!
Проблема по-прежнему не устранена?
Если транзакции по-прежнему не импортируются, отправьте нам сообщение со следующим кодом:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.)
Ник аккаунта в YNAB
Дата, получатель и сумма нескольких транзакций, которые не были импортированы, но были очищены от вашего счета в онлайн-банке более 3 дней назад
В начало
Некоторые транзакции отсутствуют.
Если большинство транзакций импортируются, но вам не хватает определенного временного интервала (или некоторых случайных транзакций), это может произойти по нескольким причинам. Прежде чем поместить недостающие транзакции в пакет из-под молока, следует учесть несколько моментов.
шагов, которые нужно предпринять
1
Считайте вашу активность входа в систему . В большинстве случаев YNAB может извлечь недостающие транзакции, чтобы заполнить пробел, но если с момента последнего входа в YNAB прошло некоторое время, и в это время произошла ошибка соединения, которая не была разрешена, мы может гарантировать только то, что он будет принимать транзакции за предыдущие 15 дней.Если вы считаете, что это ваша ситуация, воспользуйтесь нашим другие параметры ввода транзакции, чтобы добавить их.
2
Отметьте дату вашей последней согласованной транзакции. YNAB не будет импортировать транзакции, датированные тремя или более днями до этой даты. Если пропущенные вами транзакции старше указанной, вам необходимо добавить их вручную.
3
Отметьте дату начального остатка на счете. Транзакции, которые выполняются до этого, не будут импортированы автоматически.Если хотите, можете отредактируйте дату вашего начального баланса. Не забудьте также отрегулировать сам баланс!
Проблема по-прежнему не устранена?
Если транзакции постоянно отсутствуют в будущем импорте, отправьте нам сообщение со следующим текстом:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.)
Ник аккаунта в YNAB
Дата, сумма и получатель нескольких недавних отсутствующих транзакций
В начало
Транзакции задерживаются.
Задержки никогда не приносят удовольствия — особенно для нас, энтузиастов бюджета! 🤓 Но есть несколько переменных, отображение которых может занять немного больше времени.
Выходные / праздничные дни: Большинство финансовых учреждений не работают в нерабочие дни. Если транзакция не будет подтверждена до конца рабочего дня в пятницу, она обычно не будет импортирована до начала следующей недели.
Время выпуска: Ваше финансовое учреждение может удерживать транзакцию как «ожидающую» в течение дня или двух, даже если транзакция отображается в вашей учетной записи онлайн.Обычно они доступны для импорта в течение 24 часов с момента очистки.
Время импорта: Не существует универсального стандарта между финансовыми учреждениями в отношении того, когда транзакции будут проводиться. Это означает, что на момент последней проверки транзакции могли быть недоступны для нас.
Время загрузки: При первом доступе к YNAB может пройти до пяти минут, прежде чем новые транзакции появятся рядом с полем «Импорт».
Задержки до трех дней не являются чем-то необычным, но если вы обнаружите, что постоянно ждете дольше указанного срока для импорта очищенных транзакций, это может означать, что есть проблема с нашей интеграцией (или ваше финансовое учреждение может уникальный график релизов).
шагов, которые нужно предпринять
В следующий раз, когда вы ждете подтвержденных транзакций для импорта:
1
Войдите в YNAB и подождите три-пять минут. Мы знаем, что это может показаться вечностью, но на то, чтобы раскрутить все крутящиеся колеса, может уйти немного времени.
2
Не отменяйте связь с аккаунтом и не удаляйте соединение.
3
Если в учетной записи есть транзакции, доступные для импорта, вы увидите точку уведомления рядом с именем учетной записи.Если рядом с аккаунтом нет точки, попробуйте обновить страницу в браузере.
Проблема по-прежнему не устранена?
Если прошло более трех дней, а транзакции по-прежнему недоступны для импорта, отправьте нам сообщение со следующим текстом:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.)
Ник аккаунта в YNAB
Дата, сумма и получатель нескольких транзакций, которые не были импортированы, но погашены более 3 дней назад
В начало
Инвестиционные / кредитные операции не импортируются.
Может быть, вы только что закончили настройку своего первого IRA после прочтения курса YNAB Invest Like A Pro. Или вы работаете над выплатой ссуды по DMC Delorean 1982 года. Вы добавляете аккаунт в свой бюджет, подключаете его к подключению, а потом … радиомолчание.
Данные для инвестиционных и ссудных счетов обрабатываются иначе, чем с обычных расходных / сберегательных счетов, поэтому ожидается, что они будут импортированы неправильно или не будут импортированы вообще.
Лучший способ управлять этими учетными записями в вашем бюджете — это несвязанных учетных записей отслеживания .Таким образом, они не влияют на ваш дневной бюджет, но вы все равно можете следить за своим собственным капиталом. 📈
шагов, которые нужно предпринять
1
Настройте учетную запись как несвязанную Учетная запись отслеживания, если вы еще этого не сделали (Отслеживание> Актив или Ответственность).
2
Создать Запланированная транзакция для отображения регулярных взносов или платежей. Или, если у вас много активности в аккаунте, дайте Файловый импорт попробуйте в веб-приложении!
3
Обновляйте баланс так часто, как хотите.
В начало
Мне заменили кредитную карту.
Иногда вашу кредитную карту меняют в лучшую сторону (обновите меня, пожалуйста!) Или в худшую сторону (нет, спасибо, мошенничество!). Мы надеемся, что это было к лучшему, но в любом случае может потребоваться до 48 часов , чтобы он отобразился под соединением.
После того, как ваша учетная запись появится, вам нужно будет отменить связь с исходной картой и повторно привязать к новой, чтобы ввести свои транзакции.
шагов, которые нужно предпринять
1
Наведите указатель мыши на свой счет кредитной карты на левой боковой панели.
2
Щелкните значок редактирования и выберите Отменить связь с учетной записью .
3
Снова наведите указатель мыши на учетную запись и выберите Связать учетную запись .
4
Выберите существующее соединение с этим финансовым учреждением.
5
Найдите новую карту (может потребоваться прокрутка!) И выберите ее. Это свяжет его с вашей существующей учетной записью и снова запустит импорт.
Проблема по-прежнему не устранена?
См. «Мне не хватает учетной записи», «Транзакции прекратили импорт» или отправьте нам сообщение.
В начало
Транзакции импортируются более одного раза.
Дубликаты могут возникать по ряду причин, но обычно это означает что-то об изменении транзакций — например, дата, получатель платежа («Отмена транзакции QPC», кто угодно? 🧐), памятка, сумма, форматирование и т. Д. немного липкой калитки, поэтому их трудно обнаружить и полностью устранить, как бы мы ни старались!
шагов, которые нужно предпринять
1
Чтобы удалить дубликаты из вашего реестра, выберите транзакции, которые вам не нужны, используя флажки слева (или верхний флажок, чтобы выбрать их все сразу), и выберите «Правка»> «Отклонить».
2
После того, как они удалены, сверьте свои счета, чтобы убедиться, что ваш баланс на правильном уровне.
3
После этого попробуйте удалить и заново добавить соединение. Это может привести к тому, что ваши соединения будут подключены к другому источнику данных, что может решить проблему в будущем.
Проблема по-прежнему не устранена?
Хотя повторяющиеся транзакции могут иногда импортироваться, если каждая транзакция дублируется при каждом новом импорте, отправьте нам сообщение со следующим:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.))
Ник аккаунта в YNAB
Скриншот того, как эти транзакции выглядят в YNAB. (Инструкции для Mac или ПК)
Снимок экрана, на котором показано, как они выглядят в вашем реальном счете в онлайн-банке с заблокированной любой важной личной информацией. (Инструкции для Mac или ПК)
Если вы заметили, что они все еще «ожидают рассмотрения» в вашем финансовом учреждении.
В начало
Неправильный начальный баланс.
На твоей отметке! Получить набор!… подождите, это не так. Время от времени начальные балансы отображаются неправильно, но, к счастью, их легко исправить, и это не свидетельствует о каких-либо проблемах в будущем.
шагов, которые нужно предпринять
После привязки аккаунта вы можете редактировать начальный баланс прямо в реестре аккаунта.
Проблема по-прежнему не устранена?
Если при продвижении вперед по-прежнему возникают проблемы, отправьте нам сообщение со следующим кодом:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.))
Ник аккаунта в YNAB
Описание и / или снимок экрана проблемы. (Инструкции для Mac или ПК)
В начало
Суммы операции сторнируются.
Если входящие и исходящие потоки импортируются неправильно, вы можете подумать, что ваш работодатель взимает с вас плату за работу на них, или ваш продуктовый магазин платит вам за то, чтобы делать покупки там. 🤔
(Если эти транзакции относятся к учетной записи ссуды или инвестиционной учетной записи , данные с этих учетных записей обрабатываются иначе, чем со счетов с обычными расходами, поэтому ожидается, что они будут импортированы неправильно или не будут импортированы вообще.)
Когда суммы транзакций реверсируются для счетов регулярных расходов / сбережений, есть две возможные причины; финансовое учреждение неожиданно форматирует свои данные или возникла проблема с интеграцией.
шагов, которые нужно предпринять
1
Во-первых, давайте очистим ваш аккаунт. Если вы еще этого не сделали, смените суммы вручную и сверьте их, чтобы убедиться, что ваш баланс находится на должном уровне.
2
Если транзакций много, откатывать их одну за другой может быть утомительно.Для этого мы рекомендуем удалить транзакции и вместо этого использовать файловый импорт. Вы можете поменять местами столбцы притока / оттока одним щелчком мыши!
3
Теперь, чтобы сузить причину этих обратных сумм, загрузите файл из своего финансового учреждения (QFX или CSV), если вы еще этого не сделали, и откройте его. Или, если хотите, можете отправить его нам для проверки. 🔎
4
Если вы видите отрицательные символы «-» перед вашими притоками и / или нет отрицательного символа перед вашими оттоками, это означает, что есть проблема с данными.Свяжитесь с вашим финансовым учреждением напрямую, чтобы сообщить им об этом. Это поможет решить проблему в корне!
Проблема по-прежнему не устранена?
Если данные финансового учреждения форматируются правильно, отправьте нам сообщение со следующим кодом:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.)
Ник аккаунта в YNAB
Скриншот того, как эти транзакции выглядят в YNAB.(Инструкции для Mac или ПК)
Снимок экрана, на котором показано, как они выглядят в вашем реальном счете в онлайн-банке с заблокированной любой важной личной информацией. (Инструкции для Mac или ПК)
Файл QFX или CSV, загруженный из вашего финансового учреждения
В начало
Получатели ошибаются.
Мы делаем все возможное, чтобы доставить точных получателей, но есть несколько уникальных сценариев, в которых они могут пойти не так. Вы можете обнаружить, что полезная информация удалена, включено слишком много информации или, возможно, получатель платежа указан неверно — о боже! 😰
шагов, которые нужно предпринять
Чтобы сузить круг происходящих событий, перейдите в раздел «Управление получателями» и посмотрите, нужно ли вам комбинировать, переименовывать или редактировать правило получателей платежей.Вы также можете редактировать получателя платежа прямо в вашем реестре.
Проблема по-прежнему не устранена?
Если переименование получателя не является причиной и вы постоянно видите неверных получателей, отправьте нам сообщение со следующим текстом, чтобы мы могли сузить его еще больше:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.)
Ник аккаунта в YNAB
Снимок экрана, на котором ваше финансовое учреждение отображает получателя платежа.(Инструкции для Mac или ПК)
То, что вы ожидали, что получатель будет импортировать как
Что вы видите после «Импортировано как …» при наведении курсора на получателя платежа (в веб-версии YNAB)
Что вы видите, когда щелкаете получателя и раскрываете сведения об импорте банка (в веб-версии YNAB)
В начало
Транзакции импортируются в неправильную учетную запись.
Запутались, потому что ваши ежедневные покупки капучино, которые должны быть на вашем текущем счете, импортируются на вашу кредитную карту хозяйственного магазина? Когда это происходит, есть две возможные причины: учетная запись связана неправильно или возникла проблема с интеграцией.
шагов, которые нужно предпринять
1
Во-первых, давайте перенесем ваши транзакции на свои места. Если вы уже импортировали транзакции в неправильную учетную запись, вы можете переместить их из одной в другую, выбрав их, перейдя в меню «Правка» вверху реестра и выбрав Переместить в учетную запись . Таким образом, вам не нужно удалять и вводить их заново!
2
Теперь давайте убедимся, что ваши аккаунты правильно связаны.Вы можете проверить это, наведя курсор на имя своей учетной записи на левой боковой панели, щелкнув значок редактирования и подтвердив учетную запись, с которой она связана.
3
Если это неверно, выберите Отменить связь с учетной записью и повторно свяжите ее с правильной учетной записью.
Проблема по-прежнему не устранена?
Если ваши учетные записи связаны правильно, но импортируются в неправильную учетную запись, отправьте нам сообщение со следующим текстом:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.))
Псевдоним счета, на котором проводятся транзакции
Псевдоним аккаунта, на котором они появились некорректно
Дата, получатель и сумма по крайней мере одной транзакции, которая импортирована неправильно
В начало
Неверная сумма транзакции.
Транзакции могут быть импортированы с неправильной суммой по разным причинам, и все они заставляют нас ломать голову. В большинстве случаев это разовая задача, и вы можете получить квадрат, отредактировав сумму прямо в реестре аккаунта.
Если новые транзакции продолжают импорт с неправильными суммами, отправьте нам сообщение со следующим:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.)
Ник аккаунта в YNAB
Скриншот того, как эти транзакции выглядят в YNAB. (Инструкции для Mac или ПК)
Снимок экрана, на котором показано, как они выглядят в вашем реальном счете в онлайн-банке с заблокированной любой важной личной информацией.(Инструкции для Mac или ПК)
В начало
Незавершенные транзакции не отображаются.
Каждое финансовое учреждение обрабатывает ожидающие транзакции по-разному, поэтому, как бы нам ни хотелось, чтобы ожидающие транзакции безупречно отображались в вашем реестре учетной записи, они могут не отображаться! Некоторые банки просто не поддерживают ожидающие транзакции, и это самая частая причина их отсутствия.
Однако мы все равно хотели бы выяснить причину отсутствия незавершенных транзакций.Итак, если в вашем банке есть ожидающие транзакции, но они не отображаются в вашем реестре, отправьте нам сообщение со следующим кодом:
Название финансового учреждения
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.)
Ник аккаунта в YNAB
Снимок экрана с ожидающими транзакциями в вашей учетной записи онлайн-банкинга с заблокированной любой важной личной информацией. (Инструкции для Mac или ПК)
В начало
Я не вижу аккаунтов.
Подключение без учетных записей — это как бюджет без категорий. Нет. Полезный. Если вы успешно подключились к своему финансовому учреждению, но по-прежнему не видите никаких учетных записей, выполните следующие действия.
шагов, которые нужно предпринять
1
Убедитесь, что вы выбрали правильный вариант подключения. Некоторые финансовые учреждения имеют несколько порталов в зависимости от типа учетной записи. Например, если вы добавляете кредитную карту, Discover Card — лучший вариант, чем Discover Bank.Чтобы убедиться, что вы выбрали нужный, выполните поиск в нашем списке, выбрав «Добавить учетную запись»> «Связанная», введите название своего финансового учреждения и просмотрите все возможные варианты.
2
Правильный вариант, но счетов по-прежнему нет? Обновите соединение, удалив и снова добавив его.
3
Дайте ему немного времени. ⏲ Аккаунты могут появиться в течение 24-48 часов после повторного добавления подключения.
Проблема по-прежнему не устранена?
Если ваши аккаунты не появятся в течение 48 часов, отправьте нам сообщение со следующим текстом:
Название финансового учреждения
Веб-адрес, который вы используете для входа в систему напрямую в этом учреждении
Тип счетов, которые вы ожидаете увидеть (чековые, инвестиционные и т. Д.)
Снимок экрана со сводной страницей вашей учетной записи в онлайн-банке — веб-адрес этой страницы отображается в браузере, а вся важная личная информация заблокирована. (Инструкции для Mac или ПК)
В начало
Мне не хватает аккаунта.
Мы знаем, что вы взволнованы — вы открыли блестящую новую учетную запись, нетерпеливо открыли свой бюджет и … его нигде не видно. 😔
Если прошло 48 часов с тех пор, как эта учетная запись появилась на веб-сайте вашего финансового учреждения (вы знаете, потому что вы в курсе всего этого!), Но ее все еще нет в YNAB, вот шаги, которые необходимо предпринять:
шагов, которые нужно предпринять
1
Финансовые учреждения могут иметь несколько порталов в зависимости от типа учетной записи, которую вы ищете.Например, если вы добавляете кредитную карту, Discover Card — лучший вариант, чем Discover Bank.
Чтобы убедиться, что вы выбрали нужный, выполните поиск в нашем списке, выбрав Добавить учетную запись> Связанный , введите название своего финансового учреждения и просмотрите все возможные варианты.
2
Если вы подтвердили, что выбрали правильный вариант, попробуйте снова связать учетную запись в окне инкогнито / приватного просмотра. Инструкции для Safari, Chrome, Firefox, Edge.
3
Обновите соединение с помощью удаление и повторное добавление. Не волнуйтесь — вы не потеряете данные о транзакциях!
4
Дайте ему немного больше времени. ⏲ Мы видели, что на появление аккаунтов уходит более 48 часов, но не должно занимать больше 72 часов.
Проблема по-прежнему не устранена?
Если с момента удаления и повторного добавления соединения прошло 48 часов, а аккаунт по-прежнему не отображается, отправьте нам сообщение со следующим текстом:
Название вашего финансового учреждения
Название отсутствующей учетной записи, в точности так, как указано в вашем финансовом учреждении.
Тип счета (текущий, кредитная карта, инвестиционный, ссудный и т. Д.))
Последние четыре цифры номера счета
Снимок экрана со сводной страницей вашей учетной записи в онлайн-банке — веб-адрес этой страницы отображается в браузере, а вся важная личная информация заблокирована. (Инструкции для Mac или ПК)
В начало
У меня несколько версий одной и той же учетной записи.
Каким бы увлекательным ни было получение всех долларов с этих дублирующих аккаунтов, разумнее оставить все, исходя из некоторого подобия реальности, не так ли? 😉 Дублирующиеся учетные записи могут появиться, когда финансовое учреждение вносит любое изменение типа в данные вашей учетной записи, оставляя старые версии учетных записей «тупиковыми», даже если они все еще видны на бэкэнде.
шагов, которые нужно предпринять
1
При связывании учетной записи вы можете увидеть несколько версий одной и той же. Выберите тот, который больше всего соответствует вашему текущему балансу.
2
Если вы впервые связываете аккаунт и начальный баланс неверен, вы можете изменить его прямо в реестре аккаунта.
Транзакции должны импортировать нормально, продвигаясь вперед!
Проблема по-прежнему не устранена?
Если проблема не исчезнет, отправьте нам сообщение со следующим кодом:
Название вашего финансового учреждения
Снимок экрана со сводной страницей вашей учетной записи в онлайн-банке — веб-адрес этой страницы отображается в браузере, а вся важная личная информация заблокирована.(Инструкции для Mac или ПК)
Или см. Транзакции, импорт которых остановлен.
В начало
Отправить сообщение
Если вы попробовали выполнить указанные шаги по устранению неполадок, но ваше соединение по-прежнему не работает, пришло время отправить нам сообщение. В зависимости от того, где вы читаете эту статью, у вас есть несколько вариантов:
Если у вас серый значок «x» в верхнем правом углу, это ваш путь к . Отправьте сообщение — это даже даст вам возможность поговорить с нами в чате, если мы будем доступны!
В противном случае внизу вы увидите ссылку «Связаться с нами».
И вы всегда можете написать нам по адресу [адрес электронной почты]
В начало
Нет транзакций, нет проблем: почему этот ветеран путешествий с оптимизмом смотрит на стартап, запущенный накануне COVID-19
Рассел Карстенсен основал Мельбурн, Австралия. в июле 2019 года и запустила бизнес на рынок в декабре.
В свете чего с тех пор в мировой туристической индустрии это может показаться очень несвоевременное решение.Но Карстенсен так не считает, и на самом деле Аэронология опережает график со своим бизнес-планом и регулярно добавляет новые партнеры.
Карстенсен ранее управлял двумя крупными туристическими компаниями в Рынок Австралии / Новой Зеландии — компания по управлению корпоративными поездками QBT and Air Билеты, 70-летний поставщик услуг по распространению авиабилетов и продаже билетов что, по словам Карстенсена, общая стоимость сделки составила около 1,7 миллиарда долларов. когда он ушел в 2018 году.
Его план полуотставки изменился, когда прежний коллеги обратились к нему с предложением создать новую — и улучшенную — технологию путешествий. решение, в первую очередь для турагентов.
Мы поговорили с Карстенсеном, чтобы узнать больше об аэронологии, как он планирует продолжать развивать бизнес и почему он будет осторожен о привлечении инвесторов. Беседа была немного отредактирована для краткость.
Объясните проблему, которую призвана решить аэронология?
Когда я ушел из бизнеса по продаже авиабилетов, мы бронировали и покупка билетов у оптовиков и консолидаторов билетов на азиатском рынке, и мы обнаружили, что рынок действительно ручной, низкотехнологичный.
То, что мы предоставляем, эквивалентно интернет-банкингу для турагент. У них есть собственный прямой контракт с глобальным система распространения, и мы обеспечиваем веб-интерфейс для зеленых экранов и через API извлеките соответствующую информацию для турагента, чтобы деловое решение.
Получайте дозу цифровых путешествий в свой почтовый ящик каждый день
Подпишитесь на нашу рассылку новостей ниже
Для турагента, чтобы сделать заказ — скажем, четыре сектора, два пассажирам, две сумки, две заявки на питание — в GDS для лиц с пятилетним опыт, чтобы сделать это бронирование занимает около 28 минут.Есть много записи, которые довольно сложные. Когда они использовали наш интерфейс, требуется три минуты.
И этот пример — просто полеты. Естественное явление турагент сначала проверит рейсы и забронирует их, затем добавит отели, а затем страхование путешествий, затем деятельность и, возможно, автомобиль. И они могут отправиться в круиз, и они могут поехать в тур. Часто для этого им приходится переходить на разные экраны.
Мы только что подключились к WebBeds, это второй крупнейший в мире номерной банк.Подключаем все их отели к бронированию процесс на одном экране.
В некоторой степени это похоже на Expedia для туристических агентств. Наш Самая большая точка продажи — мы можем превратить турагента из турагента за 1 миллион долларов туристическому агенту за 4 миллиона долларов, фактически не проходя никакой специальной подготовки. А потом в конце концов, агент может установить цену на этот продукт по любой цене, которая ему нравится. Это может составлять до 2000 долларов, и может не быть большой маржи или комиссии в это бронирование, чтобы они могли пометить его до 2200 долларов.Мы предоставляем документ, подтверждающий, что это 2200 долларов, а также маршрут.
Как развивался ваш бизнес с тех пор, как вы запущен?
Когда мы запустились в декабре, у нас были две очень большие организации. зарегистрироваться у нас — Connexus Travel в Северной Азии, старый Swire Travel, и один из моих главных конкурентов в этом австралийском / новом Рынок Зеландии зарегистрировался в течение трех дней после моего запуска — это Express Туристическая группа. А потом у нас появился действительно крупный бизнес из Сингапура, — Чан Brothers Travel, один из престижных туристических компаний за пределами Сингапура, и также Global Travel.
Итак, у меня есть Гонконг, Пекин, Шанхай, Тайвань, Присутствие на рынках Сингапура, Австралии и Новой Зеландии, и это то, что мы будем сосредоточиться, вероятно, в течение следующих шести-двенадцати месяцев.
У нас мульти-GDS — у нас есть Travelport, Sabre, Amadeus, Travelsky. У нас будут все лоукостеры, если мы сделаем нашу сделку с лоукостерами. агрегатор перевозчиков, и мы работаем со всеми крупными авиакомпаниями с NDC.
Мы также были выбраны IATA в качестве ускорителя программа, которая начинается в августе, а также ATPCO Bridge Labs и Singapore Tourism Ускоритель.Как стартап, нам очень повезло, и мы успешно попали в эти огромные организации.
Расскажите нам о своей бизнес-модели и о том, как вы поживаете пострадал от кризиса с коронавирусом.
Лично мне принадлежит 65% компании. Мы полностью профинансированы до начала следующего года.
До появления вируса туристические агенты были постоянно заняты, и они зарабатывали много хороших денег за последние 20 лет. Когда вы зарабатывая деньги, когда вы заняты, склонность к изменениям сводится к минимуму.Его человеческая природа.
Теперь вирус все остановил. Каждое путешествие бизнес по всему миру думает: «Если я собираюсь продержаться, мой бизнес придется выглядеть по-другому. Мои расходы должны быть намного ниже, и мне придется работать более продуктивно ».
Но для этого нет технологий. Это где мы вошли. Мы достигли кривой до того, как кривая была реализована.
Как мы зарабатываем деньги, мы берем 1 австралийский доллар за транзакцию.Сейчас нас 13 человек, и мы, вероятно, дорастем до около 20 к концу этого года. Мы открыли команду разработчиков в Маниле, но большинство нашей операции находится в Мельбурне. Когда мы используем все наши технологии, мы не нужно расти, мы просто должны поддерживать. Так что я мог бы произвести 100 миллионов транзакций с той же численностью персонала.
Каковы ваши планы по географическому расширению?
В прошлом году, когда мы составляли бизнес-план, мы должны были сосредоточиться на Азиатско-Тихоокеанском регионе в 2020 году — чтобы выйти на каждый из этих основных рынков в Северная Азия, Юго-Восточная Азия, Австралия, Новая Зеландия.
В некоторой степени это похоже на Expedia для туристических агентств.
Рассел Карстенсен — Аэронология
Мы дошли до этого к февралю с очень уважаемыми туристическими компаниями, поэтому сейчас мы на девять месяцев опережаем кривая, и наш охват рынка шире, чем предусматривалось в бюджете.
Сейчас я уже обсуждаю технологию в Европе и в Соединенные Штаты. Прекрасная вещь, мы работаем на спине всех другие глобальные GDS. Наша платформа является облачной. Мы собираемся быть многоязычный.А услуги, которые мы предоставляем туристическому агентству, продиктованы сделка между агентством и поставщиком.
В следующем году мы нацелены на Соединенные Штаты, Северную Америку. и Южную Америку, а в следующем году мы планируем оставить след в Европа и Африка.
Вы говорите, что у вас достаточно денег, чтобы продержаться до конца 2020 года, но какова ваша стратегия, если объемы поездок на самом деле не увеличиваются до тех пор, пока в 2021? И тогда может пройти гораздо больше времени, прежде чем они вернутся на уровни I. предположим, были в бизнес-плане, который вы разработали в прошлом году — так как же выжить? устойчивый период дохода ниже ожидаемого?
Очевидно, что происходит с транзакционной стороной путешествия беспрецедентны, и цифры в целом составляют от 5 до 10% от показателей 2019 года.
К счастью, есть многолетний опыт в нашем бизнесе, поэтому мы были в подобных ситуациях раньше — спад, 11 сентября, атипичная пневмония, свиной грипп, авиакатастрофы и войны. Это держит нас в хорошем состоянии вместо этого, потому что мы научились не паниковать, поэтому контролируйте то, что мы можем, и продолжайте развивается. Моргать не будем… пока.
У нас есть пятилетний прогноз и второй полный год работы, и мы планируем придерживаться этих показателей.
В нашем текущая бизнес-модель: у нас очень сильный внутренний рынок в Австралии и Новая Зеландия и потенциально «пузырь путешествий» между этими странами, тогда есть китайский внутренний рынок, где и сейчас есть огромное количество совершаются туристические операции.Наконец, регион APAC сделал невероятно хорошая работа по сдерживанию распространения COVID-19.
Еще одна наша сильная сторона — это контракты, стратегические единицы, и наш продукт действительно работает так, как ожидалось. Турагенты и онлайн-турагентства, использующие наше приложение, на самом деле от трех до пяти в разы продуктивнее и наша деловая репутация в отрасли в этом регионе выдающийся.
Но каким бы хорошим ни был ваш продукт, потребительский спрос вне вашего контроля.Это вызывает бессонные ночи?
Aeronology располагает проверенными технологиями, опытной командой, низкая и гибкая база затрат, отличные контракты с отличными туристическими компаниями в региона APAC, и мы не полагаемся на доходы поставщиков. Мы не занимаемся коммерцией отношения с любым из них, нам просто нужны их API для транзакций.
Если нам потребуются новые инвестиции, мы спросим. Аэронология имеет то, что большинство инвесторов хотят отличную модель, недорогие инновационные технологии и неограниченная возможность совершать миллиарды транзакций без увеличения эксплуатационные расходы на те же проценты роста.Я сплю с одним открытым глазом.
Итак, что вы будете искать, если откроетесь для инвесторов?
На данный момент мы рады оставаться конфиденциальными. Но если инвестор увлечен путешествиями и имеет некоторый рычаг в этот рынок, мы бы их рассмотрели.
Абсолютно ни в коем случае мы не допустим GDS инвестор в нас, потому что, как только GDS покупает что-либо, они облажаются. Так если у нас будут инвесторы, мы будем выбирать, кто они.
Мы не нужны деньги, но было бы хорошо иметь выход на рынок — может быть, U.К. или, может быть, США
Несмотря на продолжающийся рост и распространение инструменты самообслуживания, вы рассчитываете на долговечность традиционных турагенты?
Абсолютно ни в коем случае мы не позволим инвестору GDS в нас, потому что, как только GDS покупает что-либо, они облажаются.
Рассел Карстенсен — Аэронология
Да. В январе я был в Женеве, чтобы подать заявку на участие в акселераторе IATA. Когда мы добились успеха, я спросил председателя отборочной комиссии, как мы получили в группу — мы единственные, кто занимается туристическими агентствами — и он сказал, что по-прежнему 65% все транзакции в ИАТА выполняются турагентами, и они то же самое последние 20 лет.
Так они видят ценность технологии на рынке, который все еще больше, чем OTA, и который может влиять на поведение в сфере путешествий лучше, чем может OTA.
ОТА, все на дно бочки бегут. Путешествие агент обеспечивает ценность поездки, и есть еще много людей, которые будут обратиться к туристическим агентствам, чтобы получить опыт, почувствовать себя комфортно, собрать все воедино, а затем они знают, что могут связаться с этим турагентом, чтобы решить любые проблемы.
Модель OTA была [бранно] выставлена на этом конкретном рынке, потому что, как как только все пошло грушей, звонить было некому.
Итак, если я получаю 5% от этих 65%, я очень богатый человек.
Но вы также предоставляете технологии для OTA — расскажите нам больше о который.
Довольно часто, когда вы делаете заказ через OTA, это бронирование был обработан на сервере, и большая часть этого процесса выполняется людьми — они могут сидеть на Филиппинах, в Индии. Пятьдесят процентов могут быть сделано с помощью роботов, и мы также предоставляем для этого технологии.
Но и за сцены много тех OTA, у них есть сторонние компании, занимающиеся обработкой файлов по всему миру — так что то, что вы считаете автоматизированным, по-прежнему выполняется вручную задний конец.
Я сосредотачиваюсь на туристическом агентстве, моя вторая задача — как я автоматизирую услуги OTA, будь то корпоративные или розничные.
Кто ваши конкуренты? А как насчет вашей бывшей компании, Билеты на самолет?
Хороший вопрос. У меня его нет. Это звучит действительно, правда глупо, потому что, если бы это было так просто, все бы так делали. Но это непросто. Реальность такова, что некоторые делают часть этого — есть те, кто занимается робототехникой, подсказка менеджмент, ценообразование.
Аэронология абсолютно конкурирует с авиабилетами по технологии стек в Австралии и Новой Зеландии, потому что мы обеспечиваем транзакцию технологии основного конкурента Air Tickets Express Travel Group.
Текущий Версия технологии Air Tickets — V1, версия ETG — V8. Я ожидаю, что ETG будет больше, чем авиабилеты в течение двух лет и, возможно, раньше. Я создал воздух Технология продажи билетов, поэтому я знаю, где взять наши новые приложения.
И технологии Aeronology также будут в абсолютной конкуренции с любой оптовой компании по продаже билетов в любой точке мира, которая не использует наши Сервисы.
Получаете ли вы доход сейчас?
На прошлой неделе я заработал 2 доллара.
Мы тестировали нашу технологию и выпустили тысячи и тысячи тестовых билетов. Первые два билета, выпущенные по нашей технологии на коммерческой основе. как оплата пассажиров была сделана на прошлой неделе.
Было два первого класса из Гонконга в Лондон. обратные билеты, которые стоили около 8000 долларов каждый. Они были выполнены консультантом офиса в Гонконге — это заняло бы около 20 минут, и они сделали это примерно за одну минуту. И я заработал 2 доллара.
Я хочу делать 100 миллионов таких в год.И это возможность. Это не просто билет, это номер в отеле, туристическая страховка, машина.
Только подумайте об этом маленьком рынке в Австралии, который у меня был для бизнеса по продаже авиабилетов, и мы совершали 3,5 миллиона транзакций в год. Если я смогу это продублировать — а это произойдет в следующие два с половиной года — это 2,5 миллиона австралийских долларов, которые я зарабатываю.
Прелесть этой модели в том, что мне не нужно увеличивать размер моего персонала. Если у нас есть процесс в одной GDS, он остается таким.В единственная стоимость будет, если мне придется наращивать объем облачных вычислений, что пропорционально не будет так уж плохо.
Мне не нужно постоянно обновляться. И красота для туристических агентств — они не платят лицензионный сбор, они просто платят за использование. Так что, если они им не пользуются, это им ничего не стоит. И если они его используют, это очень дешево, и это добавочная стоимость к существующим услугам.
Отсутствуют транзакции Google Analytics? Вот 10 причин, почему! — Плагин Google Tag Manager для WordPress
Отсутствующие транзакции Google Analytics находятся в моем верхнем списке часто задаваемых вопросов на форуме поддержки или по электронной почте.Если у вас есть магазин электронной коммерции и вы отслеживаете заказы с помощью Google Analytics, скорее всего, вы столкнулись с проблемой: вы видите покупку на сервере администратора, но не видите этого в отчетах Google Analytics. И это обычно не связано с системой интернет-магазинов, которую вы используете: владельцы магазинов WooCommerce сталкиваются с этой проблемой, возможно, ежедневно, так же, как пользователи Magento или даже владельцы магазинов Shopify.
Но почему? Это ошибка? «Особенность»? Что-то, с чем вам нужно жить, или что-то, что можно исправить? Давайте рассмотрим некоторые объяснения и возможные исправления.
Во-первых, давайте рассмотрим две причины, связанные с используемой технологией:
# 1 Ваш платежный шлюз не отправляет пользователя обратно на страницу благодарности
Это одна из наиболее распространенных причин, по которой транзакции не отслеживаются в Google Analytics, особенно если вы используете Диспетчер тегов Google для развертывания своих измерений.
Некоторые сторонние платежные шлюзы дают пользователям возможность посещать свой кошелек или другие части веб-сайта без необходимости возвращаться к продавцу.Хотя ваш интернет-магазин будет уведомлен об успешном платеже в фоновом режиме, отказ от принуждения пользователя к возврату на страницу благодарности может стать проблемой, если мы говорим об отслеживании: протокол измерения, который я объясню ниже более подробно, может также может быть решением: когда интернет-магазин получает уведомление о платеже, некоторые плагины также могут выполнять свои собственные коды, которые также могут включать отслеживание Google Analytics на стороне сервера.
Однако
Google Tag Manager отличается: это чисто браузерное решение, в настоящее время нет возможности запускать теги в вашем контейнере с вашего сервера.Пользователь должен посетить страницу с благодарностью за ваш заказ в браузере, который использовался при оформлении заказа. Без этого соответствующие теги в вашем контейнере Диспетчера тегов Google не сработают, ваше отслеживание Google Analytics не будет выполнено, и вы пропустите транзакцию в своих отчетах GA.
Большинство сторонних платежных шлюзов предлагают вариант, который будет перенаправлять вашего клиента обратно на страницу с благодарностью за заказ после оплаты. Вы должны проверить это и включить, где это возможно.
# 2 Некоторые заказы поступают из вашего мобильного приложения
Это может быть тривиально, но давайте просто добавим это в список: если в вашем интернет-магазине также есть мобильное приложение, в котором пользователи могут размещать заказ, вам обязательно нужно проверить, есть ли в этом приложении отслеживание электронной торговли Google Analytics.В противном случае вы можете увидеть заказ на странице администратора вашего интернет-магазина, но он наверняка будет отсутствовать в ваших отчетах Google Analytics.
Если вы используете WordPress (и, возможно, WooCommerce), могут быть некоторые дополнительные причины, которые также могут относиться к другим системам электронной коммерции аналогичным образом:
# 3 Расширение WooCommerce изменяет страницу полученного заказа по умолчанию
WooCommerce по умолчанию не включает отслеживание Google Analytics. Для этого вам нужно использовать плагин.Большинство плагинов полагаются на некоторые хуки и функции на странице получения заказа, которые WooCommerce выполняет по умолчанию. Однако есть некоторые плагины WooCommerce, которые изменяют эту страницу полученного заказа, позволяя вам выбрать страницу, созданную на заказ, вместо страницы по умолчанию. Это замечательно и полезно в большинстве случаев, но некоторые плагины не выполняют одни и те же хуки и коды на этих страницах, полученных с помощью настраиваемого порядка, не позволяя другим модулям увидеть, что пользователь только что разместил заказ.
Очевидно, что вам следует либо избегать использования таких плагинов, либо связаться с автором плагина, чтобы обновить плагин, чтобы он имитировал все элементы и поведение страницы полученного порядка по умолчанию.
# 4 Ваш плагин Analytics / Tag Manager не поддерживает ваш плагин электронной торговли
Хотя многие встроенные плагины Google Analytics поддерживают, например, WooCommerce, некоторые из них помещают в интернет-магазин необходимый код отслеживания электронной торговли, только если вы покупаете платную версию. Некоторые плагины Google Tag Manager вообще не поддерживают какие-либо плагины электронной коммерции (конечно, не мои). Если вы используете другие плагины электронной коммерции, кроме WooCommerce, вы увидите, что многие плагины GA / GTM еще не могут отслеживать покупки в электронной торговле.Вам следует тщательно выбирать платформу электронной коммерции и, конечно же, свой плагин для отслеживания выбранной платформы электронной коммерции 🙂
В некоторых случаях вы пропускаете транзакцию в отчетах GA из-за намерений пользователя:
# 5 Пользователь отказался от отслеживания Google Analytics
Менее известным расширением браузера является надстройка отказа от Google Analytics. Ссылка на эту страницу иногда помещается на страницу политики конфиденциальности веб-сайтов, чтобы предложить пользователям возможность отказаться от отслеживания.Но также довольно легко найти это расширение, так как большинство похожих запросов в Google показывают это дополнение на первой позиции. Технически это добавляет некоторый код JavaScript на каждый веб-сайт, который посещает пользователь, который дает указание коду отслеживания Google Analytics не отслеживать пользователя. Это также означает, что GA не будет сбрасывать файлы cookie и отправлять какие-либо данные на свои серверы.
Этот вид блокировки можно легко обнаружить, поэтому вы можете отменить его программно, но я бы не рекомендовал это делать.Уважение намерений вашего пользователя должно быть важнее, чем просмотр покупки в отчетах Google Analytics, даже если вы не сможете полностью оценить свои маркетинговые кампании.
(Если вы действительно хотите вернуть свое отслеживание, вы или ваш программист должны прочитать, как работает этот вид блокировки. Повторно включить сбор данных не должно быть проблемой. Но опять же: это против вашего пользователя и должно Â не используется)
# 6 Пользователь использует блокировщик рекламы или любое другое расширение браузера, связанное с конфиденциальностью.
Более известен тот факт, что самые популярные блокировщики рекламы обычно также блокируют отслеживание Google Analytics.Это означает, что если ваш посетитель блокирует рекламу, вы обычно мало знаете об этих посетителях. Обычно на самом деле ничего, даже не факт, что этот пользователь посетил ваш сайт / интернет-магазин. Существуют и другие расширения браузера, которые позволяют пользователям контролировать веб-сайты и их отслеживание. Основная цель этих надстроек браузера — повысить безопасность, что также включает в себя возможность отключить Google Analytics или другой вид отслеживания.
Этот вид отказа — тоже решение вашего посетителя, поэтому отменить его и отслеживать этих пользователей — это решение, которое вам не подходит.Некоторые плагины и расширения популярных систем электронной коммерции дают владельцам возможность использовать метод, называемый отслеживанием на стороне сервера. Это означает, что на ваш сайт не добавляется код отслеживания, поэтому ничего нельзя отключить или заблокировать. Вместо этого для отправки данных в GA во время загрузки страницы используется так называемый протокол измерений Google Analytics. Данные собираются и отправляются в фоновом режиме на вашем сервере, а не в браузере вашего пользователя. Это также означает, что некоторые данные могут отсутствовать таким образом (например, размер экрана), но многие другие — и важные — данные будут доступны в ваших отчетах независимо от того, какую блокировку использует пользователь.
Но еще раз: это противоречит желанию вашего пользователя, и поэтому его следует избегать.
Теперь давайте рассмотрим еще несколько технических причин, которые не могут объяснить отсутствие транзакции Google Analytics независимо от используемой системы электронной торговли:
# 7 Скрипт на странице препятствует отслеживанию работы над вашим заказом. Страница благодарности
Большинство веб-сайтов в настоящее время используют несколько скриптов для улучшения взаимодействия с пользователем и обеспечения динамики вашей веб-страницы. Сценарии и программы иногда могут давать сбой даже после тщательного тестирования.Это потому, что практически невозможно протестировать каждый веб-сайт в каждом браузере со всеми возможными опциями и расширениями при каждом подключении к Интернету. Некоторые комбинации терпят неудачу.
Неисправный модуль на странице благодарности вашего интернет-магазина может запустить эффект домино, препятствуя выполнению других скриптов. Это может включать коды отслеживания Google Tag Manager и Google Analytics. Выявить такие случаи очень сложно, так как на вашем компьютере и в тестовых средах все работает нормально. Но может быть одно решение для обнаружения таких ошибок и сообщения о них: отслеживание ошибок JavaScript.
Вы можете попросить своего программиста выявить любую ошибку на вашем сайте, проверить, загружен ли Google Analytics, и отправить сведения об ошибке в Google Analytics. Это будет включать точное сообщение об ошибке, имя файла и номер строки в этом файле, где произошла ошибка. Почему это будет полезно? Потому что Google Analytics собирает множество других важных технических данных рядом с сообщением об ошибке: браузер, версия браузера, информация об устройстве, информация об операционной системе, разрешение экрана и т. Д. Это золото для любого разработчика и может помочь обнаружить и исправить неожиданные ошибки.Отслеживание ошибок JavaScript также может улучшить производительность других элементов веб-сайта, таких как страницы категорий или страница корзины. Я планирую подробнее написать об этой технике в отдельной статье позже.
# 8 В коде отслеживания Google Analytics / Tag Manager есть ошибки
Это очень похоже на предыдущие причины, но в этом случае ваши коды Google Tag Manager / Google Analytics содержат проблемы.
Например, в JavaScript вам нужно заключить любые текстовые данные в символ «или».Если в названиях ваших продуктов есть такой символ, и ваш программист (или автор плагина Google Tag Manager / Analytics) не подготовил код для его обработки, может случиться так, что браузеры увидят ‘или «в названии вашего продукта как» конец текстовых данных », нарушая выполнение кода, поскольку он не может обрабатывать символы после знака« или »в названии вашего продукта.
«Классный продукт с 4-дюймовым дисплеем»
С точки зрения браузеров текст синего цвета не будет подвергаться угрозе как часть названия продукта, но его нельзя рассматривать как команду, либо переводя браузер в неожиданное состояние, когда он должен прервать текущую операцию: например, отслеживание данные о ваших покупках.
Есть две причины, связанные с ограничениями отслеживания Google Analytics:
# 9 Слишком много товаров включено в одну транзакцию
Это применимо, если вы используете так называемое расширенное отслеживание электронной торговли в Google Analytics. Это следующее поколение отслеживания электронной торговли в GA, у него много возможностей, если вы используете его с Диспетчером тегов Google (о чем я тоже хотел бы рассказать в отдельной статье).
Теперь давайте узнаем кое-что (возможно) новое: определение полезной нагрузки попадания.
Подумайте обо всех данных, которые Google Analytics собирает во время загрузки вашей страницы. Даже если вы не используете отслеживание электронной торговли, просто поместив код отслеживания по умолчанию на свой веб-сайт, вы увидите множество данных о вашем пользователе в своих отчетах: источники, возможно, ключевые слова, данные о размере экрана, заголовке страницы и т. Д. Теперь представьте себе довольно большой заказ в вашем интернет-магазине либо с большим количеством продуктов, либо с меньшим количеством продуктов, но с очень длинными названиями продуктов. Добавьте к этому данные, отслеживаемые по умолчанию.
А теперь подумайте о черной бумаге, на которой вы начинаете записывать все собранные данные рядом друг с другом. Вы также пишете короткие имена рядом со всеми данными, чтобы знать, какие числа и тексты принадлежат определенным измерениям. После того, как вы записали все собранные данные на этот лист, это будет ваша так называемая полезная нагрузка обращения, данные, отправляемые в Google во время загрузки вашей страницы. Если сюда входят названия продуктов, бренды, названия категорий продуктов (с множеством уровней категорий), это может быть довольно долго, не так ли?
Google Analytics, однако, сбросит эту полезную нагрузку и не отправит ее на серверы Google, если размер (длина) этой полезной нагрузки превысит 8 КБ.Это 8192 байта, что обычно составляет 8192 символа, за исключением некоторых нелатинских (или нелатинских) языков, где для идентификации одного символа требуется более одного байта. На странице благодарности с большим количеством товаров в указанном порядке это можно сделать быстро.
Но что делать в таких случаях?
Google Analytics позволяет импортировать данные о продуктах, такие как названия продуктов, бренды, названия категорий, с помощью загрузки CSV или программным способом. Здесь вы отправляете в полезной нагрузке обращения только артикулы ваших продуктов и присоединяете другие данные о продуктах в пользовательском интерфейсе Google Analytics, например, с помощью загрузки CSV.Google Analytics проанализирует загруженные вами данные о товарах в формате CSV при обработке данных о входящих покупках с вашими артикулами и, если найдет заказанные товары в этом CSV-файле, будет заполнять отчеты электронной торговли, используя данные из загруженного вами CSV
Вы или ваш программист можете подключиться к потоку сбора данных Google Analytics и разделить всю полезную нагрузку на более мелкие части. Отличное решение можно найти в этой статье LunaMetrics.
# 10 За один сеанс было отслежено слишком много взаимодействий
Еще одним ограничением отслеживания Google Analytics является то, что он позволяет отправлять «только» 500 обращений за сеанс.Хит, как правило, — это загрузка страницы, но щелчок по вашему продукту на странице категории или по кнопке добавления в корзину также будет хитом, если вы отслеживаете их, поскольку эти события должны отслеживаться. А теперь представьте пользователя, который действительно пытается найти нужный правильные продукты. Он ищет множество продуктов, помещает их в корзину, и когда этот пользователь, наконец, достигает страницы с благодарностью за ваш заказ, в этом сеансе происходит взаимодействие №501. И в этом случае Google удаляет хит, содержащий данные о покупке. Это ограничение может влиять на
веб-сайтов с более высокими показателями страниц / сеансов, но меньшее количество страниц / сеанс рядом с большим количеством отслеживания событий также может помешать правильному отслеживанию.
Сводка
Как видите, любой недостающей транзакции в отчетах Google Analytics может быть несколько причин. Вы всегда должны сначала уважать конфиденциальность пользователей, а затем пытаться исправить другие возможные причины. 100% точности и паритета обычно не удается достичь, но иногда можно улучшить соотношение отслеживаемых покупок. Принятие этого обычно является лучшим выбором, поскольку вы пытаетесь отслеживать все и каждого, независимо от выбора вашего пользователя.
Заявление GASB
No.33 «Бухгалтерский учет и финансовая отчетность по необменным операциям»
Выдано: Главным налоговым инспекторам округа, города, поселка и деревни
Положение GASB № 33 содержит инструкции по бухгалтерскому учету и отчетности по необменным операциям. Необменная транзакция — это транзакция, при которой правительство получает (или дает) стоимость, не передавая (или не получая) равноценную стоимость в обмен. Нет четкой связи между предоставленными услугами и поддерживающими доходами. В выписке описаны четыре категории необменных транзакций:
Производные налоговые поступления (например, налог на прибыль или налог с продаж).
Установленные необмениваемые доходы (например, налоги на недвижимость.
Требуемые государством необменные транзакции (например, федеральные программы или программы штата, которые местные органы власти уполномочены выполнять).
Добровольные безобменные операции (например, добровольно заключенные гранты).
Целью данного бюллетеня является обсуждение влияния Положения № 33 на признание выручки при использовании модифицированного метода начисления для учета. Модифицированный метод начисления будет использоваться при подготовке вашего годового финансового отчета для государственного контролера.
Положение № 33 изменяет признание доходов для грантов, ориентированных на расходы / возмещения (Категории 3 и 4). До отчета №33 выручка признавалась в момент понесения расходов. В заявлении № 33 говорится, что для начисления доходов от гранта, основанного на расходах / возмещении, расходы должны быть произведены, и доходы должны быть доступны. Доступные означает, что они могут быть получены в текущем периоде или достаточно скоро после этого, чтобы их можно было использовать для погашения обязательств текущего периода.Период доступности должен соответствовать временным рамкам, используемым в настоящее время для признания выручки. Если выручка недоступна для финансирования расходов текущего периода, выручку следует отложить.
Отчет № 33 вступает в силу для финансовых лет, начинающихся 1 июля 2000 г. или после этой даты. Изменения бухгалтерского учета, внесенные в соответствии с этим отчетом, должны рассматриваться как корректировки предыдущего периода. Код счета 8015 следует использовать для уменьшения начального остатка средств при анализе изменений в отчете о капитале фонда в вашем годовом финансовом отчете.
Если вам требуется дополнительная информация или техническая помощь, обратитесь в региональный офис, обслуживающий ваше правительство.
13.3.1 Заявления START TRANSACTION, COMMIT и ROLLBACK
13.3.1 Заявления START TRANSACTION, COMMIT и ROLLBACK
НАЧАТЬ СДЕЛКУ [ transaction_characteristic [, transaction_characteristic ] ...] transaction_characteristic : { С ПОСТОЯННЫМ СНИМКАМ | ЧИТАЙ ПИШИ | ТОЛЬКО ЧИТАТЬ } НАЧАТЬ [РАБОТА] ЗАВЕРШИТЬ [РАБОТУ] [И [НЕТ] ЦЕПЬ] [[НЕТ] ВЫПУСК] ОТКАТ [РАБОТА] [И [НЕТ] ЦЕПЬ] [[НЕТ] РЕЛИЗ] SET autocommit = {0 | 1}
Эти инструкции обеспечивают контроль над использованием транзакции:
НАЧАТЬ СДЕЛКУ или BEGIN начать новую транзакцию.
COMMIT фиксирует текущую транзакцию, делая его изменения постоянными.
ROLLBACK откатывает текущий транзакция, отменив ее изменения.
SET autocommit отключает или включает режим автоматической фиксации по умолчанию для текущего сеанса.
По умолчанию MySQL работает с режим автофиксации включен.Это означает, что, если не внутри транзакции, каждый оператор является атомарным, как если бы он был окружен START СДЕЛКА и ОПЕРАЦИЯ . Тебе нельзя используйте ROLLBACK , чтобы отменить эффект; однако, если ошибка возникает во время выполнения оператора, оператор прокатывается назад.
Чтобы неявно отключить режим автоматической фиксации для одной серии заявления, используйте START TRANSACTION утверждение:
НАЧАТЬ СДЕЛКУ; ВЫБЕРИТЕ @A: = СУММ (зарплата) ИЗ table1 WHERE type = 1; ОБНОВЛЕНИЕ table2 SET summary = @ A WHERE type = 1; СОВЕРШИТЬ;
С НАЧАТЬ ТРАНЗАКЦИЮ автоматическая фиксация остается отключено, пока вы не завершите транзакцию с помощью COMMIT или ROLLBACK .В Затем режим автоматической фиксации возвращается в предыдущее состояние.
НАЧАТЬ ОПЕРАЦИЮ разрешает несколько модификаторов которые контролируют характеристики транзакции. Чтобы указать несколько модификаторы, разделяйте их запятыми.
Модификатор WITH CONSISTENT SNAPSHOT начинает последовательный прочтите, чтобы узнать о механизмах хранения, которые на это способны. Этот относится только к InnoDB . Эффект — это то же, что и выдача НАЧАТЬ ОПЕРАЦИЮ за которым следует SELECT из любого InnoDB таблица.Видеть Раздел 15.7.2.3, «Последовательные неблокирующие чтения». Модель С Модификатор CONSISTENT SNAPSHOT не изменяет текущая сделка уровень изоляции, поэтому он обеспечивает согласованный снимок только в том случае, если текущий уровень изоляции — это тот, который разрешает непротиворечивое чтение. В единственный уровень изоляции, который разрешает непротиворечивое чтение, — это ПОВТОРНОЕ ЧТЕНИЕ . Для всех другие уровни изоляции, СОГЛАСНО Предложение SNAPSHOT игнорируется.Сгенерировано предупреждение когда предложение WITH CONSISTENT SNAPSHOT игнорируется.
ЧТЕНИЕ ЗАПИСЬ и ЧТЕНИЕ ТОЛЬКО модификаторы устанавливают режим доступа к транзакции. Они разрешить или запретить изменение таблиц, используемых в транзакции. Ограничение READ ONLY предотвращает транзакция от изменения или блокировки как транзакционной, так и нетранзакционные таблицы, которые видны другим транзакции; транзакция все еще может быть изменена или заблокирована временные таблицы.
MySQL обеспечивает дополнительную оптимизацию запросов на InnoDB таблицы, когда транзакция известна быть доступным только для чтения. Указание ТОЛЬКО ДЛЯ ЧТЕНИЯ гарантирует, что эти оптимизации применяются в тех случаях, когда статус только для чтения не может быть определен автоматически. Видеть Раздел 8.5.3, «Оптимизация транзакций только для чтения InnoDB» для получения дополнительной информации. Информация.
Если режим доступа не указан, применяется режим по умолчанию.Если значение по умолчанию не было изменено, это чтение / запись. это не разрешено указывать одновременно ЧТЕНИЕ ЗАПИСЬ и ТОЛЬКО ЧИТАЙТЕ в том же заявлении.
В режиме только для чтения остается возможность изменять таблицы создан с помощью ключевого слова TEMPORARY с использованием Операторы DML. Изменения, сделанные с помощью операторов DDL, не разрешено, как и в случае с постоянными таблицами.
Для получения дополнительной информации о режиме доступа к транзакции, включая способы изменения режима по умолчанию, см. Раздел 13.3.7, «Заявление SET TRANSACTION».
Если система read_only переменная включена, явно начиная транзакцию с START TRANSACTION READ WRITE требуется CONNECTION_ADMIN привилегия (или устаревший SUPER привилегия).
Важный
Многие API-интерфейсы, используемые для написания клиентских приложений MySQL (например, JDBC) предоставляют свои собственные методы для запуска транзакций, которые можно (а иногда и нужно) использовать вместо отправки START TRANSACTION выписка от клиента.См. Главу 29, Connectors and APIs , или документацию по ваш API, для получения дополнительной информации.
Чтобы явно отключить режим автоматической фиксации, используйте следующее утверждение:
УСТАНОВИТЬ autocommit = 0;
После отключения режима автоматической фиксации путем установки автоматическая фиксация переменной до нуля, изменения в безопасных для транзакций таблицах (например, для InnoDB или NDB ) не являются постоянными немедленно.Вы должны использовать COMMIT , чтобы сохранить изменения на диск или ROLLBACK на игнорируйте изменения.
autocommit — переменная сеанса и должен быть установлен для каждого сеанса. Чтобы отключить режим автоматической фиксации для каждое новое соединение, см. описание системная переменная autocommit в Раздел 5.1.8, «Системные переменные сервера».
BEGIN и BEGIN WORK являются поддерживается как псевдоним START TRANSACTION для инициирование транзакции. НАЧАТЬ СДЕЛКУ — это стандартный синтаксис SQL, это рекомендуемый способ начать специальную транзакция, и разрешает модификаторы, которые НАЧАТЬ не.
Оператор BEGIN отличается от использования BEGIN ключевое слово, которое запускает НАЧАЛО ... КОНЕЦ составное заявление. Последний не начинает транзакцию. Видеть Раздел 13.6.1, «Составное выражение BEGIN … END».
Примечание
Во всех хранимых программах (хранимых процедурах и функциях, триггеры и события), парсер обрабатывает BEGIN [WORK] как начало НАЧАТЬ... КОНЕЦ блок. Начните транзакцию в этом контексте с ПУСК ТРАНЗАКЦИЯ взамен.
Необязательное ключевое слово WORK поддерживается для COMMIT и ROLLBACK , как есть ЦЕПЬ и ВЫПУСК статьи. ЦЕПЬ И ВЫПУСК может использоваться для дополнительного контроля за завершением транзакции. Значение типа завершения системная переменная определяет поведение завершения по умолчанию.Видеть Раздел 5.1.8, «Системные переменные сервера».
Предложение AND CHAIN вызывает новую транзакцию. начаться, как только закончится текущая, а новая транзакция имеет тот же уровень изоляции, что и только что завершенная транзакция. Новая транзакция также использует тот же режим доступа (READ ЗАПИШИТЕ или ТОЛЬКО ЧИТАЙТЕ ) как только что завершенная транзакция. Пункт RELEASE заставляет сервер отключать текущий сеанс клиента после прекращение текущей транзакции.В том числе NO ключевое слово подавляет CHAIN или завершение RELEASE , что может быть полезно, если система completed_type переменная установлена, чтобы вызвать завершение цепочки или освобождения дефолт.
Начало транзакции приводит к тому, что любая ожидающая транзакция преданный идее. См. Раздел 13.3.3, «Заявления, вызывающие неявную фиксацию», для получения дополнительной информации. Информация.
Начало транзакции также вызывает блокировки таблиц, полученные с помощью ТАБЛИЦЫ БЛОКИРОВКИ будет выпущен, как хотя вы казнили РАЗБЛОКИРОВАТЬ ТАБЛИЦЫ.Начало транзакции не освобождает глобальная блокировка чтения получена с помощью FLUSH TABLES С ЗАМОК СЧИТЫВАНИЯ.
Для достижения наилучших результатов транзакции должны выполняться только с использованием таблицы, управляемые единым механизмом хранения, безопасным для транзакций. В противном случае могут возникнуть следующие проблемы:
Если вы используете таблицы из более чем одного безопасного для транзакций хранилища двигатель (например, InnoDB ), и уровень изоляции транзакции не СЕРИЙНЫЙ , это возможно, что когда одна транзакция фиксируется, другая продолжается транзакция, использующая те же таблицы, видит только некоторые из изменения, внесенные первой транзакцией.То есть атомарность транзакций не гарантируется со смешанными двигателями и могут возникнуть несоответствия. (Если транзакции со смешанным механизмом нечасто, вы можете использовать НАБОР УРОВЕНЬ ИЗОЛЯЦИИ ТРАНЗАКЦИИ, чтобы установить изоляцию уровень до SERIALIZABLE на на транзакцию по мере необходимости.)
Если вы используете таблицы, которые не являются безопасными для транзакций в транзакции, изменения в этих таблицах сохраняются сразу, независимо от статуса режима автоматической фиксации.
Если вы выдадите ОТКАТ оператор после обновления нетранзакционной таблицы в сделка, ER_WARNING_NOT_COMPLETE_ROLLBACK появляется предупреждение. Изменения в безопасных для транзакций таблицах откатываются назад, но не изменения в таблицы, не защищенные от транзакций.
Каждая транзакция сохраняется в двоичном журнале одним блоком, ПРИНЯТЬ .Сделки, которые откат не логируются. ( Исключение : Изменения в Нетранзакционные таблицы нельзя откатить. Если сделка откат включает модификации нетранзакционных таблицы, вся транзакция регистрируется с ОТКАТ заявление в конце, чтобы гарантировать, что изменения в нетранзакционные таблицы реплицируются.) См. Раздел 5.4.4, «Двоичный журнал».
Вы можете изменить уровень изоляции или режим доступа для транзакций с помощью оператора SET TRANSACTION .См. Раздел 13.3.7, «Заявление SET TRANSACTION».
Откат может быть медленной операцией, которая может происходить неявно. без явного запроса пользователя (например, когда возникает ошибка). Из-за этого SHOW PROCESSLIST отображает Откат в столбец State для сеанса, а не только для явные откаты, выполненные с ОТКАТ оператор, но также и для неявных откатов.
Когда InnoDB выполняет полный откат транзакции, все блокировки, установленные транзакцией, снимаются. Если один оператор SQL в транзакции откатывается в результате ошибки, такой как ошибка дублирования ключа, блокировки, установленные Оператор сохраняется, пока транзакция остается активной. Этот происходит потому, что InnoDB хранит блокировки строк в формат так, что он не может знать впоследствии, какая блокировка была установлена какое заявление.
Если оператор SELECT в транзакция вызывает хранимую функцию, а оператор в сохраненная функция терпит неудачу, этот оператор откатывается. Если ROLLBACK есть выполняется для транзакции впоследствии, вся транзакция откатывается.
Транзакционные издержки
Каковы транзакционные издержки?
Затраты по сделке — это расходы, понесенные при покупке или продаже товара или услуги. Транзакционные издержки представляют собой труд, необходимый для вывода товара или услуги на рынок, в результате чего возникают целые отрасли, занимающиеся упрощением обменов.В финансовом смысле транзакционные издержки включают комиссии брокеров и спреды, которые представляют собой разницу между ценой, которую дилер заплатил за ценную бумагу, и ценой, которую платит покупатель.
Ключевые выводы
Транзакционные издержки — это платежи, которые банки и брокеры получают от покупателей и продавцов за выполнение своих функций.
Затраты по сделке являются одним из ключевых факторов, определяющих чистую прибыль.
Различные классы активов имеют разные диапазоны транзакционных издержек; инвесторам следует выбирать активы, стоимость которых находится в нижней части диапазона для своего типа.
Каковы транзакционные издержки?
Общие сведения о транзакционных издержках
Транзакционные издержки для покупателей и продавцов — это платежи, которые банки и брокеры получают за свою роль. Также существуют транзакционные издержки при покупке и продаже недвижимости, которые включают комиссионные агента и затраты на закрытие, такие как сборы за поиск титула, сборы за оценку и государственные сборы. Другой тип транзакционных издержек — это время и рабочая сила, связанные с транспортировкой товаров на большие расстояния.
Транзакционные издержки важны для инвесторов, поскольку они являются одним из ключевых факторов, определяющих чистую прибыль. Транзакционные издержки уменьшают доходность, и со временем высокие транзакционные издержки могут означать потерю тысяч долларов не только из-за самих затрат, но и из-за того, что издержки уменьшают объем капитала, доступного для инвестирования. Комиссии, такие как коэффициенты расходов паевых инвестиционных фондов, имеют такой же эффект. Различные классы активов имеют разные диапазоны стандартных транзакционных издержек и комиссий. При прочих равных, инвесторы должны выбирать активы, стоимость которых находится в нижней части диапазона для их типов.
Исключение транзакционных издержек
Когда транзакционные издержки уменьшаются, экономика становится более эффективной, и больше капитала и рабочей силы освобождается для производства богатства. Такой сдвиг не обходится без болезней роста, поскольку рынок труда должен адаптироваться к новым условиям.
Один из видов транзакционных издержек — это препятствие для общения. Когда в остальном идеально подобранные продавец и покупатель не имеют абсолютно никаких средств связи, транзакционные издержки сделки слишком высоки, чтобы их можно было преодолеть.Банк выполняет роль посредника, связывая сбережения с инвестициями, а процветающая экономика оправдывает доход банка за транзакционные издержки по сбору информации и связыванию сторон.
Тем не менее, век информации, особенно появление Интернета и телекоммуникаций, значительно снизил барьеры для общения. Потребителям больше не нужны крупные учреждения и их агенты, чтобы делать осознанные покупки. По этой причине выживанию страхового агента угрожает широкий спектр технологических стартапов, которые запускают веб-сайты, продающие или продвигающие страховые полисы.Легкий доступ к информации и коммуникациям, предоставляемый Интернетом, также поставил под угрозу существование рабочих мест, таких как агент по недвижимости, биржевой маклер и продавец автомобилей. Считается, что именно это разрушило Scottrade.
По сути, цены на многие товары и услуги снизились из-за уменьшения барьеров для общения между обычными людьми. Розничные торговцы и мерчандайзеры также выполняют роль посредников, объединяя потребителей с производителями. Отрасль розничной торговли также пережила потрясения в последние годы из-за компании электронной коммерции Amazon.com, опередив традиционных гигантов, таких как Kohl’s и Macy’s, в сводном рейтинге, основанном на активах, доходах и рыночной стоимости.
Пример транзакционных издержек
Согласно исследованию, проведенному исследователями Роджером Эделеном, Ричардом Эвансом и Грегори Кадлеком, среднегодовая операционная стоимость взаимного фонда в США составляла 1,44%. Первая из этих затрат — брокерские комиссии, возникающие при покупке или продаже управляющего фондом. запас. Фонды с низкой оборачиваемостью будут платить меньше брокеров, хотя они могут платить больше, чем индивидуальные инвесторы.
Большой паевой инвестиционный фонд также может нести издержки воздействия на рынок, когда крупная покупка фондом акций искусственно повышает цену. Некоторые менеджеры уменьшают эти затраты, распределяя свои покупки на более длительные периоды времени. Наконец, взаимный фонд столкнется с расходами на спред, которые могут быть выше, когда управляющий торгует акциями на глобальных биржах или биржах с меньшей ликвидностью.
.

conspi.ru - Конспирология - Теория заговора

Руководство по SQL. Транзакции. – PROSELYTE

Состояния транзакций, сборка мусора, интересующиеся и активные транзакции, sweep, примеры

Автор: Ann Harrison, Harbor

Состояния транзакций

Как транзакции узнают о состояниях друг друга?

Мусор

Сборка мусора

Сборка мусора – итог

Старейшая заинтересованная транзакция (OLDEST INTERESTING TRANSACTION)

Старейшая активная транзакция (OLDEST ACTIVE TRANSACTION)

Чистка (SWEEPING)

Транзакции «in limbo»

Несколько примеров

Случай 1. Поток неконкурирующих транзакций

Случай 2. Готовится засада

Случай 3. Кто попадет в засаду?

Случай 4. Смертельные качели

Итог

Смена источника данных о транзакциях – Справочный центр OWOX

Как добавить данные о транзакциях из CRM

Структура таблицы с данными о транзакциях

Как соотносятся User ID из Google Analytics и таблицы-источника

Как соотносятся данные о транзакциях из Google Analytics и таблицы-источника

PostgreSQL : Документация: 9.6: 13.2. Изоляция транзакций : Компания Postgres Professional

13.2. Изоляция транзакций

Важно

13.2.1. Уровень изоляции Read Committed

13.2.2. Уровень изоляции Repeatable Read

Примечание

13.2.3. Уровень изоляции Serializable

Управление транзакциями базы данных — Документация Django 1.9

Транзакции, ACID, CAP | GeekBrains

Транзакции

Изоляция транзакций

ACID

CAP-теорема

Сапёр / Статьи / База знаний / SAPLand — Мир решений SAP

Использование транзакции SU53

КБ 860314 — транзакции не отображаются при открытии окна «Выбор банковской операции» в Microsoft Dynamics GP

Признаки

Причина

Разрешение

Устранение неполадок связанных учетных записей — Справка YNAB

Мои учетные данные не работают.

шагов, которые нужно предпринять

Проблема по-прежнему не устранена?

Мне нужно переподключаться каждый день.

Контрольные вопросы

Одноразовый пароль (OTP)

Мое соединение заблокировано.

шагов, которые нужно предпринять

Проблема по-прежнему не устранена?

Я не получаю свои пароли.

шагов, которые нужно предпринять

Проблема по-прежнему не устранена?

Мое финансовое учреждение обновило свой веб-сайт.

Моего финансового учреждения нет в списке.

Не останавливайтесь на достигнутом!

Мое финансовое учреждение поддерживает протокол OAuth.

Импорт транзакций остановлен.

шагов, которые нужно предпринять

Проблема по-прежнему не устранена?

Сделки ни разу не импортировали.

шагов, которые нужно предпринять

Проблема по-прежнему не устранена?

Некоторые транзакции отсутствуют.

шагов, которые нужно предпринять

Проблема по-прежнему не устранена?

Транзакции задерживаются.

шагов, которые нужно предпринять

Проблема по-прежнему не устранена?

Инвестиционные / кредитные операции не импортируются.

шагов, которые нужно предпринять

Мне заменили кредитную карту.

шагов, которые нужно предпринять

Проблема по-прежнему не устранена?

Транзакции импортируются более одного раза.

шагов, которые нужно предпринять

Проблема по-прежнему не устранена?