The balancing leg of a payroll journal is mapped through the wage type that has always existed for it, an out-of-date mapping window is named as one, and a tenant with no chart of accounts is given the standard chart on deploy.
A Mapping Dated After the Period Is Named, Not Called Missing
A GL mapping takes effect from the day it is created, so a mapping added while closing last month’s payroll is dated after the period end and is correctly filtered out — but the refusal then said the wage type was not mapped while the operator was looking straight at the mapping they had just saved.
The message now names the effective window and says to widen it, rather than inviting a second mapping row that will not help either.
The Net Pay Leg Is Mapped Through Wage Type 9920
The posting service looked for a wage type code that no catalogue has ever contained, so the balancing net-pay leg could never be mapped however carefully the mapping table was filled in. It now reads 9920 Net Pay, which has been in the standard catalogue since the payroll engine shipped.
Creating a second wage type meaning “net pay” would have left two codes for one concept and an even chance of an operator mapping the wrong one.
A Tenant With No Chart of Accounts Is Given the Standard One
The chart of accounts came only from a command run by hand per tenant, and three production tenants had never had it run — which blocks GL account creation outright, because an account has to hang off a chart. The deploy now seeds it.
It seeds only into an empty chart. The shipped template is not the only chart in use, codes collide across standards, and renumbering a chart that already carries posted journals is a supervised act — not something a deploy may do behind the operator’s back.