Inter-Branch Data Sync¶

There is no central application server, so branches and Head Office (HQ) stay in step by shipping files — exported data batches moved over flash disk, email, or FTP. This is the TransferData subsystem (INVENTORY/Form/TransferData/).

Direction: driven by `PRSH_HO`¶

The company record's cPRSH.PRSH_HO flag ("is this Head Office?") decides who exports what, and the ZIP filename prefix encodes the direction:

flowchart LR
    subgraph Branch["Branch (PRSH_HO = N)"]
        BX["Export CAB*.ZIP"]
        BI["Import DTA*.ZIP"]
    end
    subgraph HQ["Head Office (PRSH_HO = Y)"]
        HX["Export DTA*.ZIP"]
        HI["Import CAB*.ZIP"]
    end
    BX -->|"branch → HQ"| HI
    HX -->|"HQ → branch"| BI
    style Branch fill:#e3f2fd,stroke:#1976d2
    style HQ fill:#e8f5e9,stroke:#388e3c

Branch → HQ: branch exports CAB<…>.ZIP; HQ imports files matching prefix CAB.
HQ → Branch: HQ exports DTA<…>.ZIP; branch imports files matching prefix DTA.

Filename pattern (outbound): IIf(PRSH_HO="Y","DTA","CAB") & Left(Outlet,9) & yyyyMMdd & Right(100+noUrut,2) & PRSH_KODE & ".ZIP".

The forms¶

Form	Role
`frmTransferDataKeluar.vb`	Outbound export — stage → zip → send.
`frmTransferDataMasuk.vb`	Inbound import — receive → unzip → load.
`frmTransferDataSOC.vb`	Targeted export of SOC (stock-opname / `BOH_NODOC`) documents to selected outlets.

Sync control & log tables¶

erDiagram
    tbMaster_FileTransfer ||--o{ tbTR_LogTransferFile  : "each export logged"
    tbMaster_FileTransfer ||--o{ tbTr_SinkronisasiData : "batch record counts"
    tbMaster_FileTransfer {
        string TRF_FILEKIRIM PK
        string TRF_STRSQL "source query"
        string TRF_KONDISI1
        string TRF_FORMATFILE "XML / CSV"
        string TRF_PROSESHARIAN "daily flag"
    }
    tbTR_LogTransferFile {
        string LOG_KODECABANG PK
        string LOG_NAMAFILE PK
        date   LOG_TGLPROSES PK
        string LOG_TIPE "K=keluar"
        string LOG_MEDIA "EMAIL/FTP/FLASH"
        string LOG_KODETUJUAN
    }

Config (tbMaster_FileTransfer) declares what to send and its query; each run is recorded so inbound can dedup by LOG_NAMAFILE. Payload tables themselves carry the *_IDTRANS stamp (below) rather than pointing at these log tables with a foreign key — the linkage is by the sync id, not a relational constraint.

Transport media (chosen by `PRSH_SENDVIA`)¶

flowchart TD
    Z["Data batch (ZIP of XML/CSV)"] --> M{"PRSH_SENDVIA"}
    M -->|"1"| F["Flash disk / folder<br/>write to export folder"]
    M -->|"2"| E["Email (GMail)<br/>SMTP send / POP3-IMAP receive"]
    M -->|"3"| T["FTP<br/>passive-mode upload/download"]
    style E fill:#fff3e0,stroke:#fb8c00
    style T fill:#fff3e0,stroke:#fb8c00

`PRSH_SENDVIA`	Medium	How
`1`	Flash disk / folder	Writes the ZIP to the export folder.
`2`	Email	`FrameWork.SmartSoft.Net.GMail` — `SendEmail()` with the ZIP attached (SMTP port 587); inbound `ReceiveEmail()` (POP3 995) / `ReceiveAndDeleteEmail()` (IMAP). Config: `PRSH_SMTP`, `PRSH_EMAILTO`, `PRM_EMAILITTO`.
`3`	FTP	`FrameWork.SmartSoft.Net.FTP` (hand-rolled passive-mode socket FTP) — `UploadFile` / `GetFileList` + `DownloadFile`. Config: `PRSH_URLFTP`, `PRSH_USERFTP`, `PRSH_PASSFTP`, `PRSH_PORTFTP`, `PRSH_PATHFTP`.

The folder convention¶

Setting	Meaning
`PRSH_FOLDERKIRIM`	Outbound ("kirim" = send) staging. Export creates a per-day subfolder `…\dd\`, writes per-table `.XML`/`.CSV`, then zips into `CAB`/`DTA*.ZIP`.
`PRSH_FOLDERTERIMA`	Inbound ("terima" = receive) drop. Import downloads/receives ZIPs here, unzips (`Ziplib.UnCompress`), and dispatches each extracted file by its 3-char prefix.

What moves, and how batches are tracked¶

Payloads are per-table .XML (via DataSet.WriteXml) or .CSV. The set of transferable tables comes from tbMaster_FileTransfer (TRF_FILEKIRIM prefix, TRF_KETERANGAN, split into Master vs Transaksi checklists, TRF_PROSESHARIAN flag).
File prefixes seen: Master*, SO (sales/re-order), PB (permintaan/receipt), SVH+SVP (service header + photo), ABN (attendance → CSV), BRP, SOC (stock-opname doc).
Every export is logged — in tbTr_SinkronisasiData (SIN_ columns, per-batch record count) and in tbTR_LogTransferFile (LOG_NAMAFILE, LOG_TIPE, LOG_MEDIA, LOG_KODETUJUAN, date range, LOG_USERID). Inbound dedups against LOG_NAMAFILE so the same file isn't imported twice. The transferable-table set and its export SQL come from tbMaster_FileTransfer (TRF_STRSQL, TRF_KONDISI1/2, TRF_PROSESHARIAN).

The `*_IDTRANS` sync stamp¶

flowchart LR
    A["HAKCVT.IdTrans(memUserID)"] --> B["Stamps every synced row:<br/>ST_IDTRANS · BOH_IDTRANS/BOD_IDTRANS<br/>SOH_IDTRANS/SOD_IDTRANS · POH_IDTRANS<br/>PRD_IDTRANS · TRA_IDTRANS"]
    B --> C["Ties a received XML batch<br/>back to its transfer transaction"]
    style B fill:#fff3e0,stroke:#fb8c00

Nearly every table carries a per-table *_IDTRANS column, generated by HAKCVT.IdTrans(memUserID). On import, frmTransferDataMasuk sets these as it inserts — this is the thread that links a received batch back to the originating transfer, and it is why the _IDTRANS columns appear on essentially every table (see Database Overview).

This is eventual, file-based consistency

Branches are not live-consistent with HQ. They converge when a batch is exported, transported, and imported — with dedup by filename and identity by *_IDTRANS. A "missing at HQ" report is usually a transfer that hasn't been sent/received yet, not lost data. Check tbTR_LogTransferFile first.