Known Issues & Risks

This page collects the system's known weak points in one place. None of it is a surprise to people who have worked on the code — writing it down is what makes the docs honest and useful for support, onboarding, and any future hardening or rewrite. Each item notes the risk and where it lives.

These are documented, not necessarily bugs to fix today

The system runs a live business. Treat this as a risk register: understand it, work with it safely, and use it to prioritise if/when a modernization is funded.

Security

#	Issue	Risk	Where
S1	EDP / DLY backdoor superusers — no DB row, time-derived password, bypass all permission checks.	Undocumented full access to anyone who knows the algorithm + server clock.	Security
S2	ButtonAccess fails open — any SQL exception returns add/edit/delete = True.	A DB hiccup elevates privileges instead of denying.	Security
S3	Reversible-cipher passwords — PassToChar/CharToPass (shift + reverse), not hashed.	User passwords are recoverable from the stored value.	Security
S4	DB credentials use the same reversible cipher in the registry, and sit cleartext in the connection string.	SQL Server credentials are recoverable per workstation.	Build & Deploy
S5	No parameterized SQL — session/user values are concatenated into SQL everywhere.	System-wide SQL-injection exposure.	Data Access

Correctness & concurrency

#	Issue	Risk	Where
C1	MAX(field)+1 / NewNumber doc numbering — no counter lock on that path.	Two concurrent postings can get the same document number.	Transactions
C2	Accumulator stock model needs periodic recompute — buckets can drift from the source documents.	Stock trusts a stored-proc recompute (Usp_ProsesHitungStock*) rather than being self-reconciling like a ledger.	Stock & Costing
C3	Average cost floors negative on-hand to 0 in GetAvgCost.	Receiving against a negative balance ignores the negative qty → average cost can drift.	Stock & Costing
C4	Errors are commonly swallowed — Try/Catch ex As Exception returning Nothing.	Failures pass silently; DataTable(...) returns Nothing on error and callers may not check.	Data Access
C5	CommandTimeout = 0 (no timeout) on all queries.	A pathological query can hang a workstation indefinitely (intentional trade-off for long recompute/report jobs).	Data Access

Architecture & maintainability

#	Issue	Risk	Where
A1	Global module state carries the session — memUserID, cPRSH, memTanggal, ConnStr.	Implicit dependencies; not thread-safe; startup order is load-bearing.	Session State
A2	App mutates machine state at startup — sets the Windows clock + locale registry keys, may remap LPT1.	Side effects on shared machines; surprising for support.	Session State
A3	External DLL dependency by relative path outside the repo.	Build fails without the exact sibling folder layout.	Build & Deploy
A4	No test suite.	No automated safety net; changes are validated manually.	—
A5	Layering is a tendency, not enforced — forms run SQL directly; the Class/ layer is optional.	Business logic and data access leak into the UI.	Architecture
A6	Two coexisting data-access styles (inline SQL vs typed BrowseData) with overlapping duties.	Inconsistency; the typed classes still build string SQL.	Data Access

Platform & lifecycle

#	Issue	Risk	Where
P1	Frozen stack — VB.NET, .NET 3.5, VS 2008, Crystal Reports, SQLDMO.	End-of-life tooling; hard to hire for; security patches limited.	Technology Stack
P2	Windows-only, fat client, DB-direct — no service tier.	Every PC holds DB credentials and connects directly; no central API to secure or evolve.	Architecture
P3	Setup project builds only in the VS IDE.	Cannot fully automate the installer build via MSBuild/CI.	Build & Deploy

If you are planning a modernization

The items above map cleanly onto the usual redesign moves — treat them as the why behind each:

• Ledger, not accumulator (C2, C3) — an append-only stock-movement ledger with a derived balance is self-reconciling and removes the recompute step.
• Locked sequence table (C1) — replace MAX()+1 with a row-locked counter inside the posting transaction.
• Hash passwords + real secret storage (S3, S4) — bcrypt/PBKDF2 for users; OS/secret manager for DB credentials.
• Parameterized queries / an ORM (S5) — eliminates injection and the two-style split.
• Fail closed (S2) — deny on error, and drop the hard-coded backdoors (S1).
• Explicit session context (A1) — pass a request/session object instead of globals.

Scope note

This site documents the legacy system as it is. Any modernization is a separate, deliberate project — this page just gives it an accurate starting map.