Several valid, active Ecuadorian RUCs with third digit 9 are rejected with InvalidChecksum. They satisfy neither the juridical (mod-11, check digit at position 10) nor the public (mod-11, check digit at position 9) algorithm, so the 0f94ca6 fix from #457 doesn't catch them. This is the same class as the still-unresolved #290.
Each number below is confirmed active in the official SRI registry (tipoContribuyente: SOCIEDAD):
| RUC | Company (SRI) | public (pos 9) | juridical (pos 10) |
|---|
1793213150001 | CARNADA S.A.S. | fail | fail |
1793189906001 | CREDI&CORP S.A. | fail | fail |
0993366721001 | DISTRIBUCIONES-MEJIA S.A.S. | fail | fail |
0993370026001 | PONTEDORA S.A.S. (the #290 example) | fail | fail |
Reproduce:
importstdnum.ec.rucstdnum.ec.ruc.validate('1793213150001') # InvalidChecksumVerify validity against the SRI's own public registry (the same backend its consultation site uses):
curl -s "https://srienlinea.sri.gob.ec/sri-catastro-sujeto-servicio-internet/rest/ConsolidadoContribuyente/obtenerPorNumerosRuc?ruc=1793213150001"# -> [{"razonSocial":"CARNADA S.A.S.","estadoContribuyenteRuc":"ACTIVO","tipoContribuyente":"SOCIEDAD",...}]On the "reliable source" you asked for in #290/#457: Ecuador's own e-gov team documents that the check digit is not always computable. Their tracker (gobec_forms#32) states that when the sequential portion exceeds 6 digits, "Module 11 validation for the 10th digit as verifier is no longer executed," and concludes that such RUCs can only be validated against the SRI registry, not by formula.
Honest caveat: I could not derive a clean deterministic rule for which numbers lack a recomputable check digit. It does not track legal form (CREDI&CORP is an S.A., not S.A.S., and also fails) or registration date. The only authoritative validation appears to be the registry lookup itself.
Possible directions (your call): (a) document this as a known limitation for 3rd-digit-9 RUCs; (b) optionally fall back to structural validation (length/province/type/establishment) when both checksums fail for 3rd-digit-9, accepting that these carry no verifiable check digit. Happy to send a PR for whichever you prefer.
Several valid, active Ecuadorian RUCs with third digit
9are rejected withInvalidChecksum. They satisfy neither the juridical (mod-11, check digit at position 10) nor the public (mod-11, check digit at position 9) algorithm, so the0f94ca6fix from #457 doesn't catch them. This is the same class as the still-unresolved #290.Each number below is confirmed active in the official SRI registry (
tipoContribuyente: SOCIEDAD):1793213150001179318990600109933667210010993370026001Reproduce:
Verify validity against the SRI's own public registry (the same backend its consultation site uses):
On the "reliable source" you asked for in #290/#457: Ecuador's own e-gov team documents that the check digit is not always computable. Their tracker (gobec_forms#32) states that when the sequential portion exceeds 6 digits, "Module 11 validation for the 10th digit as verifier is no longer executed," and concludes that such RUCs can only be validated against the SRI registry, not by formula.
Honest caveat: I could not derive a clean deterministic rule for which numbers lack a recomputable check digit. It does not track legal form (CREDI&CORP is an
S.A., notS.A.S., and also fails) or registration date. The only authoritative validation appears to be the registry lookup itself.Possible directions (your call): (a) document this as a known limitation for 3rd-digit-9 RUCs; (b) optionally fall back to structural validation (length/province/type/establishment) when both checksums fail for 3rd-digit-9, accepting that these carry no verifiable check digit. Happy to send a PR for whichever you prefer.