TOTVS Protheus product master cleansing: types, groups and blocking

To clean up the product master in TOTVS Protheus, start with the fields that change how the system behaves: product type, product group, the two units of measure and their conversion factor, the default inbound and outbound TES, origin and IPI rate. To take a duplicate out of use, rely on the B1_MSBLQL block field or on a business rule in routine FATA100, not on deletion. And keep your own change log, because the native Protheus history only records the description and the profit margin fields.

Protheus is the Brazilian ERP developed by TOTVS. Here is a common scene: a request comes in for a new code for nitrile gloves. The analyst searches the products and finds three similar ones: one in group "0002 Borracha" (rubber), one with no group, and one typed as MC (consumable material) that the plant uses as a raw material. With a queue of tickets, the shortest path is to open the first one, use the "Cópia" (copy) option and release the new code. The fourth code is born with the same group, the same type and the same default TES as the original, right or wrong.

This article covers what is specific to Protheus within material and product master data cleansing: the product master (routine MATA010), product groups (MATA035) and record blocking (MSBLQL). The general field by field review, which applies to any system, is in our material master data cleansing checklist.

What is the product master in Protheus?

According to TOTVS documentation, the "Produtos" master (routine MATA010) holds the main information about products and services the company buys, manufactures or supplies, and controls those products across all modules of the system (TDN, Produtos - MATA010). TDN is the TOTVS technical documentation portal. The fields live in table SB1 with the prefix B1_, such as B1_DESC (description) and B1_MSBLQL (block flag).

The same page notes that the meaning of "product" varies by industry and module: in the workshop module it is a spare part, in environmental management it is waste, in transport management it is fuel. That is why an error in SB1 does not stay in purchasing. It shows up in inventory, production, billing and the tax books.

Is the product type right, and what changes if it is not?

TOTVS documentation says the "Tipo do Produto" (product type) field groups products so that processes, reports and queries can be restricted. The examples given are BN (outsourced processing), CG (general expenses), MO (labor), MP (raw material), PA (finished good), PI (intermediate product) and MC (consumable material). Companies can create their own types in table 02 of the "Configurador" (configuration) module (TDN, MATA010).

Three points from the same page guide the cleanup:

• Types are informational only. The one type with special handling is BN, which identifies products processed by the company or sent out for processing; these are not reserved when production orders are opened.
• Whether an item is bought or produced does not depend on its type. The system determines that from the existence of the master record and its structures (bills of materials).
• If the company uses product type in its accounting posting rules, the types should be consistent with the chart of accounts.

Our reading: an MC item used as MP does not block purchasing or production, but it distorts every filter and report by type and, if type feeds accounting, it can send postings to the wrong account. So changing a type is a decision for the controller's office, not for the master data team alone. It is also worth reviewing table 02 itself: custom types created over the years, with similar names, often split the same family of items.

Do your product groups (MATA035) still make sense?

According to TOTVS documentation, a group brings together products with common characteristics (shape, weight, type, use, dimension) so they are easier to select in processes, queries and reports, and to flag items that need special handling, storage or packaging. Routines parameterized by group accept a range of groups, and every product classified in them is included (TDN, Grupos de Produtos - MATA035).

The system ships with seven groups, codes 0001 to 0007: "Plástico" (plastic), "Borracha" (rubber), "Alumínio" (aluminum), "Eletrônicos" (electronics), "Pneumáticos" (tires), "Produtos Químicos" (chemicals) and "Produto de Venda" (sales product). TOTVS says they are only suggestions and can be changed or deleted, and new groups can be added at any time.

The warning sign is a database that never touched those suggestions. "Produto de Venda" mixes items with nothing in common, "Eletrônicos" becomes a drawer for anything with a plug, and part of the products has no group at all. Because reports and routines work by group range, a poorly defined group makes an item vanish from an analysis or land where it does not belong. We recommend designing the groups from the classification the company wants to use, and only then moving the products.

Units of measure and conversion factor: what should you check?

Protheus works with two units. TOTVS documentation describes the standard unit, used in every transaction from purchase to sale, and the second unit, derived from the conversion factor and the conversion type, which tells the system whether to multiply or divide the first unit by the factor. The TOTVS example: 3 kg, factor 1000, multiplication, gives 3,000 grams. The system keeps stock balances in both units, but unit cost reflects the standard unit. When there is no fixed factor, as with items that vary with humidity or heat, both quantities can be entered directly (TDN, MATA010).

