Rodrigo - Digibyte

Já enviei pro Isaque o componente AcbreSocial, é só questão dele disponibilizar, não sei quando vai fazer isso. Ele aproveita várias estruturas do nfe, sua estrutura de classes está definida e tem a parte de gerar o xml pronta. No momento está gerando rubricas e cargos e estou fazendo mais dois eventos (empresas e dados iniciais). O que precisa fazer: Seguindo o exemplo dos eventos que fiz fazer os outros (fácil mas chatinho); Implementar a parte de assinatura/transmissão lembrando que grande parte está pronta já que o acbresocial usa as classes/units da nfe e algumas outras ainda não estão definidas pela receita.

Certo, pode ser, de qualquer forma acho que o manual que está para ser lançado vai nos esclarecer melhor. Estou fazendo o componente TACBReSocial usando as units do acbr e seguindo o modelo da NFE. Está quase gerando o registro de de cargos (1030), até amanhã deve estar pronto já o componente instalável. Algumas coisas terão que ser alteradas e implementadas mas servirá de base para o resto, assim que estiver pronto aviso.

O que peguei do manual foi: Evento utilizado para inclusão, alteração e exclusã o de registros na tabela de RUBRICAS do empregador. As informações consolidadas desta tab ela são utilizadas para validação do evento de Remuneração dos trabalhadores. Para envio deste ev ento é necessário o envio prévio do evento de Informações Cadastrais do Contribuinte/Empregador Consequentemente se pode alterar e exluir creio que seja em um momento posterior aos dados iniciais, onde irão só as inclusões. Por exemplo, preenche o cadastro de eventos na carga inicial, dois meses depois é criada uma nova hora extra, manda o 1010 como inclusão desse evento.

Mas o S1010 - rubricas não vai fazer parte apenas dos eventos iniciais, se tiver alguma inclusão/alteração de rubrica ele deverá ser informado. Pelo menos foi isso que entendi. Então não sei se é conveniente herdar de TEventosIniciais Em relação ao ideEmpregador também pensei isso mas vi em algum lugar que a ideEmpregador tinha razão social e em outro não tinha (se não era ela era a de funcionário). Se achar no manual posto aqui.

Bom dia conversei com o Lucas e vou começar a ajudar a desenvolver o esocial, vou criar o componente ACBreSocial pra ver se conseguimos fazer o projeto andar, precisamos da colaboração de mais pessoas. Minha idéia inicial é usar o "esqueleto" do acbrnfe mas vou precisar de ajuda de quem já está mais ambientado com ele. Primeira pergunta: no nfe temos uma classe TNotasFiscais que logicamente implementa as notas fiscais. No eSocial existem vários arquivos, ex s1010(rubricas), s1020(lotações), s1030(cargos). Para seguir o padrão do nfe cada arquivo seria implementado em uma classe descendente de TACBrESocial assim como é TNotasFiscais de TAcbrNfe ? Por exemplo teríamos TAcbrESocial.Ts1010 , é correto isso ?

Assinar um outro xml qualquer (no cado do esocial), seria possível ?

Mas com o manual disponibilizado creio que já seria possível começar a montar o acbr esocial, eu posso ajudar bastante pois estou atualizado sobre o assunto, porém sinceramente, alguém com mais experiência no acbr teria que dar o ponta pé inicial.

Quais os primeiros passos, o que devemos fazer para dar inicio no projeto ?

Já utilizei o zebedee no passado, ele cumpre muito bem o que promete e dá uma grande diferença quando a questão é volume de dados. O maior problema do firebird na internet porém não é esse, é que ele fica comunicando entre o server e o client e isso tem um atraso muito grande. O zebede ataca um dos pontos, o volume de dados. Sua aplicação porém tem que trabalhar com o menor volume possível de dados trafegando e o menor número de consultas possível. Digamos, 10 consultas com "1Kb" de dados é muito mais lento do que uma com "20Kb", isso é acentuado no firebird.

