PlanMaker DECIMAL: Decode Binary and Hexadecimal Text into Numbers

• Introduced: Documented by the PlanMaker 2016 manual; the original introduction release and date are unknown.
• Availability: Documented in PlanMaker 2026. That checked version is not a final supported-version endpoint.
• Scope: Current reference belongs to the PlanMaker 2026/NX manual family. Individual FreeOffice and mobile-build availability are not established here.
• Checked: October 14, 2026, against the official DECIMAL reference and historical manuals. Examples were independently calculated; no native PlanMaker execution was performed.

DECIMAL(Number, Base)

Both arguments are required. Number is the representation to convert; Base is its source base, currently documented as an integer from 2 through 36. There is no omitted-base default in the printed signature. SoftMaker’s examples put representations in quotation marks, including the binary input that starts with zeroes. Follow that text form for imported codes rather than relying on automatic conversion.

The result has a different purpose from BASE: DECIMAL decodes a representation into a number, while BASE encodes a number as text. Neither function identifies a source base from the digits alone. See the official DECIMAL entry.

On DecodeValues, put Representation, Source base, Decimal value, Input length and Value plus one in A1:E1. Enter the formulas shown in A2:A9 to guarantee text inputs, and the numeric base in B. Do not type the expected C values into the formula column.

Enter C2 =DECIMAL(A2,B2), D2 =LEN(A2) and E2 =C2+1, then fill C2:E2 through row 9. The first two C results reproduce SoftMaker’s examples. The extra arithmetic column operates on the decoded value rather than the visual sequence of digits.

For a manual hexadecimal check, FF means 15*16+15 = 255. Binary 00101010 means 32+8+2 = 42. Decimal 010 and binary 1010 both decode to ten in this table, despite their different source strings and bases. Keep A and B when the original representation matters.

On a separate SameDigits sheet, put ="10" in A2 and fill it to A6. Enter 2, 8, 10, 16, 36 in B2:B6. C2 =DECIMAL(A2,B2) filled to C6 gives 2, 8, 10, 16, 36 respectively.

The positional calculation is simply 1*Base+0. A successful conversion therefore does not prove that the correct base was supplied. For imported device codes or identifiers, obtain that information from the file specification; do not guess it from a leading zero or from the absence of letters. The base-36 example follows the current documentation, with older-version uncertainty described below.

Create CounterChange, with seven columns available. Use these headers in A1:G1: Start text, End text, Base, Start decimal, End decimal, Difference and Difference in source base. Enter ="00F0" in A2, ="0108" in B2 and 16 in C2.

D2: =DECIMAL(A2,C2)
E2: =DECIMAL(B2,C2)
F2: =E2-D2
G2: =BASE(F2,C2)

Expected D2:G2 are 240, 264, 24 and the text 18. The independent check is 15*16 = 240, 1*256+8 = 264, and 1*16+8 = 24. Eighteen as ordinary decimal text would mean something different from hexadecimal 18.

Duplicate the sheet as ChangedCounter. Change only B2 to ="0110". E2 becomes 272, F2 becomes 32 and G2 becomes text 20; D2 remains 240. This example assumes an increasing counter with no rollover and uses a positive difference suitable for BASE’s documented domain. It is not a general elapsed-count solution for wrapped or signed counters.

On Padding, enter ="0010" in A2, ="10" in A3, and 16 in both B2 and B3. Put =DECIMAL(A2,B2) in C2 and fill to C3: both results are 16.

In E2, =C2=C3 is TRUE. In E3, =EXACT(A2,A3) is FALSE. In F2, =BASE(C2,B2) returns text 10; in F3, =BASE(C2,B2,LEN(A2)) returns 0010. The restored width comes from A2’s retained length, not from the decoded number. EXACT and LEN distinguish value equality from a padded identifier’s text identity.

This small round trip uses digit-only text and positive values. It does not establish normalization rules for every alphabetic representation, sign or imported type.

The 2016 manual, pages 506–507 and 2018 manual, page 486 specify bases 2–32. The checked 2021, 2024 and 2026 references specify 2–36. Whether this reflects an implementation change or a documentation correction is not established; the wider range should not be projected into every older build.

SoftMaker’s Excel 2013 compatibility note concerns Excel, not the first PlanMaker version. For workbook exchange, preserve the original representation and base and check the receiving application’s contract.

The short DECIMAL entry does not define the maximum input length, exact integer precision, prefixes such as 0x, lowercase handling, fractional representations, signed encodings, whitespace coercion or exact error tokens. For example, digit 2 is not a valid binary digit by the positional model, but the vendor entry does not identify the precise PlanMaker error for that invalid input. These examples deliberately use valid, small, explicit representations.

Use the separators displayed by your formula editor when they differ from the English manual’s commas. Do not change the quoted digits or the source base to resolve a formula-entry problem.