d-stream

Видимо лучше всего - чужой и свой код.

Исходить надо из несколько иного: при любых расчетах с физлицами требуется формировать кассовые чеки (54ФЗ)

Далее - искать временные исключения для каких видов деятельности и до какого срока кассовые чеки можно не формировать.

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

На практике прокидывают радиомост от кого-нибудь. В этом есть некоторые засады:
1. зачастую оборудование ставится завышенной мощности (более 20мВт), что чревато при принципиальном подходе надзорных органов штрафом и изъятием оборудования
2. в провайдерских договорах как правило в той или иной форме присутствует пункт о непредоставлении "интернета на сторону" - тут при наличии провайдерской корысти донор может пострадать от расторжения договора до сдачи его надзору за безлицензионное предоставление телематических услуг связи...

На практике "все так делают и никого не наказывают", но стоит вспомнить про отравившихся боярышником - до этого все его пили и не травились...

Совсем упрощенно - с годовым оборотом менее миллиона долларов - можно работать бесплатно. Больше - уже есть моменты, но имея миллион долларов оборота - заботить будут совсем иные вопросы.

Полагаю что статический анализатор анализирует файл, предполагая что это что-то но не sql

Растаскивая мух и котлет по разным сторонам тарелки:
1. Транспорт - циски, микротики, провайдерские варианты - без разницы. Главное реализовать доступность голов и филиалов
2. AD - собственно еще со времен 2000 в продуктах Майкрософт есть все для построения лесов, сайтов - достаточно выбрать наиболее понравившуюся модель со степенью авторитарности (голова-лес или же трасты)
Ну и как уже подметили - DFS для "совместной" работы. Естественно есть нюансы...

Конкретика сильно зависит от архитектуры. Единственное что могу сказать, что всякие хелперы в виде промежуточных итогов - могут оказаться скорее злом.

Дык в чем именно проблема?
l2tp/IPsec в общем-то умеют через NAT ходить, а каким путем они пойдут - это PBR укажет. Главное не забыть про тропинку назад.

Собственно любое решение приведет в явному или неявному разделению CSV на несколько.
Так что можно это делать любым удобным способом.

Обобщенный универсальный вариант:

update table
set ...
from table
join ....
where ...

ИП - по сути только одна СНО.
Для множественных СНО - только юрлицо.

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

использовать join

серверная материнка с двумя процессорами, двумя видеокартами, "серверной" памятью окажутся подороже двух компьтеров

select * from ( select ... union select) as t1
join t2 on t1....

https://ru.wikipedia.org/wiki/%D0%90%D0%BF%D0%BF%D...

ru-wiki.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0...

https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D...

select 
date,
sum(dbt),
sum(crd)
from(
select date, summa as dbt, 0 as crd  from t1
union all
select date, 0 as dbt, summa as crd from t2
) as t3 
group by date