É, não me expressei bem. Quero gerar um arquivo de crédito em conta corrente para pagamento de salário, nada a ver com cobrança. É utilizado o arquivo padrão cnab240 então pensei que talvez o acbr boleto possa gerar.

É possível usá-lo para gerar remessa de crédito em conta corrente ? Alguma dica ?

Pessoal, estou achando que as alterações efetuadas estão confusas, não documentadas, uma se sobrepondo a outra. Por exemplo, na unit ACBrEPCBLOCO_0_CLASS tem o seguinte trecho: with Reg0140.Registro0150.Items[intFor] do begin // Check(funChecaPAISIBGE(COD_PAIS), '(0-0150) %s-%s, o código do país "%s" digitado é inválido!', [COD_PART, NOME, COD_PAIS]); if Length(CNPJ) > 0 then Check(funChecaCNPJ(CNPJ), '(0-0150) %s-%s, o CNPJ "%s" digitado é inválido!', [COD_PART, NOME, CNPJ]); if Length(CPF) > 0 then Check(funChecaCPF(CPF), '(0-0150) %s-%s, o CPF "%s" digitado é inválido!', [COD_PART, NOME, CPF]); // Check(funChecaIE(IE, UF), '(0-0150) %s-%s, a Inscrição Estadual "%s" digitada é inválida!', [COD_PART, NOME, IE]); // Check(funChecaMUN(COD_MUN), '(0-0150) %s-%s, o código do município "%s" digitado é inválido!', [COD_PART, NOME, IntToStr(COD_MUN)]); Check(NOME <> '', '(0-0150) O nome do participante é obrigatório!'); Nele está comentado a função de checagem de município, coisa que não estava um tempo atrás. Não tem nada explicando o motivo, nem quem fez. Eu ia corrigir um erro que dava quando não era informado COD_MUN mas agora fico sem saber o que fazer.

Para o CST_PIS e CST_COFINS fiz uma alteração, e acho que já foi implementada no projeto, onde em vez de tipos é utilizado simplesmente string. Acho que dessa forma fica mais simples, não há necessidade de conversões, os dados podem ser aproveitados diretamente do banco de dados.

Alguma posição a respeito disso ?

O Isaque conseguiu "captar" extamente o que eu quiz dizer. Se decidirem mudar eu me proponho a fazer isso, é só avisar.