Warning signs: an inverted conversion type (divide instead of multiply), a fixed factor on an item whose weight varies, a second unit with no factor on an item with a fixed conversion, and duplicate codes of the same item with different standard units. This field needs item by item review, with the people who buy and receive the material.

Which SB1 fields depend on decisions by tax and purchasing?

Origin, IPI rate and ICMS rate

On the "Impostos" (taxes) tab, TOTVS documentation says the IPI rate (IPI is Brazil's federal tax on industrialized products) follows the TIPI, the official IPI rate table. The origin code (0 domestic, 1 foreign by direct import, 2 foreign bought in the domestic market) is used on invoices and in the tax books. The ICMS rate (ICMS is the Brazilian state tax on the circulation of goods) should only be filled in for items with specific taxation; otherwise the internal rate from parameter MV_ICMPAD applies. Inbound and outbound routines only calculate ICMS, IPI and ISS (the municipal service tax) if the TES in use says so (TDN, MATA010). TES stands for "Tipo de Entrada e Saída", the Protheus inbound and outbound transaction type that drives tax, stock and financial effects.

Warning signs: an ICMS rate filled in on an item with no specific taxation, different origin codes between duplicates of the same item, an IPI rate that does not match the classification. Reviewing the NCM itself (the Mercosur product classification code used in Brazilian tax documents) has its own guide: how to review NCM codes in the material master.

Default TE and TS

The "TE Padrão" and "TS Padrão" fields assign a default TES for the product's inbound and outbound transactions, used to calculate taxes, update stock and post financial movements. Changing the default TES in bulk changes tax, stock and financial results of every future transaction. The tax team decides, together with the controller's office.

Default supplier and supplier branch ("Loja Padrão")

According to the documentation, the "Fornecedor Padrão" and "Loja Padrão" fields must be filled when purchasing uses partnership contracts and delivery authorizations, with the same supplier as the contract. If they are not, replenishment planning creates purchase requisitions instead of delivery authorizations. An outdated default supplier, or one copied from a duplicate code, changes how the item gets bought.

What should you do with generic "Diversos" products?

TOTVS itself suggests, as a tip in the product master, creating products with codes such as "Genéricos", "Despesas" or "Diversos" (generic, expenses, miscellaneous) for non-stock items. The feature is legitimate. The trouble starts when it has no usage rule: recurring purchases of items that should have their own code go through the generic one, and the company loses price, supplier and consumption history.

During cleanup, we recommend listing what was bought under those codes, separating real expenses from recurring materials, and writing down when the generic code may be used. Recurring items get their own code with a standardized description (our guide on how to write material descriptions helps with that part).

How do you take a duplicate product out of circulation in Protheus?

Before touching the system, the company needs to have decided which code survives. The criteria for that choice are in our guide on identifying duplicate materials. Once the pair is decided, the process in Protheus has four steps, each backed by the documentation.

1. Do not count on deletion

TOTVS states that a product cannot be deleted if it is part of the "Sugestão de Orçamento" (budget suggestion) (TDN, MATA010). Our reading: even when deletion is accepted, blocking is usually the safer path for a duplicate, because it keeps the code and the history linked to it, as the next step shows.

2. Block it with field B1_MSBLQL

According to TOTVS documentation, records in Protheus are blocked through the MSBLQL field; if the table does not have it, it is created in the "Configurador" module. In the billing module, the block prevents the record from being selected in new transactions, such as a new sales order. Status and history already generated remain valid and can be handled normally, and the block applies only from the moment it is set (TDN, FAT0099 MSBLQL).

3. Check production before blocking

The same page warns that B1_MSBLQL prevents the product from being selected in new sales orders, but also prevents processing of the production order, if the company uses them. If the duplicate still has a production order to process, blocking it now stalls that order.

4. If only sales need to stop, use a business rule

As an alternative, TOTVS suggests adding the product to a business rule in routine "Regras de Negócio" (FATA100), tab "Comercialização" (sales), as an exception rule. Sales orders with that product are then blocked by business rule (TDN, FAT0099 MSBLQL). In practice, we recommend the business rule while the old code's production orders finish, and B1_MSBLQL once nothing depends on it anymore.

Does Protheus keep a history of what changed during cleanup?

Only partly. TOTVS documentation says that with parameter MV_HISTTAB set to .T., each confirmed change to the product master is recorded in table AIF ("Alterações Cadastrais", master data changes). But the control only records changes to the product description and the profit margin: fields B1_DESC, B1_PICMENT and B1_PICMRET (the last two are the profit margin used to calculate ICMS under tax substitution, known as ICMS-ST, in the "Solid. Entr." and "Solid. Saída" fields of the "Impostos" tab, not the commercial margin). Table AIF is used by the tax team, with function MSCONHIST to query the history (TDN, MATA010).

Type, group, units, conversion factor, default TES, origin, default supplier and block flag are outside that history. In our reading, those are exactly the fields that change most in a cleanup. So each batch needs its own log, with code, field, old value, new value, date and approver.

Why does the copy option spread errors?

TOTVS presents the "Cópia" (copy) option, in the product maintenance menu, as a way to speed up data entry. It copies the source product with everything it has. If the source item is in the wrong group, with the wrong type or an outdated default TES, the new code inherits all of it, as in the opening scene. Until the database is clean, we recommend copying only from reviewed template products.

What to check in each Protheus feature, and who decides?

The "who decides" column is our recommendation, not a TOTVS rule. Adjust it to your organization.

Protheus feature or field	What to check	Warning sign	Batch or item by item	Who decides
"Tipo do Produto" (table 02)	Whether the type reflects real use; whether custom types in table 02 overlap	MC used as MP; types with similar names; BN on an item never sent for processing	Batch by group, after the rule is approved	Controller's office (if type feeds accounting) with master data
Product groups (MATA035)	Whether groups 0001 to 0007 were adapted; whether every product has a group	Products with no group; catch-all group with unrelated items	Group design item by item; reassignment in batch	Master data with procurement
Standard unit, second unit, conversion factor and type	Consistency between the two units and the direction of conversion	Multiply instead of divide; fixed factor on a variable weight item	Item by item	Procurement and warehouse
Origin, IPI rate, ICMS rate	Origin 0, 1 or 2; IPI per TIPI; ICMS only with specific taxation	Different origin between duplicates; ICMS filled in for no reason	Item by item, with tax validation	Tax
Default TE and TS	Whether the default TES still matches the item's operation	Old TES; different TES across codes of the same item	Batch only after testing in a staging environment	Tax with controller's office
Default supplier and supplier branch ("Loja Padrão")	Whether they match the partnership contract, when there is one	Purchase requisition created where a delivery authorization was expected	Item by item	Purchasing
Generic products ("Diversos", "Despesas")	What was bought under them and how often	Recurring material always bought through the generic code	Item by item analysis; usage rule for all	Purchasing with controller's office
B1_MSBLQL and business rule (FATA100)	Whether the duplicate still has a production order or sales order to process	Duplicate not blocked; block that stalled a production order	Pair decision item by item; block in batch	Master data with production planning and sales
MV_HISTTAB and table AIF	Whether the parameter is active and what it records	Team assuming the system keeps the full history	One-time setting	IT with tax

What does this look like in a concrete case? (hypothetical example)

Hypothetical example, created only to illustrate. It is not a customer case.

A manufacturer has three codes for the same nitrile glove. Code A is in a PPE group the company created, typed MC. Code B is in the suggested group "0002 Borracha", also typed MC. Code C was created by copying a raw material and ended up typed MP, with the raw material's default TES. The team decides that A survives.

1. The tax team checks origin, IPI rate and the default TE of A before any change, since A will now receive all the demand.
2. Code B has no open production order or sales order. Master data sets B1_MSBLQL and records the old and new values in the cleanup log.
3. Code C appears in a production order that is still open. Blocking it with B1_MSBLQL would prevent that order from being processed. The team uses the business rule in FATA100 to stop new sales of C and schedules B1_MSBLQL for after the order closes.
4. The controller's office confirms that the MP type on C fed an accounting posting rule. The type of C is corrected only after that analysis, so future postings do not change without notice.
5. Master data agrees that new gloves are created by copying A, already reviewed, and never B or C.

Where to start

1. Export SB1 with type, group, units, conversion factor and type, origin, tax rates, default TE and TS, default supplier and B1_MSBLQL. Check that the MSBLQL field exists in the table; if it does not, IT creates it in the "Configurador" module.
2. Review the type table (table 02) and the MATA035 groups before touching products. They will define your batches.
3. Take to tax and to the controller's office the list of changes to default TES and to types used in accounting. None of these change without their decision.
4. Decide the duplicate pairs and, for each one, check open production orders and sales orders. Choose between B1_MSBLQL and a business rule in FATA100.
5. Build the change log with code, field, old value, new value, date and approver, because the native history (MV_HISTTAB and AIF) does not cover these fields.
6. Test each batch in a staging environment: issue an invoice, open a production order, create a purchase requisition. Bulk loading is done by the technical team, with the tool they already use, tested in staging first.
7. Apply to production batch by batch, starting with the highest impact groups. If the database is large, ABC prioritization helps order the batches.

Frequently asked questions

Can you delete a duplicate product in Protheus?

Not always. TOTVS documentation states that a product that is part of the "Sugestão de Orçamento" (budget suggestion) cannot be deleted. For duplicates, the documented way to take a code out of use is the B1_MSBLQL block field, which prevents use in new transactions and keeps the history already generated.

Does blocking a product with B1_MSBLQL stop production?

Yes. TOTVS warns that B1_MSBLQL prevents the product from being selected in new sales orders and also prevents processing of the production order, if the company uses them. If only sales need to stop, the documented alternative is a business rule in routine FATA100, tab "Comercialização", as an exception.

Does Protheus keep a history of product master changes?

Partly. With parameter MV_HISTTAB set to .T., changes go to table AIF, but only when the description (B1_DESC) or the profit margin (B1_PICMENT and B1_PICMRET) changes. Changes to type, group, units, default TES and block flag need a separate log.

What does a wrong product type affect?

According to TOTVS documentation, types are informational, used for filtering, and do not decide whether an item is bought or produced. The only type with special handling is BN. The effect shows up in reports and processes filtered by type and, if the company uses type in accounting posting rules, in accounting.

Can I use the default groups 0001 to 0007?

You can, but TOTVS presents those groups (plastic, rubber, aluminum, electronics, tires, chemicals and sales product) only as suggestions that can be changed or deleted. Keep the ones that reflect your catalog and create the groups that are missing.

Do I need to stop operations to clean up the data?

Not necessarily. An MSBLQL block applies only to new transactions and does not invalidate what was already generated, which allows cleanup in batches. Note that B1_MSBLQL also prevents processing of production orders, so check open production orders before blocking or, if the goal is to stop only sales, use the business rule in FATA100. The care goes to changes that affect future transactions, such as default TES and types used in accounting: those should go through staging tests and be approved by tax and the controller's office.

How 4MDG can help

What this article covers is the Protheus side. Before it comes the work on the catalog itself: taxonomy by family, PDM with short and long descriptions, deduplication with scoring and survivorship, NCM and UNSPSC classification, unit of measure and conversion factor. That is our material master data cleansing service, which ends with loading and governance, with validation rules at entry and an approval workflow. The 4MDG platform integrates with ERPs such as SAP, TOTVS and Oracle through connectors, as described in capabilities and architecture. To see where your catalog stands, request the free assessment or reach us through the contact page.

Note: parameters, fields and routines may vary with the Protheus version and configuration in your company. Confirm with your technical team and your tax team before applying any of this. The tax rules mentioned here apply only in Brazil.

Sources

• TOTVS, TDN, "Produtos - MATA010". https://tdn.totvs.com/display/public/PROT/Produtos+-+MATA010. Accessed on November 3, 2026.
• TOTVS, TDN, "Grupos de Produtos - MATA035". https://tdn.totvs.com/display/public/PROT/Grupos+de+Produtos+-+MATA035. Accessed on November 3, 2026.
• TOTVS, TDN, "FAT0099 MSBLQL Bloqueio de Registro / Cadastro". https://tdn.totvs.com/display/PROT/FAT0099_MSBLQL_Bloqueio_de_Registro_Cadastro. Accessed on November 3, 2026.