На проектах эта задача решается, но в частных случаях.
И на каждом проекте причина своя.
Если бы причина была бы одна и та-же -- её следовало бы запостить в Микрософт, чтобы они исправили. Но этого не происходит.
В этом посте я расскажу о своей идее, как можно исправлять расхождения.
Во время исправления будет выявлена и истинная причина.
Если она повторится на нескольких проектах -- можно будет запостить в Микрософт.
Ниже на картинке приведена взаимосвязь между таблицами для двух модулей -- контрагенты (на примере поставщиков) и склад.
Стрелки показывают -- что от чего зависит.
Мы видим, что в поставщиках между таблицами есть кольцо. Если мы исправим одну таблицу кольца на основании другой таблицы кольца то нарушим связь с третьей таблицей. Исправив третью -- испортим остальные две.
Иными словами в контрагентах нет одной таблицы, которая была единственным "источником правды" об операциях -- суть операции размазана по трём таблицам.
Поэтому автоматизированное исправление контрагентов при серьёзных повреждениях невозможно.
Иное дело -- склад.
Глядя на рисунок, там есть только один путь -- слева направо. Даже петля, которая содержит складские сопоставления, кольцом не является, потому что путь по петле только в одну сторону.
Иными словами, располагая только таблицей INVENTTRANS, можно воспроизвести всё, что из неё следует -- и постинг, и даже складскую сторону LEDGERTRANS, т.е. совсем всё, кроме пересчётов себестоимости, но их всегда можно пересчитать.
У меня есть своя методика, как можно исправлять ошибки по складу
Пока реализовать не удалось, не было подходящего клиента.
Выгоды, которые могут быть достигнуты:
1) Повышается производительность, за счёт того, что удалятся ненужные строки (отменённые сопоставления, например)
2) Сойдётся склад с ГК (есть только одна причина, по которой временно склад может не сойтись с ГК -- отмена пересчёта себестоимости не тем периодом, который отменяется. Эту причину устранить не удастся)
3) Повышается достоверность складских отчётов
Методика заключается в следующем (описание простое, но реализация будет очень сложна):
Формируем список правил такого плана :
- При обработке записи в INVENTTRANS нам надо: создать запись в постинге, заполнить поля -- тип постинга в соответствии с источником проводки, счёт постинга -- в соответствии с источником и настройками, то же самое для корреспондирующей стороны. Проделать эту операцию один или два раза в зависимости от того, включена ли физическая разноска
- Создать запись в LEDGERTRANS на основании сумм из INVENTTRANS и счетов из INVENTTRANSPOSTING
Располагая такими правилами можно построить в памяти (или на диске, рядом) копию таблицы INVENTRRANSPOSTING, после чего сравнить её с оригинальной.
Если запись в новой найдена, а в оригинальной нет, то добавить.
Если запись в оригинальной найдена, а в новой её нет -- удалить.
Если обе записи есть (по ключу), но они отличаются неключевыми полями -- обновить.
Сначала нужно получить список расхождений, не применяя их ("Семь раз отмерь -- один отрежь").
Проанализировать их.
По логике, если мы не ожидали, что база сильно битая, а расхождений получилось много, то надо проверить правила и возможно подкорректировать их.
А если расхождений не много, и мы согласны с каждой строкой исправления -- применить.
Применять исправления можно, только если мы согласны с каждой строкой исправлений.
Таким же образом строится и копия складской стороны LEDGERTRANS и сравнивается с оригинальной.
Применять исправления там сложнее, т.к. может быть затронута и корр. сторона, но, думаю, это, возможно.
В результате получим отличный склад без ненужных записей и с высокой производительностью.