Boa tarde. Alguns dias atrás estava com uma dúvida em relação a utilização do acbr e foi respondida minha dúvida nesse link: viewtopic.php?f=12&t=2162 Hoje porém estou vendo que isto não é uma solução correta pra muitos casos. Por exemplo os campos CST_PIS e CST_COFINS não tem os códigos numerados a partir do zero em sequência (0, 1, 2, 3, etc) portanto se eu utilizar CST_COFINS := TAcbrSituacaoTribCofins(sp_c185.FieldByName('CST_COFINS').AsInteger) pra puxar o valor do baco de dados não vai funcionar. Quando o BD retornar "01" que é alíquota normal o acbr vai retornar "02" que é alíquota diferenciada. Perguntas: Por que criar um tipo específico (ex. TACBrSituacaoTribCOFINS) ao invés de simplesmente ler o valor que o banco de dados retorna? Não seria muito mais fácil? Qual a solução pra isso? Abrir cada classe a ser utilizada e fazer um "case" ou "if" gigante pra converter os valores em tipos do acbr? case CST_COFINS of stcofinsValorAliquotaNormal : strCST_COFINS := '01'; stcofinsValorAliquotaDiferenciada : strCST_COFINS := '02'; stcofinsQtdeAliquotaUnidade : strCST_COFINS := '03'; stcofinsMonofaticaAliquotaZero : strCST_COFINS := '04'; stcofinsValorAliquotaPorST : strCST_COFINS := '05'; stcofinsAliquotaZero : strCST_COFINS := '06'; stcofinsIsentaContribuicao : strCST_COFINS := '07'; stcofinsSemIncidenciaContribuicao : strCST_COFINS := '08'; stcofinsSuspensaoContribuicao : strCST_COFINS := '09'; stcofinsOutrasOperacoesSaida : strCST_COFINS := '49'; stcofinsOperCredExcRecTribMercInt : strCST_COFINS := '50'; stcofinsOperCredExcRecNaoTribMercInt : strCST_COFINS := '51'; stcofinsOperCredExcRecExportacao : strCST_COFINS := '52'; stcofinsOperCredRecTribNaoTribMercInt : strCST_COFINS := '53'; stcofinsOperCredRecTribMercIntEExportacao : strCST_COFINS := '54'; stcofinsOperCredRecNaoTribMercIntEExportacao : strCST_COFINS := '55'; stcofinsOperCredRecTribENaoTribMercIntEExportacao : strCST_COFINS := '56'; stcofinsCredPresAquiExcRecTribMercInt : strCST_COFINS := '60'; stcofinsCredPresAquiExcRecNaoTribMercInt : strCST_COFINS := '61'; stcofinsCredPresAquiExcExcRecExportacao : strCST_COFINS := '62'; stcofinsCredPresAquiRecTribNaoTribMercInt : strCST_COFINS := '63'; stcofinsCredPresAquiRecTribMercIntEExportacao : strCST_COFINS := '64'; stcofinsCredPresAquiRecNaoTribMercIntEExportacao : strCST_COFINS := '65'; stcofinsCredPresAquiRecTribENaoTribMercIntEExportacao : strCST_COFINS := '66'; stcofinsOutrasOperacoes_CredPresumido : strCST_COFINS := '67'; stcofinsOperAquiSemDirCredito : strCST_COFINS := '70'; stcofinsOperAquiComIsensao : strCST_COFINS := '71'; stcofinsOperAquiComSuspensao : strCST_COFINS := '72'; stcofinsOperAquiAliquotaZero : strCST_COFINS := '73'; stcofinsOperAqui_SemIncidenciaContribuicao : strCST_COFINS := '74'; stcofinsOperAquiPorST : strCST_COFINS := '75'; stcofinsOutrasOperacoesEntrada : strCST_COFINS := '98'; stcofinsOutrasOperacoes : strCST_COFINS := '99'; end;

O CFOP está declarado de forma diferente conforme abaixo: Nos registros c181/c185 o CFOP é string. Nos registros c191/c195 o CFOP é integer.

