...
| Informações |
|---|
| title | Configuração necessária para envio de e-mail |
|---|
|
MV_RELACNT - Conta utilizada para envio do e-mail
MV_RELSERV - Endereço do servidor de e-mail
MV_RELPSW - Senha da conta utilizada para envio do e-mail
MV_RELAUSR - Usuário de autenticação de e-mail
MV_RELAPSW - Senha do usuário de autenticação de e-mail
MV_RELFROM - Endereço de e-mail que ira disparar o e-mail
MV_RELAUTH - Faz autenticação no servidor de e-mail |
| Informações |
|---|
| title | Log XML - MV_TSATLOG = 5 | MV_TSATLOG |
|---|
|
- Quando o parâmetro estiver com a opção 1, só será enviado o e-mail com o log se houver erros de integração.
- Quando o parâmetro estiver com a opção 2, só será gerado o log (arquivo txt) no diretório definido no parâmetro MV_TSADARQ se houver erros de integração.
- Quando o parâmetro estiver com a opção 3, só será enviado o e-mail e gerado o log (arquivo txt) se houver erros de integração.
- Quando o parâmetro estiver com a opção 5 o sistema irá gerar
A opção 5 gera - o xml de envio e retorno na pasta system, essa opção é útil para analisar erros, porém consome muito espaço em disco, por isso é importante ativá-lo para realizar o teste necessário e logo depois desativá-lo. Quando ativo o sistema sempre irá gerar o XML na pasta system, independentemente se houve erro ou não na integração. Além disso, se houver erros na integração será gerado o arquivo de log de erro (arquivo txt) no diretório definido no parâmetro MV_TSADARQ e será enviado o e-mail com o log.
Nome dos arquivos XMLs gerados:
"Numero Sequencial"_SND.
XML → - XML → XML enviado ao Suricato
"Numero Sequencial"_RCV.
XML → - XML → XML recebido do suricato como retorno do XML SND
|
03. PORTARIA 671
Com a portaria 671/2021 surgiu a necessidade de realizar 2 alterações no Protheus, para que o sistema consiga realizar corretamente a integração de marcações vindas do Suricato.
...
| X3_CAMPO | X3_TIPO | X3_TAMANHO | X3_TITULO | X3_DESCRIC |
|---|
| RR1_FUSO | C | 5 | Fuso Horário | Fuso horário da marcação |
| RR1_CODCPF | C | 11 | CPF | CPF do funcionário |
| RR1_VRSLAY | N | 3 | Vers. Layout | Versão do Layout |
| RR1_INSCR | C | 14 | Inscr. Emp | CNPJ ou CPF do empregadordo empregador |
| RR1_CCTREP | C | 17 | Código CCT | Código da CCT da marcação |
MSA_CONTROL_MARCAC
Se a tabela utilizada for a MSA_CONTROL_MARCAC, além da execução do UPPDISTR será necessário a compilação do pacote de fontes da última Expedição Contínua. Após a execução do pacote de dicionários será criada a pergunta "Atualiza Tabela MSA"? na rotina de Carga Inicial (PONM430). Esta pergunta será responsável para dizer se o sistema deve ou não atualizar a MSA_CONTROL_MARCAC com os novos campos. A pergunta terá apenas 2 respostas 1 - Sim e 2 - Não, caso seja preenchida com 1 - Sim, o sistema irá criar o novos campos da MSA_CONTROL MARCAC, caso ela esteja preenchida com não, o sistema não irá atualizar a tabela.
...
| Coluna | Tipo | Tamanho |
|---|
| COD_FUSO | varchar | 5 |
| COD_CPF_FUNC | varchar | 11 |
| NUM_VERS_LAYOUT_AFD | int | 3 |
| COD_INSCR_EMP | varchar | 14 |
| COD_CCT | varchar | 17 |
03.2 ALTERAÇÃO DA API RECORDCLOCKMARKINGS
...
| Bloco de código |
|---|
{
"items": [
{
"codRelogioExtChave": "",
"codFuncMsa": "003651",
"codNsr": 1,
"codPisMsa": "022036983234",
"datMarcacAces": "2022-11-01 09:00:00.000",
"numHorarMarcacAces": 32400,
"codRep": "00000000000000123",
"codUnidExtChave": "T1D MG 01",
"codUsuarExtChave": "T1D MG 01 003651",
"codFuso": "-0300",
"codCPF": "16046091098",
"numVersLayout": 3,
"inscrEmp": "11456156000111",
"codCCT": "00000000123212111"
}
]
} |
04. CADASTRO DO RELÓGIO
...
| Informações |
|---|
|
1 - Para que as marcações salvas na MSA sejam processadas corretamente, o código do REP, no cadastro do Protheus, deverá ser o mesmo código salvo no campo COD_REP na tabela MSA. Por exemplo se o Suricato salvar o código "5001030033938" no campo COD_REP da MSA, o Campo REP do cadastro de relógio do Protheus deverá ser salvo com o conteúdo "5001030033938". 2 - Com a portaria 671 é necessário informar o tipo do REP (1510, REP-A, REP-C e REP-P). Para um relógio do Suricato teremos apenas duas três opções, 1510, REP-A e REP-C, em ambos todos os tipos os sistema irá identificar o funcionário pelo PIS ou CPF da marcação por ser um relógio do Suricato, por este motivo qualquer uma das opções são válidas no cadastro do relógio, porém é necessário verificar qual o tipo do REP do Suricato e preencher corretamente o cadastro do relógio.
3 - Marcações vindas de um REP-A devem ter o código da Convenção Coletiva de Trabalho, esse código será utilizado na geração do Arquivo Eletrônico de Jornada - AEJ. Saiba mais: DT Adequação API integração Suricato Portaria 671. |
Exemplo de configuração dos campos no Cadastro de Relógios para integração de marcações no Suricato:
...
| Totvs custom tabs box |
|---|
|
| Totvs custom tabs box items |
|---|
| Campos utilizados na integração do funcionário, ao incluir ou alterar qualquer um dos dados utilizados para a montagem do XML será realizada uma nova integração. WSRHTSANaturalPerson <?xml version="1.0" encoding="UTF-8"?>
-<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
-<soap:Body>
-<insertOrUpdate xmlns="http://naturalperson.tsa.totvs.com/">
-<arg0 xmlns="">
<address>AV. BRAZ LEME </address> Endereço + Num.Endereço + Compl.Ender. (RA_ENDEREC + RA_NUMENDE + RA_COMPLEM)
<city>SAO PAULO </city> Municipio (RA_MUNICIP)
<country>BRASILEIRO</country> Nacionalid. (RA_NACIONA)
<email>totvs@totvs.com.br</email> End. E-Mail (RA_EMAIL)
<externalKey>T1D MG 01 00079820211011164347</externalKey> Código Unico RA_CODUNIC (Empresa + RA_FILIAL + RA_MAT + Data e hora da Integração)
<federalId>03024407049</federalId> CPF (RA_CIC)
<idCard>2020-01-01</idCard> R.G. (RA_RG)
<idCardDate>1900-01-01</idCardDate> D t.Emis.RG (RA_DTRGEXP) Se não for preenchido será enviado 1900-01-01
<idCardEmitter>SSP </idCardEmitter> Orgao expedR (RA_RGEXP)
<idCardState>SP </idCardState> UF do RG (RA_RGUF)
<image>BitMap da imagem do funcionário</image> Foto do Funcionário (RA_BITMAP)
<name>Funcionário Totvs </name> Nome do Funcionário (RA_NOME)
<neighborhood>CASA VERDE </neighborhood> Bairro (RA_BAIRRO)
<phone1>11111111 </phone1> Telefone (RA_TELEFON)
<phone2>911111111 </phone2> Num. Celular (RA_NUMCELU)
<phoneCode1>11</phoneCode1> DDD Telefone (RA_DDDFONE)
<phoneCode2>11</phoneCode2> DDD Celular (RA_DDDCELU)
<state>SP</state> Estado (RA_ESTADO)
<zipCode>02511000</zipCode> CEP (RA_CEP)
<sex>M</sex> Sexo (RA_SEXO)
<birthDate>1985-11-19</birthDate> Data Nasc. (RA_NASC)
</arg0>
</insertOrUpdate>
</soap:Body>
</soap:Envelope>
WSRHTSAUserIntegration <?xml version="1.0" encoding="UTF-8"?>
-<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
-<soap:Body>
-<insertUserShiftWork xmlns="http://user.tsa.totvs.com/">
-<arg0 xmlns="">
<endDate>2049-12-31T00:00:00</endDate> Data Demissão (RA_DEMISSA se RA_DEMISSA estiver vazia será enviado 2049-12-31)
<initialDate>2021-01-01T00:00:00</initialDate> Data Admissão (RA_ADMISSA)
<shiftWorkExternalKey>T1D MG 00101</shiftWorkExternalKey> Chave de identificação do turno (Empresa + Turno + Sequencia (Empresa + PF_FILIAL + PF_TURNOPA + PF_SEQUEPA))
<userExternalKey>T1D MG 01 000798</userExternalKey> Chave de identificação do funcionário (Empresa + RA_FILIAL + RA_MAT)
<InitialScaleBaseDate>2020-12-28T00:00:00</InitialScaleBaseDate> Primeiro dia da sequência e turno informado. Por exemplo a data de admissão do funcionário foi no dia 01/01/2021, esse dia é uma sexta-feria e a sequência 01 começa na segunda, então será enviada o dia 28/12/2020.
</arg0>
</insertUserShiftWork>
</soap:Body>
</soap:Envelope> |
|
...