Aqui não estava gerando o registro M410, filho do 400. Comparei com o 800/810 e existe a diferença destacada abaixo, a não ser que seja por algum motivo específico creio que seja um erro. procedure TBloco_M.WriteRegistroM400(RegM001: TRegistroM001) ; var intFor : integer; strCST_PIS : AnsiString; begin if Assigned(RegM001.RegistroM400) then begin for intFor := 0 to RegM001.RegistroM400.Count - 1 do begin with RegM001.RegistroM400.Items[intFor] do begin case CST_PIS of stpisValorAliquotaNormal : strCST_PIS := '01'; stpisValorAliquotaDiferenciada : strCST_PIS := '02'; stpisQtdeAliquotaUnidade : strCST_PIS := '03'; stpisMonofaticaAliquotaZero : strCST_PIS := '04'; stpisValorAliquotaPorST : strCST_PIS := '05'; stpisAliquotaZero : strCST_PIS := '06'; stpisIsentaContribuicao : strCST_PIS := '07'; stpisSemIncidenciaContribuicao : strCST_PIS := '08'; stpisSuspensaoContribuicao : strCST_PIS := '09'; stpisOutrasOperacoesSaida : strCST_PIS := '49'; stpisOperCredExcRecTribMercInt : strCST_PIS := '50'; stpisOperCredExcRecNaoTribMercInt : strCST_PIS := '51'; stpisOperCredExcRecExportacao : strCST_PIS := '52'; stpisOperCredRecTribNaoTribMercInt : strCST_PIS := '53'; stpisOperCredRecTribMercIntEExportacao : strCST_PIS := '54'; stpisOperCredRecNaoTribMercIntEExportacao : strCST_PIS := '55'; stpisOperCredRecTribENaoTribMercIntEExportacao : strCST_PIS := '56'; stpisCredPresAquiExcRecTribMercInt : strCST_PIS := '60'; stpisCredPresAquiExcRecNaoTribMercInt : strCST_PIS := '61'; stpisCredPresAquiExcExcRecExportacao : strCST_PIS := '62'; stpisCredPresAquiRecTribNaoTribMercInt : strCST_PIS := '63'; stpisCredPresAquiRecTribMercIntEExportacao : strCST_PIS := '64'; stpisCredPresAquiRecNaoTribMercIntEExportacao : strCST_PIS := '65'; stpisCredPresAquiRecTribENaoTribMercIntEExportacao : strCST_PIS := '66'; stpisOutrasOperacoes_CredPresumido : strCST_PIS := '67'; stpisOperAquiSemDirCredito : strCST_PIS := '70'; stpisOperAquiComIsensao : strCST_PIS := '71'; stpisOperAquiComSuspensao : strCST_PIS := '72'; stpisOperAquiAliquotaZero : strCST_PIS := '73'; stpisOperAqui_SemIncidenciaContribuicao : strCST_PIS := '74'; stpisOperAquiPorST : strCST_PIS := '75'; stpisOutrasOperacoesEntrada : strCST_PIS := '98'; stpisOutrasOperacoes : strCST_PIS := '99'; end; Add( LFill('M400') + LFill( strCST_PIS ) + LFill( VL_TOT_REC,0,2 ) + LFill( COD_CTA ) + LFill( DESC_COMPL ) ) ; end; // Registros FILHOS WriteRegistroM410( RegM001.RegistroM400.Items[intFor] ); ********* faltavam as duas linhas acima destacadas em vermelho *********** /// RegistroM990.QTD_LIN_M := RegistroM990.QTD_LIN_M + 1; end; /// Variavél para armazenar a quantidade de registro do tipo. FRegistroM400Count := FRegistroM400Count + RegM001.RegistroM400.Count; end; end;

Quando instalei o demo também observei alguns erros. Agora está corrido mas assim que der um tempinho (alguns dias) e ninguém fizer mando um demo atualizado.

As áreas de sintegra, pis/cofins, fiscal, etc poderiam ser separadas

O meu gera vazio, será que seu acbr está atualizado?

Aqui gera normal, creio que os zeros estão retornando do seu banco de dados. Para quem é de fora informe em branco ( '' ).

Muito obrigado, isso mesmo que precisava, esqueçi que poderia usar o cast

Olá, estou começando a usar o AcbrPisCofins e surgiu uma dúvida a respeito de sua implementação no delphi. Por exemplo, o registro 0200, vejam meu código: with ACBrSPEDPisCofins1.Bloco_0.Registro0200New do begin COD_ITEM := sp_0200.FieldByName('COD_ITEM').AsString; DESCR_ITEM := sp_0200.FieldByName('DESCR_ITEM').AsString; TIPO_ITEM := sp_0200.FieldByName('TIPO_ITEM').AsString; end; Claro, a linha destacada retornou erro pois TIPO_ITEM não é TString, é TAcbrTipoItem. Consultando os fontes achei no código abaixo os valores válidos para TIPO_ITEM, então bastaria informar corretamente ( case TIPO_ITEM of tiMercadoriaRevenda : strTIPO_ITEM := '00'; tiMateriaPrima : strTIPO_ITEM := '01'; tiEmbalagem : strTIPO_ITEM := '02'; etc ) Minhas perguntas: Porque não é utilizado no componente o valor (em string por ex.) já definido no manual, não seria mais lógico e fácil? (apenas uma curiosidade sobre o funcionamento do Acbr) Terei que fazer um "case ao contrário" para converter as string retornada do banco de dados em TAcbrTipoItem, existe uma forma mais "inteligente" pra resolver essa questão? Isso aconteçe com vários outros tipos do Acbr... Obs: encontrei alguns erros no projeto de exemplo, vou atualizar o Acbr e se ainda estiverem lá espero contribuir com a correção.